Bagaimana cara menjadi programmer "lebih cepat"?

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,

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

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

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.

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

"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.

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

Namun seringkali, peningkatan kecepatan berarti mengorbankan kualitas.

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?"

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.

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!

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

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.

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

Belajar mengetik-sentuh secepat mungkin .

Saya melakukannya besok .

Mendapatkan Hal-hal yang Dilakukan juga sangat membantu.

Aku punya rentang perhatian yang pendek, jadi buku-buku ini membantuku tetap fokus ... apa yang aku lakukan lagi?

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.

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

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

Emacs

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.

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

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

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.

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

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.

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.

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.

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.

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

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?

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).