7 kebiasaan programmer berkinerja tinggi

Pemrogram pemula menghabiskan banyak waktu untuk mendapatkan pengetahuan yang dibutuhkan untuk menyelesaikan wawancara. Mereka memecahkan masalah dan meningkatkan resume mereka. Tetapi bagian yang paling menarik dimulai setelah programmer menerima posisi yang diinginkan - di beberapa startup, di Google, di Amazon atau di tempat lain. Sering kali ternyata bahwa pengetahuan dan keterampilan yang membantu seseorang menemukan pekerjaan tidak sesuai dengan apa yang perlu Anda ketahui dan dapat melakukan tugasnya sehari-hari.



Penulis artikel, terjemahan yang kami terbitkan hari ini, mengatakan bahwa tim tempat ia bekerja terinspirasi oleh kisah TechLead tentang 7 kebiasaan programmer yang sangat efektif. Anggota tim memutuskan untuk mengekspresikan pemikiran mereka sendiri tentang masalah ini. Di sini, dalam bentuk kiat, memberikan analisis 7 keterampilan programmer yang efektif.

1. Belajar membaca kode orang lain



Semua orang kecuali Anda menulis kode yang buruk. Itulah sebabnya kemampuan seorang programmer untuk bekerja dengan kode orang lain adalah keterampilan yang berharga. Keterampilan ini memberi orang yang memilikinya banyak yang baik.

Programmer harus dapat memahami kode orang lain. Bagaimanapun, ini adalah pekerjaannya. Tidak masalah seberapa membingungkan kode tersebut atau seberapa buruk ditulisnya. Ngomong-ngomong, "kode orang lain" mungkin adalah apa yang ditulis oleh programmer sendiri, katakanlah, setahun yang lalu.

Keterampilan ini secara positif mempengaruhi programmer dalam dua cara. Pertama, kemampuan membaca kode orang lain memungkinkan untuk memahami cara kerja kode berkualitas buruk. Melihat melalui karya orang lain, Anda bisa mengetahui teknik mana yang pekerja dan mana yang tidak. Kedua, dan yang lebih penting, ini membantu untuk mengungkapkan kekhasan persepsi kode orang lain oleh orang lain, untuk mengetahui kode mana yang dirasakan dengan mudah dan mana yang sulit.

Jika Anda membaca kode orang lain dan menemukan sesuatu di dalamnya yang tidak Anda sukai, cobalah untuk tidak diam tentang hal itu. Ini akan meningkatkan kredibilitas Anda di mata kolega.

Perhatikan orang-orang yang bekerja dengan Anda, tentang betapa pentingnya menulis kode yang mudah dipelihara, tentang betapa pentingnya komentar yang baik. Ini akan semakin memperkuat status Anda di tim.

Kode Anda sendiri harus dirancang sedemikian tinggi sehingga akan jelas dan tanpa dokumentasi. Faktanya, programmer yang baik tidak perlu mendokumentasikan kodenya. Ini buang-buang waktu, waktu yang lebih baik dihabiskan untuk pemrograman dan rapat.

Kemampuan untuk memahami kode berkualitas rendah, antara lain, membantu dalam membuat perubahan pada kode tersebut. Terkadang ini berarti mengedit kode di mana seseorang tidak pandai melakukannya. Misalnya, suatu hari kami menemukan skrip yang melibatkan teknologi seperti PowerShell, Python, dan Perl. Di Perl, kami tidak mengerti dengan baik. Namun, kami berhasil memahami proyek dengan cukup dalam, berhasil memahami esensi dari apa yang terjadi dan membuat perubahan yang diperlukan pada kode. Ini menjadi mungkin karena fakta bahwa kami memahami kode yang perlu kami ubah, termasuk kode skrip Perl.

Kemampuan untuk memahami kode orang lain meningkatkan nilai programmer karena dia dapat memahami bagaimana bahkan sistem canggih diatur, sehingga ketika Anda melihatnya, orang lain hanya akan menyerah.

2. Mengembangkan bakat untuk proyek yang gagal


Ada banyak keterampilan yang perlu waktu untuk dikuasai. Salah satunya, yang, kami yakin, layak dikuasai, adalah untuk mengembangkan pemahaman tentang proyek mana yang tidak boleh Anda tangani dan proyek mana dengan tingkat probabilitas tinggi yang dapat menghasilkan "perlombaan untuk bertahan hidup".

Di perusahaan besar, selalu ada banyak proyek yang sedang dikerjakan programmer. Tetapi tidak semua proyek ini akan selesai. Tidak semuanya akan bermanfaat. Di antara mereka mungkin adalah mereka yang tidak memiliki makna komersial (setidaknya untuk programmer). Beberapa proyek, yang umumnya menjanjikan, mungkin menderita kekurangan manajerial. Ini tidak berarti bahwa Anda harus memberikan beberapa ide segera setelah Anda menyadari bahwa Anda tidak setuju dengan mereka yang menawarkannya. Namun, jika penulis ide tidak dapat menjelaskan dengan jelas manfaat apa yang dapat diberikan perusahaan untuk proyek setelah selesai, maka mungkin proyek semacam itu tidak layak untuk dimulai.

Selain itu, beberapa proyek mungkin terlalu berorientasi pada teknologi daripada menyelesaikan masalah tertentu. Ini kadang-kadang, bahkan pada awal pekerjaan, memungkinkan kita untuk memahami bahwa penyelesaian proyek semacam itu tidak akan membawa banyak manfaat.

Untuk mempelajari sekilas untuk mengenali proyek yang tidak menjanjikan, Anda harus mengambil bagian dalam banyak proyek semacam itu. Karena itu, jika Anda berada pada tahap awal karir seorang programmer, jangan menghabiskan terlalu banyak waktu untuk menilai prospek semua proyek yang sampai kepada Anda. Seiring waktu, Anda akan mengembangkan naluri batin, yang dipandu oleh mana Anda dapat dengan cepat mengenali proyek yang akan gagal.

3. Hindari pertemuan



Apa pun pekerjaan Anda, Anda tidak dapat melakukannya tanpa rapat. Ini berlaku untuk semua orang. Faktanya adalah bahwa Anda perlu menemukan bahasa yang sama dengan manajer proyek, pengguna, pelanggan. Namun, rapat memiliki satu fitur yang tidak menyenangkan: terkadang rapat tiba-tiba memakan waktu hampir sepanjang hari kerja. Itulah mengapa sangat penting untuk belajar menghindari pertemuan yang tidak perlu. Mungkin akan lebih baik untuk tidak "menghindari pertemuan," tetapi berusaha untuk "mengendalikan waktu yang dihabiskan untuk rapat." Tujuan dari ini adalah untuk menghabiskan waktu hanya pada pertemuan-pertemuan yang benar-benar diperlukan, pada mereka yang berkontribusi pada pengembangan proyek.

Metode manajemen waktu yang paling umum yang digunakan untuk rapat adalah mengalokasikan blok dua jam setiap hari, yang berubah menjadi pertemuan berkelanjutan. Banyak yang mengadakan pertemuan berulang untuk waktu yang mereka anggap paling tepat. Pertemuan ini digunakan untuk membahas masalah pekerjaan.

Cara lain untuk mengatur waktu adalah datang bekerja lebih awal daripada yang lain untuk mengelola bisnis Anda. Sebagai contoh, kami lebih suka melakukan hal itu. Dan omong-omong, jika Anda datang ke kantor lebih awal, akan jauh lebih tenang untuk bekerja di sana daripada biasanya. Kebanyakan orang datang lebih awal adalah sama. Mereka melakukan ini untuk memiliki waktu untuk mengatasi pekerjaan mereka. Karena itu, mereka tidak mengganggu pekerjaan orang lain.

Dalam kasus kami, ini penting untuk anggota tim individu. Faktanya adalah bahwa pekerjaan kami membutuhkan waktu untuk berkonsentrasi penuh pada tugas tertentu. Saat ini, kami tidak berkomunikasi dengan siapa pun. Tentu saja, ada beberapa situasi ketika, untuk menyelesaikan masalah, Anda perlu mendiskusikannya dengan seseorang dan bekerja bersama. Tetapi setelah semua pertanyaan diselesaikan, pengembang hanya perlu menulis kode. Secara umum, kita berbicara tentang masuk ke zona nyaman tertentu di mana programmer dapat selalu mengingat segala sesuatu yang berhubungan dengan tugas yang sedang dia selesaikan. Jika dia terus-menerus terganggu, dia mungkin mengalami kesulitan untuk kembali dengan cepat ke apa yang dia pikirkan.

4. Master GitHub



Ketika Anda melihat beberapa programmer kelas atas, Anda merasa bahwa mereka mulai menggunakan GitHub pada hari pertama kehidupan mereka. Mereka memahami arti dari setiap perintah dan parameter, mereka dengan mudah mengatasi urusan mereka.

Tetapi yang lain pertama kali menemukan GitHub di pekerjaan pertama mereka. Bagi mereka, GitHub adalah neraka nyata, dibangun dari tim yang tidak jelas dan proses misterius. Mereka tidak pernah benar-benar yakin dengan apa yang mereka lakukan. Itulah sebabnya semua jenis "lembar contekan" di GitHub sangat populer.

Hal di atas berlaku untuk sistem kontrol versi apa pun. Jika digunakan dengan benar, itu sangat berguna. Jika Anda salah menggunakannya, itu sangat mengganggu pekerjaan. PR sederhana atau komit dapat dengan mudah berubah menjadi mimpi buruk yang membutuhkan programmer beberapa jam. Waktu ini akan dihabiskan untuk mengurai seluk-beluk cabang dan garpu. Selain itu, jika Anda secara teratur lupa mengunduh versi repositori terbaru ke mesin Anda, Anda dapat terus-menerus menangani konflik gabungan. Tidak ada yang baik tentang itu.

Jika Anda membutuhkan "cheat sheet" di GitHub - lakukanlah.

Pelajari cara bekerja secara produktif dengan GitHub. Dalam hal ini, tidak masalah seberapa tepatnya Anda mencapai ini.

5. Tulis kode sederhana yang mudah dipelihara



Beberapa programmer pemula memiliki sifat berikut: mereka mencoba, dalam satu proyek, untuk mewujudkan semua yang mereka tahu. Intinya di sini adalah bahwa mereka berusaha untuk menggunakan pengetahuan mereka tentang pemrograman berorientasi objek, struktur data, pola desain, dan teknologi baru di setiap bagian kode yang mereka buat. Ini tidak perlu mempersulit kode karena fakta bahwa dengan pendekatan ini, tugas programmer dapat dengan mudah dipengaruhi oleh, misalnya, pola-pola desain yang telah dia terapkan dalam praktek.

Ada keseimbangan antara struktur proyek yang terlalu rumit dan kode sederhana. Pola desain dan pemrograman berorientasi objek dirancang untuk menyederhanakan kode dalam proyek skala besar. Namun, semakin kita menggunakan abstrak dan enkapsulasi, semakin "kotak hitam" dalam solusi kami, semakin sulit untuk men-debug kode untuk solusi tersebut.

6. Belajarlah untuk mengatakan tidak dan memprioritaskan


Rekomendasi ini, pada kenyataannya, dapat diberikan kepada siapa saja - setidaknya seorang analis keuangan, setidaknya seorang programmer. Tetapi dapat dicatat bahwa ada perasaan bahwa setiap orang menginginkan sesuatu yang istimewa dari teknisi. Misalnya, jika Anda seorang insinyur analisis data, maka Anda mungkin ditawari tugas yang jauh lebih luas dari apa yang seharusnya Anda lakukan. Beberapa tim membutuhkan semacam sampel data, yang lain membutuhkan data ringkasan, dan yang lain membutuhkan saluran pipa baru.

Perlu dicatat bahwa kemampuan untuk memprioritaskan dan kemampuan untuk mengatakan tidak sebenarnya dapat menjadi dua keterampilan yang terpisah. Namun, keterampilan ini sangat terkait erat satu sama lain. Di mana ada kebutuhan untuk salah satunya, yang kedua biasanya diperlukan. Prioritas adalah ketika waktu dihabiskan hanya pada apa yang berdampak serius pada perusahaan. Dan kemampuan untuk mengatakan tidak adalah penolakan untuk melakukan pekerjaan yang seharusnya dilakukan orang lain.

Mempelajari apa yang kita bicarakan mungkin sulit, karena orang sering berusaha untuk menyelesaikan setiap masalah yang mereka atur. Ini terutama berlaku bagi mereka yang baru saja belajar dan mendapatkan pekerjaan pertama mereka. Sebelumnya, dalam studi mereka, mereka diberi tugas yang mereka tangani dengan baik. Sekarang, di tempat kerja, mereka mengharapkan hal yang sama dan berusaha untuk tidak mengecewakan siapa pun.

Di sini Anda perlu memahami bahwa di perusahaan besar ada banyak sekali tugas. Yang paling penting adalah hanya mengambil tugas-tugas yang dapat diselesaikan.

Ada banyak keterampilan yang tidak diuji dalam sebuah wawancara. Mereka jarang tersedia di sekolah. Seringkali situasi ini muncul hanya karena karakteristik lingkungan belajar, dan bukan karena seseorang tidak ingin menunjukkan kepada siswa tugas nyata yang mungkin mereka hadapi dalam kenyataan.

7. Belajarlah untuk berpikir tentang bagaimana perkembangan Anda akan digunakan.



Ada satu keterampilan yang sulit untuk mengatur tes selama wawancara. Situasi di mana diperlukan sulit untuk mereproduksi saat belajar. Ini adalah tentang kemampuan untuk melihat kesalahan yang dapat dilakukan pengguna akhir suatu sistem perangkat lunak. Kami biasanya menyebutnya "memikirkan kasus penggunaan program."

Sebenarnya, "pemikiran skenario" ini hanyalah nama yang agak lunak untuk apa yang disebut "perlindungan dari orang bodoh".

Misalnya, karena sebagian besar tugas programmer adalah mendukung kode, ia sering kali harus mengubah kode, yang terkait erat dengan sesuatu yang lain. Bahkan perubahan sederhana dari sesuatu memerlukan pencarian untuk semua tempat di mana ia digunakan. Misalnya, objek, metode, API dari sistem tertentu dapat berubah. Jika Anda membuat perubahan yang tidak masuk akal pada sistem, itu dapat "merusak" bagian-bagian program yang sama sekali tidak terduga. Selain itu, kita berbicara tentang perubahan skala apa pun - bahkan sesuatu seperti perubahan tipe dalam database.

Keahlian ini juga mencakup kemampuan untuk menemukan dan menganalisis situasi batas yang mungkin timbul ketika bekerja dengan sistem. Ini juga mencakup kemampuan untuk memahami skema keputusan tingkat tinggi pada tahap desain.

Ini juga berlaku untuk pengembangan bagian sistem yang lebih besar, seperti modul atau layanan mikro. Saat mulai menyelesaikan masalah seperti itu, Anda perlu memikirkan bagaimana tepatnya entitas yang Anda rencanakan untuk dibuat akan digunakan. Anda perlu memikirkan tentang skenario penyalahgunaan mereka, tentang berbagai opsi untuk penggunaannya, dan apa yang Anda buat dapat digunakan sepenuhnya tanpa terlihat pada pandangan pertama.

Proses penulisan kode hanyalah bagian dari tugas menyelesaikan masalah tertentu. Sangat mudah untuk membuat program yang berfungsi dengan baik di komputer Anda. Tetapi kode yang digunakan orang lain dengan mudah dapat berperilaku sangat berbeda dari yang diharapkan. Bagaimana kode yang Anda tulis akan digunakan dalam produksi? Dengan sistem apa dia harus berinteraksi? Proses apa yang bisa menjadi bagian darinya? Tidakkah ia tampak terlalu primitif dan terbatas pada seorang programmer yang harus mendukungnya setelah beberapa tahun? Ini adalah pertanyaan yang sangat sulit.

Ringkasan


Dalam artikel ini, kami memberi Anda gambaran tentang 7 keterampilan yang umum bagi programmer berkinerja tinggi. Kami berharap Anda telah menemukan di antara mereka yang ingin Anda kembangkan sendiri.

Pembaca yang budiman! Apa yang Anda sarankan untuk dikuasai untuk seseorang yang berusaha untuk profesionalisme dalam pemrograman?

Source: https://habr.com/ru/post/id457382/


All Articles