Apa Aja Yang Ada di Buku The Pragmatic Programmer-Your Journey to Mastery

source: https://m.media-amazon.com/images/I/51A8l+FxFNL.jpg

Baru — baru ini aku lagi baca buku ini. Udah cukup lama direkomendasikan, karena sepertinya isinya menarik. Yuk kita pelajarin bareng!

Kita awali dengan Tips:
Care About Your Craft
Develop program dengan baik.

Think! About Your Work
think about what you’re doing while you’re doing it. Manfaatkan waktu dengan baik. Tulis kode yang mudah di maintain, habiskan lebih sedikit waktu untuk meeting. Lakukan meeting jika memang benar — benar diperlukan dan lakukan meeting yang bermanfaat untuk menghemat waktu.

Chapter 1: A Pragmatic Philosophy

Ada sekitar 7 topics yang dibahas di chapter ini.

1. It’s Your Life
   Ini hidup kita, kita yang punya responsibility atas hidup kita sendiri. Engineer / developer kadang menganggap kalau mereka tidak di apresiasi, mendapat gaji kecil, atau team mereka toxic. Mereka menolak perubahan, berharap things will get better. Tapi mereka passive.
   Ada tips yang dibahas disini :
   Kita Punya Hak Untuk Memilih.
   - Jika kita punya masalah dengan lingkungan kerja? Fix it. As Martin Fowler says, “you can change your organization or change your organization.”
   - Jika merasa tertinggal dengan perkembangan teknologi, sisihkan waktu untuk belajar hal baru yang menarik menurut kita. You’re investing yourself. Kita bisa men develop diri kita sendiri.
   - Prefer kerja remote? coba ajukan ke atasan atau temukan remote job impianmu. Company IT punya banyak opportunity untuk kita.
2. The Cat Ate My Source Code
   Taking responsibility atas diri kita sendiri, atas karir kita sendiri. Tidak takut melakukan salah, mengakui kesalahan dan kekurangan serta jujur kalau masih belum tau.
   Dalam situasi apapun, akan ada kemungkinan things go wrong. Jadi kita harus bersiap akan hal itu dan take it professionally, bersikap tenang dan jujur.
   - Team Trust
   Dalam team perlu ada kepercayaan orang kepada kita. Pastikan mereka bisa mengandalkan kita dan kita juga percaya dan mengandalkan mereka.
   Kepercayaan sangat penting untuk membentuk kreativitas & kolaborasi. In a healthy environment based in trust, kita bisa saling mengutarakan pendapat dan saling mengandalkan dalam tim.
   - Take responsibility
   kita berkomitmen untuk menyelesaikan sesuatu dengan baik. Penting untuk mengetahui apa yang bisa kita kerjakan dan apa yang tidak, apa yang bisa kita kontrol dan apa yang tidak. Kita harus punya penilaian sendiri terhadap diri sendiri untuk menentukan responsibility ini. Jika melakukan salah, kita harus mengaku dengan jujur dan menawarkan solusi.
   “Jangan blame orang lain atau mencari alasan, fokus pada solusi bukan pada masalah”.
   Ketika ada masalah, bilang pada bos bahwa The Cat Ate My Source Code, tidak akan menyelesaikan masalah.
   Tip yang selanjutnya:
   Berikan Pilihan, Jangan buat Alasan Yang Tidak Jelas
   Sebelum approach ke orang lain kenapa something tidak bisa diselesaikan, telat, atau rusak, talk to rubber duck dulu. Apa alasannya masuk akal? terdengar bodoh? bagaimana kalau di dengar oleh atasan?
   Pikirkan dahulu apa yang nantinya akan mereka katakan pada kita. Tentang, apakah kita sudah mencoba A B C? apakah ada hal lain yang bisa dilakukan? pikirkan dulu untuk menyelamatkan diri sendiri dan tim.
   “Jangan langsung katakan kalau itu tidak bisa dilakukan”.
   Jelaskan dulu kemungkinan — kemungkinan yang bisa dilakukan. Mungkin refactoring, prototyping, introduce better testing etc.
   “Jangan takut untuk tanya dan meminta atau menerima bantuan”
   “Jika memang terlanjur bilang ‘tidak tahu’, pastikan ikuti dengan ‘aku akan mencari tahu’” Ini terdengar mengambil responsibility dengan profesional.
3. Software Entropy
   Entropi adalah istilah fisika yang mengacu pada besarnya gangguan pada sistem. Dalam software juga terdapat gangguan — gangguan yang biasa disebut technical debt dengan anggapan bahwa gangguan itu adalah hutang yang nantinya (mungkin) akan dibayar. Faktor penyebab technical debt bisa beragam, diantaranya psikologi atau budaya dalam pengerjaan project. Meski di rencanakan dengan baik, project tetap dapat hancur. Namun tetap dapat diperbaiki.
   Terkadang kita membiarkan jika ada hal kecil yang bermasalah tapi impact nya tidak besar saat itu. Sebenarnya jika hal itu dibiarkan, kerusakan kecil bisa menjadi besar dan kemungkinan akan lebih sulit diperbaiki jika sudah depend dengan yang lainnya. Selain kerusakan pada suatu hal atau suatu code, pemikiran negatif atau pemikiran yang salah dari anggota tim juga perlu segera diluruskan agar tidak mengganggu dan mempengaruhi anggota lainnya.
   Kemudian kita lanjutkan ke tip berikut :
   Don’t Live With Broken Windows
   Jangan tinggalkan “Jendela Pecah”(kode yang buruk, desain yang buruk, atau keputusan yang salah) yang belum diperbaiki.
   - Segera perbaiki ketika problem itu ditemukan.
   - Jika tidak ada cukup waktu untuk memperbaiki, setidaknya berilah tanda atau catatan yang menandakan bahwa kita sudah aware dengan problem yang terjadi. Bisa dengan cara mengomentari kode yang melanggar, atau menampilkan pesan “Tidak Diimplementasikan”, atau gantikan dengan data dummy. Take action untuk mencegah kerusakan lebih lanjut.
   First, Do not Harm.
   “Jangan menambah kerusakan hanya karena ada satu masalah. Satu masalah itu sudah sangat besar”.
   Jika kita kerja di project yang punya cukup banyak problem, kita mungkin bilang, “Sudah ada beberapa yang rusak, jadi aku ikuti saja yang sudah ada”. Tidak masalah jika saat ini project baik baik saja, tapi ingat kalau 1 jendela saja sudah pecah maka akan sangat mungkin project itu bisa hancur dalam waktu dekat.
   Akan berbeda jika kita telah ada di project yang di desain dengan baik, code nya bersih dan rapi. Maka kita akan sangat berhati — hati dan tidak ingin menjadi yang pertama menimbulkan kerusakan.
4. Stone Soup and Boiled Frogs

to be continued