Pemrograman sebagian besar adalah proses berpikir (2014)
(agileotter.blogspot.com)- Hasil yang tampak sebagai kode lebih dekat ke hasil murni yang tersisa setelah membaca, meneliti, debugging, memverifikasi, dan mengambil keputusan, bukan keseluruhan pekerjaan sehari penuh
- Dalam pertanyaan informal yang diajukan kepada para programmer selama bertahun-tahun, jawaban yang paling umum untuk mengetik ulang perubahan berdurasi 6 jam hanya dengan melihat diff adalah sekitar 30 menit
- Rasio ini bukan berasal dari penelitian ilmiah, melainkan dari survei dan pengamatan diff, tetapi menjadi patokan praktis untuk memandang pemrograman sebagai 1/12 aksi, 11/12 berpikir
- Pengembangan perangkat lunak lebih dekat ke pekerjaan desain daripada produksi bergaya pabrik, dan setelah desain awal dibuat, penyalinannya dilakukan mesin dengan biaya marginal yang nyaris nol
- Jika manajemen dan proses dioptimalkan untuk menambah waktu mengetik, hasilnya akan meleset, dan lingkungan serta cara kolaborasi yang meningkatkan kualitas berpikir jauh lebih penting
Waktu yang dibutuhkan untuk mengetik ulang pekerjaan 6 jam
- Asumsinya adalah seorang programmer melakukan 6 jam pemrograman serius pada hari yang baik dengan hampir tanpa rapat dan gangguan
- Sebelum pulang ia mencetak diff, tetapi semalaman sistem kontrol versi rusak dan dipulihkan dari backup hari sebelumnya, sehingga pekerjaan satu hari hilang
- Inti pertanyaannya adalah berapa lama programmer yang diberi diff itu akan membutuhkan waktu untuk memasukkan kembali pekerjaan 6 jam tersebut ke codebase
- Selama bertahun-tahun, pertanyaan ini diajukan di konferensi, ke perusahaan klien, rekan kerja, dan programmer yang baru ditemui, dan jawaban yang paling umum adalah sekitar 30 menit
- Karena 6 jam memuat 12 kali 30 menit, pengamatan ini mengarah pada ungkapan bahwa pemrograman adalah 1/12 aksi, 11/12 berpikir
Sifat rasio ini dan keterbatasannya
- Angka ini bukan hasil penelitian ilmiah yang ketat, juga bukan survei resmi dengan catatan yang baik
- Tujuannya bukan mencari hukum statistik atau matematis dari aktivitas pemrograman, melainkan menemukan jawaban yang masuk akal untuk pertanyaan yang masuk akal
- Karena tidak ada perusahaan yang benar-benar mau menghapus seluruh pekerjaan harian untuk membuktikan atau membantah eksperimen ini, dasar buktinya tetap berupa perkiraan dan pengamatan diff harian
- Dari melihat banyak changelog dan diff, jumlah perubahan murni pada hari yang baik umumnya tampak sekitar 30 menit ± 10 menit
Mengetik bukan bottleneck
- Ungkapan “mengetik bukan bottleneck” sudah lama diulang di stiker dan media sosial
- Bagi sebagian programmer, mengetik itu sendiri bisa menjadi bottleneck, tetapi inti dari produksi kode yang cepat biasanya bukan sekadar kecepatan mengetik atau kemahiran alat
- Dalam tulisan panjang Quora “How do programmers code so quickly?”, seorang responden menyebut muscle memory, kemahiran alat, kemampuan debugging, kemampuan mengetik, dan kemampuan mencari informasi
- Namun dalam produksi kode yang cepat, mengetik dan alat lebih dekat ke sarana pendukung, sementara waktu untuk menilai apa yang harus dilakukan mengambil porsi yang lebih besar
Perbedaan antara pabrik perangkat lunak dan pekerjaan desain
- Dalam produksi barang fisik, sebagian besar pekerjaan yang terlihat adalah gerakan, dan tindakan menggulung baja, mencetak, menekan, milling, menata, dan merakit tampak seperti pekerjaan itu sendiri
- Pabrik modern, seperti mesin CNC, melakukan gerakan yang presisi berdasarkan model abstrak, yaitu data, dan manusia mengelola mesin alih-alih mengerjakannya langsung secara manual
- Di sisi perangkat lunak, pabriknya sudah selesai dibangun, dan pengguna menekan tombol “copy” atau “download” untuk memperoleh bit-perfect copy
- Setelah model awal ada, biaya marginal untuk penyalinan berikutnya pada dasarnya mendekati nol, dan perangkat lunak adalah barang intelektual
- Uncle Bob Martin telah mengatakan bahwa pengembangan perangkat lunak bukan pekerjaan fabrikasi melainkan pekerjaan desain, dan setelah desain awal, penyalinan dilakukan mesin dengan biaya yang nyaris nol
- Programmer, tester, PO, Scrum Master, dan manajer perangkat lunak merancang model data yang menjadi dasar bagi salinan yang akan digunakan pelanggan dan komunitas
Pekerjaan intelektual sulit diamati
- Cara berpikir era industri berusaha melihat pengembangan perangkat lunak seperti pabrik, dan developer mendapat tekanan untuk tampak seperti melakukan kerja fisik meskipun itu merugikan proses yang sebenarnya
- Aktivitas intelektual sulit diamati dan diukur, dan ide yang 80% selesai tidak memiliki bentuk fisik
- Mungkin ada eksperimen, kode proof-of-concept, dan catatan, tetapi itu tidak bisa menunjukkan tingkat penyelesaian yang akurat seperti pekerjaan fisik
- Kursi yang sedang diproduksi akan tampak kira-kira 50% selesai pada titik 50%, dan akan tampak seperti produk jadi saat selesai
- Desain kursi mungkin bahkan belum ada di atas kertas sampai kemajuannya melewati 70%, dan sebelum desain selesai pun sulit mengetahui apakah itu benar-benar 70% selesai
Mengapa perubahan 30 menit berarti pekerjaan 6 jam
- 30 menit adalah waktu untuk mereproduksi hasil murni dari kode yang ditulis, dihapus, diedit, dan dibuat ulang sepanjang hari, bukan seluruh usaha yang dicurahkan
- Programmer terus mengevaluasi dan membentuk hipotesis saat menulis kode untuk menghindari cacat dan kerentanan keamanan
- Teks kode hanya memuat apa yang harus dilakukan program saat dijalankan, dan umumnya tidak menyisakan alasan mengapa pendekatan itu dipilih, dampaknya pada bagian lain sistem, atau kesalahan apa yang sempat dimasukkan lalu dihapus
- Sebagian besar pekerjaan nyata bukan pada perubahan itu sendiri, melainkan pada menentukan bagaimana perubahan dilakukan, dan karena kode yang ada harus dipahami, waktu akan lebih lama pada source yang tidak memperlihatkan kekacauan kode atau desainnya
- Hasil kerja programmer diintegrasikan ke codebase bersama sehingga memiliki konteks sosial, dan pekerjaan membantu programmer lain, tester, dan operator memahami perubahan juga menciptakan biaya dan manfaat yang tidak terlihat dalam kode
Jumlah baris kode bukan ukuran kemajuan
- 6 jam pekerjaan intelektual bisa berubah menjadi perubahan murni setara 30 menit di codebase setelah melalui pembacaan, penelitian, keputusan, konfirmasi, verifikasi, dan peninjauan
- Ini tidak berarti jumlah baris kode yang ditambahkan, dan ada kasus ketika perbaikan bug serta penambahan fitur dilakukan tetapi jumlah baris kode pada akhir pekan justru lebih sedikit daripada di awal pekan
- Pernah ada masalah karena selama beberapa minggu tercatat jumlah baris kode negatif, tanpa menyadari bahwa manajer tingkat atas tim melaporkan SLOC seolah-olah itu indikator kemajuan
- Yang benar-benar dilakukan programmer lebih dekat ke membaca, belajar, memahami, menebak, meneliti, debugging, testing, kompilasi, menjalankan, membentuk hipotesis, dan membantahnya
- Banyak pekerjaan pada akhirnya tetap berupa berpikir dan mengambil keputusan
Menulis lebih sedikit bisa berarti pengembangan yang lebih cepat
- Salah satu jawaban di Quora mengatakan bahwa gerakan jari di atas keyboard memang terlihat, tetapi waktu untuk berbicara dengan pengguna, mendiskusikan masalah dengan rekan, meneliti, dan berpikir tidak terlihat
- Responden lain mengatakan bahwa membantu pelanggan menghapus pemikiran yang tidak perlu yang mereka sebut “requirements” atau “must have” adalah hal yang paling mempercepat penyampaian solusi
- Responden lain lagi mengatakan bahwa developer hebat menyelesaikan lebih dari 90% pekerjaannya sebelum menyentuh keyboard, sambil memahami requirement dan membayangkan solusi yang tepat
- “Mengetahui apa yang tidak perlu ditulis”, “melakukan lebih sedikit”, “bekerja dalam langkah-langkah yang lebih kecil”, dan “mencari tahu apa yang harus dilakukan terlebih dahulu” adalah jawaban yang berulang kali muncul
- Orang yang mengetik lebih banyak atau lebih sering copy-paste bisa jadi kurang dalam berpikir dan memahami, dan akibatnya kesalahan meningkat serta beban programmer lain untuk memahami dan memperbaiki ikut bertambah
Proses harus dirancang untuk berpikir
- Jika pemrograman adalah 1/12 aksi dan 11/12 berpikir, maka orang tidak boleh ditekan untuk mengetik selama 11/12 waktunya
- Yang dibutuhkan adalah bahan, lingkungan, dan proses yang meningkatkan kualitas berpikir
- Jika sebaliknya, sistem akan dioptimalkan untuk efek yang keliru
- Produktivitas bisa meningkat ketika sistem sengaja dibuat agar lebih mudah berpikir bersama tentang perangkat lunak dan mengambil keputusan
- Kita perlu bereksperimen dengan pembelajaran dalam pekerjaan dan memikirkan cara membangun sistem yang mengoptimalkan proses berpikir
1 komentar
Komentar Hacker News
Pernyataan dalam artikel bahwa “developer yang benar-benar hebat menyelesaikan lebih dari 90% pekerjaannya sebelum menyentuh keyboard” kadang benar, tetapi menurut saya itu melewatkan fakta bahwa orang tidak bisa menampung banyak batasan dan konsep sekaligus di kepala
Ruang lingkup untuk berpikir murni tanpa menulis apa pun sangat terbatas, jadi begitu satu pendekatan yang mungkin terlintas, saya biasanya hampir langsung memegang keyboard sebelum memolesnya menjadi desain yang terspesifikasi lengkap
Saat mencoba berbagai pendekatan dengan menulis kode nyata, sering kali solusi yang awalnya saya anggap terbaik ternyata jauh lebih buruk daripada solusi yang semula terlihat kurang menjanjikan, dan tidak ada yang mengungkap masalah sebaik kode konkret yang berjalan
Pada akhirnya, coding adalah proses mematerialkan ide menjadi kode untuk memvalidasinya, dan seperti sudut pandang prototyping bahwa kita membuang iterasi pertama, penulisan kode juga harus dipandang sebagai bagian dari proses berpikir
Seperti legenda bahwa ia memikirkan Git selama kira-kira sebulan, lalu menyelesaikannya dalam 6 hari dan beristirahat pada hari ke-7; tetapi bagi orang biasa, terutama saya, prosesnya lebih berupa interaksi: memikirkan apa yang akan ditulis, menulis, menguji, berpikir lagi, lalu memperbaiki sebagian
Pada akhirnya, proses mencapai versi final yang berfungsi sampai batas tertentu lebih dekat ke seni
Setelah mendapatkan gambaran kasar, saya mulai menulis kode dari bagian “lengket” yang tampaknya paling mungkin menimbulkan masalah
Karena tidak semua masalah bisa diprediksi di awal, kita harus benar-benar menabraknya, dan cara ini sering membuat banyak pekerjaan dibuang
Saya hampir tidak menulis dokumen sampai cukup yakin bahwa arahnya benar[0], karena itu membantu mengurangi kondisi yang saya sebut Concrete Galoshes[1]
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
Satu-satunya cara mempelajarinya adalah banyak coding praktik nyata dan pembelajaran aktif, dan itu juga berarti terus-menerus memakai stack teknologi yang sama
Saya lebih suka tetap di stack yang sama agar bisa fokus pada masalahnya sendiri, tetapi “developer hebat” yang dimaksud di sini kemungkinan cukup satu dimensi dalam hal pemilihan alat
Semakin bertambah usia, semakin jelas bahwa arsitektur jauh lebih penting daripada keputusan mikro
Hal-hal mikro bisa dioptimalkan, tetapi keputusan makro biasanya permanen
Sering kali kita merancang kode di dalam test dan membiarkannya sedikit banyak mengarahkan implementasi
Setelah membayangkan hasil akhir di kepala, saya menulis test dalam bentuk yang menurut saya merupakan API yang baik untuk sistem, lalu memulai dari sana
Hasilnya, kode pada dasarnya menjadi testable, dan setelah beberapa kali menjalankan Red → Green → Refactor, kita mencapai keadaan yang memuaskan
Saya penasaran apakah orang lain juga bekerja seperti ini
Penjelasan dalam buku Jonathan E. Steinhart, “The Secret Life of Programs”, adalah yang paling saya sukai
Isinya, pemrograman komputer terdiri dari dua tahap: 1. memahami alam semesta 2. menjelaskannya kepada anak berusia tiga tahun
Artinya, kita tidak bisa menulis program yang melakukan sesuatu yang tidak kita pahami; jika tidak tahu aturan ejaan, kita tidak bisa membuat pemeriksa ejaan; dan jika tidak paham fisika, sulit membuat video game aksi yang bagus
Untuk menjadi programmer yang baik, kita harus belajar sebanyak mungkin tentang segala hal, dan karena solusi masalah sering datang dari tempat yang tak terduga, jangan mengabaikannya hanya karena tampak tidak relevan saat ini
Tahap kedua adalah menjelaskan apa yang kita ketahui kepada mesin yang melihat dunia dengan sangat kaku, seperti anak berusia tiga tahun
Jika bertanya kepada anak “Sepatumu di mana?”, ia bisa menjawab “di sana”; ia memang menjawab pertanyaan, tetapi sebenarnya tidak menyimpulkan maksud bahwa kita akan keluar dengan memakai sepatu
Anak-anak tumbuh dan belajar fleksibilitas serta kemampuan inferensi, tetapi komputer, seperti Peter Pan, tidak pernah tumbuh dewasa
Setiap orang dan setiap masalah punya cara berpikir yang cocok, dan jika belajar berpikir serta memprogram dengan berbagai cara, alat yang bisa dipilih menjadi lebih banyak
Karena itu saya tidak suka klaim yang seolah-olah mengatakan pemrograman harus terjadi dengan satu cara yang benar
Pernyataan “kita tidak bisa menulis program untuk sesuatu yang tidak kita pahami” juga tidak benar; sering kali kita memakai perangkat lunak untuk memahami bagaimana sesuatu sebenarnya bekerja
Pemodelan fisika pun sering kali bukan bertujuan mencapai kesetiaan sempurna terhadap realitas, melainkan eksplorasi untuk mencari keseimbangan antara pengalaman pengguna dan tingkat kesulitan sebuah game
Pemrograman bisa menjadi alat kognitif yang eksploratif, dan itu tidak berarti sebagian besar pemikiran harus selalu datang lebih dulu
Saya menyukai generalis atau orang yang belajar sendiri, tetapi itu bukan tahap pertama yang wajib untuk menjadi programmer yang baik
Anak-anak bukannya memiliki “pandangan dunia yang kaku”, melainkan tidak selalu bisa menyimpulkan implikasi sosial, dan komputer pun bisa diprogram untuk menarik kesimpulan logis dari fakta yang diketahui
Saya pernah menjelaskan sesuatu kepada anak-anak dari berbagai usia, termasuk anak berusia tiga tahun, tetapi pengalaman itu sama sekali tidak mirip dengan pemrograman komputer
Saya cukup yakin angka ini pada dasarnya benar, tetapi sejauh ini belum ada perusahaan yang setuju untuk menghapus pekerjaan sehari penuh hanya demi membuktikan atau membantah eksperimen ini
Dulu, ketika saya masih jauh lebih sabar, saya punya atasan yang setiap malam meninjau semua perubahan kode dan menghapus yang tidak ia sukai
Atasan itu percaya bahwa version control terlalu rumit, jadi ia mencoba menjadikan akses jarak jauh ke network drive di rumahnya sebagai standar perusahaan
Karena itu, kadang saat masuk kerja keesokan harinya, pekerjaan hari sebelumnya sudah terhapus, dan sampai akhirnya kami diam-diam memasang SVN, saya menjadi sangat terampil membuat ulang pekerjaan hari sebelumnya
Bahkan termasuk pengujian edge case, jarang sekali butuh lebih dari satu jam
Karena agak trauma dari pekerjaan pertama, di pekerjaan kedua saya langsung bertanya apakah ada repositori Git, dan atasan menjawab bahwa ia tidak ingin kodenya dipublikasikan karena mengira Git sama dengan Github
Belakangan kami diakuisisi oleh perusahaan yang lebih besar dan saya mendapat akses intranet; di sana saya menemukan sebuah instance GitLab, lalu menaruh kode yang sebagian besar saya kerjakan sendiri di sana untuk version control dan dokumentasi, bahkan memasang GitLab Runner
Saya juga mendokumentasikan langkah demi langkah cara menjalankan kodenya, dan saat saya diberhentikan lalu diminta menyerahkan kode, saya menunjukkan semuanya dan menjelaskan cara mereproduksinya; atasan saya cukup terkesan dan berterima kasih
Mungkin, dengan bersikeras melakukan sesuatu dengan cara yang menurut saya benar di tempat kerja yang buruk, saya sedikit meninggalkan dampak yang baik
Sebelum menemukan GitLab itu, saya membuat repositori Git mentah di network share dan melakukan push ke sana
Sekalipun niatnya baik, ketika manajer terlibat dalam kode atau review, hampir selalu hasil bersihnya merugikan tim
Ini tulisan yang bagus untuk dikirim kepada non-programmer
Seperti halnya programmer membutuhkan pengetahuan domain, orang yang ingin mendapatkan sesuatu dari programmer juga perlu sedikit memahami pemrograman
Diff yang sangat kecil sekalipun bisa memakan waktu berjam-jam karena debugging, desain, dan pembelajaran
Mudah saja tidak terkesan jika hanya melihat jumlah output, tetapi mendengar penjelasan dari seseorang dan mencari tahu sendiri selama berjam-jam sambil seperti membenturkan kepala ke tembok adalah dua hal yang sama sekali berbeda
Misalnya menghabiskan beberapa hari untuk menemukan commit satu baris yang meningkatkan performa 100 kali lipat, sambil pada saat yang sama harus menjelaskan di rapat sinkronisasi kenapa tiketnya tidak bergerak
Jadi pengetahuan domain adalah kuncinya
Saya bekerja di bidang keuangan, duduk di trading desk sambil memantau berbagai bursa, dan menulis kode untuk mengimplementasikan berbagai strategi
Jika tidak tahu apa yang harus dilakukan bisnis, kita juga tidak bisa memikirkan apa yang harus dilakukan komputer
Dari sudut pandang ini, masuk akal melatih coder seperti penerjemah
Teman saya yang penerjemah sangat memahami tata bahasa dan idiom beberapa bahasa dan mempelajari bahasa baru seperti kita mempelajari bahasa pemrograman baru, tetapi ia juga menghabiskan cukup banyak waktu mempelajari industri farmasi, dan kini menerjemahkan dokumen medis
Pengacara dan akuntan juga merupakan profesi dengan hambatan bahasa
Ketika menjadi ahli, kita mempelajari bahasa hukum, akuntansi, dan software, tetapi ahli yang baik memberi jawaban dalam bahasa bisnis, bukan bahasa spesialis
Pengacara yang kurang baik akan menjelaskan semua kemungkinan hasil dalam istilah hukum lalu menyerahkan keputusan kepada klien, tetapi pengacara yang baik akan mengatakan bahwa meski ada banyak kemungkinan kecil, dalam praktiknya semua klien di posisi yang sama memilih X karena tujuan bisnis ini
Di pekerjaan trading pertama saya, seorang trader membuat modul Excel VBA untuk menjalankan prosedur yang menyisir saham dan mencari target perdagangan
Tidak ada version control, hanya file yang tersimpan di disk; dalam beberapa minggu, seorang pegawai baru menyimpan file setelah menghapus seluruh modul VBA itu, tanpa backup dan tanpa bantuan dari IT
Wajah trader itu sempat memerah, lalu setelah tenang ia menerima kenyataan bahwa seharusnya memang ada backup dan mempertanyakan kenapa ia melakukan itu dengan VBA, kemudian duduk dan mengetik ulang semuanya seperti layar terminal tahun 80-an yang menampilkan huruf satu per satu
Keyakinan saya adalah bahwa untuk membuat solusi yang baik, pertama-tama harus ada pengalaman di domain tersebut
Saat ini saya menghabiskan sebagian besar waktu untuk mendapatkan pengalaman di domain baru, dan duduk di samping pakar domain agar cepat membangun pengetahuan yang diperlukan
Mereka lebih memilih software engineer yang sudah 15 tahun membuat software terkait akuntansi daripada orang dengan latar belakang seperti saya, lalu menyuruh orang itu berbicara dengan akuntan selama 30 menit
Sering terlihat resep yang menyatakan bahwa pemrograman harus bekerja dengan satu cara tertentu, tetapi jenis pekerjaan sangat berbeda di tiap subbidang
Menurut saya, daripada mencoba mempelajari atau mengajarkan satu metodologi tunggal yang sempurna untuk semua bidang, lebih baik memiliki kotak perkakas berisi berbagai pendekatan dan metodologi, serta memahami situasi yang cocok untuk masing-masing
Karena itu, orang jadi berfokus pada keterampilan pemrograman umum yang dapat ditransfer lintas industri
Hal serupa juga muncul di bagian awal buku PPP karya Bjarne[0]
Intinya kira-kira: “Bahkan programmer terbaik sekalipun—terutama programmer terbaik—menghabiskan sebagian besar waktunya bukan untuk menulis kode, melainkan memahami masalah. Memahami masalah sering kali membutuhkan waktu yang serius dan upaya intelektual yang besar. Itulah tantangan intelektual yang dimaksud banyak programmer ketika mereka mengatakan bahwa pemrograman itu menarik.”
Saya juga membeli edisi baru[1] yang baru-baru ini sempat muncul di halaman depan[2]
[0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
[1]: https://www.stroustrup.com/programming.html
[2]: https://news.ycombinator.com/item?id=40086779
Hal-hal seperti database apa yang akan dipakai, bahasa apa yang terbaik, apakah akan mengizinkan null di kode dan database, format API, format log, dan semacamnya
Itu tidak terlalu menarik, dan memang kadang perlu ditinjau ulang, tetapi pemborosan waktu seperti ini yang saya alami di tiga perusahaan terakhir kebanyakan terasa seperti masalah yang seharusnya sudah terselesaikan
Sebenarnya, kalau perusahaan punya pola pikir yang kuat, meski meragukan sekalipun, itu bisa jauh lebih produktif
Kalau sudah ditetapkan memakai Perl, MongoDB, dan CGI, saya rasa saya akan lebih produktif daripada belakangan ini, terlepas dari stack tersebut
“Pemrograman sebagian besar adalah berpikir” adalah salah satu kalimat yang kita ucapkan kepada diri sendiri seolah-olah itu kebenaran mendalam, tetapi sebagai pengamatan, itu tidak terlalu produktif
Bahwa pemrograman adalah berpikir maknanya persis sama dengan semua kerja pengetahuan adalah berpikir
Desain juga sebagian besar berpikir, akuntansi juga sebagian besar berpikir, dan manajemen pun pada umumnya berpikir
Perbedaan yang bermakna bukan pada berpikir itu sendiri, melainkan apa yang dipikirkan
Manajer harus men-debug masalah manusia, jadi mereka butuh banyak waktu dengan orang-orang, yaitu rapat
Developer men-debug masalah komputer, jadi mereka butuh banyak waktu dengan komputer
Di sini ada ketegangan yang jelas, dan tidak ada ekstrem yang berhasil, jadi kita harus menemukan keseimbangan agar tidak terlalu saling mengganggu pekerjaan masing-masing
Saya tidak sedang membicarakan kode ala code golf yang sulit dipahami, melainkan fakta bahwa semua yang kita hasilkan harus dipelihara
Ini jelas berbeda dari novelis, yang mungkin tidak terlalu peduli pada pemeliharaan dan lebih peduli pada emosi yang ditimbulkan teks
Optimasi terbaik untuk “bagaimana membuat sistem tempat berpikir dioptimalkan dengan bereksperimen dan belajar di pekerjaan?” adalah mengurangi interupsi
Menurut penelitian, interupsi berdampak merusak pada pemrograman
Setelah terinterupsi, butuh 10–15 menit untuk melanjutkan pekerjaan, seorang programmer kemungkinan hanya mendapat satu sesi 2 jam tanpa interupsi dalam sehari, dan waktu terburuk untuk menginterupsi adalah saat sedang mengedit, mencari, atau memahami
Saya penasaran apakah ada cara untuk melacak dan menampilkan interupsi semacam ini
[0] http://blog.ninlabs.com/2013/01/programmer-interrupted/
Namun developer diharapkan menyelesaikan pekerjaan coding berdurasi beberapa jam di antara rapat tanpa akhir, ping singkat Slack/Zoom, dan sinkronisasi
Kadang ketika harus bekerja dari rumah pada akhir pekan, saya melihat bahwa kualitas kerja pada akhir pekan tanpa gangguan jauh lebih baik daripada hari kerja yang kacau
Ini tidak cocok untuk semua orang dan tidak cocok untuk semua situasi, sementara 20% sisanya adalah koordinasi dengan orang-orang yang bekerja siang hari, tetapi produktivitas dari sesi tanpa gangguan yang baik selama beberapa jam tidak ada bandingannya
Sekali lagi, ini bukan cara yang cocok untuk semua orang, bahkan mungkin bukan untuk kebanyakan orang
Di rumah tidak ada yang mengganggu saya, dan kalaupun ada gangguan, saya bisa menentukan sendiri kapan meresponsnya
Terutama saat menangani masalah sulit, jika ada interupsi setiap 10–20 menit, lebih baik berhenti saja; kalau tidak, kemungkinan besar Anda akan menghasilkan kode berantakan yang nantinya membuat sakit kepala
Alat itu dirancang untuk menghormati privasi: mencatat bahwa browser web digunakan, tetapi tidak mencatat URL spesifik seperti apakah itu intranet internal atau fb.com
Sesekali muncul popup yang meminta pengguna menilai sendiri produktivitas mereka dan meninggalkan komentar teks bebas, dan kami tidak mengaitkannya dengan user ID agar orang tidak berbohong demi terlihat seperti manusia super
Kami membuat frontend Windows dan backend Scala lalu menyebarkannya ke kelompok relawan yang mencakup developer, pengacara, dan staf keuangan, tetapi setelah analisis data pertama, saat mulai menarik, waktu dan anggaran habis sehingga tidak sempat dijadikan makalah
Kami juga melihat alat yang sudah ada seperti Rescue Time( https://www.rescuetime.com/
), tetapi kami menilai penyimpanan data produktivitas internal di cloud eksternal tidak dapat diterima
Pemrograman yang baik kadang memang sebagian besar berpikir, tetapi benar juga ungkapan “tidak ada rencana yang bertahan setelah kontak pertama dengan musuh”
Pemrograman praktis adalah kombinasi cermat antara membuat rencana dan mencoba menjalankan kode di IDE, dan keseimbangannya harus berubah sesuai use case
Jika Anda tidak menulis kode selama berhari-hari, berarti Anda sudah sepenuhnya mengetahui permukaan masalahnya, atau Anda hanya sedang menebak
Kalau yang terakhir, tidak banyak yang perlu dipikirkan
Kali kedua akan lebih cepat
Saya setuju bahwa berpikir bisa diperluas menjadi “berpikir dengan bantuan alat”
Ini adalah ungkapan ulang dari Programming as Theory Building karya Peter Naur, dan sangat menentukan bagi saya dalam memahami esensi pemrograman
Pemrograman bukanlah pekerjaan menciptakan program itu sendiri, melainkan membentuk wawasan tertentu tentang urusan di dunia; kode yang pada akhirnya dihasilkan hanyalah ekspresi sederhana dari teori yang telah dibangun