Bagaimana Anda menyeimbangkan antara "lakukan dengan benar" dan "lakukan secepatnya" dalam pekerjaan sehari-hari Anda? [Tutup]

Saya menemukan diri saya merenungkan pertanyaan ini dari waktu ke waktu, berulang kali. Saya ingin melakukan hal-hal dengan cara yang benar: menulis kode yang bersih, mudah dimengerti, dan benar yang mudah dipelihara. Namun, apa yang akhirnya saya lakukan adalah menulis tambalan di atas tambalan; hanya karena tidak ada waktu, klien menunggu, bug harus diperbaiki dalam semalam, perusahaan kehilangan uang untuk masalah ini, seorang manajer menekan dll, dll.

Saya tahu betul bahwa dalam jangka panjang saya menyia-nyiakan lebih banyak waktu pada tambalan-tambalan ini, tetapi karena waktu ini bekerja berbulan-bulan, tidak ada yang peduli. Juga, seperti yang dikatakan oleh salah satu manajer saya: "kami tidak tahu apakah akan ada jangka panjang jika kami tidak memperbaikinya sekarang."

Saya yakin saya bukan satu-satunya yang terperangkap dalam siklus pilihan nyata / ideal tanpa akhir ini. Jadi bagaimana Anda, sesama programmer, mengatasi ini?

UPDATE: Terima kasih atas diskusi yang menarik ini. Sangat menyedihkan bahwa begitu banyak orang harus memilih setiap hari antara jumlah dan kualitas kode mereka. Namun, masih banyak yang mengherankan, orang berpikir adalah mungkin untuk memenangkan pertempuran ini, jadi terima kasih semua atas dorongan ini.

Sebenarnya, ini adalah pertanyaan yang sangat sulit karena tidak ada jawaban yang benar-benar tepat. Di organisasi kami, kami telah menempatkan proses yang lebih baik untuk menghasilkan kode yang lebih baik. Kami memperbarui standar pengkodean untuk mencerminkan bagaimana kami, sebagai kelompok, menulis kode, dan kami telah melembagakan pengujian / refaktor / desain / kode yang sangat kuat. Kami mengirimkan secara terus menerus atau setidaknya mencoba. Paling tidak, kami memiliki sesuatu untuk ditunjukkan kepada para pemangku kepentingan setiap dua minggu. Kami merasa bahwa kami adalah pengrajin perangkat lunak dan semangat kerja tinggi. Namun, terlepas dari semua checks and balances ini, kami menderita masalah yang sama dengan Anda.

Pada akhirnya, kami mengirimkan produk ke pelanggan yang membayar. Pelanggan ini memiliki kebutuhan dan harapan, realistis atau tidak. Seringkali tim penjualan membuat kita kesulitan hanya untuk mendapatkan komisi. Terkadang pelanggan memiliki harapan langsung yang tidak realistis atau permintaan berubah meskipun kami memiliki kontrak. Garis waktu terjadi. PTO dan hari-hari yang hilang selama sprint dapat terjadi. Segala macam hal kecil dapat memuncak dalam situasi di mana kita dipaksa ke dalam teka-teki "lakukan dengan benar" atau "lakukan secepat mungkin." Hampir selalu, kita dipaksa untuk "melakukannya secepat mungkin."

Sebagai pengrajin perangkat lunak, pengembang, pemrogram, orang-orang yang memberi kode untuk suatu pekerjaan - adalah kecenderungan alami kita untuk "melakukannya dengan benar." "Lakukan secepatnya" adalah apa yang terjadi ketika kita bekerja untuk bertahan hidup, seperti kebanyakan dari kita. Saldo sulit.

Saya selalu mulai dengan mendekati manajemen eksekutif (Saya Direktur Pengembangan Perangkat Lunak dan pengembang aktif dalam grup itu) untuk mempertahankan jadwal, tim, dan pekerjaan yang sedang dilakukan. Biasanya pada saat itu saya diberitahu pelanggan harus memilikinya sekarang dan harus bekerja. Ketika saya tahu tidak ada ruang untuk negosiasi atau memberi, saya kembali dan bekerja dengan tim untuk melihat sudut apa yang bisa dipotong. Saya tidak akan mengorbankan kualitas dalam fitur yang mendorong kebutuhan pelanggan untuk mendapatkannya SECEPATNYA, tetapi sesuatu akan hilang dan akan didorong ke sprint lain. Ini hampir selalu OK.

Ketika Anda tidak dapat mengirim karena ada begitu banyak bug, kualitas kode buruk dan semakin buruk, dan waktu semakin pendek, maka Anda berada dalam situasi yang berbeda dari apa yang saya jelaskan. Dalam hal itu, salah urus saat ini atau di masa lalu, praktik pembangunan yang buruk yang menyebabkan kualitas kode yang buruk, atau faktor lain mungkin membawa Anda pada mars kematian.

Pendapat saya di sini adalah melakukan yang terbaik untuk mempertahankan kode yang baik dan praktik terbaik untuk mulai menarik perusahaan Anda keluar dari parit. Jika tidak ada satu pun kolega yang mau mendengarkan atau pergi untuk menentang kelompok, maka mungkin sudah saatnya untuk mencari pekerjaan baru.

Pada akhirnya, kehidupan nyata mengalahkan semua. Jika Anda bekerja untuk perusahaan yang perlu menjual apa yang sedang Anda kembangkan, maka Anda akan menghadapi pertukaran ini setiap hari. Hanya dengan berusaha keras untuk mencapai prinsip-prinsip pengembangan yang baik sejak awal, saya berhasil bertahan di depan kurva kualitas kode.

Dorongan dan tarik antara pengembang dan penjual mengingatkan saya pada sebuah lelucon. "Apa perbedaan antara penjual mobil bekas dan seorang penjual perangkat lunak? Setidaknya penjual mobil bekas tahu dia berbohong." Pertahankan dagu Anda dan cobalah untuk "melakukan hal yang benar" saat Anda pergi.

Satu hal yang saya sadari dalam karier saya adalah selalu ada waktu untuk melakukannya dengan benar. Ya, manajer Anda mungkin mendorong. Klien mungkin kesal. Tetapi mereka tidak tahu berapa lama hal yang harus dilakukan. Jika Anda (tim dev Anda) tidak melakukannya, itu tidak selesai; Anda memegang semua leverage.

Karena Anda tahu apa yang sebenarnya akan menyebabkan manajer Anda mendorong Anda atau klien Anda kesal? Kualitas Buruk .

Ini bermuara pada apa yang saya mulai pikirkan sebagai "Konflik Abadi" (antara bisnis dan teknik). Saya tidak punya solusinya karena ini adalah masalah yang tidak pernah hilang tetapi Anda dapat melakukan hal-hal untuk membantu mengurangi.

• Mengkomunikasikan Nilai

Apa yang orang sering tidak sadari adalah bahwa sebagai insinyur kita hanya mengasumsikan masalah "bisnis yang sukses" selalu diberikan. Kami ingin kode kami menjadi bagus dan rapi dan dapat dipelihara sehingga kami dapat menambahkan fitur baru dan men-tweak yang sudah ada dengan cepat dan dengan minimum pelanggan melakukan QA bagi kami dengan menemukan kasus pinggiran yang aneh yang akan digagalkan oleh kode yang lebih baik. Mempertahankan pelanggan dan mempertahankan keunggulan kompetitif dengan fitur dan kemahiran yang tidak dapat dilakukan orang lain dengan cukup cepat adalah kemenangan bisnis yang berkontribusi langsung pada kode yang baik dan menginformasikan banyak alasan mengapa kita menginginkan kode yang lebih baik di tempat pertama.

Jadi, jelaskan. "Kami ingin melakukan X dalam basis kode kami karena jika tidak, itu akan berdampak negatif pada bisnis karena Y" atau "... karena itu akan meningkatkan kemampuan kami untuk tetap kompetitif dengan meningkatkan kemampuan kami untuk mengubah peningkatan baru dan fitur di sekitar lebih cepat . "

Dan lakukan yang terbaik untuk mencoba dan mendapatkan bukti nyata bahwa perbaikan berhasil. Jika meningkatkan beberapa bagian dari aplikasi menghasilkan fitur / peningkatan lebih cepat, periksa alat backlog apa pun yang mungkin Anda gunakan untuk bukti dan tunjukkan pada pertemuan yang sesuai.

• Dapatkan Tim di Halaman Same Sial

Ego sering menjadi masalah. Satu hal yang sangat dibutuhkan oleh tim teknik adalah untuk menetapkan nilai memiliki semacam pendekatan yang disepakati secara konsisten untuk memecahkan jenis masalah tertentu pada setiap orang yang melakukan piala Kool Aid d'jour sendiri karena mereka lebih tahu. Tidak apa-apa untuk percaya bahwa preferensi orang lain lebih buruk daripada Anda, tetapi nilai konsistensi lebih baik jika pendekatannya bisa diterapkan dan itu adalah argumen yang tidak dapat Anda menangkan. Kompromi demi konsistensi adalah kuncinya. Ketika hal-hal yang konsisten lebih sulit untuk melakukannya salah karena cara yang konsisten biasanya juga akan menjadi cara tercepat.

• Pilih Alat yang Tepat

Ada dua mazhab kerangka / perkakas / perpustakaan / apa pun. "Atur 99% dari itu untuk saya jadi saya harus tahu / melakukan sangat sedikit" vs. "menjauh dari jalan saya ketika saya tidak ingin Anda di sana, tetapi bantu saya DIY dengan sangat cepat dan konsisten dengan hal-hal yang sebenarnya saya inginkan untuk digunakan pada wortel daripada prinsip tongkat. " Mendukung yang kedua. Fleksibilitas dan kontrol granular tidak boleh dikorbankan di altar perputaran cepat karena untuk biz, "kita tidak bisa melakukan ini karena alat kita sendiri tidak akan membiarkan kita" tidak pernah merupakan jawaban yang dapat diterima dan pertanyaan akan selalu muncul untuk non- teknik produk sepele / sekali pakai. Dalam pengalaman saya, alat yang tidak fleksibel hampir selalu rusak terbuka lebar atau bekerja secara tidak hati-hati dan membuat kekacauan besar yang tidak dapat dipelihara. Lebih sering daripada tidak, solusi fleksibel / mudah untuk memodifikasi sama cepat atau hampir secepatnya dalam jangka pendek. Cepat, fleksibel, dan dapat dirawat dimungkinkan dengan alat yang tepat.

• FFS, Jika Insinyur Tidak Memutuskan, Setidaknya Dapatkan Input Insinyur pada Memilih Alat

Saya mengerti ini adalah pertanyaan perspektif pengembang, tetapi saya sudah terlalu banyak situasi di mana keputusan teknologi dibuat dengan input nol insinyur. Apa-apaan itu? Ya, seseorang pada akhirnya harus melakukan panggilan terakhir, tetapi dapatkan beberapa pendapat yang berkualifikasi jika Anda seorang manajer non-teknis, bukan apa yang dikatakan beberapa orang penjualan atau situs demo tentang produknya sendiri. Apa pun yang menjanjikan untuk menghemat uang Anda karena orang tidak perlu sepintar atau karena melindungi pengembang dari diri mereka sendiri adalah kebohongan yang kotor dan kotor. Pekerjakan bakat yang bisa Anda percayai. Katakan kepada mereka apa yang Anda inginkan dari tumpukan atau solusi teknologi lainnya dan terima masukan mereka dengan serius sebelum memutuskan kereta musik apa yang akan Anda gunakan.

• Fokus pada Desain Atas Implementasi

Alat adalah untuk implementasi dan karena itu dapat membantu Anda, tetapi prioritas pertama harus menjadi arsitektur terlepas dari set mainan apa pun yang Anda miliki untuk membangun arsitektur itu. Pada akhirnya, KISS dan DRY serta semua filosofi luar biasa yang berkembang dari hal-hal tersebut lebih dari apakah itu dalam. NET atau Java atau mungkin sesuatu yang gratis DAN tidak menyedot.

• Catat Kekhawatiran Anda

Ketika pihak bisnis bersikeras Anda melakukannya dengan cara yang buruk, simpan e-mail itu, terutama bagian di mana Anda mengatakan mengapa itu akan dikenakan biaya. Ketika semua prediksi Anda menjadi kenyataan dan masalah serius yang merusak bisnis terjadi, saat itulah Anda memiliki banyak argumen untuk menangani masalah insinyur dengan lebih serius. Tapi mengatur waktu dengan hati-hati. Di tengah-tengah nyala api neraka adalah waktu yang buruk untuk "Aku-bilang-begitu" untuk mengikuti kode api. Matikan api, dan bawa daftar masalah Anda yang sebelumnya diabaikan ke pertemuan / percakapan retrospektif, dan cobalah untuk tetap fokus pada masalah teknik yang diungkapkan dan diabaikan dan alasan Anda memahami mengapa mereka diabaikan, bukan nama-nama orang yang sebenarnya membuat keputusan untuk diabaikan. Anda seorang insinyur. Tetap pada masalah, bukan pada orang-orang. " Kami menyatakan keprihatinan atas X karena kami takut itu akan menyebabkan masalah Y. Kami diberi tahu Z dan menunda untuk menanganinya. "

Hanya ada satu solusi. Cadangan sekitar 10-20% dari waktu proyek / kerja untuk refactoring. Jika sulit meyakinkan manajemen bahwa itu adalah tugas yang dapat dibenarkan, berikan mereka satu-satunya argumen: tanpa refactoring biaya pemeliharaan kode akan tumbuh secara eksponensial dari waktu ke waktu. Ada baiknya memiliki beberapa metrik / artikel / hasil penelitian untuk mendukung tesis ini selama pertemuan dengan manajer :)

Sunting: ada beberapa sumber daya bagus tentang "refactoring vs meningkatnya biaya pemeliharaan" yang disebutkan dalam whitepaper ini: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

Kapan pun Anda punya waktu untuk melakukan sesuatu dengan benar, gunakan itu - tulis kode terbaik yang Anda bisa, dan tingkatkan terus. Jangan membuat pekerjaan Anda lebih sulit dengan menjadi ceroboh dan memperkenalkan utang teknis ketika tidak perlu.

Panggilan darurat untuk memperbaiki bug parah bukanlah hal yang dapat Anda kontrol sendiri, ketika terjadi, Anda harus bereaksi SECEPATNYA, itulah kehidupan. Tentu saja, jika Anda mendapat kesan bahwa seluruh pekerjaan Anda terdiri dari panggilan darurat, dan Anda tidak pernah punya cukup waktu untuk melakukan hal-hal yang benar, maka Anda sedang berada di jalan untuk kehabisan tenaga dan harus berbicara dengan atasan Anda.

Jika itu tidak membantu, masih ada "strategi Scotty" untuk mendapatkan cukup waktu untuk melakukan hal-hal dengan benar: gandakan semua perkiraan Anda dengan faktor 4:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

Saya melihat pekerjaan saya sebagai menyediakan perangkat lunak berkualitas terbaik yang dimungkinkan dalam batasan waktu yang diizinkan untuk proyek tersebut. Jika saya khawatir bahwa tingkat kualitas akan rendah, maka saya akan melibatkan pemilik proyek. Saya menggambarkan kekhawatiran saya dan membahas potensi risiko penerapan perangkat lunak di negara bagian itu. Satu dari 3 hal akan terjadi pada saat ini:

1. Pemilik proyek tidak akan mau menerima risiko dan akan mengubah jadwal kembali untuk memungkinkan kita menghabiskan lebih banyak waktu pada kualitas perangkat lunak.

2. Pemilik proyek tidak akan mau menerima risiko tetapi tidak bisa mengembalikan jadwalnya. Jika ini terjadi, maka kita perlu bernegosiasi tentang fitur / fungsi apa yang harus dihapus dari ruang lingkup proyek untuk menghabiskan lebih banyak waktu pada kualitas perangkat lunak untuk bagian utama aplikasi.

3. Pemilik proyek akan menerima risiko dan perangkat lunak berkualitas rendah akan keluar sesuai jadwal. Kadang-kadang risiko bisnis tidak menggunakan apa pun (atau menggunakan terlambat) jauh lebih besar daripada risiko bisnis menggunakan perangkat lunak berkualitas rendah, dan hanya pemilik proyek yang dapat membuat keputusan itu.

Perangkat lunak menulis sangat mirip dengan melukis potret. Tidak mungkin untuk mengatakan bahwa potret dilakukan "benar" atau "sempurna". Sempurna adalah musuh yang dilakukan. Anda dapat benar-benar menghabiskan 1 bulan bekerja pada satu metode dan itu masih belum dianggap "sempurna" oleh sebagian orang. Pekerjaan saya adalah melukis potret yang disukai pelanggan.

Ini tidak akan berhasil dalam setiap kasus, tetapi saya beruntung menggunakan strategi ini jika masalahnya adalah masalah produksi yang rusak yang harus segera diperbaiki. Perkirakan waktu untuk melakukan perbaikan cepat agar produksi berjalan dan waktu untuk melakukan perbaikan kualitas untuk masa depan. Sampaikan estimasi kepada bos / klien Anda dan dapatkan waktu yang disetujui untuk keduanya. Kemudian Anda melakukan perbaikan cepat untuk mendapatkan produksi yang berjalan dan perbaikan jangka panjang segera setelah itu ketika tekanan waktu yang mendesak dimatikan. Saya menemukan bahwa jika saya menyajikannya karena saya memerlukan waktu ini untuk menyelesaikan pekerjaan dengan benar, tetapi saya dapat melakukan perbaikan sementara sampai saya dapat melakukan itu, bahwa klien saya sepertinya menyukai pendekatan itu. Itu membuat prod berjalan lagi dan itu butuh perawatan jangka panjang.

Keseimbangan optimal mungkin untuk menghabiskan waktu ekstra melakukannya dengan benar seperti Anda akan membuang waktu memperbaiki bug yang Anda hilangkan dengan melakukannya dengan benar. Hindari pelapisan emas solusinya. Dalam kebanyakan kasus, solusi Volkswagen yang dilakukan dengan benar sama baiknya dengan solusi Cadillac. Anda biasanya dapat memutakhirkan nanti ketika terbukti Anda membutuhkan Cadillac.

Memperbaiki kode yang tidak mengikuti praktik terbaik seringkali membutuhkan waktu lebih lama. Mencoba menemukan dari mana nol berasal ketika panggilan terlihat seperti abcde (), dapat memakan waktu lama.

Menerapkan KERING dan menggunakan kembali kode yang ada biasanya jauh lebih cepat daripada pengkodean dan pengujian solusi lain. Ini juga membuatnya lebih mudah untuk menerapkan perubahan ketika itu terjadi. Anda hanya perlu mengubah dan menguji satu set kode, bukan dua, tiga, atau dua puluh.

Bertujuan untuk kode dasar yang solid. Banyak waktu yang terbuang untuk membuatnya sempurna. Ada praktik terbaik yang mengarah pada kode yang cepat, tetapi tidak harus yang tercepat. Di luar itu, mencoba mengantisipasi kemacetan dan mengoptimalkan kode saat dibangun dapat menghabiskan waktu. Lebih buruk lagi, optimasi dapat memperlambat kode.

Kapan pun memungkinkan, berikan solusi kerja minimal. Saya telah melihat minggu yang terbuang solusi pelapisan emas. Berhati-hatilah dengan ruang lingkup.

Saya menghabiskan beberapa waktu mengerjakan proyek yang seharusnya memakan waktu enam bulan. Ketika saya bergabung, itu sudah berlangsung selama satu setengah tahun. Pimpinan proyek mengajukan satu pertanyaan kepada manajer proyek pada awalnya: "Apakah Anda ingin saya melakukannya dengan benar atau responsif?" Dalam satu minggu, fitur diterapkan Senin, Rabu, dan Jumat; Selasa dan Kamis fitur itu dihapus.

EDIT: Ketika kode dilakukan ke tingkat yang memuaskan, biarkan saja. Jangan kembali untuk memperbaikinya jika Anda menemukan cara yang lebih baik untuk melakukannya. Jika Anda harus membuat sendiri catatan. Jika diperlukan perubahan, tinjau ide Anda dan implementasikan jika itu masih masuk akal.

Jika ada tempat di mana Anda akan menerapkan ekstensi untuk fitur yang akan datang, jangan menerapkan ekstensi. Anda dapat meninggalkan komentar penanda untuk mengingatkan Anda di mana harus melakukan perubahan.

Buat itu berfungsi kemudian buatlah sempurna

Saya mungkin menarik beberapa kelonggaran untuk ini - tetapi jika waktu adalah esensi, maka prioritas utama Anda harus membuatnya bekerja, sesederhana itu. Komentari secara ekstensif tentang kekurangan dalam kode Anda dan catat apa yang telah Anda lakukan dalam perangkat lunak manajemen proyek / waktu yang Anda gunakan.

Semoga ini akan memberi Anda lebih banyak waktu untuk kembali ke masalah ini dan membuatnya sempurna.

Jelas tidak ada jawaban mutlak yang benar untuk ini, tetapi ini adalah jawaban yang saya coba dan pertahankan. Anda mungkin tidak menemukannya cocok dengan gaya kerja Anda saat ini. Yang membawa saya ke alternatif ...

Temukan saja metode yang cocok untuk Anda ; dan kemudian bertahan dengan itu. Setiap orang memiliki cara mereka sendiri dalam menangani proyek dan tidak ada pendekatan "satu ukuran untuk semua". Temukan pendekatan, dan buat itu menjadi milik Anda.

"Melakukannya dengan benar" berarti membuat pertukaran yang tepat untuk situasi tertentu. Beberapa dari mereka adalah:

1. Waktu dan biaya pengembangan
2. Kemudahan membaca, men-debug, dan memperbarui kode nanti (semuanya dari nama variabel hingga arsitektur)
3. Ketelitian solusi (kasus tepi)
4. Kecepatan eksekusi

Jelas, jika sepotong kode akan digunakan sekali dan dibuang, # 2 dapat dikorbankan untuk yang lain. (Tetapi berhati-hatilah: Anda mungkin berpikir Anda akan membuangnya, kemudian menemukan Anda harus terus menggunakan dan memeliharanya, pada titik mana akan lebih sulit meyakinkan orang untuk memberi Anda waktu untuk memperbaiki sesuatu yang "berfungsi".)

Jika Anda dan / atau tim Anda akan terus menggunakan dan memperbarui beberapa kode, mengambil pintasan sekarang hanya berarti memperlambat diri Anda nanti.

Jika saat ini Anda mengirim kode buggy (lemah di # 4) dan butuh waktu lama untuk melakukannya (lemah pada # 1), dan itu karena Anda mencoba memperbarui kode yang lemah di # 2, well, Anda sudah punya argumen yang kuat dan pragmatis untuk mengubah praktik Anda.

Jika itu bug, lakukan SECEPATNYA, jika ini fitur baru, luangkan waktu Anda.

Dan jika Anda bekerja untuk perusahaan yang tidak menghargai pekerjaan pengembang, Anda mungkin tidak punya pilihan selain melakukannya dengan cepat dan mengorbankan kualitas.

Saya telah bekerja untuk sejumlah perusahaan yang hanya berpindah dari satu proyek ke proyek lain, dan melakukan semuanya dengan cepat. Pada akhirnya, mereka hanya sedikit berhasil dalam setiap proyek karena implementasi (bukan hanya pemrograman) dilalui.

Perusahaan-perusahaan terbaik di luar sana mengerti bahwa perangkat lunak yang baik membutuhkan waktu dan keahlian.

Ketika dalam keadaan darurat buat solusi penambalan. Buat bug baru dalam pelacakan bug yang menyebutkan ini. Lakukan dengan benar, kapan pun Anda memiliki waktu yang tepat.

Saya pikir saya melakukan apa yang semua orang yang terjebak bekerja di industri ini. Saya menyelesaikannya secepat mungkin dan jika saya harus meninggalkan beberapa hal baik yang akan membantu mencegah masalah di masa depan, atau membuat penyelesaian masalah lebih mudah di masa depan, saya lakukan. Ini bukan situasi yang optimal tetapi ketika Anda terjebak dengan tenggat waktu berdasarkan estimasi berdasarkan pada estimasi, berdasarkan banyak variabel yang tidak diketahui, itu adalah yang terbaik yang dapat Anda lakukan.

Ini rencana yang bagus:

1. Buat rencana do-it-right Anda mengambil jumlah waktu yang persis sama daripada do-it-asap.
2. Optimalkan waktu Anda untuk melakukannya sampai lingkungan Anda bahagia; menjaga kualitas
3. ???
4. Keberhasilan

Saya melakukan banyak hal dengan cara rutin, cara pertama yang terlintas dalam pikiran. Itu cepat, dan saya suka berpikir bahwa saya seorang programmer yang baik dan saya melakukan banyak hal dengan cukup baik pada percobaan pertama.

Sesekali (saya ingin mengatakan dua kali per hari, tetapi dua kali per minggu lebih realistis), terutama ketika saya menemukan sesuatu yang sangat membosankan untuk dilakukan dengan cara rutin, saya pikir "apa yang akan menjadi cara MENGAGUMKAN untuk melakukan ini ? " dan saya menghabiskan waktu ekstra untuk menemukan atau menemukan cara yang lebih baik untuk melakukannya.

Jika saya terus melakukan hal itu dengan cukup, pengkodean rutin saya akan terus meningkat, saya kira.

Perangkat lunak adalah hal yang aneh dan proses pengembangan perangkat lunak lebih aneh.

Tidak seperti kebanyakan hal dalam kehidupan nyata, tetapi seperti kebanyakan hal yang berkaitan dengan komputer

Lebih cepat lebih bisa diandalkan

Ini bertentangan dengan setiap intuisi yang selama ini Anda ajarkan kepada Anda, mobil yang disetel lebih sering rusak daripada yang standar, rumah-rumah yang dibangun dengan cepat berantakan lebih cepat, pekerjaan rumah yang dilakukan di belakang bus sekolah tidak mendapatkan nilai tinggi.

Tetapi prosedur metodis yang lambat tidak menghasilkan perangkat lunak yang lebih baik. Orang-orang yang menghabiskan berminggu-minggu membuat dokumen persyaratan, dan berhari-hari pada diagram kelas sebelum menulis kode tidak menghasilkan perangkat lunak yang lebih baik. Lelaki yang mendapatkan persyaratan dasar, mengklarifikasi beberapa masalah, mencoret diagram kelas di papan tulis dan membuat kode timnya hampir selalu menghasilkan perangkat lunak yang lebih andal dan lebih baik, dan melakukannya dalam hitungan hari daripada bulan.

Pekerjaan itu tidak tepat untuk Anda.

Kode berkualitas rendah ditulis "karena tidak ada waktu, klien menunggu, bug harus diperbaiki dalam semalam, perusahaan kehilangan uang untuk masalah ini, seorang manajer menekan keras" adalah gejala dari perusahaan yang dikelola dengan buruk.

Jika Anda ingin bangga dengan pekerjaan Anda dan menulis kode berkualitas tinggi, maka hal terbaik yang harus dilakukan adalah menemukan majikan yang mengerti itu dan akan membayar Anda untuk melakukannya.