Bagaimana cara menjadi programmer "lebih cepat"?


142

Evaluasi pekerjaan terakhir saya hanya mencakup satu titik lemah: ketepatan waktu. Saya sudah mengetahui beberapa hal yang dapat saya lakukan untuk meningkatkan ini tetapi yang saya cari adalah beberapa hal lagi.

Apakah ada yang punya tips atau saran tentang apa yang mereka lakukan untuk meningkatkan kecepatan output mereka tanpa mengorbankan kualitasnya?

Bagaimana Anda memperkirakan garis waktu dan menaatinya? Apa yang Anda lakukan untuk menyelesaikan lebih banyak dalam periode waktu yang lebih singkat?

Setiap umpan balik sangat dihargai, terima kasih,


96
Habiskan lebih sedikit waktu untuk SO di tempat kerja, jika Anda melakukannya.
San Jacinto

52
Jika Anda membaca ini, ini sudah terlambat

32
Saya membaca "Bagaimana menjadi programmer yang lebih gemuk". Membuat saya tertawa
marcgg

13
Saya akan mengajukan pertanyaan lanjutan kepada Anda. Apakah keinginan Anda untuk menjadi "programmer yang lebih cepat" adalah hasil dari kinerja buruk Anda sendiri (AKA, Anda perlu mengasah keterampilan Anda, Anda perlu fokus dan menghilangkan gangguan (seperti SO), dll), atau perencanaan yang buruk dari pengembangan sudut pandang (AKA, Anda diberikan 1 minggu untuk melakukan sesuatu yang orang waras tahu akan membutuhkan waktu 1 bulan). Setiap item memiliki solusi yang sangat berbeda.

3
Tidak ada jawaban yang tepat, jadi jadikan itu pertanyaan wiki komunitas atau tutup pertanyaan Anda.
Donal Fellows

Jawaban:


190

Matikan komputer. Ambil pensil dan kertas. Sketsa desain Anda. Tinjau dengan rekan-rekan Anda. Kemudian tulis kodenya.


9
ATAU Anda dapat mengaktifkan komputer Anda, dan buka yaitu MS Visio
sshow

208
Pensil dan kertas atau papan tulis lebih cepat daripada kebanyakan aplikasi yang pernah saya gunakan.
Thomas Owens

24
Melakukannya di atas kertas memfokuskan pikiran.

100
mengapa saya tidak bisa menurunkan komentar visio? Tidak menggunakan visio adalah cara tertentu untuk mempercepat pengembangan!

52
Ugh .... Visio. Setiap kali saya diminta untuk "menggunakan Visio dalam dokumen desain Anda", saya pertama-tama membuat sketsa di atas kertas, kemudian menghabiskan dua hari berikutnya berjuang untuk mendapatkan semua baris di Visio yang benar.
Robert Fraser

149

Beberapa ide...

  • Hindari pelapisan emas - lakukan hanya apa yang diminta dari Anda (dalam hal persyaratan)
  • Memahami persyaratan bisnis dan melakukannya dengan benar pertama kali
  • Pahami lingkungan dan alat Anda sepenuhnya
  • Menjadi pengetik yang fantastis, gunakan pintasan keyboard, bukan mouse
  • Ambil pendekatan berulang dan bangun cek kewarasan untuk memastikan Anda berada di jalan yang benar
  • Jangan menemukan kembali roda, pertimbangkan menggunakan kembali pekerjaan sebelumnya dan pekerjaan orang lain
  • Hilangkan gangguan, jangan terus memeriksa email, melihat keluar, berbicara dengan rekan kerja, dll.
  • Jangan terlalu memaksakan diri - kenali kapan Anda perlu istirahat

7
+1 untuk tidak menciptakan kembali roda. Belajarlah untuk menghasilkan kode yang dapat digunakan kembali, yang dapat disambungkan ke kode lain dan bekerja tanpa menulis ulang. (mis .: fungsi dengan parameter, alih-alih hard-coding)

34
+1 untuk "hindari pelapisan emas" - ini telah menyebabkan saya melewatkan terlalu banyak tenggat waktu karena kecenderungan perfeksionis / anal-retensi saya.
Dinah

7
Mengetik - poin penting. Selalu kagum dengan jumlah coders yang saya temui yang belum belajar mengetik ...
Paddy

2
+1 menghilangkan gangguan. Seperti yang saya lihat, mereka adalah pemakan waktu utama.

2
+1 untuk kiat-kiat meningkatkan mikro (alih-alih perbaikan makro dalam hal perencanaan proyek).

132

Keinginan Anda untuk menjadi programmer "lebih cepat" dengan sendirinya patut dipuji. Namun, tidak tepat waktu tidak berarti Anda lambat, itu berarti proyek itu direncanakan dengan buruk. Menjadi seorang programmer "lebih cepat" tidak akan membantu; itu hanya berarti Anda akan lebih cepat melewati tenggat waktu.

Anda (dan tim Anda) melakukan salah satu kesalahan berikut (atau semuanya):

  • meremehkan pekerjaan yang perlu dilakukan;
  • kehilangan persyaratan besar atau bagian arsitektur selama perencanaan;
  • perkiraan kerja yang membingungkan dengan perkiraan kalender dan tidak memperhitungkan hal-hal seperti rapat / telepon / overhead lainnya;

Ada beberapa cara Anda dapat mengatasi salah satu dari tiga di atas. Tetapi sebelum Anda dapat memperbaiki salah satunya, Anda perlu tahu mengapa semuanya berjalan seperti itu. Lakukan postmortem pada estimasi dua atau tiga proyek terakhir vs waktu aktual yang diambil dan cari tahu kemana waktu tambahan tersebut.

Saya akan mengulanginya lagi - lambat dalam menulis kode tidak akan menyebabkan melewati tenggat waktu , jika Anda telah merencanakannya dengan tepat untuk memperhitungkan fakta itu.


47
Beberapa devs benar-benar terlalu lambat. Itu bisa menjadi masalah.

12
Ya, ini bisa menjadi masalah, tapi ini masalah pribadi. Seharusnya tidak pernah menjadi masalah proyek atau tim. Dengan kata lain, ini dapat berdampak pada karier seseorang, tetapi seharusnya tidak pernah memengaruhi jadwal proyek.
Franci Penov

12
'tidak tepat waktu bukan berarti Anda lambat, itu berarti proyek itu direncanakan dengan buruk' - itu adalah deskripsi kotak teks dari argumen yang tidak valid. ada banyak alasan lain mengapa Anda mungkin tidak tepat waktu, salah satunya mungkin karena Anda lambat.
daging

15
@flesh - jika Anda tahu Anda lamban, mengapa Anda tidak merencanakan jadwal Anda untuk memperhitungkan fakta itu? Dengan kata lain, jika Anda tahu Anda tidak bisa berlari secepat Usain Bolt, apakah Anda berencana untuk berlari 100m dalam waktu 9,7 detik?
Franci Penov

5
@ Kibbee - dalam situasi ini Anda memotong fitur. Anda tidak dapat berjanji untuk melakukan pekerjaan tertentu dalam waktu tertentu ketika Anda tahu itu tidak dapat dilakukan dan berharap untuk keajaiban.
Franci Penov

89

Sungguh, pelajari editor Anda. Jika Anda menggunakan IDE, pastikan Anda menggunakan semua fitur yang ditawarkannya. Dapatkan lembar contekan untuk mempelajari pintasan keyboard untuk editor pilihan Anda. Jika Anda menggunakan shell, atur pintasan untuk direktori yang sering digunakan


3
Ini memang kadang-kadang dapat meningkatkan produktivitas secara drastis
sshow

6
Menulis kode aktual hanyalah bagian dari pekerjaan dev. Menghabiskan waktu untuk mempelajari IDE dengan sempurna adalah titik optimalisasi; dan Anda tahu apa yang mereka katakan tentang optimisasi, bukan? - "Ukur dulu dan kemudian optimalkan kemacetan".
Franci Penov

1
Saya tidak melihat ini sama sekali. Jika saya mengetuk 50% dari waktu pengetikan saya, berapa banyak waktu yang bisa menyelamatkan saya dalam sehari? Dalam pengalaman saya, saya menghabiskan sebagian besar waktu untuk berpikir tentang / menguji / mengevaluasi / sedikit memodifikasi kode / dll, dibandingkan dengan benar-benar menulisnya, saya pikir ini akan berakhir menjadi tidak banyak kemenangan sama sekali.

4
Itu membuat menavigasi IDE sesuatu yang Anda lakukan tanpa berpikir. Apa pun yang membutuhkan upaya sadar, seperti pindah ke tombol abu-abu kecil menandai sesuatu atau yang lain di samping semua tombol abu-abu kecil lainnya memperlambat Anda dengan mengganggu pemikiran Anda. Memiliki ctrl-n di bawah ujung jari saya tanpa gerakan apa pun adalah kemenangan besar.
Paul McMillan

5
Sepanjang baris yang sama: pelajari kunci 'panas' umum. Misalnya, dalam banyak program Windows ... Salin: Ctrl + c Potong: Ctrl + x ('x' terlihat seperti gunting terbuka) Tempel: Ctrl + v (tepat di sebelah 'c' dan 'x' di atas) Pergi ke mulai dari baris: Beranda Pergi ke Akhir baris: Akhir Pindahkan kursor dengan kata (bukan karakter): [Shift] + Ctrl + kiri atau kanan Pergi ke atas doc: Ctrl + Home Pergi ke akhir doc: Ctrl + End dll.

38

"Apakah ada yang punya tips atau saran tentang apa yang mereka lakukan untuk meningkatkan kecepatan output mereka tanpa mengorbankan kualitasnya?"

Banyak, banyak orang berjuang untuk kualitas "akhir" dengan mengorbankan sesuatu yang (a) sederhana, (b) dapat diandalkan dan (c) benar.

Cara paling penting untuk mempercepat perkembangan Anda adalah menyederhanakan apa yang Anda lakukan sehingga sesederhana mungkin.

Kebanyakan orang yang memiliki masalah dengan pengiriman tepat waktu memberikan cara, terlalu banyak. Dan alasan yang diberikan seringkali konyol. Mereka sering persyaratan hanya dirasakan, bukan persyaratan aktual.

Saya telah mendengar banyak orang memberi tahu saya apa yang pelanggan "harapkan". Ini adalah kebijakan yang buruk.

Bangun hal yang paling sederhana. Jika pelanggan membutuhkan lebih banyak, bangun lebih banyak. Tapi bangunlah hal yang paling sederhana yang paling mungkin.


"Banyak, banyak orang berjuang untuk kualitas" tertinggi "dengan mengorbankan sesuatu yang (a) sederhana, (b) dapat diandalkan dan (c) benar." Anda bisa membiarkannya begitu saja dan saya akan memilihnya.
corymathews

"Sederhanakan, sederhanakan." ~ Henry David Thoreau

2
Yup ... ini juga berarti abstraksi prematur. Jika sesuatu hanya akan memiliki satu implementasi, jangan membuatnya menjadi antarmuka.
Robert Fraser

3
Salah satu kutipan favorit saya sesuai dalam situasi ini "membuat sesuatu sesederhana mungkin, tetapi tidak sederhana" ~ parafrase, Albert Einstein
Nemi

Tetap sederhana adalah apa yang bahkan banyak programmer tidak mendapatkan dengan benar: mereka jatuh ke dalam perangkap "optimasi prematur adalah akar dari semua kejahatan" dengan mudah. Biasanya program yang paling sederhana adalah yang tercepat atau yang berkualitas tinggi.

32

Hindari memoles kode Anda dengan sempurna, hanya membuatnya bekerja. Itu yang diharapkan bisnis.

Namun seringkali, peningkatan kecepatan berarti mengorbankan kualitas.


10
Saya akan menyarankan "membuatnya bekerja" dan jika waktu memungkinkan untuk menyempurnakannya!
Preet

28
-1: Tidak ada alasan untuk mengorbankan kualitas. Anda selalu dapat mengorbankan fitur.
S.Lott

6
Saya telah melihatnya terjadi berulang kali. Pengembang terhenti pada 1% terakhir dari fitur yang diberikan dan kemudian mengejar ketinggalan dan ketinggalan ketika mencoba untuk menyelesaikan fitur yang tersisa. Selesaikan apa yang diharapkan dari Anda terlebih dahulu, lalu kembali dan poles.

3
Seringkali, peningkatan kualitas berarti peningkatan kecepatan. Jika Anda mengambil sedikit waktu untuk memperbaikinya, Anda mungkin menghemat lebih banyak waktu dalam pengujian dan debugging.
David Thornley

2
Jika Anda terjebak pada satu fitur, kerjakan sesuatu yang berbeda.

29

Penggunaan kembali - Saya mencoba memfaktorkan bit pintar dari proyek sebelumnya, jadi saya bisa menggunakannya lagi di proyek selanjutnya. Selalu layak bertanya pada diri sendiri, "bisakah saya menggunakan ini lagi suatu hari nanti?"


Keadaan pikiran yang sempurna untuk pemrograman yang lebih cepat dalam jangka panjang, meskipun pada awalnya mungkin membutuhkan lebih banyak waktu.

8
+1: Berhati-hatilah, saya telah menemukan diri saya menggeneralisasi dan mengabstraksikan sesuatu sehingga saya dapat menggunakannya lagi di lain hari ... dan melewatkan tenggat waktu hari itu atau menggandakan waktu yang seharusnya diperbaiki oleh bug untuk diperbaiki ... sehingga saya dapat "Mungkin" menghemat waktu nanti.
Steven Evers

2
Memiliki "tas trik" adalah kuncinya. Jika ini menjadi masalah pekerjaan bagi Anda, ada baiknya Anda meluangkan waktu Anda sendiri untuk mengembangkan karya yang dapat digunakan kembali (dengan asumsi domain tempat Anda bekerja dapat menerima penggunaan kembali kode).

24

Tetap sederhana.

Jika Anda menggunakan TDD, Anda harus mengikuti " merah, hijau, refactor ":

  1. Tulis tes yang gagal ( merah ). (Seringkali untuk fungsi kode Anda belum punya.)
  2. Melakukan kejahatan pengkodean yang mengerikan untuk mendapatkan tes Anda lulus ( hijau ). Hardcode jika perlu.
  3. Refactor , mungkin memecahkan tes untuk sementara waktu, tetapi secara keseluruhan meningkatkan desain.

3
Saat melakukan TDD, Anda memiliki pelari uji yang menghasilkan laporan merah / hijau per tes untuk menunjukkan apakah mereka lulus.

2
@Konstantin: Menulis beberapa kode menggunakan TDD mungkin membutuhkan waktu 20% lebih lama, tetapi juga menghasilkan kode yang lebih baik dan dalam jangka panjang, ketika sistem tumbuh, kecepatan membuat perubahan tetap hampir sama. TDD membantu Anda menghindari utang teknis yang memperlambat Anda.

3
Mengetik tidak pernah menjadi bagian lambat dari pemrograman. Meskipun Anda perlu mengetik lebih banyak dengan TDD, itu tidak memperlambat Anda. Bahkan mungkin mempercepat Anda, karena menulis tes pertama membantu Anda untuk fokus pada apa yang diperlukan sebelum berpikir tentang cara mengimplementasikannya.

1
Jika manajemen tidak memahami beberapa konsep utama, Anda harus menjelaskannya kepada mereka. Misalnya martinfowler.com/bliki/TechnicalDebt.html

3
@Konstantin, jika Anda menganggap "pengembangan" sebagai tindakan menulis pernyataan kode, saya setuju dengan Anda. Namun, jika Anda mempertimbangkan "pengembangan" untuk memasukkan pengemasan, menyiapkan catatan pembuatan, menyebarkan, menguji, membuat laporan cacat, meninjau dan memprioritaskan cacat, penugasan tugas, penyelidikan, debugging dan memperbaiki dan memulai proses lagi - kemudian 15 menit untuk tulis tes unit melebihi hari-hari dan hilangnya kepercayaan pelanggan 1000x lebih.

22

Unduh semua dokumentasi bahasa / perpustakaan Anda secara lokal ke komputer Anda, lalu cabut kabel jaringan Anda / matikan Wi-Fi .

Tidak mencoba menjadi lucu di sini. Ini sangat membantu saya!


Saya melakukan hal yang sama.

Lagipula dokumentasi online dan pencarian pemecahan masalah sangat dibesar-besarkan.

Instal firewall dan konfigurasikan untuk memblokir hampir semua akses web (saya punya pengecualian untuk beberapa domain, misalnya MSDN)
finnw

Saya benar-benar mempertimbangkan melakukan ini (fakta bahwa saya meninggalkan komentar ini cukup bukti)
Ikke

Dan kehilangan SO? tidak ada

20

Perhatikan ketika Anda terlalu lama membaca Stack Overflow. Alasan "Kompilasi" hanya bekerja begitu lama. :)


15
Tergantung pada seberapa cepat kompiler Anda. Jadi mungkin "solusi" adalah menemukan kompiler yang lebih lambat dan menjalankannya pada memori Pentium 2 w / 128MB? :-)
Franci Penov

@ Franci, bahkan mungkin menempatkan ruang swap pada floppy disk. Atau dua di RAID.

20

Hindari berpindah tugas terlalu sering. Gangguan dan pengalihan tugas dapat mematikan sehari, bahkan jika Anda menggunakan alat seperti Mylyn untuk mengelola tugas Anda.

Mencari tahu rincian (misalnya, 30 menit) dan hanya mengerjakan hal-hal yang berkaitan dengan tugas yang ada. Hal lain (laporan bug baru, email tentang masalah lain, masalah prosedural yang tidak terkait) tertunda setidaknya sampai "pos pemeriksaan berikutnya". Pastikan untuk menonaktifkan pemberitahuan email yang muncul sehingga Anda tidak akan terjebak.

Ini sangat efektif jika Anda memiliki teman di tim Anda yang akan memberi tahu Anda jika semuanya benar-benar meleleh dan membutuhkan perhatian segera.


Ini tidak akan berhasil jika Anda memiliki atasan yang mengharapkan tanggapan terhadap email dalam 10 menit.
finnw

Ini sebenarnya sangat relevan. Sejauh mungkin, jangan biarkan diri Anda menjadi korban pemikat perhatian egois dan tetap berpegang pada tugas asli Anda. Jika Anda membiarkan diri Anda ditarik ke arah yang berbeda, hasil akhirnya adalah Anda tidak mencapai apa-apa selain dari sesuatu.
AndyUK

14

Lakukan dengan benar, cara terbaik, pertama kali. Jika itu berarti Anda harus berhenti dan memikirkannya sebentar sebelum mulai, maka lakukanlah. Bekerja 90% dari waktu.


2
+1 Ini sangat benar. Itu tidak berarti Anda harus "sempurna"; kita semua akan melakukan kesalahan. Tetapi jika kita melakukan hal-hal dengan cara terbaik yang mungkin dilakukan pertama kali, konsekuensi dari kesalahan itu akan jauh lebih kecil.

+1 - Sepertinya saya ingat pernah membaca di suatu tempat bahwa perbedaan antara programmer yang baik dan programmer yang buruk tidak dalam kecepatan. Perbedaannya adalah bahwa pemrogram yang baik akan menyimpan lebih banyak kode mereka.
Jason Baker

Itu moto saya, lakukan dengan cara yang benar, pertama kali. Jangan terbiasa untuk selalu kembali dan memperbaiki kode Anda, karena Anda tidak melakukannya dengan benar sesuai dengan spesifikasi.

"Jika kamu tidak punya waktu untuk melakukannya dengan benar, bagaimana kamu akan punya waktu untuk melakukannya?"
Alex Feinman

Anda mungkin perlu pengalaman dari software yang sebenarnya untuk dapat menentukan apa yang cara terbaik. Dalam hal ini Anda tidak bisa memperbaikinya pertama kali.

14

2
Ini adalah bonus yang bagus ... tapi saya pikir itu tidak akan berdampak banyak secara keseluruhan. Mengetik kode mungkin adalah bagian yang paling tidak memakan waktu. (Ya, saya mengikuti dan membaca tautannya. Saya hanya tidak setuju dengannya.)

Jika faktor pembatas pengkodean Anda adalah seberapa cepat Anda mengetik, Anda mungkin bekerja pada level abstraksi yang salah.
Pete Kirkham

+1. Tautan yang hebat, artikel yang bagus untuk mereka yang membacanya sampai akhir;) Saya mengetik dengan baik, tapi itu mengilhami saya untuk beralih ke tata letak keyboard Programmer Dvorak en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard (tapi saya mengganti '"dan -_ Kunci dengan Microsoft Keyboard Layout Creator), dan saya yakin bahwa segera saya akan mengetik lebih cepat :) Lihat juga: typematrix.com/dvorak
Roman Boiko


12

Latihan dan kerja keras.

Anda perlu meluangkan waktu dan upaya. Ketika Anda menjadi lebih nyaman dan percaya diri dengan alat apa pun yang Anda gunakan, kecepatan dan kreativitas harus diikuti.

Jika Anda ingin meningkatkan keterampilan tertentu, mungkin juga membantu untuk merancang latihan yang memungkinkan Anda bekerja secara khusus untuk itu. Jika kelambatan Anda dalam fase desain, cobalah mencari masalah desain untuk bekerja secara online. Mengulangi latihan yang sama akan membuat Anda menyelesaikannya lebih cepat dan melatih kecepatan. Saya pribadi suka latihan algoritma TopCoder untuk berlatih kecepatan pemrograman semata. Mereka juga memiliki tantangan desain, tetapi saya belum mencobanya.


Praktek sering diremehkan dalam pemrograman. Ini seharusnya menjadi salah satu dari 5 jawaban teratas.

Wow. Tidak yakin mengapa itu tidak lebih tinggi juga. Saya belum pernah mencoba ini. Saya akan mencobanya!
David

11

Pelajari tentang The Zone, pelajari cara memasukkan diri Anda ke dalamnya, dan pelajari cara mengenali saat Anda tidak di dalamnya.

Setelah saya "di zona" saya sangat produktif dan kode mengalir keluar dari saya, sering saya bisa menyelesaikan 2 atau 3 hari pengkodean dalam 1 hari. Tetapi saya menemukan bahwa sering kali sulit untuk sampai ke tempat itu, saya menemukan diri saya menunda-nunda, menjadi terganggu oleh hal-hal lain (Stack Overflow misalnya).

Kutipan dari trik-lakukan-yang-Anda-gunakan-untuk-mendapatkan-diri-di-zona-Anda


Dan lewati makan siang jika Anda berada di zona ... atau tetap terlambat ... MMMmm Zona. drool

10

Mengetahui IDE dan kerangka kerja Anda dengan baik. Harus beralih ke Google untuk setiap hal kecil membutuhkan waktu.


Tetapi juga menyadari kapan Anda perlu ke Google dan mampu melakukannya dengan cepat adalah penting.

9

1
Harap edit ini agar saya dapat memutarnya, saat ini "terlalu lama".
kmarsh

1
Sangat bergantung pada apa yang Anda butuhkan untuk menggunakannya.

8

Sebelum Anda mulai berkembang:

  • Logout dari kotak surat Anda
  • Matikan semua klien IM
  • Dengan sopan minta teman sebaya untuk memberi Anda waktu berkonsentrasi
  • Tentu saja, berhentilah berselancar di Internet

Setiap kali Anda terganggu, Anda akan melambat karena butuh waktu bagi pikiran Anda untuk kembali ke jalur dengan pikirannya. Saya telah mendengar angka-angka bahwa untuk setiap gangguan, dibutuhkan pikiran manusia 5-10 menit untuk kembali ke proses pemikiran sebelum interupsi. Dengan begitu banyak waktu per interupsi, tidak perlu membuang banyak waktu sepanjang hari.

Orang-orang di perusahaan kami telah benar-benar mengambil waktu di kalender mereka dan kemudian pindah ke ruang konferensi kosong selama beberapa jam setiap hari.


7

Pelajari IDE pengembangan Anda masuk dan keluar. Pelajari tombol pintas. Belajarlah menggunakan mouse lebih sedikit. Saya menemukan bahwa ini menghemat banyak waktu untuk saya.


7

Apakah Anda lebih lambat dari kolega Anda, atau perkiraan Anda lebih optimis?


7

Untuk menghasilkan perangkat lunak lebih cepat, saya telah menemukan hal terbaik untuk dilakukan adalah mempelajari runtime API Anda sebaik mungkin. Jangan mengetik daftar logika ketika ekstensi LINQ akan dilakukan; jangan membangun banyak pendengar acara saat mengikat akan bekerja, dll.

Sejauh estimasi, itu datang dengan pengalaman. Anda dapat menggunakan perangkat lunak estimasi di luar sana untuk membantu Anda mengetahui estimasi yang lebih baik.

Secara pribadi, saya menemukan dengan pengembang tingkat junior, ambil apa pun perkiraan awal mereka dan kalikan dengan 2, lalu gandakan. Ini akan menjelaskan semua pembelajaran, rapat, waktu yang terbuang, dll. Pengembang tingkat yang lebih senior cenderung bekerja pada faktor 2 di atas perkiraan mereka.

Sering kali, pertanyaannya bukan apakah perkiraan Anda salah. Apakah akun perkiraan Anda untuk semua hal yang benar? Apakah Anda memberikan perkiraan dan jadwal dalam hal upaya pengkodean atau dalam hal waktu kalender? Pikirkan sepanjang waktu di hari Anda dan seberapa banyak itu aktual, koding produktif vs rapat, pembelajaran, debugging, dll.


3
"... kalikan dengan 2, lalu gandakan." Karena Anda tertarik menghemat waktu, saya punya tip matematika untuk Anda yang mungkin dapat Anda gunakan ...

LOL - Saya tahu apa yang Anda katakan. Tapi Anda akan kagum dengan seringnya ini tergelincir oleh tanpa disadari, sebagai lawan dari mengatakan "kalikan dengan 4".

7

Dua hal yang mungkin tersirat, tetapi saya belum melihat di antara jawaban di sini yang meningkatkan produktivitas adalah:

  • Gunakan beberapa jenis skrip build dan deployment. Mengkompilasi, menyebarkan, me-restart aplikasi-server dan seperti itu tidak menyedot waktu atau fokus, itu harus menjadi jenis sekali klik.

  • Memiliki semacam kontrol versi. Harus kode tanpa bisa mengembalikan perubahan seperti mencoba berjalan di atas telur


7

Beberapa ide muncul di pikiran:

  1. Dapatkan pendapat lain tentang perkiraan Anda - Apakah ada pengembang lain yang bisa Anda tanyakan seperti "Hei, apakah Anda pikir Anda bisa menyelesaikan fitur semacam ini dalam jangka waktu ini?" Gagasannya adalah bahwa masukan orang lain mungkin membantu akurasi dalam beberapa kasus karena seseorang mungkin mencatat banyak hal yang Anda lewatkan dalam membuat perkiraan.

  2. Asah keterampilan estimasi Anda - Mulailah melacak seberapa jauh Anda pada estimasi dan mengapa Anda tidak aktif: Apakah item pekerjaan lain yang menyebabkan tenggat waktu tidak terpenuhi? Apakah Anda secara konsisten meremehkan betapa rumitnya sesuatu itu? Apakah Anda memberikan seluruh waktu ketika itu tidak praktis, misalnya apa yang ditanyakan cukup samar sehingga hanya perlu membuat prototipe hingga berminggu-minggu dan kemudian harus ada evaluasi ulang apa lagi yang harus dilakukan? Melakukan hal ini mungkin paling membantu dalam membangun keterampilan itu sehingga jika Anda mengatakan sesuatu akan memakan waktu x jam, Anda dapat memiliki keyakinan akan hal itu karena Anda telah melakukannya berulang kali. Cara alternatif untuk menyatakan ini hanyalah latihan, latihan, latihan.

Memang Anda mungkin sudah mempertimbangkan ini, tetapi saya hanya berpikir ada baiknya menyatakan ini untuk orang lain di luar sana yang mungkin tidak mempertimbangkan ide-ide ini.


7
  1. Ketahui teknologi luar dan dalam.
  2. Berhenti! Berpikir! Pergi!
  3. Arsitek untuk apa pun yang mungkin muncul, tetapi hanya menerapkan apa yang benar-benar diminta.
  4. KISS - Keep It Simple Stupid
  5. Jika terlalu rumit, mungkin, itu tidak dipikirkan dengan baik. (Kembali ke 2 dan 4)
  6. Jangan terjebak dalam 5. Sering membayar untuk memulai dari awal (Kembali ke 2 dan 4)
  7. Kembali ke 1.

7

Saya pikir kata kunci mereka di sini adalah "ketepatan waktu". Mereka tidak mengatakan Anda terlalu lambat, melainkan karena Anda tidak tepat waktu.

Dalam manajemen proyek, penting bagi manajer untuk dapat memperkirakan kapan item pekerjaan Anda akan lengkap dengan akurasi. Saya menduga bahwa alasan utama mengapa upaya Anda tidak dianggap tepat waktu adalah bahwa Anda sering memiliki barang yang tidak terkirim sesuai jadwal, dan dikirim jauh lebih lambat dari yang dijadwalkan.

Untuk meningkatkan ketepatan waktu Anda, Anda mungkin ingin meluangkan lebih banyak waktu untuk memahami berapa lama waktu yang dibutuhkan untuk menyelesaikan item pekerjaan tertentu yang diberikan keterampilan, pengalaman, dan domain Anda. Ini akan memungkinkan Anda untuk memberikan perkiraan yang lebih baik kepada manajer proyek Anda. Kuncinya di sini adalah "lebih baik" ... Anda dapat mengirimkan tepat waktu lebih sering dengan mengisi semuanya dengan faktor fudge, tetapi yang ingin Anda perjuangkan adalah perkiraan yang lebih akurat.

Saya akan membahas ini dengan manajer Anda untuk melihat apakah ini benar-benar masalah. Jika tidak, Anda mungkin berakhir pemrograman dua kali lebih cepat, hal-hal yang menjanjikan dalam setengah waktu yang Anda gunakan, dan masih mendapatkan kritik karena ketepatan waktu Anda karena perkiraan Anda masih akan memiliki faktor kesalahan yang sama.


"... Luangkan lebih banyak waktu untuk memahami berapa lama waktu yang kamu butuhkan untuk menyelesaikan item pekerjaan tertentu mengingat keahlian, pengalaman, dan domainmu." -> Benar, dan ini juga akan membantu Anda memangkas ruang lingkup dan menghemat lebih banyak waktu.
Jim G.

Ini juga akan membantu manajer Anda terlihat baik bagi orang-orang di sekitar mereka - Ini juga memungkinkan materi pendukung seperti pemasaran diselesaikan selaras dengan proyek Anda.
Tom leys

7

Dapatkan stabil, tetap stabil.

Bangun sesuatu yang mengimplementasikan sedikit fungsi, dan pastikan itu berfungsi, end-to-end. Kemudian, tetap berfungsi saat Anda menambahkan bit fungsionalitas baru. Ya, ini sebagian merupakan praktik TDD, tetapi masuk akal bahkan jika Anda tidak melakukan TDD.

Alasannya adalah bahwa setiap kali saya pernah melihat seseorang dengan 2 minggu dari kode yang tidak pernah stabil, selalu memakan waktu 2 minggu untuk mendapatkan stabil.

Jika Anda tetap stabil, Anda menghilangkan ketidakpastian itu, dan juga memberi diri Anda cara untuk lingkup di dekat tenggat waktu jika perlu.

Argumen kontra yang jelas adalah bahwa melakukan hal ini akan membutuhkan lebih banyak waktu daripada hanya menulisnya sekali saja, karena Anda akan melakukan pekerjaan ekstra untuk menstabilkan kode non-final. Saya tidak membeli ini sebentar. Ketika Anda memiliki kode yang berfungsi , Anda mengubah 5 baris, dan sesuatu rusak, Anda tahu persis di mana kerusakan itu terjadi.

Jika Anda memiliki 10.000 baris kode yang tidak pernah berfungsi , dan Anda harus menemukan jeda, Anda memiliki banyak kode untuk dicari.

Perubahan kecil dan bertahap pada sistem FTW yang stabil secara konsisten. Lambat untuk melaju cepat.


7

Bagi saya, mendapatkan produktivitas yang baik adalah memiliki gagasan yang jelas tentang apa yang ingin Anda capai, dan bagaimana Anda akan sampai di sana.


1
Perjalanan bersepeda 30 menit saya untuk bekerja di pedesaan Norwegia juga cukup bagus untuk menjernihkan pikiran dan membuat proses kreatif berjalan.

6

Hampir semua jawaban telah dikatakan mati di banyak tempat di sini dan di tempat lain. Atau, setidaknya saya sudah mendengarnya sampai mati. Pelajari IDE Anda, belajar mengetik lebih cepat, menggunakan kerangka kerja, menggunakan pembuatan kode, dll, dll. Ya tentu saja hal ini akan membantu dan saya ragu ada banyak programmer yang menguasai semuanya. Tetapi sebagai tipe programmer yang menanyakan pertanyaan-pertanyaan ini dan sering mengunjungi situs-situs seperti Stack Overflow, Anda sudah mengetahui hal-hal ini . Apakah Anda hanya ingin mengulanginya di sini atau Anda hanya ingin sedikit curhat?

Tetapi bagaimana jika kita bisa mencapai kondisi itu? Maksud saya menguasai semua saran ini? Lalu apa yang akan terjadi? Baik. Saya kira garis waktu akan berkurang lebih jauh. Dan lagi, kami akan kembali ke persepsi kualitas. Maksud saya, kerajinan kami sudah pasti berkembang dan menjadi lebih dan lebih produktif selama beberapa dekade. Tetapi apakah kualitas meningkat selama waktu ini (tidak termasuk tahun-tahun awal tentu saja)?

Jawaban saya sederhana: perangkat lunak berkualitas membutuhkan waktu ! Anda hanya dapat berdagang satu untuk yang lain (kualitas / kecepatan). Tapi ya kita semua tahu bahwa bagaimanapun juga kita tidak jujur ​​tentang sejauh mana pertukaran itu sering berakhir dengan kecepatan akhir dari skala. Dan kita adalah pembohong yang lebih besar di awal proyek!

Saya mengatakan bahwa Anda tidak bersalah di sini. Masalahnya adalah persepsi orang tentang berapa lama kualitas perangkat lunak harus diambil. Kami membodohi diri sendiri dengan meyakini bahwa kami mampu menciptakan perangkat lunak berkualitas dengan jenis garis waktu yang digunakan manajer kami atau bahkan kami memperkirakannya. Kami tidak membuat perangkat lunak yang berkualitas . Kami menulis perangkat lunak yang berfungsi tetapi terkadang dengan kilatan kualitas di sudut-sudut tertentu suatu aplikasi.

Jadi apa yang bisa kita lakukan tentang ini? Kami tidak bisa begitu saja meyakinkan bos kami bahwa kami perlu menggandakan atau melipatgandakan investasi dalam setiap proyek kami. Saya katakan memimpin dengan memberi contoh. Buat perangkat lunak yang benar-benar hebat sebagai proyek sampingan. Masukkan waktu Anda sendiri ke dalamnya dan jangan berkompromi. Sementara memperhatikan bagaimana Anda maju. Catat tugas-tugas yang tampaknya tidak berhubungan yang harus Anda lakukan dengan jumlah waktu yang tidak terduga dan lihat apakah Anda dapat membenarkannya. Bandingkan ini dengan semua proyek lain yang pernah Anda kerjakan. Jadilah jujurdengan diri Anda sendiri dan semua aspek analisis ini. Dapatkah hal-hal ekstra yang Anda lakukan dengan perangkat lunak berkualitas Anda diabaikan dalam proyek "nyata" di tempat kerja? Tapi mungkin usahamu gagal. Apa alasannya? Apakah Anda bosan dan hanya bergegas untuk menyelesaikan fitur inti? Saya sendiri belum melakukan sesuatu seperti ini, itulah sebabnya saya mengakhiri pemikiran ini dengan sedikit keraguan - tetapi saya bermaksud untuk mencobanya. Saya akan membuat Anda diposting :).

Akhirnya, saya pikir sebagian besar (jika tidak semua) evaluasi kinerja bengkok dan sangat manipulatif. Anda tidak dapat membatasi kualitas dan kecepatan pada 100%. Atasan Anda harus membuat skor Anda terhadap standar yang ditetapkan oleh organisasi. Standar organisasi tentang pertukaran antara kualitas dan kecepatan. Mari kita bayangkan bahwa OrangeSoft Inc. mengharapkan kualitas 33% dan kecepatan 66%. Jadi, jika Anda menulis kode yang mungkin memiliki sepertiga dari tes unit itu harus tetapi membuatnya dengan kecepatan dan mengurangi waktu pengiriman Anda harus mencetak hampir 100% pada ulasan Anda! (Ini adalah analogi yang cukup kasar tetapi Anda mengerti maksudnya). Tetapi sebaliknya, yang terjadi adalah bahwa Bob menulis kode dengan sangat cepat tetapi yang terkenal buggy. Jadi pada ulasan kinerjanya dia akan skor 3/5 untuk kualitas dan 5/5 untuk kecepatan. Sebaliknya, Carol menulis kode jauh lebih lambat tetapi menghasilkan lebih sedikit bug. Dia skor 5/5 untuk kualitas tetapi 3/5 untuk kecepatan. Either way Bob dan Carol bisa merapat pada kenaikan gaji mereka. Apakah mungkin bagi setiap karyawan untuk mendapatkan skor sempurna? Apakah ini adil?


5

Teknik yang saya gunakan adalah prototyping evolusioner

Anda dapat google untuk info lebih lanjut - tetapi jika kebutuhan adalah untuk menghasilkan sesuatu dengan cepat, ini tentang satu-satunya cara untuk pergi. Plus, itu memiliki manfaat bahwa ketika pengguna mengatakan bahwa dia menyukainya, Anda sudah selesai (... dan dapat mulai melakukan dokumentasi).

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.