7 Kebiasaan Sederhana dari 1% Engineer Teratas

• "Cara coder elite menunjukkan kemampuan yang lebih unggul dibanding coder lain"

Jadilah engineer, bukan coder (Be an engineer, not a coder)

• Engineering adalah tentang memecahkan masalah
• Engineer terbaik memandang kode sebagai sarana untuk mencapai tujuan
• Menulis kode memang menyenangkan, tetapi menulis kode tanpa tujuan tidak ada artinya. Sebaliknya, kode digunakan untuk merancang solusi bagi pengguna
• Coding mengejar kreativitas! Kreativitas sering muncul di bawah batasan. Dengan menambahkan "batasan" berupa masalah yang jelas untuk diselesaikan, engineer dapat menikmati kebebasan untuk mengeksplorasi dan membuat solusi dengan cara yang mereka anggap paling tepat
• Engineer terbaik berorientasi pada produk dan, di atas segalanya, memprioritaskan pemecahan masalah untuk manusia, dan ini mengarah ke langkah berikutnya

Tulis kode untuk manusia, bukan komputer (Code for the human, not the computer)

"Siapa pun yang bodoh pun bisa menulis kode yang dapat dipahami komputer. Programmer hebat menulis kode yang dapat dipahami manusia." - Martin Fowler

• Kode bukan hanya untuk komputer, tetapi juga untuk manusia
• Kode ditujukan untuk sesama engineer satu tim yang akan membaca, memelihara, dan membangun di atas kode Anda
• Kode ditujukan untuk pengguna, baik anak kecil yang memakai ponsel, developer yang memanggil API, maupun diri Anda sendiri
• Engineer terbaik selalu menilai nilai sebuah kode untuk semua pengguna
• Jika kode itu gagal memuaskan bahkan satu saja dari para pelanggannya, kode tersebut tidak akan masuk ke production

Lepaskan diri dari kode itu sendiri (Detach from the code itself)

• Engineer hebat tidak terobsesi pada kode itu sendiri
• Jika hasil akhirnya bisa menjadi lebih baik secara keseluruhan, mereka tidak takut menghapus kode yang sudah 90% selesai lalu memulai lagi
• Mereka menerima feedback dengan aktif karena kode bukan sesuatu yang personal
• Kode tidak pernah sempurna. Tidak ada yang peduli pada kode sempurna. Yang orang pedulikan hanyalah kode yang membawa perubahan
• Cara terbaik untuk melatih diri agar tidak melekat pada kode adalah dengan "menyadari bahwa dalam 20 tahun, kemungkinan besar sebagian besar kode Anda akan menjadi technical debt, tidak lagi digunakan, atau ditulis ulang"

Gunakan standar yang konsisten (Use consistent standards)

• Saat menulis kode, patuhi standar dan gaya coding yang konsisten
• Menjaga konsistensi membuat diri Anda di masa depan dan rekan setim lebih mudah membaca dan memahami kode
• Dengan menggunakan style guide yang konsisten, tim maupun codebase akan lebih mudah diskalakan
  • Inilah cara perusahaan seperti Meta/Google dapat dengan cepat merilis banyak kode tanpa membuat codebase mereka menjadi tidak bisa dibaca atau dipelihara seiring waktu
• Semua perusahaan dengan performa hebat menginternalisasi style guide, memahami manfaatnya, dan sebisa mungkin mengikutinya
  • Google telah membuka sebagian style guide mereka sebagai open source
  • Meta memiliki style guide C++ di beberapa proyek open source mereka
• Tips: menyiapkan linter untuk formatting demi tim Anda benar-benar layak diberi waktu

Tulis kode yang sederhana (Write simple code)

• Semua engineer elite yang saya kenal mungkin menghasilkan sesuatu yang kompleks saat proses pembuatannya, tetapi pada akhirnya mereka menghasilkan kode yang mudah dibaca dan dipahami
• Ucapan terbaik saya tentang hal ini adalah bahwa kode mereka "memuaskan secara estetika"
• Kode mereka rapi, terstruktur, dan logis (clean, organized, and logical)
• Setiap keputusan dalam kode memiliki alasan, dan jika tidak, hal itu didokumentasikan dengan baik di dalam kode
• Cara yang baik untuk menulis kode yang rapi adalah mengikuti prinsip seperti SOLID. Awalnya prinsip ini dirancang dengan OOP (object-oriented programming) dalam pikiran, tetapi bisa diperluas ke pemrograman secara umum
  • Single Responsibility: satu kelas hanya boleh memiliki satu tanggung jawab
  • Open-Closed: objek software (kelas, modul, dan sebagainya) harus terbuka untuk ekstensi tetapi tertutup untuk modifikasi agar menghasilkan kode yang dapat diprediksi dan mudah dipelihara
  • Liskov Substitution: subtype harus dapat menggantikan tipe dasarnya tanpa memengaruhi kebenaran program
  • Interface Segregation: kode tidak boleh bergantung pada antarmuka raksasa yang tidak menggunakan semuanya. Sebaliknya, package harus diizinkan untuk menyertakan dan mengimpor antarmuka yang lebih kecil dan spesifik
  • Dependency Inversion: modul level atas tidak boleh bergantung pada modul level bawah; keduanya harus bergantung pada abstraksi untuk mendorong desain sistem yang lebih fleksibel dan terpisah
• Contohnya bisa dilihat pada naming: nama yang baik tidak mengandung nilai ajaib, memiliki pembedaan yang jelas, serta menggunakan nama fungsi yang deskriptif dan variabel yang mudah dipahami

Jangan biarkan ada kejutan (Don’t allow surprises)

• Kode tidak boleh menghasilkan hasil yang tak terduga. Ini bisa dicapai dengan mengikuti prinsip kode dan menulis pengujian yang tepat
• Kode yang baik itu dapat diprediksi
• Testing memperkuat kejelasan dan prediktabilitas kode, serta memberi rasa percaya diri. Dengan automated test yang baik, tim bisa mengubah kode tanpa khawatir merusak bagian yang tidak terlihat
• Beberapa jenis testing
  • unit test untuk komponen individual dan fungsi yang terisolasi
  • integration test untuk interaksi antar beberapa komponen
  • end-to-end test yang mengevaluasi fungsi seluruh sistem dari sudut pandang pengguna
• Testing harus sederhana. Saat membaca test yang gagal, Anda harus bisa dengan mudah memahami apa yang salah
• Penting juga untuk tahu apa yang tidak perlu diuji
  • Misalnya, jika upaya untuk melakukan end-to-end test lebih besar daripada manfaat nyata bagi program, testing dapat diganti dengan dokumentasi yang cermat, monitoring, dan pengiriman notifikasi kepada orang yang tepat (misalnya code owner)
  • Selain itu, testing juga tidak boleh menguji detail implementasi dalam kode, seperti menguji selector CSS tertentu pada kode frontend atau hanya menggunakan atribut data maupun screenshot test

Sering berkomunikasi (Communicate often)

• Sistem yang hebat tidak dibangun sendirian. Engineer hebat melalui design review, meminta feedback, dan terus mengiterasi desain awal kode mereka
• Semua orang memiliki celah dalam pengetahuan mereka yang bisa diisi oleh orang lain. Perspektif baru sering membantu membuat kode lebih jelas atau memberi pendekatan baru yang sebelumnya tidak terpikirkan
• Engineer terbaik tidak takut meluangkan waktu untuk bekerja bersama demi hasil akhir yang lebih baik, serta menghargai komunikasi dan kolaborasi
• Ini bisa sesederhana mengirim ping ke rekan tim untuk review cepat sebuah dokumen atau menambahkan code reviewer pada pull request yang penting

Coding dengan cepat... dan lambat (Code fast… and slow)

• Engineer terbaik yang saya kenal menyelesaikan proyek dengan cepat, tetapi melakukan coding dengan lambat
• Terdengar aneh, bukan?
  • Semua prinsip dan kebiasaan di atas menambah lebih banyak waktu pada tahap awal coding. Namun, melalui prinsip dan kebiasaan ini, engineer dapat memajukan progres proyek selangkah demi selangkah
  • Dengan meluangkan waktu untuk menggunakan standar, melakukan testing dengan benar, menerapkan prinsip, dan sering berkomunikasi, Anda bisa menghemat lebih banyak waktu dalam jangka panjang
• Saya sendiri mengalaminya saat masih intern dan junior engineer, dan banyak engineer lain juga demikian: terburu-buru maju 3 langkah bisa membuat Anda menabrak rintangan lalu mundur 5 langkah

Jangan mengikuti aturan secara membabi buta (Don’t follow rules blindly)

• "Aturan" dan "prinsip" di atas hanyalah guideline semata. Tidak semua hal akan pas rapi sepenuhnya dengan guideline
• Terkadang kode yang Anda tulis bisa saja berupa persegi yang tidak masuk ke dalam lingkaran, dan itu tidak masalah
  • Dalam kasus ini, dokumentasikan alasan mengapa kode ditulis dengan cara tertentu
  • Jika tidak, seseorang seperti Anda di masa depan bisa melihat kode itu dan berpikir, "Wah, dulu saya bodoh sekali. Kenapa ini tidak mengikuti standar kita?"
  • Lalu mereka akan menghabiskan 20 jam untuk menulis ulang agar sesuai standar, hanya untuk sampai pada kesimpulan yang sama seperti sebelumnya
• Realitas pengembangan software adalah tidak semua kode bisa rapi atau mengikuti aturan dengan sempurna
• Namun, kode yang konsisten, rapi, mudah dipahami, bisa diuji, dan bernilai itu tetap mungkin ada
• Pola lain yang saya temukan pada engineer terbaik
  • Memiliki pengetahuan domain yang mendalam setidaknya di satu bidang. Semua engineer yang saya catat menjadi yang terbaik di bidangnya saat ini karena mereka fokus pada area tertentu seperti infrastruktur frontend, distributed systems, clean UI, dan sebagainya hingga menjadi ahli
  • Sering dan dengan tepat memasarkan diri sendiri. Engineer ini tidak bersembunyi di tempat yang tidak terlihat. Semua orang yang bekerja bersama mereka tahu nilai dan keahlian mereka, dan ini merupakan hasil dari pemasaran diri yang tepat serta mengerjakan proyek yang berdampak

[greety]

Saya mendapatkan insight yang bagus. Terima kasih :)

[geekbini]

Tulisan yang bagus!

[nina514]

Teknologi itu penting, tetapi ini kembali membuat saya berpikir bahwa yang lebih penting adalah membuat produk yang benar-benar bermanfaat bagi orang!!!

[functor]

Terima kasih atas tulisannya yang bagus!

[functor]

Ternyata ada 7 kebiasaan, tapi isinya malah 9 ya wkwk

[xguru]

Saya juga menghitungnya.. sepertinya yang paling belakang dan yang paling depan cuma judul saja! hehe

[saalome]

Wah, tulisan yang keren dan sangat mudah disetujui juga, hehe

[saalome]

Konten terbaik sepanjang masa di antara artikel sejenis yang pernah saya lihat sejauh ini

[rsm0503]

Jika sedikit digeneralisasi, ini adalah tulisan bagus yang akan bermanfaat bagi semua orang.

[kuroneko]

Kalau sampai segini rasanya bukan ringkasan lagi, tapi seperti terjemahan... Terima kasih banyak atas ringkasannya.
Ini tulisan yang layak dibaca berulang kali sesekali.

[piriri11]

Memang benar banget wkwkwk saya juga ingin membacanya berulang-ulang.