Waktu berlalu, kan?

Karier saya dimulai pada 2012, dengan magang pertama di C ++. Jujur, saya tidak tahu apa yang saya lakukan (sebenarnya, tidak ada yang berubah). Namun, saya telah belajar beberapa pelajaran.

Penafian: Tidak akan ada kode dalam pesan ini.

Pertanyaan: Bahasa apa yang paling penting dalam pemrograman?

Ini bahasa Inggris. Atau Spanyol, Cina, Polandia. Siapa pun yang Anda gunakan untuk berkomunikasi dengan rekan kerja.

Berbicara dengan orang lain jauh lebih penting daripada berbicara dengan mobil.

Pemrograman adalah olahraga tim. Jarang ada produk yang brilian yang dibuat dari awal oleh satu orang ( CodeSandbox adalah contoh yang bagus, meskipun Ives baru-baru ini mempekerjakan beberapa karyawan), tetapi dalam sebagian besar kasus diperlukan sebuah tim.

Keterampilan komunikasi dapat menyelamatkan atau mengubur proyek. Jangan khawatir, masalahnya bukan hanya masalah Anda, bahkan NASA pun menderita karenanya .

Keahlian profesional dan komunikasi mungkin lebih penting untuk keberhasilan proyek daripada yang murni teknis. Siapa yang peduli bahwa Anda telah merekrut lima pakar basis data terbaik di dunia jika mereka menolak untuk berbicara satu sama lain, dan Anda berakhir dengan lima contoh berbeda MySQL, Aurora dan MongoDB.

Anda perlu memahami secara mendalam apa yang sedang Anda kembangkan dan mengapa

Kebanyakan orang menjadi lebih bahagia ketika mereka memiliki tujuan. Ini juga berlaku untuk pekerjaan.

Tujuan Anda sebagai pengembang bukan untuk menerjemahkan JIRA ke JavaScript, Trello ke C #, dll. Tujuan Anda adalah untuk menyelesaikan masalah .

Jika Anda memiliki pemahaman yang mendalam tentang sistem yang Anda bangun / pelihara, maka Anda dapat membuat keputusan di luar teknologi murni. Ajukan pertanyaan: apakah fitur ini bahkan diperlukan? Masalah apa yang dipecahkan? Bisakah kita memecahkan masalah ini secara berbeda? Kami ingin menyelesaikan masalah ini sejak awal?

Pemikiran seperti itu kadang-kadang disebut konteks bisnis, tetapi jika Anda ingin melakukan pekerjaan dengan baik, Anda tidak hanya perlu memahami konteksnya, tetapi juga dapat membentuk dan mempengaruhinya. Untuk mempengaruhi suatu produk, tidak perlu menempati posisi manajerial dalam suatu organisasi. Paling tidak, ini tidak perlu untuk memahami produk.

Jika tinjauan kode sangat menegangkan, maka hal itu sangat, sangat tidak terorganisir.

Ya Tuhan Verifikasi kode.

Kami benar-benar tidak memikirkannya, tetapi tindakan menerbitkan karya dengan studinya oleh beberapa orang lain agak unik untuk profesi kami. Tidak heran ini menyebabkan stres.

Saya pribadi melihat orang-orang mengirimkan ulasan kode secara khusus pada saat X tidak ada di kantor atau Y sedang dalam perjalanan bisnis. X adalah seorang programmer yang brilian, tetapi sulit untuk mempertahankan ulasan kodenya. Ratusan komentar pemilih di bawah permintaan junior pool sama sekali tidak membuktikan keunggulan Anda sebagai pengembang. Ini hanya membuktikan sifat buruk Anda.

OK, tapi apa yang harus saya lakukan ketika fungsi ini benar-benar rusak?

Bangun. Hubungi orang ini, bicara langsung . Bicaralah dengannya, cari tahu mengapa dia menerapkan kode dengan cara ini.

Kebanyakan orang tidak ingin menulis kode yang buruk. Dan jika mereka melakukannya, mereka mungkin berurusan dengan kendala yang tidak Anda sadari. Mereka mungkin juga tidak pandai pemrograman (belum), dan di sini Anda dapat membuktikan diri Anda sebagai seorang mentor.

Sesuatu HARUS salah, bersiap-siaplah

Menurut Wikipedia:

Hukum Murphy adalah pepatah atau epigram yang biasanya berbunyi: "Segala sesuatu yang bisa salah akan salah."

Ini adalah salah satu hal yang terlalu benar. Saat mendesain suatu sistem, selalu menganggap beberapa jenis kegagalan.

Jika Anda membuat formulir login, anggap orang akan menyalin dan menempelkan teks seluruh buku ke dalam bidang kata sandi.

Jika Anda membuat jendela WYSIWYG, misalkan seseorang mencoba untuk memecahkannya, dan kemungkinan akan dapat melakukannya.

Jika Anda memiliki database, itu akan terputus di beberapa titik. Jika Anda belum mencoba memulihkan database dari cadangan, ini bukan cadangan.

Jika Anda menyiapkan demonstrasi di depan audiens, pastikan demo berfungsi online, offline, terbalik, dan terendam air.

Jangan takut untuk mengatakan "Saya tidak tahu"

Hak istimewa paling menyenangkan dari judul "Senior" pada lencana adalah, akhirnya , kesempatan untuk menjawab:

Saya tidak tahu, saya belum pernah mencobanya. Aku akan melihat dan memanggilmu kembali.

Menjadi seorang junior, saya sangat takut: tiba-tiba seseorang akan menduga bahwa saya adalah seorang penipu. Setelah beberapa tahun sebagai pengembang - jika saya belum melihat sesuatu, mungkin itu masih belum muncul. Atau muncul teknologi keren lain yang perlu dieksplorasi. Pembelajaran seumur hidup bukanlah kata kunci, ini adalah kenyataan dalam TI.

Atau saya hanya penipu yang luar biasa yang berhasil menipu semua orang bahwa saya benar-benar dapat melakukan pekerjaan saya. Kamu tidak pernah tahu.

Belajar di depan umum

Segera setelah Anda beralih dari "Saya tidak tahu" ke "Ya, itu menarik" - bagikan dengan seseorang. Menulis blog, merekam video, berbicara di acara berbagi pengetahuan, atau hanya ... memberi tahu seseorang. Jika Anda berpikir ada sesuatu yang jelas bagi semua orang, ini tidak benar. Bahkan profesional terbaik pun memiliki sesuatu untuk dipelajari dari pemula, dan sebaliknya.

Mengajar adalah cara yang sangat efektif untuk memastikan bahwa Anda benar-benar memahami subjek yang dimaksud.

Seperti yang dikatakan orang pintar:

Ketika satu mengajar, dua belajar.

Pelajaran apa yang Anda pelajari sebagai pengembang?