Apa yang harus diketahui oleh setiap programmer?


245

Terlepas dari bahasa pemrograman atau sistem operasi yang digunakan atau lingkungan yang mereka kembangkan, apa yang harus diketahui setiap programmer?

Beberapa latar belakang:

Saya tertarik menjadi programmer terbaik yang saya bisa. Sebagai bagian dari proses ini saya mencoba memahami apa yang tidak saya ketahui dan akan sangat bermanfaat bagi saya jika saya tahu. Walaupun ada banyak daftar di sepanjang baris "n hal yang harus diketahui oleh setiap pengembang [masukkan bahasa pemrograman]", saya belum menemukan hal serupa yang tidak terbatas pada bahasa tertentu.

Saya juga berharap informasi ini menarik dan bermanfaat bagi orang lain.

Jawaban:


636

Cara menelan kesombongan dan mengakui kesalahan tanpa menganggapnya pribadi.


60
Itu adalah sesuatu yang setiap manusia harus lakukan terlepas dari pekerjaan mereka (... jenis kelamin, agama, budaya, status sosial ...), bukan begitu? ;)

3
Oh ya. Tapi kami para programmer (paling tidak saya punya) memiliki kecenderungan untuk memiliki kebanggaan lebih terbuka daripada kebanyakan :-)

17
Saya berharap saya bisa memilih Anda dua kali.

4
Saya pikir ini adalah satu hal yang saya pelajari di universitas. Di sekolah menengah saya selalu menjadi salah satu anak yang cerdas. Jika saya tidak pergi ke universitas, saya akan berpikir saya cukup pintar dan memiliki ego yang besar. Pergi ke uni, dan berinteraksi dengan orang-orang yang benar-benar lebih terampil maka saya membantu saya melihat betapa bodohnya saya
Kibbee

4
Meskipun ini sangat benar, masalahnya tidak selalu penolakan atau ego besar, tetapi konsekuensi potensial dari mengakui secara terbuka untuk melakukan kesalahan, setidaknya tidak tanpa semacam pertahanan diri / kontrol kerusakan terlebih dahulu. Terkadang itu adalah hal budaya. :)

309

Bagaimana berpikir seperti pengguna, dan bukan seperti programmer geek techie.


2
Saya selalu merasa ironis bahwa hal yang kelihatannya tidak dimiliki oleh sebagian besar dari kita dalam industri adalah salah satu keterampilan yang paling penting untuk dimiliki: keterampilan komunikasi.

Tidak setuju dengan ini lebih lanjut. Ini harus menjadi # 1.

23
Saya sebenarnya tidak setuju. Untuk itulah Anda mempekerjakan orang. Anda tidak akan pernah bisa berpikir seperti pengguna, tetapi Anda pasti bisa membuat orang memberi tahu Anda apa yang dipikirkan pengguna dan bertindak berdasarkan saran itu. Hanya saja, jangan tanya pengguna bagaimana pendapat mereka! Itu pilihan terburuk dari semuanya.

1
Anda dapat merekrut orang lain untuk melakukan itu, tetapi jika tim pengembangan Anda dapat memahami bagaimana pendapat pengguna, maka Anda akan memiliki argumen dan iterasi yang jauh lebih sedikit sebelum semuanya benar. Selain itu, jika pengembang dapat berpikir seperti pengguna, siapa yang tahu fitur baru apa yang akan mereka buat

3
Pengguna mungkin saja seorang programmer geek techie, tetapi kecil kemungkinannya seorang programmer geek techie yang juga menerapkan kode . Jika aplikasi memiliki semantik / perilaku yang sangat halus dan kompleks, orang yang menulis kode mungkin satu-satunya orang yang dapat memahami cara menggunakan aplikasi ...
Reuben

244

Kapan meminta bantuan, dan kapan TIDAK meminta bantuan.


2
Benar sekali. Akhir-akhir ini, jawabannya muncul di kepala saya ketika saya bertanya kepada seseorang. :(
kevindaub

jadi, apa jawabannya?)

28
Tanyakan bebek karet Anda terlebih dahulu. Jika dia tidak dapat membantu Anda, maka tanyakan orang lain ...
Dean Agak

3
Terpilih karena ketika saya baru mulai, saya tidak menyadari betapa saya menjengkelkan pengembang lain dengan terus bertanya kepada mereka hal-hal sederhana, saya harus mencari tahu sendiri sampai saya punya beberapa n00b melakukannya untuk saya.

1
Saya selalu bertanya pada diri sendiri pertanyaan "Apa yang akan kolega saya katakan jika saya bertanya kepada mereka". Biasanya itu membantu saya sedikit lebih jauh ke bawah masalah sebelum saya kemudian harus benar-benar bertanya.

184

Cara membaca kode orang lain.


102
Tambahan: Cara menulis kode yang dapat dibaca orang lain

42
Tambahan # 2: Cara membaca kode Anda sendiri 6 bulan kemudian

10
@Nathan Koop: Seharusnya lebih baik "Cara menulis kode sehingga Anda bisa membacanya sendiri 6 bulan kemudian".
Doc Brown

4
Ketika sudah 6 bulan, itu sudah menjadi kode orang lain. Dalam arti bahwa Anda telah berevolusi, menjadi lebih baik, dan mungkin juga orang lain yang menulisnya, jadi perlakukanlah demikian.
MPelletier

7
Tambahan # 3: Cara membaca kode Anda 6 menit kemudian.
buka

152

Keakraban dengan sistem kontrol versi. Tidak harus setiap orang, tetapi konsep dasar yang dapat diterapkan untuk semuanya harus diketahui.


dan bahwa kontrol revisi tidak software
jrhicks

4
Saya akan menambahkan bahwa ada perbedaan yang cukup signifikan antara SCM terpusat (mis. Subversi, CVS) dan SCM terdistribusi (mis. Git, mercurial, bazaar) sehingga penting untuk mempelajari masing-masing.
intuited

128

Inilah 10 bit saya:

  • Bagaimana menjadi rendah hati. Kita semua di sini untuk belajar. Anda mungkin lebih pintar dari yang lain, tetapi ada banyak orang yang lebih pintar dari Anda.
  • Cara belajar / mengkonsumsi informasi. Saya tidak tahu tentang Anda, tetapi saya selamanya belajar! Buku, Internet, apa pun!
  • Apa kamus itu dan bagaimana menggunakannya, dan bagaimana mengetahui akronim dengan cepat.
  • Apa alat dasar perdagangan dan apa yang mereka lakukan (IDE, CVS et al).
  • Ketahui terminologi umum dan apa artinya: pola desain, kegunaan, pengujian (ha!), Tumpukan, dll.
  • Memiliki pemahaman tentang OOP.
  • Jadilah "mampu" dalam setidaknya satu bahasa, tidak ada yang luar biasa, hanya tahu cara mengidentifikasi variabel dan metode, dll. Dari sini Anda dapat belajar FAST.
  • Memahami bahwa orang pada akhirnya menggunakan perangkat lunak dan ingin membuat orang-orang bahagia

38
Ini harus menjadi pos oktal.
Even Mien

10
Mengenai bit pertama .... "Jangan terlalu rendah hati, kamu tidak terlalu bagus".
Magnus

@TheOtherScott, lol tangkapan bagus, tapi saya benar-benar mengatakan 2 bit: D;)

3
Mengenai poin 3: www.acronymfinder.com
Jasper Bekkers

1
@ jasper / intuited: cukup ketikkan akronim ke google dan itu akan menarik satu atau yang lain ... jawabannya biasanya di salah satu dari 10 hasil pertama. info lebih lanjut dapat diperoleh dengan mengklik!
buka

104

Mungkin terlalu halus, tetapi saya menganggapnya sebagai "mengetahui masalah mana yang harus dipecahkan." Banyak programmer (dan orang normal) menyia-nyiakan upaya luar biasa untuk menyelesaikan hal-hal yang sebenarnya tidak terlalu penting; atau mereka menciptakan solusi, dengan banyak pekerjaan ekstra, itu tidak cukup apa yang dibutuhkan.


4
Setuju, mengkhawatirkan tentang skenario penggunaan-kasus yang hanya segelintir pengguna yang akan menemukan alih-alih lebih banyak fungsi inti adalah perangkap yang terlalu umum! Saya masih belajar ini dengan cara yang sulit ...
Ian Robinson

Saya harus meletakkan tautan ke jawaban Anda sebagai beranda mantan pemimpin tim saya. kamu benar sekali.

4
Saya suka bahwa Anda mengatakan "banyak programmer (dan orang normal)" :-)

95

Bagaimana cara santai. Itu rahasia produktivitas.

Akhirnya, kemauan keras dan kafein tidak cukup. Kontraksi konstan yang kita lakukan ini sangat merusak.

Ini masalah besar.


1
Apa yang Anda maksud dengan kontraksi?

4
@ Elgg: Kadang-kadang ketika saya bekerja, saya bisa benar-benar santai dan sangat produktif. Pada hari-hari buruk saya, saya menggunakan adrenalin dan kafein, dan saya merasakan ketegangan yang luar biasa di tubuh saya. Jika saya memperhatikan dengan saksama, saya sebenarnya mengidap beberapa otot. Saya memperhatikan ketegangan ini pada orang lain sepanjang waktu. Sayangnya itu dapat menyebabkan semua jenis masalah seperti kelelahan dan penyakit jantung, dan mungkin juga menyebabkan hilangnya produktivitas karena hanya mungkin untuk berlari untuk waktu yang terbatas. Itulah kontraksi yang saya bicarakan.
Brian MacKay

@ Eh, maksudnya kontraksi otot yang tidak digunakan.

2
berbicara tentang kopi dan kontraksi, tahukah Anda bahwa kopi mengecilkan pembuluh darah yang mensuplai darah ke otak. Itu menyebabkan otak terbangun. Kopi bukan hal yang baik. tl; air minum dr
Reno

83

Tipe data dasar & teori algoritma. Hal-hal seperti notasi O Besar, array, antrian, dll.


Sama sekali tidak membantu Anda jika yang Anda lakukan hanyalah membuat template untuk sistem manajemen konten web.

3
Nah, saat ini algoritma standar diimplementasikan di perpustakaan / kerangka kerja tetapi saya setuju bahwa beberapa pemikiran keras seperti algoritma berguna, tetapi tidak terlalu sering

7
Hanya karena sudah diterapkan tidak berarti Anda tidak harus memahami apa yang harus digunakan kapan, kompleksitas menjamin, dll. Ini adalah hal penting di balik algoritma.

3
Setuju dengan Greg Rogers. Anda mungkin perlu mengimplementasikan algoritme tetapi Anda lebih memahami kompleksitas dan pengorbanannya. Misalnya. Beberapa algoritma membutuhkan lebih banyak memori tetapi lebih cepat.

6
Anda tidak akan tahu mana yang digunakan jika Anda tidak memahaminya. Algoritma sangat penting.

60

Bagaimana memilih alat yang tepat untuk tugas yang tepat, dan tidak ikut serta dalam perang api konyol tentang alat pemrograman favoritnya.


Memberi +1 agar yang satu ini tidak menginap di 42 :)
CharlesB

54

Nah, ini $ 0,02 saya:

  • Pembelajaran tidak pernah berhenti. Tidak peduli seberapa baik Anda berpikir Anda, selalu ada seseorang yang lebih baik daripada Anda, dan selalu ada sesuatu yang dapat Anda tingkatkan tentang diri Anda. Jika Anda berhenti belajar, Anda pasti akan menurun sebagai seorang programmer. Membaca buku-buku. Baca blog. Bicaralah dengan programmer lain.
  • Coba pelajari beberapa bahasa. Setidaknya salah satunya berorientasi objek. Selain itu, Anda harus mengetahui sesuatu tentang berbagai teknologi yang terkait dengan bahasa yang Anda pelajari (mis. Jika Anda belajar Java, alangkah baiknya jika Anda tahu sesuatu tentang Spring, dan sebagainya ..).
  • Refactoring. Cepat atau lambat Anda akan membutuhkan pengetahuan itu.
  • Pelajari cara menangani kode lawas.
  • Tulis tes unit. Pelajari tentang TDD.
  • Belajar bekerja dalam tim.
  • Tulis kode yang elegan dan mudah dibaca. Seperti pepatah lama: "Tulis kode Anda seolah-olah orang yang akan mempertahankannya adalah pembunuh berantai psikotik yang tahu di mana Anda tinggal."
  • Belajar bagaimana menjadi malas dan disiplin pada saat yang sama. Pemrogram yang baik memiliki kedua kualitas ini. Aneh tampaknya, mereka tidak saling bertentangan, tetapi saling melengkapi.

Apakah itu, 0,02 dolar atau 0,02 sen Anda? LOL! :-D

"Tulis kodemu seolah orang yang akan memeliharanya adalah pembunuh berantai psikotik yang tahu di mana kau tinggal." +1
Ben

50

Anda tidak dapat menguji kualitas menjadi suatu produk.


2
Dengan demikian "Jaminan Kualitas" profesional memiliki nama yang salah.

1
Secara teknis, QA dan Test bukanlah hal yang sama, meskipun menurut Anda saya tidak yakin sebagian besar organisasi benar-benar mempraktikkan perbedaan.
Tall Jeff

5
Baru-baru ini ditemui - dan macet: "Hasil pengujian tidak berkualitas, tetapi pengetahuan".
peterchen

richdiet: Pakar SQA James Bach percaya bahwa "A" di SQA / QA harus berarti "Bantuan". Saya sangat setuju dengan pendapatnya dan pernyataan Anda.

44

Setiap programmer harus memahami pola desain .


13
Saya akan menambahkan bahwa mereka juga membutuhkan pemahaman bahwa tidak semuanya dapat ditanduk sepatu ke dalam pola desain yang diberikan.
tloach

10
Saya juga akan menambahkan bahwa tidak setiap programmer harus memahami pola desain. Ada bahasa di luar sana di negeri-negeri yang jauh yang memiliki fitur-fitur lain yang begitu kuat sehingga pikiran mengalir langsung keluar dari pemrogram dan ke dalam program kerja. Dalam bahasa-bahasa itu, pola yang disengaja adalah penyesatan.
Ali

2
pola desain adalah untuk desingers bukan "programmer" - seorang programmer perlu tahu bahwa ketika dia menjadi "desainer"

10
Ada dua jenis orang .. orang yang suka coding dan orang yang lebih suka berbicara tentang coding. Pola desain adalah suatu keharusan bagi kelompok kedua ..
Bjorn Reppen

1
Pola semacam itu adalah cara untuk mengatasi keterbatasan bahasa. Seorang programmer harus memahaminya hanya karena ia harus memahami dan mampu mengatasi kelemahan bahasanya.

44

Saya sedikit terlambat untuk yang ini, tapi saya akan pergi dengan pengetahuan yang diberikan oleh Edsger Dijkstra:

Selain kecenderungan matematis, penguasaan bahasa ibu seseorang yang sangat baik adalah aset paling vital dari seorang programmer yang kompeten.

Jika Anda tidak dapat menulis paragraf yang bagus, kemungkinan Anda juga tidak bisa menulis kode yang baik.


8
Namun saya kagum pada ejaan, tata bahasa, dan tanda baca yang mengerikan yang digunakan dalam penulisan bahasa alami oleh beberapa programmer. Anda akan berpikir bahwa bekerja setiap hari dengan sistem yang memiliki toleransi nol untuk kesalahan ejaan dan sintaks tidak valid akan memiliki efek yang menguntungkan ...

1
@cheduardo, itu karena setelah Anda mengkompilasi atau menjalankan program, dalam sebagian besar bahasa, Anda akan diberitahu tentang kesalahan pengejaan, tata bahasa atau tanda baca, yang kemudian dapat dengan mudah diperbaiki. Tidak demikian untuk kesalahan logis.
Insya Allah

@ Insya Allah: kecuali jika Anda melakukan sesuatu seperti if (BlowUpTheSystem = 1). Memang, diberikan pengujian unit yang tepat, Anda cenderung menghemat waktu saja. Tapi waktu itu sangat penting.
intuited

2
Setuju .. hmm ... minus bagian "bahasa asli", beberapa dari kita [sayangnya?] Berkomunikasi lebih baik / lebih jelas dalam bahasa non-asli kita.

39

Jangan terlalu terikat secara emosional, melekat pada, atau beragama tentang teknologi, OS, atau bahasa tertentu - tidak ada yang sempurna - dalam jangka panjang Anda akhirnya berharap Anda bisa membuat ala carte sendiri dari apa yang Anda inginkan. suka tentang masing-masing yang berbeda.

Pikirkan itu seperti mobil - Anda mungkin tidak pernah mengendarai mobil tertentu sebelumnya, tetapi mereka semua memiliki kunci, roda kemudi, akselerator, dan rem - Anda harus bisa masuk dengan cepat dan pergi begitu Anda memilah-milah di mana. Perlakukan OS dan bahasa dengan cara yang sama dan fokus pada mempelajari konsep-konsep penting yang mendasari mereka bahkan jika Anda berada di pergolakan spesifik dari setiap contoh yang diberikan.

Dan seiring waktu coba untuk memahami dan menghargai leluhur, warisan, dan kesamaan berbagai teknologi yang akan membantu Anda menjaga perspektif. Sadarilah misalnya bahwa, sementara pohon evolusi secara aktif bercabang dan penuh jalan buntu, teknologi dari waktu ke waktu cenderung berulang kali berkumpul di sekitar 'praktik terbaik' dan 'skala ekonomi' ( misalnya, perhatikan bahwa Mac tidak jauh berbeda dari PC di bawah tenda hari ini ...).

Terakhir, ingatlah betapa pun menyenangkannya Anda dengan semua itu, teknologi pada dasarnya mewakili lensa yang tidak sempurna antara apa yang dapat dibayangkan oleh pikiran Anda dan apa yang sebenarnya Anda hasilkan. Lakukan yang terbaik, belajar untuk belajar, dan tetap bisa beradaptasi ...



35

Bahwa hari Anda berhenti belajar harus menjadi hari Anda tidak lagi seorang programmer.


Jika aku punya satu keinginan, itu mungkin Santa adalah ayahku.

Karena Santa ...?

1
Hari Anda berhenti belajar harus menjadi hari Anda mati. :) +1 tetap
ShdNx

Jadi untuk hidup selamanya Anda harus selalu terus belajar? Sekarang ada ide yang bisa saya setujui!
canadiancreed

34

Pengujian dan debugging unit.


Yang pertama menghilangkan kebutuhan untuk yang kedua. ;-)

4
Tidak, ketika pengujian unit gagal, itu perlu debugging. Keduanya pergi bersama.
Zan Lynx

Tidak bisa cukup menekankan hal ini.
fastcodejava

33

Itu disebutkan sebelumnya tapi saya pikir itu layak untuk jawabannya sendiri.


Saya semakin sering menggunakannya, dan saya mengambil bagian di sana-sini, tapi saya masih belum amatir.

Saya sangat setuju. Ini terlihat aneh dan sulit ketika Anda tidak memahaminya, tetapi ketika Anda memahaminya, itu jauh lebih mudah daripada satu ton panggilan fungsi substring / indexof yang akan diperlukan untuk melakukan hal yang sama sebaliknya. Saya hanya akan memastikan bahwa pola Anda dikomentari dengan baik.
Kibbee

9
Beberapa orang, ketika dihadapkan dengan masalah, berpikir, "Saya tahu, saya akan menggunakan ekspresi reguler." Sekarang mereka memiliki dua masalah. - "Jamie Zawinski": jwz.livejournal.com , di comp.lang.emacs
Bjorn Reppen

Menggunakan editor pada dasarnya dibangun di sekitar mereka adalah cara yang baik untuk mempelajari seluk beluk jahat. Pengalaman saya adalah dengan vim — yang menggunakan sebagian besar setara dengan standar PCRE de facto — tapi saya mendapat kesan bahwa aturan yang sama berlaku di dunia emacs.
intuited

1
Beberapa orang, ketika dihadapkan dengan ekspresi reguler, berpikir "Saya tahu, saya akan mengutip Jamie Zawinski." Sekarang mereka memiliki dua masalah (salah satunya adalah bahwa mereka mungkin tidak tahu apa yang mereka lakukan di tempat pertama) .
Donal Fellows

29

Tidak seorang pun ingin menggunakan perangkat lunak. Mereka ingin masalah diselesaikan.


7
Persis. Ketika saya mendengar pengembang berusaha menjelaskan basis data kepada pengguna akhir sebagai jawaban atas pertanyaan mereka tentang mengapa sesuatu tidak dapat dilakukan, saya merasa ngeri. Mereka tidak perlu tahu bagaimana kami melakukan sesuatu. Mereka hanya ingin itu berhasil. Dan memang seharusnya begitu.
Kevin Fairchild

Saya suka percaya bahwa orang dapat menulis perangkat lunak yang menyenangkan untuk digunakan.

Sangat setuju. Namun ini juga berlaku untuk API. Tidak ada yang mau belajar API baru karena sangat lucu. Kami ingin fungsionalitas API, bukan kode yang diwakilinya.
Blub

Kevin, saya berharap "implementasi programmer" kami (kata mewah untuk pengujian pria) akan membaca dan memahami itu. Saya juga duduk di belakang meja saya berharap dunia akan menelannya ketika dia mulai berbicara tentang loop dan jika pernyataan kepada pengguna akhir.

27

Kopi dan IntelliSense adalah teman terbaik Anda.


Saya berharap saya bisa memberikan ini lebih dari 1 suara positif!
Dinah

Saya berharap untuk memiliki lebih banyak kopi !!!! ñ_ñ

Saya pikir saya setuju dengan ini lebih dari hal lain di SO.
Unkwntech

Saya praktis tidak pernah minum kopi kecuali saya benar-benar harus menyelesaikan proyek dalam X jam, ketika: Jumlah jam habis + X> 8 selama sehari.
Blub

Kopi tidak memberi Anda energi. Itu hanya memeras sebagian dari cadangan internal Anda. Itu buruk / tidak sehat.
Andrei Rinea

18

Cara mengamati objek rumit besar dan menguraikannya menjadi objek kecil sederhana yang masih menyelesaikan tugas yang sama ketika disatukan kembali.


18

Jangan pernah mempercayai pengguna ( terutama jika aplikasinya publik!), Mereka akan sering melakukan apa saja untuk menghancurkan aplikasi Anda dengan satu atau lain cara.

Jadikan itu bukti di masa depan & dapat diperluas - Anda tidak pernah tahu kapan Anda ingin mengembangkannya dalam beberapa tahun mendatang dan menyadari betapa banyak upaya yang diperlukan untuk membuat ulang kode yang dibuat dengan buruk.


1
Ini terlalu umum. Beberapa pragmatisme juga bagus.
mafu

18

Bahwa programmer tidak tahu segalanya dan harus selalu mencoba mempelajari bahasa / teknologi baru, dll.


16

Dasar-dasar desain UI yang baik dan desain komunikasi (grafis) .

Saya melihat begitu banyak aplikasi dan proyek hancur oleh desain yang buruk atau kegunaan yang buruk. Hanya mempelajari dasar-dasarnya dapat membuat dunia berbeda. Ditambah teknik pemecahan masalah visual (yaitu, bagaimana mengkomunikasikan konsep secara visual) adalah tantangan yang merangsang yang harus membuka mata Anda terhadap cara pandang baru, yang pada gilirannya akan berdampak pada kode Anda.

Buku yang direkomendasikan adalah Buku Desain Non Desainer oleh Robin Williams

Inilah yang dikatakan Joel Spolsky tentang hal itu :

Wow! Setiap orang harus melakukan beberapa desain grafis, dan tidak setiap tim perangkat lunak memiliki kemewahan desainer profesional. Buku yang sangat bagus dan tipis ini akan memberi Anda pemahaman tentang prinsip-prinsip di balik tata letak halaman, font, dll. Berita baiknya adalah, Anda dapat membacanya di bak mandi sebelum air menjadi dingin, dan hari berikutnya, kotak dialog dan powerpoint Anda dan halaman web akan mulai terlihat lebih baik.


1
Saya akan kedua dengan anggukan tambahan untuk 'desain hal sehari-hari'. amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
Stimul8d

14

Setiap programmer harus tahu cara belajar dengan cepat. Banyak kali Anda datang ke pekerjaan dan akan diminta untuk mengembangkan teknologi yang belum pernah Anda gunakan. Mereka mungkin memberi Anda sekitar satu minggu atau lebih untuk berdiri (jika Anda beruntung) sebelum Anda diminta untuk menulis kode kualitas produksi.


Saya memulai pekerjaan pemrograman pertama saya dan dalam waktu seminggu menulis kode yang pada akhirnya akan ditayangkan. Untungnya saya seorang pembelajar yang cepat dan memiliki pengalaman pemrograman masa lalu. Dalam 6 bulan saya telah merestrukturisasi koneksi client-server untuk meningkatkan kinerja tiga kali lipat. Ini dalam bahasa yang belum pernah saya gunakan sebelumnya.

14

Kontrol versi. Dan mengutip teman perempuan saya: "Saya tidak hanya ingin Anda mencuci piring, saya ingin Anda menyukainya !"



10

Dari atas kepala saya:

  1. Sangat sedikit masalah pemrograman yang membutuhkan matematika di luar penjumlahan, pengurangan, perkalian, dan pembagian. Jika Anda berpikir untuk menggunakan kalkulus untuk menyelesaikan masalah, teliti alternatifnya secara menyeluruh sebelum melakukannya.

  2. Setiap kali Anda menebak-nebak cara kerja sesuatu, Anda salah melakukannya. Bukan tugasmu untuk menjadi telepati.

  3. Orang yang memberi Anda spek jarang tahu semua yang dia inginkan sampai Anda menghapusnya.

  4. Lebih dari setengah menjadi programmer hebat berasal dari berurusan dengan manusia. Berinteraksi dengan tim Anda, mengelola manajer Anda, dan menangani pengguna akhir adalah setengah dari pekerjaan.

  5. Kode yang baik ditulis untuk dibaca oleh orang sebanyak yang dibaca oleh kompiler Anda.

  6. Praktik terbaik dan realitas praktis akan bertentangan lebih dari yang dipikirkan oleh programmer, tetapi kurang dari yang dilakukan oleh manajer. Ketika mereka tampak dalam konflik, terserah Anda untuk melukiskan dan memahami konflik dan kemudian menyerah pada yang praktis. Solusi yang halus dan pintar hanya lebih baik daripada solusi yang jelek dan brutal jika lebih efektif dalam jangka panjang.

  7. Alat yang hebat tidak bisa menjadi programmer yang hebat, tetapi alat yang buruk membuat kita sama buruknya.

  8. Jangan pernah meremehkan teknologi, tetapi selalu mencari alternatif terbaik.

  9. Semakin banyak bahasa yang Anda kenal, semakin baik Anda menggunakan bahasa yang Anda gunakan.

  10. Jangan diganggu oleh lambannya pemikiran berorientasi pemrograman ke dalam kehidupan sehari-hari Anda. Bahkan ketika kita tidak berada di depan komputer, kita semua menderita keterbatasan bandwidth, memiliki penalti kinerja dari pengalihan tugas, dan perlu memuat sesuatu dari penyimpanan cadangan. Komputer seharusnya meniru pemikiran manusia dan analognya ada di mana-mana.


Nomor 10 membuatku tertawa. Berkali-kali saya akan mengerjakan masalah di tempat kerja tetapi hanya di tempat tidur jam 10 malam yang akhirnya saya dapatkan jawabannya!

9

Membaca kode orang lain tidak akan merusak otak Anda, tetapi mencari tahu mengapa Anda tidak melakukannya dengan cara itu (jika lebih baik atau tidak adalah pertanyaan lain).

Ini memberi Anda pemrograman percobaan gedanken , dan kadang-kadang Anda menemukan seseorang yang mengimplementasikan sesuatu dengan lebih baik! Seperti cara yang lebih baik.

Jawaban ini secara alami diperluas untuk membaca kode Anda sendiri, sehingga diperluas untuk menggunakan kontrol versi dan DIFF, dan dengan demikian menjadi 42.

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.