Apa yang bisa memperlambat pengembang? [Tutup]

Hal-hal apa yang cenderung memperlambat pengembang?

Cobalah untuk tidak mengirim jawaban yang:

• lambat sekarang tetapi bermanfaat dalam fitur. (TDD, Refactoring, ...)
• daftar selingan .

Oh, ini mudah:

1. Rapat
2. Lebih Banyak Rapat
3. Pertemuan tentang pertemuan terakhir
4. Rapat untuk mempersiapkan pertemuan mendatang
5. Mengembangkan presentasi power point untuk rapat
6. Mengembangkan presentasi power point untuk rapat yang membahas fitur-fitur yang belum diterapkan, tidak boleh diimplementasikan, dan untuk alasan apa pun pria penjualan akan melompati semuanya. Saya tidak dapat memprediksi dokumen apa yang ingin Anda tampilkan di aplikasi berdasarkan lokasi Anda saat ini tanpa koneksi internet atau akses ke hard drive Anda. Tidak juga, menyerah saja memintanya juga.

Komputer lambat

Apa pun yang menyebabkan pengalihan konteks .

StackOverflow, programmers.stackexchange.com, dll :)

Saya akan mengatakan kelelahan.

Segala upaya untuk mengikuti proses yang tidak sesuai dengan tugas yang dihadapi.

Ini bisa bermacam-macam, tapi yang umum saya lihat meliputi:

• metodologi pengujian yang tidak sesuai dengan kode yang sedang diuji
• proses yang secara dramatis lebih gesit atau tradisional daripada surat perintah yang dapat disampaikan
• pedoman yang dimaksudkan untuk toolset berbeda dari toolset yang dipilih
• desain kepala sekolah yang tidak sesuai dengan kebutuhan proyek
• menggunakan toolset yang tidak cocok untuk tugas tersebut

Semua hal ini dapat sangat bermanfaat pada beberapa proyek atau dalam beberapa situasi, tetapi beberapa organisasi mencoba melakukan segalanya dengan satu cara dan yang menyebabkan kecocokan yang buruk pada proyek lain yang sering kali adalah kematian produktivitas.

Politik

misalnya: Ketika lebih dari satu orang memiliki persyaratan (atau lebih buruk, dua kepentingan berbeda), dan mereka membuat perubahan bersaing dan bertentangan dengan persyaratan saat pengembangan sedang berlangsung.

Percakapan orang lain

dan kebisingan secara umum

Banyak jawaban berbicara tentang pengalihan konteks dan keluar dari zona, dan kebisingan, terutama percakapan, adalah salah satu hal yang mengarah kepada saya.

Di dunia kecil saya, saya dikelilingi oleh kebisingan dan percakapan di semua sisi. Satu baris berakhir, tim mainframe mengadakan pertemuan perencanaan konstan di baris kubus. Kadang-kadang, mereka akan bertemu dengan konsultan di kantor di sepanjang dinding, dan itu cenderung mengarah pada teriakan keras dan teriakan dan tertawa dan aku harus pergi dan meminta mereka untuk menutup pintu.

Di sisi lain, tabel konferensi tim web ada di sisi lain dinding kubus barat saya, jadi saya bagian dari setiap pertemuan, suka atau tidak. Ada juga sebuah printer di sisi lain dari dinding kubus selatan, dan itu selalu bagus untuk chit-chat dari orang-orang yang nongkrong menunggu hasil cetak mereka.

Jawaban langsung dan jelas dari " Tidak bisakah Anda mendapatkan headphone peredam bising" tidak membantu ketika apa yang Anda inginkan adalah diam.

Kadang-kadang untuk ulasan kode, saya membawa setumpuk kertas ke ruang makan siang (tentu saja di waktu non-makan siang), tetapi ada TV di sana yang biasanya menggelegar. Saya akan mematikannya jika tidak ada yang menonton. Kalau tidak, saya akan mencari kubus kosong di departemen lain di bagian lain gedung.

Jika Anda ingin programmer Anda melakukan pekerjaan yang perlu mereka lakukan, yang sebagian besar berpikir dan mempertimbangkan dan mempertimbangkan, mereka membutuhkan lingkungan di mana mereka dapat melakukannya.

Menulis terlalu banyak baris kode tanpa tes yang memadai.

Kurangnya kopi berkualitas tinggi.

harus membuat perkiraan sempurna yang tidak boleh membelok dari begitu pembangunan dimulai, ini adalah skenario ayam-telur menurut saya

Memperbaiki bangunan rusak orang lain

Rapat tanpa agenda.

Mesin lambat.

Kurangnya monitor kedua.

Mouse tua yang memiliki bola bukan yang baru dan bagus.

Kurangnya akses internet pada mesin, membuat query MSDN / stackoverflow / etc sedikit menyakitkan.

Menghabiskan terlalu banyak waktu pemrograman

Bahkan jika Anda benar-benar menyukai pemrograman, menghabiskan terlalu banyak waktu pada akhirnya akan membuat Anda lelah ...

Hindari segala sesuatu yang membuat Anda keluar dari "zona". Itu berarti kotak masuk email Anda, aplikasi sembulan twitter Anda, obrolan perusahaan Anda, dll.

Memiliki kondisi kerja yang tenang berarti menghindari kebisingan desktop itu juga.

Setiap permintaan perubahan yang akan lebih mudah diterapkan jika Anda mengetahuinya sebelumnya.

Kode buruk

Harus menulis ulang bagian dari orang lain yang bisa melakukan pekerjaan dengan benar di tempat pertama adalah waktu terbesar yang dapat saya bayangkan.

The Much That Slows You Down adalah posting blog yang bagus untuk ini.

...

Banyak proyek mengulangi fitur tingkat infrastruktur inti berulang-ulang, memperlambat bisnis itu dalam memberikan fitur yang membedakan bisnis dari para pesaingnya.

...

Tidak dapat dihindari bahwa produk dan inovasi akan membantu mengurangi waktu yang dihabiskan pengembang untuk tugas-tugas yang tidak membedakan. Pertanyaannya adalah seperti apa bentuk layanan dan alat itu.

...

Nah akhir-akhir ini perlambatan terbesar adalah karena kami sedang mengembangkan beberapa hal secara simultan yang seharusnya dilakukan dalam urutan tertentu. Jadi saya menunggu sampai (nama diubah untuk melindungi orang yang tidak bersalah) John menyelesaikan komponennya yang saya butuhkan untuk paket SSIS saya dan Harry diperlambat menunggu saya untuk mengimpor catatan karena dia perlu beberapa data untuk melihat untuk menguji ekspornya (pernah mencoba untuk menulis laporan ekspor yang kompleks ketika tidak ada data di salah satu tabel?) dan semua orang melambat karena desain belum selesai dan tabel database yang perlu kita lakukan tugas kita belum dibuat dan bahkan mungkin tidak berakhir menjadi apa yang mereka katakan akan terjadi, dll.

Menjawab pertanyaan di stackexchange.com, seperti ini.

Meskipun Anda diminta untuk tidak membuat daftar gangguan, itu bisa menjadi faktor besar. Lihatlah lingkungan kerja mereka, periksa untuk melihat apakah mereka sering terganggu atau diminta untuk melakukan hal-hal lain yang tidak terkait dengan proyek.

Kadang-kadang, pengembang mungkin macet karena mereka melakukan sesuatu yang belum pernah mereka lakukan sebelumnya, dan mereka tidak tahu di mana mencari bantuan. Jika itu tim kecil atau individu, itu bisa menjadi lebih sulit. Kita cenderung agak sombong dan tidak suka mengakui ketika kita tidak tahu bagaimana melakukan sesuatu. Juga, kami tidak suka meminta bantuan orang lain. Tidak ada cara mudah untuk membuat pengembang mengakui hal ini, kecuali mungkin bertanya apakah mereka dapat memenuhi tenggat waktu, atau apa yang mereka butuhkan untuk memenuhi tenggat waktu, dan kemudian berharap mereka akan jujur. Anda mungkin perlu menawarkan untuk membawa bantuan lain, atau menemukan seseorang yang dapat membantu mereka.

Kurangnya persyaratan yang jelas, yang menyebabkan mereka harus memikirkan atau membuat keputusan.

• Harus menunggu sekitar 15 menit agar PC boot ke keadaan yang dapat digunakan
• Menunggu PC untuk berpindah aplikasi
• Menjadi satu-satunya orang di kantor yang harus membuat teh / kopi sendiri.
• Keyboard yang rusak (diperbaiki!)
• Bekerja di luar kantor Managing Director (CEO AS) (dan juga bukan di kantor), dengan hanya satu partisi di antaranya (terutama ketika ada rapat)
• Bos hanya bisa dihubungi melalui email, tetapi semua orang ada di gedung
• Tidak diizinkan menggunakan VCS - tampaknya itu seharusnya ada di otak saya
• Layar kecil
• Tidak memberikan waktu istirahat selain makan siang
• Harus melakukan backup server jarak jauh meskipun memiliki sysadmin di gedung
• Disuruh melakukan backup kata secara manual.
• Terpaksa menggunakan sistem manajemen waktu bodoh yang tidak perlu rumit
• Hanya mendapatkan ide samar tentang persyaratan dua bulan ke pekerjaan

Saya bisa melanjutkan, tapi ini hari Jumat dan saya ingin melupakan pekerjaan.

• Kurangnya dokumentasi (Sistem, Perusahaan, dll.)
• Kurangnya kode komentar
• Pemahaman sistem yang tidak lengkap
• Politik (mis. Rapat yang tidak perlu, dokumen, hambatan oleh manajemen ...)
• Dokumentasi persyaratan tidak lengkap
• Facebook!
• Terlalu banyak tidur?

Terlalu banyak orang dalam proyek ini.

Melihatnya beberapa kali ketika manajemen memutuskan berdasarkan tidak ada data nyata bahwa mereka perlu menambahkan lebih banyak orang ke proyek. Itu berakhir di ppl yang tahu apa yang terjadi perlu menghentikan segalanya untuk memegang tangan orang yang tahu sedikit tentang apa yang terjadi. Saya telah melihat lebih dari satu jamur proyek dalam ukuran dan kemudian pergi ke toilet dengan cepat dari sana sedangkan sebelum itu berjalan dengan baik, meskipun mungkin agak lambat.

Jadi Anda beralih dari terlambat satu bulan karena tidak cukup kecepatan / terlalu banyak yang harus dilakukan untuk tidak memberikan sama sekali karena Anda benar-benar merusak anggaran pada semua orang tambahan itu.

Terlepas dari hal-hal yang disebutkan oleh orang lain, jauh antara memutuskan untuk mengkompilasi & menjalankan kode Anda dan mendapatkan hasil positif / negatif . Idealnya, RTT ini hanya sebentar, tetapi saya telah melihat contoh jam. BTW, unit testing mencoba menangani masalah ini.

Lain terkait ini adalah latensi umum dari lingkungan kerja Anda. Bayangkan Anda perlu bekerja melalui koneksi desktop jarak jauh ke komputer di sisi lain dunia, melalui koneksi yang menyeramkan. Aku pernah disana. Saya benci ini.

• Dokumen yang berlebihan

• Memiliki ketergantungan pada seseorang yang tidak pernah ada (seperti bos Anda - jika Anda perlu mengajukan pertanyaan tetapi dia selalu ada dalam rapat)

• Alat & peralatan tidak memadai.

• Orang-orang mendorong dayung mereka tanpa alasan (perubahan apa pun yang terlihat oleh UI tunduk pada hal ini) atau hanya berdebat tentang hal-hal sepele.

• Mesin kopi rusak

• Ditugaskan tugas yang salah

Pendingin udara gagal berfungsi.

Jadi suhu di kantor mencapai 40 derajat pada musim panas -5 di musim dingin.

-5 tidak baik untuk mengetik, karena saya tidak bisa memakai sarung tangan dan mengetik. 40, hanya memperlambat pemikiran saya.

Ini adalah pendapat yang sangat pribadi dan mungkin kontroversial, tetapi merencanakan dan terlalu banyak berpikir tentang desain di muka atau menulis kode "kualitas" sepanjang waktu. Ada pepatah yang mengatakan bahwa "pengkodean selama berminggu-minggu dapat menghemat waktu perencanaan" yang mungkin benar dalam beberapa kasus.

Namun saya sering melihat programmer mencoba membuat sketsa desain yang bagus sebelum memulai pengkodean. Saya menemukan diri saya bahwa lebih mudah untuk hanya "pergi", karena Anda memprogram Anda akan belajar lebih banyak tentang masalah dan solusi Anda yang akan memungkinkan Anda untuk memperbaiki solusi Anda dengan cepat menjadi desain yang baik. Sebagian besar masalah yang timbul cukup banyak yang tidak diketahui pada awal pengkodean (minimal ke pikiran lemah saya) sehingga membuang banyak waktu merancang di muka hanya membuang-buang waktu.

Ini juga mengapa saya tidak suka TDD, Anda membuang terlalu banyak waktu untuk menulis tes yang membuat Anda cenderung untuk refactor atau membutuhkan banyak waktu untuk menulis ulang tes. Unit Test sangat bagus untuk beberapa kasus dan beberapa tahapan proyek, tetapi permulaannya bukan salah satunya IMHO :)

Dapatkan sesuatu bekerja dengan cepat dan tingkatkan.

Block Programmer : Tidak seperti slow down lainnya, ini lebih sulit untuk diselesaikan.