Apa yang bisa memperlambat pengembang? [Tutup]


12

Hal-hal apa yang cenderung memperlambat pengembang?

Cobalah untuk tidak mengirim jawaban yang:

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

@ Mark Trapp: Hah ?! Itu sama sekali bukan duplikat ...: -S
Tamara Wijsman

1
Jika pertanyaan itu ternyata tidak berguna, saya akan menghapusnya dalam waktu dekat, orang-orang mendaftar gangguan yang sudah tercakup oleh pertanyaan lain dari saya. Jadi saya cenderung mencari hal-hal yang tidak mengganggu ... TheLQ dan Bill adalah contoh jawaban yang bagus.
Tamara Wijsman


Dipilih untuk membiarkan pertanyaan terbuka karena ini tentang hal-hal yang tidak mengganggu ...
Tamara Wijsman

11
Stackoverflow, SuperUser, Programmer ... yeah, pada dasarnya situs-situs seperti ini :)
bedwyr

Jawaban:


49

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.

4
singkatnya: manajemen? ; o)
n1ckp

11
@ n1ck Tidak, tidak. Manajemen yang baik dapat mempercepat pengembang. Penjadwalan waktu programmer yang buruk (yaitu satu aspek menjadi manajer) benar-benar dapat memperlambat pengembangan.
wheaties

3
apa yang membunuh saya adalah ketika perusahaan saya melakukan ini: Rapat, Pertemuan Lebih Banyak, Pertemuan tentang Rapat terakhir, Rapat untuk mempersiapkan, Rapat untuk membahas mengapa kita tidak bisa menyelesaikan apa pun. Mengapa kita tidak dapat mencapai sesuatu? Anda punya empat puluh devs duduk di sebuah ruangan mendengarkan Anda !!
Mike M.

2
Harap perhatikan bahwa jawaban ini hampir sesuai pada slide Powerpoint.

44

Masalah yang sama di sini
pramodc84

1
Saya akan membeli sendiri laptop ASAP dan mengerjakannya jika saya berada dalam situasi itu, dengan asumsi perusahaan mengizinkannya.
adamk

Komputer lambat cenderung menjadi akar penyebab gangguan. Setiap kali programmer menunggu mereka mungkin masuk ke mode gangguan dan tidak akan kembali ke program sampai beberapa waktu kemudian.
edA-qa mort-ora-y

Mereka mengganti komputer saya beberapa minggu yang lalu. Ini kurang kuat dari yang 4 tahun menggantikannya. Bagus.
MetalMikester


25

StackOverflow, programmers.stackexchange.com, dll :)


4
Tidak setuju! StackOverflow membantu menyelesaikan masalah, sehingga mempercepat pengembangan!
Wizard

3
Konyol ofensif. Untuk setiap menit saya sudah 'terbuang' pada SO, itu telah membeli saya kembali 20.
MIA

11
+1. sama sekali tidak menyinggung. SO sangat baik untuk menunda-nunda. Ini facebook baru saya. :)
back2dos

@ back2dos Tolong jangan membandingkan kedahsyatan SO dengan potongan .. yaitu facebook
adamk


15

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.


13

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.


9

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.


Kadang terlalu sunyi di tempat saya berada. Saya mulai memusatkan perhatian pada klik mouse semua orang dan orang-orang bernapas berat, dll ... Ini seperti berbaring di tempat tidur dan mendengar kriket.
kirk.burleson

8

Menulis terlalu banyak baris kode tanpa tes yang memadai.


Ini adalah penyebab utama terhentinya pengalaman saya.
Paddyslacker

1
@Paddyslacker: lebih banyak tes = lebih produktif? Hah? Hanya untuk orang-orang yang tidak seharusnya dalam pemrograman sejak awal. Tes bisa berguna tetapi "penyebab nomor satu hal terhenti"? Apakah kamu serius?
n1ckp

1
@ n1ck: Ya, saya serius. Kode masuk ke kondisi yang tidak dapat dipelihara dan kurangnya pengujian dan kemampuan testis dari basis kode berarti bahwa setiap fitur baru menjadi semakin sulit untuk ditambahkan. Saya merasa lucu bahwa Anda berpikir bahwa Anda pikir orang-orang yang menulis lebih banyak tes "pada awalnya tidak harus dalam pemrograman." Jadi Roy Osherove, Michael Feathers, Paman Bob, Kent Beck dll. Seharusnya tidak dalam pemrograman itu?
Paddyslacker

@Addaddlacker: Saya tidak tahu. Tidak pernah melihatnya kode. Mungkin mereka seharusnya lebih baik dalam manajemen dari deskripsi Anda? Dan mengapa kode menjadi tidak dapat dipelihara karena kurangnya tes tepatnya? Tes membuat kode yang buruk hebat dengan semacam sihir mungkin?
n1ckp

1
@ n1ck, tes tidak membayar ketika menulis kode pada awalnya, tetapi membuat banyak perbedaan ketika harus mempertahankan kode nanti.

5

Kurangnya kopi berkualitas tinggi.


Atau kekurangan soda yang baik. Saya sangat merindukan coke diet tanpa kafein! Di negara saya, saya hanya bisa mendapatkan kokas diet, atau kokas tanpa kafein, dan kokas ceri sama sekali :-(
Wisaya

1
@ Wizard - Saya dulu bekerja di perusahaan yang menyediakan Diet Cherry Coke. Tidak yakin mengapa saya pergi. Jika merasakan sakitmu.
JeffO

2
@ Wizard: cukup beli toples ceri maraschino dan tambahkan sedikit sirup ke minuman Anda. Sekarang Anda dapat membuatnya sekuat yang Anda suka ... (trik yang sama untuk vanilla: vanilla coke nyata jauh lebih unggul dari yang sudah dicampur sebelumnya)
Shog9

@Pak. C: Masalahnya adalah saya perlu diet + kopi tanpa kafein, kombinasi yang tidak tersedia di negara saya.
Wizard

5

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


Jika Anda sering mengalami hal itu, saya akan menyarankan untuk menghabiskan waktu yang tidak sepele untuk belajar memperkirakan. Kemudian Anda dapat menjawab "jika ini merupakan perkiraan, itu menurut definisi bukan jumlah waktu yang sebenarnya diperlukan".
MIA

oh saya sudah pernah menggunakan itu sebelumnya, jawabannya selalu bahwa saya buruk dalam memperkirakan, jika itu tidak dapat dipecah menjadi tugas 2-4 jam yang terlihat maka saya melakukan kesalahan tampaknya
MetaGuru

5

Memperbaiki bangunan rusak orang lain


Kedengarannya seperti seseorang tidak mentoring rekan kerjanya dengan baik.
Nama Tampilan

@bold: itu bisa terjadi secara alami dari asynchronicity. Katakanlah waktu cutoff build harian adalah jam 5 pagi, dan Anda checkout versi terbaru pada jam 9 pagi. (Dengan kata lain, Anda tidak dapat mencegah orang datang ke kantor lebih awal.)
rwong

4

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.


Terkait dengan pertemuan no agenda adalah pembajak rapat. Anda tahu ... Anda menaruhnya di kalender selama satu jam tetapi bahkan jika topiknya selesai dalam 20 menit, ada orang yang pergi untuk mencari topik lain untuk mengisi 20 menit. Saya akan mendukung Anda, tetapi kemudian saya harus menurunkan Anda pada "kurangnya monitor kedua" sebagai memperlambat. Itu nyaman, tetapi tidak memilikinya sesekali tidak memperlambat saya.
MIA

4

Menghabiskan terlalu banyak waktu pemrograman

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


4

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.


3

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


"Berjalan di atas air dan mengembangkan perangkat lunak dari suatu spesifikasi itu mudah jika keduanya dibekukan"
back2dos

1
Kutipan konyol. Berjalan di atas es tidak selalu mudah.
Peter Boughton

1
@Peter Boughton: Jika kita memilih skala, di mana pengembangan perangkat lunak dari fluktuasi spesifikasi itu sulit dan dari yang beku itu mudah, maka berjalan di atas es selalu mudah. Anda dapat mengajar anak berusia 6 tahun untuk melakukan itu. Tapi saya kira Anda tahu itu, Anda hanya bersenang-senang dari kepintaran.
back2dos

Dan Anda dapat mengajar anak berusia enam tahun untuk bekerja dari spesifikasi yang berfluktuasi juga. Itu tidak pintar-pintar, itu jengkel karena terlalu sering menggunakan kutipan seperti itu, yang tidak membantu. Spesifikasi beku tidak mudah untuk dikembangkan jika salah (karena tidak dapat diperbaiki), dan mengubah spesifikasi baik-baik saja jika Anda tahu sebelumnya bagian mana yang mengalami fluks (karena Anda dapat memenuhi kebutuhan itu).
Peter Boughton

3

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.


2

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.

...


+1: Jawaban yang bagus. Saya meninggalkan pekerjaan karena perusahaan tidak mau berkomitmen untuk mengurangi hutang teknis. Pengembang dipaksa untuk "mengulangi fitur tingkat inti infrastruktur berulang-ulang."
Jim G.

2

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.


1
Sepertinya Anda berbicara tentang kemacetan yang disebabkan oleh penyebaran pekerjaan yang terlalu tipis di anggota tim.
MIA

1
Bukan karena tim ini tersebar tipis tetapi manajemen tidak memikirkan ketergantungan dalam menugaskan proyek. Dan sesuatu yang dianggap siap pada saat peolpe lain ditugaskan untuk proyek tidak pernah orang mencoba untuk benar-benar menggunakannya.
HLGEM

2

Menjawab pertanyaan di stackexchange.com, seperti ini.


Anda dapat mempertimbangkan untuk meningkatkan keterampilan mengetik Anda.

2

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.


2
  • 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.


Sepertinya kamu harus keluar dari sana!
adamk

2
  • 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?

1

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.


0

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.


0
  • 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


0

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.


0

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.


-1 Saya dapat memahami pemikiran Anda, tetapi inti dari tahap desain adalah untuk membatasi kebutuhan untuk refactor. Ini juga memfasilitasi pengujian unit yang hebat setiap saat untuk memastikan sesuatu yang berfungsi tidak rusak dan dirilis. Jika Anda tidak melakukan perencanaan apa pun, Anda akan membuat semua orang mendapat pekerjaan lebih sulit ketika mereka harus mencoba mempertahankan kode yang tidak dapat dihindari dengan arsitektur yang buruk.
adamk

Siapa bilang arsitekturnya jelek? Saya hanya mengatakan bahwa Anda tidak ingin fase desain yang berlebihan dan perlu melakukan banyak refactoring dan merancang ulang selama proyek untuk sampai pada kode kualitas. Di sisi lain, agar ini berfungsi, Anda harus memiliki tanggung jawab kode yang jelas dihapus di mana orang yang berbeda tidak mucking di dalam kode masing-masing.
Homde

Pengalaman mengatakan bahwa itu akan memiliki arsitektur yang buruk. Terbang di kursi celana Anda dan pengkodean koboi mungkin adalah hal terburuk yang dapat Anda lakukan selama pengembangan. Memiliki fase desain yang akan berlangsung seminggu, akan menghemat bulan pemrograman dan akan mengarah ke kode yang melakukan apa yang seharusnya untuk pertama kalinya. Gagasan di balik TDD adalah bahwa Anda tidak mengubah tes. Tes-tes itu dimaksudkan untuk meniru kegunaan dunia nyata, dan jika kode Anda tidak dapat menyelesaikan tes, maka kode Anda salah.
Mike S

Pengalaman saya mengatakan sebaliknya, tapi saya rasa itu tergantung pada koboi dan timnya :) Saya telah belajar lebih dari satu minggu coding dan telah melakukan beberapa kode untuk menunjukkannya. Tentu saja Anda akan memiliki arsitektur yang buruk jika Anda tidak melakukan refactoring yang ekstrem dan berkelanjutan dan memiliki tim / koboi yang cukup gesit untuk mengikutinya. Berpikir Anda dapat melakukan "fase desain", mempelajari segalanya dan melakukannya dengan benar saat pertama kali adalah naif. Nilai sebenarnya dari sebuah prototipe adalah pelajaran yang Anda pelajari, Anda membuangnya dan melakukannya dengan benar. Lakukan itu beberapa kali dan cepat :)
Homde

0

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

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.