Saran untuk Developer Perangkat Lunak Pemula yang Sudah Membaca Semua Esai Saran Lainnya
(buttondown.email)- Di awal karier, bahkan saran dari developer terkenal sebaiknya tidak diikuti mentah-mentah; pertimbangkan dulu apakah sesuai dengan situasi Anda, karena banyak klaim di bidang perangkat lunak tidak memiliki dasar yang pasti
- Ide yang menarik boleh dicoba sendiri, tetapi selama tidak mengganggu rekan kerja, mengalami trial and error adalah bagian dari proses belajar
Debugging: The 9 Rulesdirekomendasikan sebagai buku pengantar yang mudah dibaca tentang kemampuan debugging, topik yang sering dilewatkan oleh buku-buku untuk pemula- “Cara yang benar” atau “best practice” sering kali lahir dari kasus kegagalan tertentu dan jalur historis tertentu, jadi penting membedakan teknik itu sendiri dari cara penyebarannya
- Dengan mencoba fitur tersembunyi pada tool, memahami pekerjaan departemen lain, dan menjajal berbagai jenis pemrograman sejak awal, Anda akan lebih mudah menemukan pekerjaan software yang cocok untuk diri sendiri
Sikap dalam menerima saran
- Saran developer yang banyak dibaca sering menyebar bukan karena penulisnya programmer hebat, melainkan karena mereka pandai menulis
- Tidak perlu otomatis menolak semua saran, tetapi perlu mempertimbangkan dengan cermat bagaimana saran itu berlaku untuk situasi Anda
- Klaim tentang “kebenaran objektif” dalam software perlu diterima dengan hati-hati; tidak banyak hal yang sudah diteliti secara ilmiah, dan hasil risetnya pun umumnya tidak menghasilkan kesimpulan yang tegas
- Tidak perlu terlalu khawatir akan mempelajari “hal yang salah”
- Jika Anda menyukai ide seseorang, Anda bisa mencobanya sendiri
- Selama tidak secara aktif mengganggu rekan kerja, meskipun nanti Anda menengok ke belakang dan merasa seharusnya melakukannya dengan cara berbeda, pada akhirnya itu tetap bisa menjadi pembelajaran
- Debugging: The 9 Rules adalah buku yang direkomendasikan untuk developer pemula
- Mudah dibaca dan membahas keterampilan penting bernama debugging, yang hampir tidak dibahas oleh buku-buku “programmer pemula” lainnya
- Anda juga bisa meminjamnya dari perpustakaan atau meminta perusahaan membelinya
Batasan “cara yang benar” dan best practice
- Pada suatu titik, Anda mungkin menemukan “Right Way” dalam pemrograman dan yakin bahwa bidang ini akan menjadi lebih baik jika semua orang mengikuti cara tersebut
- Contohnya termasuk test-driven development, pemrograman fungsional, Lisp, dan formal methods
- Sulit menghindari jatuh cinta pada cara seperti itu, dan pengalaman itu bisa terasa menyenangkan, tetapi penting untuk tidak menjadikan identitas Anda sebagai “Right Way Guy”
- Seiring waktu, Anda akan belajar bahwa apa pun metodenya, pemrograman tetap bisa terasa menyebalkan dan berantakan, dan software yang hebat tetap bisa dibuat tanpa memakai metode tersebut
- Setelah mengenal berbagai “Right Way”, Anda bisa mencampur dan menyesuaikannya dengan masalah yang dihadapi
- “Right Way” pertama yang Anda temui kemungkinan besar datang dari seseorang yang benar-benar terobsesi dengan cara tersebut
- Kelak, sebaiknya jangan terlalu menyalahkan orang itu, dan jangan mencampuradukkan teknik sebenarnya dengan cara orang itu mempromosikannya
- Banyak ide perlu dimodifikasi sampai tingkat tertentu agar bisa dipakai bersama ide lain, bukan hanya dalam bentuk murninya
- Seperti kata Julia Evans, “di balik setiap best practice ada cerita horor”
- Jika ada best practice yang tidak Anda pahami, Anda bisa mencari kasus kegagalan yang melahirkannya
- Jika kasus kegagalan itu tidak relevan dengan situasi Anda, tidak apa-apa memilih cara lain
- Banyak best practice dan konvensi bersifat bergantung pada jalur historis
- Sebuah praktik mungkin diikuti karena mentor Anda melakukannya, dan mentor itu juga mengikutinya karena mentor sebelumnya melakukannya
- Cara yang muncul untuk menyelesaikan masalah masa lalu mungkin kini sudah kurang relevan
- Konvensi yang terdengar seperti penjelasan setelah kejadian bisa jadi memang demikian, dan jika ditelusuri, proses terbentuknya bisa dipahami kembali
Cara memperluas intuisi praktik kerja
- Berjalan kaki disarankan sebagai kebiasaan yang membantu merapikan pikiran
- Tool yang Anda gunakan biasanya memiliki kedalaman tersembunyi
- Anda tidak perlu menguasai bahasa pemrograman, Git, JIRA, dan tool lain sampai level ahli
- Namun, disarankan meluangkan sekitar 5–10 menit untuk mencari tahu apa lagi yang bisa dilakukan tool tersebut
- Berbicara dengan orang dari departemen lain di dalam perusahaan akan memperluas pemahaman Anda tentang pekerjaan
- Anda bisa berbicara dengan tim support, domain bisnis, sales, dan lainnya
- Jika punya waktu dan mudah untuk meminta izin, mengikuti pekerjaan mereka juga disarankan
- Di awal karier, sebaiknya alami berbagai jenis pemrograman jika memungkinkan
- Ini tidak harus berarti pindah kerja; sebagian besar perusahaan melakukan beberapa jenis pemrograman sekaligus
- Di perusahaan pengembangan web, Anda bisa mencoba frontend, backend, operasi, pekerjaan database, dan lainnya
- Ini membantu pembelajaran, tetapi yang lebih penting, meningkatkan peluang Anda menemukan pekerjaan software yang benar-benar Anda sukai
- Ada contoh pribadi: saat pekerjaan pertama di frontend terasa berat, tetapi setelah pindah ke backend, ia menjadi lebih bahagia
- Karena bidang software terus berubah, ada alasan di balik saran untuk tidak terseret tren framework dan fokus pada kemampuan dasar
- Karena internet, open source, konferensi, dan lainnya, informasi di bidang software menyebar sangat cepat
- Hambatan untuk berbagi ide rendah, sehingga bahkan proyek pribadi yang hanya dipakai satu orang bisa tampak seolah diketahui banyak orang
- Banyak teknologi yang Anda dengar mungkin memiliki basis pengguna kecil dan tidak diadopsi secara luas
- Jika minat Anda kuat, tidak apa-apa menjadi early adopter, tetapi jika tidak, tidak masalah menunggu beberapa tahun untuk melihat apakah teknologi itu benar-benar bertahan
- Tidak ada yang bisa memprediksi masa depan, dan masa kini pun merupakan hasil yang dulu sulit diprediksi
- Lakukan yang terbaik yang Anda bisa, hiduplah sesuai nilai-nilai Anda, dan nikmati prosesnya
1 komentar
Komentar Hacker News
Baru-baru ini, dalam sebuah proyek hobi, saya bekerja dengan seorang junior dan satu developer yang tidak terlalu junior, dan keduanya tipe yang terobsesi dengan “cara yang benar”.
Untuk bot Discord + kode Rust sekitar 300 baris yang saat ini hanya akan kami jalankan sendiri, mereka menuntut dokumentasi lengkap, VM terpisah untuk QA dan “operasi”, deployment systemd, sistem templat untuk beberapa string, sampai lapisan ORM untuk empat query SQL.
Proyek itu paling banyak akan dipakai sekitar 10 orang, itu pun baru separuh dari requirement rilis “0.3”, dan karena mereka sudah merencanakan desain yang makin berlebihan ke depannya, saya akhirnya mundur dari proyek tersebut.
Di awal-awal belajar pemrograman, saya juga pernah jadi orang seperti itu selama beberapa tahun, tetapi saya belajar bahwa selain praktik terbaik atau gaya kode, ada hal-hal yang jauh lebih dalam dalam ilmu komputer, dan pada akhirnya yang penting adalah kode yang berjalan.
Maksudnya, perhatian yang tidak proporsional dicurahkan ke detail-detail remeh dibanding masalah inti; ada analogi tentang komite persetujuan pembangkit nuklir yang justru mengesampingkan pembangkitnya dan hanya membahas warna gudang sepeda di sebelahnya.
Dalam kasus ini juga, berfokus pada pemisahan VM QA/operasi, deployment systemd, templat untuk beberapa string, dan ORM untuk beberapa SQL pada proyek berskala 10 pengguna terlihat seperti contoh klasik hukum trivialitas.
Bagian-bagian seperti ini khususnya lebih mudah dipahami dan diperdebatkan oleh developer junior, sehingga mereka cenderung lebih banyak ikut campur, sementara fitur inti yang sulit justru mudah terabaikan.
Namun, menurut saya mendokumentasikan bagian-bagian proyek yang memang bermakna dengan benar bukanlah bentuk terlalu terobsesi pada hal sepele.
Hal-hal seperti menulis unit systemd atau memakai ORM tidak memakan waktu sebanyak yang dibayangkan, tetapi cukup membantu nantinya ketika seseorang perlu melihat-lihat proyek itu atau orang lain ingin berkontribusi.
Lebih mudah melakukannya saat konteksnya masih ada di kepala, dan setelah proyek membesar, pekerjaan remeh seperti ini hampir tidak pernah dibereskan.
Karena ini proyek hobi, mungkin justru mereka ingin mengerjakannya dengan benar sambil mempelajari alat dan mendapat kepuasan.
Di bagian awal ada adegan mereka harus membeli router seharga $50; ketika salah satu tokoh mengusulkan untuk mencoba memperbaiki router yang ada, tokoh-tokoh lain menjawab “sudah dicoba” nyaris sebelum kalimatnya selesai.
Itu menunjukkan bahwa mereka saling mengenal begitu baik dan menghabiskan begitu banyak waktu bersama sampai hampir seperti bisa membaca pikiran.
Namun ketika seseorang mengatakan “yes” untuk pembelian router baru, orang lain menjawab bahwa yang dibutuhkan adalah “aye”.
Artinya aturan kata yang harus dipakai dalam voting keputusan usaha sampingan itu sangat ketat; tidak penting apakah mereka cukup dekat untuk menyelesaikan kalimat satu sama lain, apakah itu router $50, atau apakah pemasukan usaha sampingan itu remeh.
Aturannya menuntut aye.
Sebagian orang yang terobsesi dengan “cara yang benar” tampak seperti orang-orang yang berhasil dengan menyalin pengetahuan yang tersimpan dalam kecerdasan kolektif sosial, tetapi tidak benar-benar tahu apa yang terjadi di dalam kepala mereka sendiri.
Ada keuntungan karena bisa mewarisi metodologi yang sudah teruji tanpa harus menemukannya sendiri dengan susah payah, tetapi ada juga kelemahan karena mereka secara harfiah tidak memahami situasi ketika cara itu akan berujung pada kegagalan.
Dalam komentar sutradara, dikatakan bahwa adegan ini sengaja ditempatkan untuk menunjukkan bahwa sebagian tokoh menganggap aturan terlalu serius, sementara sebagian lainnya tidak cukup serius.
Alasan orang menganjurkan praktik bergaya kultus kargo seperti ini kepada orang lain juga tampak serupa. Semakin banyak orang mengikutinya, semakin besar kemungkinan bahwa ketika praktik itu gagal secara katastrofis, orang yang gagal bukan dirinya sendiri.
Belakangan saya terlalu sering melihat kasus seperti ini, dan saya menyebut orang-orang seperti ini junior yang pintar. Tidak peduli pengalamannya 1 tahun atau 20 tahun.
Junior yang pintar tahu sebagian besar design pattern dan sudah membaca Mythical Man-Month, tetapi karena ingin mencoba teknologi, bahasa, atau framework baru, mereka berlari-lari membawa palu baru yang mengilap sambil mencari sesuatu yang tampak seperti paku.
Lalu mereka membuat keputusan aneh karena tidak memahami kekuatan yang bisa diberikan oleh database lama yang sudah dioptimalkan dengan baik.
Dengan pengalaman 20 tahun, saya sudah sering melihat bagaimana proyek seperti itu berakhir 5–10 tahun kemudian ketika lebih dari separuh tim aslinya sudah pergi; saya mempertahankan bagian yang benar-benar bernilai dan memotong separuh yang tidak berguna.
Kita tidak mengelola taman kanak-kanak developer yang ingin bersenang-senang dengan segala cara, melainkan bekerja untuk bisnis yang membayar dan mengharapkan hasil yang stabil serta relatif cepat.
Mencoba hal baru demi teknologi mutakhir atau demi menghindari kebosanan lebih sering merusak daripada memperbaiki dalam jangka panjang.
Kita harus mengadopsi teknologi yang bisa dipahami dan dikuasai oleh seluruh tim, bukan memasukkan teknologi yang hanya diketahui satu superstar yang sedang bosan.
Kalau ingin menjejalkan banyak item teknologi ke resume, lakukan saja di perusahaan semacam itu, dan tempat seperti itu juga punya sisi baiknya sendiri.
Namun, orang-orang seperti ini sering kali toh tidak bertahan lama, jadi nilai tambah keseluruhannya juga patut dipertanyakan. Bagi sebagian orang ini mungkin membosankan, tetapi saya menyebutnya cara yang terampil.
Jika tujuan side project adalah membuat perusahaan melihat GitHub saya, itu juga bisa terlihat lebih meyakinkan.
Dokumentasi sangat penting. Saya punya beberapa proyek yang cukup sederhana, di bawah 300 baris, termasuk bot dan web scraper, tetapi karena tidak didokumentasikan, sekarang saya tidak bisa menjalankannya.
Raspberry Pi yang menjalankannya mati, dan saya buntu soal cara memperbaiki framebuffer virtual headless, serta cara men-debug error tidak jelas yang hasil pencariannya tidak memberikan jawaban berguna.
Kalau saja saya mengontainerkannya atau setidaknya mendokumentasikan prosedur setup-nya, masalah seperti ini tidak akan terjadi.
Ini tulisan yang bagus dan saya berharap lebih banyak orang membacanya
Setelah 15 tahun bekerja di software, khususnya bidang manajemen data, saya mempelajari hal yang persis ini
Kesamutti Sutta yang saya pelajari dari latar belakang Buddhisme Theravada juga sangat membantu
Isinya adalah jangan begitu saja mengikuti sesuatu hanya karena sudah sering mendengarnya, karena tradisi, karena kabar burung, karena tertulis dalam kitab suci, karena dugaan atau aksioma atau logika yang terdengar masuk akal, karena bias terhadap gagasan yang sudah lama dipikirkan, karena seseorang terlihat kompeten, atau karena itu ucapan guru
Nasihat untuk menerimanya ketika kita sendiri tahu bahwa “ini baik, tidak tercela, dipuji oleh orang bijak, dan jika dipraktikkan akan membawa manfaat dan kebahagiaan” sangat berguna dalam hidup saya, bahkan setelah saya menjadi ateis sejak SMP
Ada juga klaim bahwa seseorang memelintir terjemahannya agar terlihat memiliki makna yang lebih rasionalis
Kalau benar, itu disayangkan. Karena saya ingin percaya bahwa Buddha adalah orang yang “tercerahkan” seperti ini
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
Saya setuju dengan bagian yang mengatakan jangan terlalu khawatir bahwa kita “tertipu” atau “mempelajari sesuatu yang salah”
Apakah saya mempelajari TDD saat sedang populer? Ya. Apakah saya memakai TDD sekarang? Tidak. Tapi apakah TDD mengajari saya cara menulis kode yang lebih baik? Ya
Hal yang sama berlaku untuk bahasa-bahasa yang tidak lagi saya gunakan secara profesional. Semuanya mengajarkan sesuatu
Kita tidak bisa menemukan titik tengah yang baik tanpa sedikit melewati batas di kedua sisi
Jika kode sudah ada dan kita ingin memperluasnya, masuk akal untuk menulis beberapa test di sekitar cara penggunaannya
Jika kodenya belum ada tetapi strukturnya sudah ada di kepala, dan kita bisa memisahkan bagian yang dapat dibuat dan dites terlebih dahulu, itu juga masuk akal
Itu bukan TDD dalam arti murni, lebih dekat ke pengembangan berbantuan test, tetapi tetap memanfaatkan semangat TDD
Mempelajari hal yang buruk juga merupakan bagian besar dari memahami pendekatan mana yang lebih baik atau lebih buruk
Bukan berarti TDD itu sendiri buruk, tetapi jika terlalu terobsesi, itu bisa menjadi buruk
Pada akhirnya ini juga bersinggungan dengan pandangan umum bahwa “kesalahan adalah jalan untuk belajar”
Panduan dan prinsip semacam ini umumnya baik untuk diketahui, tetapi masalah muncul ketika orang menerimanya seperti agama
Para ideolog di industri kita benar-benar merepotkan
Singkat, pas, dan langsung terasa mengena
Tulisan dan nasihat yang bagus
Pada akhirnya, setelah masa bulan madu selesai, kita belajar bahwa apa pun “cara yang benar” yang dipakai, programming tetap membuat frustrasi dan berantakan, dan kita tetap bisa membuat software hebat tanpa mengikuti cara itu
Seiring waktu, kita akan mempelajari puluhan “cara yang benar” lainnya dan mencampurnya sesuai masalah yang dihadapi
Namun dalam beberapa tahun terakhir, sepertinya banyak developer terjebak dalam obsesi pada cara yang benar sehingga tidak memperluas pengetahuan dan perspektif mereka
Jika itu benar, itu menyedihkan, dan saya tidak yakin apa penyebabnya
Mungkin karena rentang perhatian yang makin pendek saat ini membuat sulit memperluas pengetahuan secara efisien, dan posisi sekarang terasa terlalu nyaman
Atau mungkin karena imbalan untuk hanya mempelajari framework tertentu terlalu besar, sementara insentif untuk mempelajari pengetahuan dasar tentang cara kerjanya di dalam terlalu kecil
Jadi mereka tidak punya waktu untuk memetik pelajaran dari pekerjaan saat ini, dan besar kemungkinan mereka sudah pergi ketika pelajaran itu akhirnya terasa
Pada saat yang sama, mereka juga tidak punya keleluasaan untuk tidak berfokus pada teknologi tren terbaru
Arus seperti ini sangat menghambat pertumbuhan
Nasihat 1 sen dari saya adalah ini. State adalah musuh. Kurangi state di mana pun memungkinkan
Ini mencakup bukan hanya state di dalam kode, tetapi juga jumlah hal yang harus disimpan dalam memori jangka pendek untuk bekerja, sampai detail-detail khusus proyek yang harus diingat
State adalah musuh. Jika sesuatu bisa diturunkan dari prinsip pertama, kita harus selalu berusaha melakukannya begitu
Sebagian dari ini melampaui nasihat khusus untuk programmer
Poin pertama layak direnungkan oleh semua orang. Banyak penulis dan esais dibaca bukan karena mereka ahli di topik tersebut, melainkan karena mereka menulis dengan baik
Kita juga perlu berjalan-jalan
Sebaiknya mencoba berbagai jenis pekerjaan, dan mempelajari peran lain di dalam perusahaan
Terutama di perusahaan besar, pekerjaan yang kita lakukan mungkin merupakan sesuatu yang di tempat lain harus diperbaiki lagi atau diakali, dan jika kita mengubahnya, semuanya bisa menjadi lebih mudah bagi semua orang
Poin pertama juga menjadi alasan mengapa kita perlu meragukan hal-hal yang dipelajari dari layanan berbagi video seperti YouTube
Jika seseorang berbicara dengan meyakinkan dan menyajikan ide secara profesional, orang akan menanggapinya serius meskipun ide itu cacat
Di dunia tempat sebagian “esais” ternyata pada dasarnya hanya membacakan artikel Wikipedia dan posting Reddit, kita perlu bersikap untuk memisahkan kesan meyakinkan dalam penyampaian dari akurasi
Saya juga ingin memperluas poin nomor 10. Jika kita berbicara dengan orang-orang terkait, kita bisa melihat lebih jelas masalah apa yang ingin diselesaikan oleh software atau pekerjaan pengembangan, dan menemukan titik-titik sakit yang sebelumnya tidak kita lihat sendiri
Dengan sangat sedikit pengecualian, software tidak ditulis demi software itu sendiri, melainkan untuk menyelesaikan masalah
Di suatu tempat di internet atau dalam proses pelatihan, ia bisa membaca jawaban yang “benar”, lalu mengulanginya dengan meyakinkan tanpa mempertimbangkan apakah itu benar secara nyata
Saya sangat menyukai buku debugging yang direkomendasikan dalam tulisan itu sampai membeli beberapa eksemplar dan membagikannya
Saya memberikannya kepada teman, intern, data scientist, bahkan eksekutif, dan semua orang yang membacanya berterima kasih
Buku itu berisi beberapa teknik sederhana yang bagus untuk memecahkan masalah pada sistem teknis besar, sehingga berguna bagi hampir siapa saja
Mudah dibaca dan menarik, dengan banyak “cerita perang” yang memberi warna dan konteks pada nasihat yang kalau tidak bisa terasa kering
https://debuggingrules.com/
Pernyataan “orang mendengarkan saya bukan karena saya programmer yang baik, melainkan karena saya penulis yang baik” tidak hanya berarti kita perlu waspada saat membaca tulisan dari penulis yang baik, tetapi juga berlaku pada cara kita mendekati pekerjaan kita
Jika pandai menulis, kemampuan menghadapi orang lain umumnya juga membaik
Bagi pengembang perangkat lunak, menulis dan berkomunikasi adalah pekerjaan inti
Jika masih pemula, disarankan mencoba menuliskan kesulitan yang dialami, eksperimen, dan proses berpikir
Jika memungkinkan, tulislah juga esai. Itu akan menjadi keterampilan yang sangat berguna di tahap akhir karier
Ada satu kalimat yang sulit dijelaskan dengan tepat kepada pemula: “pekerjaan Anda bukanlah menulis kode”
Kita menggunakan kode sebagai alat untuk memecahkan masalah
Kode adalah sarana untuk mencapai tujuan, bukan tujuan itu sendiri
Jika coding demi kode itu sendiri, hasilnya akan keliru
Kita harus berfokus pada pemecahan masalah, dan jika tidak yakin masalah apa yang dipecahkan oleh kode kita, berhentilah coding dan cari tahu itu terlebih dahulu
Tergantung perusahaan, bisa juga email
Menjawab pertanyaan, berkolaborasi, serta memengaruhi arah tim dan organisasi memang terasa seperti pekerjaan, tetapi komunikasi, sama seperti kode, adalah alat untuk membuat sesuatu yang berguna, bukan sesuatu yang berguna pada dirinya sendiri
Sebagian besar kode, bahkan kode yang ditulis sebagai “kode demi kode”, tetap memecahkan suatu masalah
Banyak programmer juga setidaknya secara tidak sadar mengetahui hal itu, sehingga mereka menulis kode semacam itu
Masalah sebenarnya adalah orang lain, misalnya orang bisnis berjas, ingin kode itu memecahkan masalah yang berbeda
Namun kode itu harus berupa kode yang tepat
Secara lebih umum, ini dijelaskan sebagai “menerapkan sistem perangkat lunak untuk memecahkan masalah bisnis”
Jika dikatakan seperti ini kepada junior, mereka akan berfokus pada kebutuhan bisnis dan dapat menilai secara kritis perkataan MBA, manajer, atau PM agar mengerjakan hal yang benar
Namun fakta bahwa ada perangkat lunak yang bisa dijual kepada VC itu sendiri memiliki nilai
Jadi terkadang memang Anda dibayar untuk menulis kode