Topik perangkat lunak yang berubah pikiran setelah 6 tahun di industri

Hal-hal yang membuat saya berubah pikiran: dulu saya menentangnya, sekarang saya mempercayainya

• Di tim yang terdiri dari orang-orang dengan tingkat pengalaman yang beragam, bahasa bertipe lebih baik
• Meeting standup berguna untuk memantau anggota baru
• Retrospektif sprint punya bagian yang berguna dan bagian yang tidak bagus (agile/scrum master yang membuang waktu semua orang)
• Arsitektur perangkat lunak lebih penting daripada apa pun yang lain. Implementasi yang buruk dari abstraksi yang baik tidak akan merusak codebase. Abstraksi yang buruk atau layer yang hilang membuat semuanya jadi buruk
• Java tidak seburuk itu sebagai bahasa
• Kode yang cerdas biasanya bukan kode yang baik. Kejelasan lebih utama daripada segalanya
• Kode yang buruk bisa ditulis dalam paradigma apa pun
• "Best practice" berbeda-beda tergantung situasi, dan tidak bisa diterapkan ke semua hal. Mengikutinya secara membabi buta membuat Anda jadi bodoh
• Jika Anda merancang sistem yang scalable padahal tidak dibutuhkan, Anda adalah engineer yang buruk
• Analisis statis itu berguna
• DRY bukan tujuan akhir, melainkan cara menghindari masalah tertentu
• Secara umum RDBMS > NoSQL
• Functional programming bukan obat mujarab, hanya alat lainnya

Opini yang saya ambil di tengah jalan:

• YAGNI > SOLID > DRY : dalam urutan ini
  → You Aren't Gonna Need It : salah satu prinsip XP
  → SOLID : 5 prinsip utama desain berorientasi objek
  Single responsibility
  Open-close
  Liskov substitution
  Interface segregation
  Dependency inversion
  → DRY : Don't Repeat Yourself
• Pensil dan kertas adalah alat pemrograman terbaik yang jarang digunakan
• Menukar kemurnian demi kepraktisan pada umumnya adalah pilihan yang baik
• Menambahkan lebih banyak teknologi bukanlah pilihan yang baik
• Jika berbicara langsung dengan pelanggan, Anda bisa mengetahui lebih banyak tentang masalah dengan lebih akurat dalam waktu yang lebih singkat
• Kata "Scalable" punya kekuatan mistis dan mengejutkan dalam benak software engineer. Hanya dengan mengucapkannya pelan, mereka bisa jatuh ke dalam kegilaan yang korup. Dengan menggunakan kata ini, tindakan-tindakan kejam dibenarkan
• Meski disebut "engineer", sebagian besar keputusan adalah cargo cult tanpa analisis, data, atau angka yang mendukung
  → cargo cult: kebiasaan menunggu dengan percaya bahwa seseorang yang lebih maju secara teknologi (masyarakat/leluhur) akan membawa kargo istimewa lewat kapal atau pesawat
• 90%, mungkin 93%, project manager bisa saja hilang besok tanpa ada keuntungan dari sisi efektivitas maupun efisiensi
• Setelah menjalani 100 wawancara, cara interview benar-benar rusak. Saya pun tidak tahu bagaimana memperbaikinya

Opini lama yang tidak berubah:

• Orang yang menekankan style kode, aturan linting, dan hal-hal kecil lainnya adalah orang-orang aneh yang gila
• Code coverage sama sekali tidak ada hubungannya dengan kualitas kode
• Monolith cukup bagus dalam sebagian besar situasi
• Puris TDD adalah yang terburuk. Pikiran kecil mereka yang rapuh tidak bisa menerima bahwa ada workflow lain

• Saat saya mencapai 10 tahun pengalaman, saya akan melihat lagi apa yang berubah atau berbalik

[edunga1]

Setiap kalimatnya terasa sangat relate. Sepertinya ini menunjukkan perubahan dari idealisme yang menganggap segala sesuatu bisa sempurna menuju pragmatisme.

[bichi]

Setelah berada di industri selama 6 tahun, topik-topik perangkat lunak yang membuat saya berubah pikiran

Begitu memahami pentingnya TDD, sejak saat itu programmer ...

[ffdd270]

Pendapat bahwa proses interview itu rusak terus bermunculan ya. Saya sendiri juga tidak percaya diri kalau disuruh mengerjakan coding test (...)

[kunggom]

Ada juga tulisan seperti ini. Katanya ini adalah isi yang muncul dalam buku berjudul 『HARD CODE』.

https://johngrib.github.io/wiki/better-interview/

[lethee]

Baru sadar hal-hal ini setelah 6 tahun? Hahaha, hebat juga ya.

[godrm]

Baru 6 tahun lalu mendapat pencerahan sampai jadi Buddha, ya!

[xguru]

Di Hacker News, pengembang lain dan para insinyur dengan pengalaman lebih dari 20 tahun juga ikut berdatangan dan menambahkan komentar tambahan.

https://news.ycombinator.com/item?id=25887373

[godrm]

Komentar pertama sudah pedas ya hehe. Kalau dibahas satu per satu, mungkin juga ada situasi yang bersifat pengecualian, jadi sepertinya berbahaya kalau terlalu memercayai apa pun secara membabi buta

[galadbran]

Sepertinya ini akan terus menjadi isu yang sering dibahas karena cukup banyak bug yang bisa diselesaikan hanya dengan pemeriksaan tipe. Cara menangani tipe dengan aman juga terus mengalami perbaikan.

(Tapi TypeScript memang agak sulit juga T_T.)