Bagaimana waktu kerja Anda didistribusikan antara pengkodean dan berpikir? [Tutup]


8

... dalam persentase. Misalnya 60/40 atau 90/10 atau 100/0.

Hipotesis saya adalah semakin besar proporsi waktu yang Anda habiskan untuk memikirkan semakin kecil kode Anda (dan semakin sedikit waktu yang dibutuhkan untuk menuliskannya). Pikirkan lebih banyak, tulis lebih sedikit, dengan kata lain. Apakah Anda pikir itu benar?

Sebagai catatan, saya pikir di perusahaan perangkat lunak tipikal berpikir bukan bagian dari budaya: Anda biasanya seharusnya duduk di sana di komputer Anda mengetik sesuatu. Anda hampir pasti akan diperhatikan oleh manajer Anda jika Anda berkeliaran dengan tatapan kosong memikirkan langkah selanjutnya dengan kode Anda. Sangat buruk.



1
@ Chris: tidak persis, pertanyaan itu adalah tentang pengkodean versus "Membaca seputar subjek, meningkatkan pengetahuan, mempelajari hal-hal baru", yang tidak sepenuhnya memikirkan tindakan Anda. Meskipun ya, pemikiran disebutkan dalam beberapa jawaban.
mojuba

Ini hanya pertanyaan yang lebih tepat dari itu. Anda meminta pengkodean: waktu berpikir, pertanyaan itu adalah pengkodean: <apa pun kecuali pengkodean>. Cukup mirip dengan saya.
Chris

2
@ Chris: sama sekali tidak. Perbedaan besar antara memikirkan langkah Anda selanjutnya vs aktivitas apa pun selain coding. Yang ingin saya katakan di sini adalah Anda dapat meningkatkan kode dengan berpikir lebih banyak sebelum mulai coding.
mojuba

4
Saya sangat merekomendasikan Anda berpikir sambil kode.

Jawaban:


9

Saya kode di jalan terakhir.

Katakanlah 50% berpikir, 50% pengkodean termasuk 10% implementasi dan 40% debugging.


Luar biasa, saya pikir 50/50 adalah proporsi yang tepat meskipun akan tampak tidak masuk akal bagi banyak orang.
mojuba

2
Ya itu berlawanan dengan pandangan pikiran produksi-pabrik. Anda harus memahami bahwa pemrograman adalah semua pemecahan masalah, bukan kode "manufaktur", sebelum menyetujui bahwa Anda sebaiknya berpikir banyak sebelum bertindak.
Klaim

pasti debugging dapat mencakup pemikiran juga
jk.

Jelas ya. Tetapi pada kenyataannya itu masih hanya proses pikiran pemecahan masalah, sementara coding dan debugging sementara coding lebih mekanis, lebih rendah levelnya. Anda dapat menganggap berpikir sebagai membuat strategi, sementara coding menerapkannya, menggunakan taktik untuk menyesuaikan strategi Anda dengan konteks.
Klaim

Sebelum manufaktur terjadi, seseorang harus menghabiskan banyak waktu untuk berpikir dan bermain-main untuk menyempurnakan produk itu ... jadi ada banyak pemikiran dalam pembuatan juga ... itu terjadi lebih banyak di depan ... dan seringkali oleh orang yang berbeda .
CaffGeek

10

Seperti hal lain, itu tergantung

Pada awal sesuatu, sebagian besar waktu dihabiskan untuk berpikir dan merencanakan cara membuat kode. Setelah Anda memiliki rencana, sebagian besar waktu dihabiskan untuk coding.


+1, Tidak masuk akal untuk menggeneralisasi. Rasio akan sangat berbeda untuk menerapkan B + Tree daripada untuk menulis operasi CRUD.
dan_waterworth

5

60% Berpikir / 40% Pengodean

Saya tidak hanya berpikir di tempat kerja. Saya berpikir ke mana pun saya pergi. Saya cenderung tidak memulai pengkodean sampai saya memikirkan semua kemungkinan. Saya tidak berbicara tentang menulis kode di kepala saya, saya berbicara tentang melakukan penyempurnaan bertahap di kepala saya.


3

Beberapa hari saya menulis satu baris kode, namun menyelesaikan lebih banyak pekerjaan (dalam menjalankan aplikasi) daripada hari berikutnya saya menulis seribu. Manajer saya akan menyebut hari pertama sia-sia, dia melihat LOC yang diproduksi per hari untuk mengukur produktivitas (atau mereka dulu, kurang begitu hari ini).

Apakah saya kurang memikirkan hari kedua? Mungkin, tergantung pada jenis pengkodean di tangan (jika itu query tanpa alasan dari database yang telah saya lakukan ribuan kali sudah tidak banyak tantangan mental).


2

Kode yang lebih pendek umumnya lebih baik tetapi tidak selalu.

Mengapa menghukum pengembang yang meningkatkan kefasihan melalui pengalaman dan tahu persis apa yang mereka lakukan? Setiap baris kode tidak harus menjadi rodeo pertama Anda.

Jangan berasumsi karena saya mengetik yang tidak saya pikirkan. Mengetik tidak membutuhkan banyak upaya mental.

Perencanaan sangat penting, tetapi jangan bingung dengan memikirkan kode Anda.


Itu poin yang bagus, saya sebenarnya bermaksud memikirkan kode Anda lebih dari merencanakan / mendesain produk secara keseluruhan.
mojuba

2

Berbeda dengan sebagian besar "% menghabiskan pemikiran"> "% menghabiskan jawaban kode" di atas, saya (agak mengejutkan saya) menemukan bahwa saat ini produktivitas saya berkorelasi dengan penekanan tombol saya. "Saat ini" adalah kuncinya: Saya belajar bahasa / sistem baru, dan saya hanya belajar lebih banyak ketika tangan saya kotor dan membuat barang dan memecahkan barang-barang dan mencari cara untuk memperbaikinya daripada jika saya duduk dan mencoba berpikir melalui semua itu, yang sering berubah menjadi perasaan tidak produktif tentang betapa terlalu rumitnya hal bodoh ini.

(Saya biasanya tidak akan repot-repot menjawab pertanyaan dengan jawaban yang sudah diterima, tetapi ini membuat saya berpikir & saya tidak bisa menahan untuk menimbang.)


1

Ketika saya merencanakan suatu masalah secara terperinci sebelum mulai mengkodekannya, saya mendapati bahwa revisi yang saya lakukan jauh lebih sedikit. Saya pikir itu membutuhkan banyak disiplin untuk tidak langsung masuk ke kode, tetapi bermanfaat. Sayangnya, seperti yang telah Anda catat, sebagian besar bukan pemrogram tidak mengerti bahwa waktu yang jauh dari komputer untuk merencanakan dan berpikir terlebih dahulu mungkin benar-benar mempercepat dan meningkatkan tugas.


Di satu perusahaan tempat saya bekerja, kami memiliki banyak ruang rapat kecil, dan tidak apa-apa berada di sana sendirian untuk sementara waktu, asalkan Anda memegang pena dan buku catatan dan melihat dengan cermat;)
mojuba

1

Saya cukup yakin saya mengerti perbedaan Anda antara berpikir dan coding. Tapi, mengapa berhenti berpikir ketika Anda mulai coding? Mudah-mudahan, mengetik tidak membutuhkan banyak usaha sehingga Anda tidak bisa berpikir secara bersamaan.

Saya menemukan bahwa itu bekerja dengan baik untuk berpikir sejenak tentang arah yang harus saya tuju, kemudian mulai coding sementara saya memikirkan lebih banyak detail yang kurang signifikan.


1

Bagaimana waktu kerja Anda didistribusikan antara pengkodean dan berpikir?

Tergantung. Pada saat ini tahun ini, saya kebanyakan melakukan perbaikan bug, jadi berpikir adalah sebagian besar upaya pekerjaan saya.

Sebagai catatan, saya pikir di perusahaan perangkat lunak tipikal berpikir bukan bagian dari budaya: Anda biasanya seharusnya duduk di sana di komputer Anda mengetik sesuatu. Anda hampir pasti akan diperhatikan oleh manajer Anda jika Anda berkeliaran dengan tatapan kosong memikirkan langkah selanjutnya dengan kode Anda.

Anda akan menemukan bahwa sikap ini tidak terbatas pada perusahaan perangkat lunak. Ini adalah fenomena luas dalam budaya perusahaan Amerika. Pengalaman saya adalah bahwa manajer yang menghabiskan banyak waktu di militer (atau ketika lebih muda di sekolah bergaya militer) mengambil kebiasaan untuk selalu bekerja . Jika Seargant menangkap Anda tidak bekerja (dan karena berpikir tidak terlihat oleh pemirsa eksternal, berpikir == bermain-main), dia akan memerintahkan Anda untuk menggosok trotoar dengan sikat gigi (atau pekerjaan bodoh lainnya) hanya untuk membuat Anda tetap bekerja dari bermain-main. Manajer terburuk sepanjang masa di mana saya bekerja akan dengan sengaja menciptakan krisis untuk membuat pekerjaan bagi Anda jika dia menangkap Anda tanpa melakukan apa pun - dan karena dia juga pemilik, dia tidak percaya bahwa Anda perlu memikirkan sesuatu, hanya saja selesaikan.


1

Bagaimana waktu kerja Anda didistribusikan antara pengkodean dan berpikir?

MEREKA SAMA

AKHIR TRANSMISI


2
Seseorang menurunkan Anda mungkin karena gaya yang tidak diterima di sini, tapi saya menerima pesan Anda OK;)
mojuba

1

Berpikir kepada saya adalah cara abstrakisasi coding. Anda memikirkan kemungkinan dan hasil yang paling mungkin. Saya banyak berpikir. Terkadang saya berbaring dengan kepala di atas meja dan mata tertutup. Berpikir adalah tingkat desain terkecil. Saya Selalu menyesuaikan panjang pemikiran saya berdasarkan efek area dari kode yang akan saya tulis.

"Di mana saya meletakkan tombol ini?" hampir tidak ada waktu berpikir, "di mana saya meletakkan bidang basis data ini?" mendapat selama dibutuhkan.

Berpikir di atas kertas juga membantu, dan itu lebih terlihat seperti bekerja dan lebih sedikit seperti bermimpi di siang hari.


0

itu bisa sangat bervariasi. Banyak kode saya adalah hasil dari banyak alat yang saya tulis. Jadi ada hari-hari ketika saya "menulis" sejumlah besar kode, hampir tidak ada yang melakukannya dengan tangan. Dan ada hari-hari ketika saya pikir saya menghabiskan lebih banyak waktu dengan pensil daripada saya menggunakan keyboard.

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.