Apakah saran programmer senior tentang selalu menggunakan buku adalah ide yang bagus? [Tutup]

Saya adalah pengembang junior dan baru berkecimpung di industri ini selama 5 tahun. Di perusahaan saya saat ini ada senior yang memanggilnya Infestus. Kadang-kadang saya diberi kesempatan untuk bersinar dan melakukan sesuatu yang benar-benar baru dari awal.

Salah satu contoh terbaru adalah bahwa saya harus membuat singleton dalam aplikasi multithreaded. Saya telah memutuskan untuk menggunakan metode ini . Begitu Infestus melihatnya, dia dengan cepat melanjutkan untuk memanggil saya bodoh dan menyuruh saya untuk menggunakan pendekatan ini . Setelah bertanya kepadanya mengapa ia hanya menepisnya karena ini lebih baik dan itulah bagaimana ini dan buku ini tentang Jawa mengatakan itu lebih baik.

Dan itu adalah pola umum: setiap kali saya mendapat kesempatan untuk melakukan sesuatu yang baru, saya dengan cepat ditembak jatuh oleh Infestus dan satu-satunya alasan mengapa metodenya lebih baik adalah karena buku-buku itu ditulis oleh programmer terkenal. Dia selalu berusaha memberi saya buku untuk dibaca sehingga saya bisa "belajar" cara memprogram.

Saya baru memprogramkan uang selama 5 tahun, tetapi apakah selalu merupakan ide yang bagus untuk secara membabi buta mengikuti buku tentang cara terbaik untuk menyelesaikan masalah, atau haruskah saya mencoba bereksperimen sesekali? Serentetan keluhan dari Infestus mulai membuat saya tidak pernah mencoba sesuatu yang baru dan mengikuti contoh di buku.

EDIT : Saya benar-benar tersesat. Ya saya tahu bahwa mengikuti sesuatu secara membabi buta adalah ide yang buruk. Tapi programmer seperti dewa ini, Infestus, yang tampaknya tahu banyak, mengatakan kepada saya bahwa satu-satunya cara untuk memprogram dengan benar adalah dengan membaca buku dan mengikuti semuanya sampai ke T. Semua aturan yang diberlakukannya adalah yang tertulis dalam buku, jadi saya hanya ingin tahu jika buku adalah satu-satunya cara yang benar.

EDIT2 : Infestus bukan bos saya. Dia hanyalah salah satu pengembang senior yang bertugas meninjau kode. Dan sebagian besar komentarnya setelah ulasan terdiri dari nama buku di mana metode ini dan itu salah.

Anda akan menemui programmer seperti ini sepanjang karir Anda. Tidak ada yang salah dengan eksperimen dan pembelajaran sendiri. Buku pasti bagus. Banyak kali contoh bekerja di lingkungan yang bersih, tetapi jika Anda adalah pengembang untuk perusahaan lain, tidak ada lingkungan yang bersih (tanpa campur tangan orang lain).

Selalu menyenangkan mengetahui cara melakukan hal-hal dengan cara yang "benar", tetapi pendapat berubah dari tahun ke tahun. Jadi pelajari apa yang Anda bisa. Ambil apa yang Anda bisa dari pengembang senior, padukan dengan pengetahuan Anda yang Anda pelajari sendiri. Akhirnya, Anda akan menjadi pengembang senior dan akan mengambil dari pengalaman ini dan mengajar para junior devs.

Hanya saja, jangan menjadi brengsek tentang hal itu.

Apakah dia benar-benar menyebutnya Anda bodoh, atau dia hanya meremehkan kode? Memanggil sesuatu yang bodoh itu tidak bijaksana, tetapi itu tidak membatalkan saran itu. Saya pikir Infestus telah membuat saran yang berharga, dan di masa depan Anda harus mempertimbangkan sarannya dengan serius. Dia tampaknya banyak membaca, dan setidaknya dalam hal ini pendapatnya cukup baik. Sinkronisasi mahal dan rumit. Implementasinya yang direkomendasikan lebih efisien dan lebih sederhana daripada milik Anda, dan dijamin berfungsi.

Dia selalu berusaha memberi saya buku untuk dibaca sehingga saya bisa "belajar" cara memprogram.

Itu jenis dia. Dia secara aktif berusaha membantu Anda, tetapi Anda tampaknya membiarkan ego Anda menghalangi. Jangan menganggap kritik terhadap kode Anda secara pribadi. Kode murah untuk diproduksi dan mudah diubah. Jika seseorang menunjukkan Anda cara yang lebih mudah dalam melakukan sesuatu, terima kasih padanya.

Dan ya, membaca akan membuat Anda menjadi programmer yang jauh lebih baik. Semua ahli yang saya kenal membaca secara luas. Jika Anda tidak banyak membaca, berarti Anda sedang-sedang saja, dan dalam lima tahun ke depan Anda mungkin mendapati bahwa Anda tidak lagi dapat dipasarkan.

Membaca buku tidak boleh buta: penulis harus mencoba meyakinkan Anda tentang manfaat dari pendekatannya saat ia menyajikannya. Adalah masuk akal bagi senior Anda untuk mengarahkan Anda ke sebuah buku yang menjelaskan pendekatan pilihannya, daripada memintanya untuk menjelaskannya sendiri: meskipun ia harus dapat menjelaskan manfaat dari kesukaannya tanpa bergantung pada buku itu, itu juga merupakan duplikasi dari upaya yang penulis buku telah dibuat.

Jadi, baca buku itu, lihat apa yang dikatakan penulis buku itu, dan jika itu membingungkan Anda, atau Anda ingin mengonfirmasi pemahaman Anda, atau Anda tidak setuju, maka bicarakan dengan senior Anda tentang hal itu, tetapi sekarang Anda akan menjadi dapat melakukan diskusi yang lebih produktif.

Ada tiga elemen kunci untuk hubungan yang sehat. Komunikasi, kejujuran, dan kepercayaan. Itu diperhitungkan untuk semua hubungan, bahkan hubungan kerja. Anda harus berbicara dengan penyelia Anda tentang masalah ini.

Jika Anda tidak mengerti alasannya mendukung desain tertentu, katakan padanya . Katakan padanya bahwa Anda belum membaca buku itu, dan Anda ingin memahami mengapa caranya melakukannya lebih baik. Kuncinya adalah Anda harus berusaha memahami caranya melakukan sesuatu.

Saya pikir Anda juga harus memperlakukan orang ini dengan lebih hormat. Di kepala Anda, Anda memanggilnya nama yang merendahkan, dan mengkritik pendekatannya terhadap apa yang Anda anggap sebagai "belajar". Hati-hati dengan itu. Di sisi lain, Anda bilang dia menyebut Anda bodoh. Itu tidak keren, dan Anda harus mengatakan kepadanya bahwa itu tidak keren untuk memanggil seseorang bodoh.

Gagasan bisa jadi bodoh. Kita semua membuat kesalahan dan kehilangan banyak hal, bahkan para senior. Ketika ada cacat dalam desain, pertanyaan terbaik untuk diajukan adalah "Mengapa Anda melakukannya dengan cara ini? Tidakkah itu akan pecah dalam situasi X, Y, Z? Tidakkah desain B akan lebih baik?"

Ingatlah bahwa Anda sedang mengerjakan perangkat lunak ini dengan orang lain. Itu keterampilan yang sulit untuk dipelajari. Tidak masalah bahwa Anda tidak menulis apa pun dari awal, selalu ada ruang untuk bersinar dengan membuat kode Anda kode terbaik yang Anda bisa.

Dan "terbaik" sangat sering berarti dapat dibaca dan dimengerti . Kami programmer menghabiskan banyak waktu membaca kode orang lain. Jika kode itu jelas dan dapat dibaca, maka itu membuat kode itu sangat berharga. Salah satu cara kita belajar menulis kode hebat adalah dengan membaca banyak kode bagus. Anda sangat sering menemukan kode yang sangat bagus di buku. Jadi membaca satu atau dua buku pemrograman yang bagus kemungkinan akan membuat Anda seorang programmer yang lebih baik.

Di perusahaan tempat Anda bekerja, mungkin itu. Inilah yang mereka minta Anda lakukan.

Insinyur ini, Infestus, melakukan pekerjaan yang sangat buruk dalam mendidik pengembang junior dengan memberi tahu mereka "ini tertulis di buku, dan itulah sebabnya". Dia bukan seorang pengkhotbah, dia seorang insinyur, dan dia harus bisa memecahnya dan menyajikan konsep-konsep sehingga junior dapat belajar dari pengalamannya.

Saya akan mendorong Anda untuk berbicara dengan pengembang yang berpengetahuan luas di perusahaan Anda, mengajukan pertanyaan kepada mereka tentang pro dan kontra dari teknik pemrograman yang berbeda, dll. Ini bersama dengan membaca buku dan blog (saya akan merekomendasikan Joel pada Perangkat Lunak - hanya Google, itu adalah suatu keharusan) harus memberi Anda pemahaman yang lebih baik.

IMHO, ada 2 aspek di sini, yang harus Anda tangani secara terpisah:

• Fakta bahwa pria itu brengsek, memanggilmu nama dan semacamnya hanya karena dia bisa (dia senior, kamu tidak, jika salah satu dari kalian mengeluh tentang yang lain, dia akan mendapat manfaat dari keraguan) hanyalah perilaku seperti pengganggu, dan hanya buruk.

Cobalah untuk tidak membungkuk ke levelnya dengan ini. Jangan mencoba menggertaknya kembali atau "katakan padanya" kepada bos atau apa pun. Lakukan yang terbaik untuk mengabaikan aspek perilakunya, ingatlah bahwa itu menjadi terlalu ekstrem (yaitu jika itu mempengaruhi produktivitas Anda dan semacamnya) Anda harus melakukan sesuatu tentang hal itu.

• Fakta bahwa dia memberi tahu Anda bahwa kode Anda buruk (dan bagaimana melakukannya dengan benar). Jujur dari apa yang Anda gambarkan, mengabaikan nada pria itu, aspek perilakunya tidak seburuk itu. Anda belajar banyak hal lebih cepat dan bisa melihatnya dalam konteks yang tepat ketika Anda memiliki seseorang yang lebih berpengalaman mengoreksi Anda dan memberitahu Anda tidak hanya apa yang Anda lakukan salah, tetapi juga bagaimana melakukannya dengan benar (dibandingkan dengan hanya mempelajari semuanya sendiri) dari percobaan pribadi / percobaan kesalahan dan sejenisnya).

Banyak kali saya memiliki seseorang yang memperbaiki apa yang awalnya saya pikir adalah "kode saya yang sempurna" dan hanya kesal karena orang itu memberi tahu saya apa yang harus dilakukan hanya untuk kemudian menyadari bahwa dia benar selama ini, versi saya buruk, itu adalah bagus, dan syukurlah dia melihat itu! :) Jadi saya telah belajar untuk mengurangi impuls awal saya dari "hei, kamu jangan katakan padaku apa yang harus dilakukan, mista!" dan sebagai gantinya, setiap kali seseorang mengoreksi saya, saya pertama-tama benar-benar, secara objektif, memeriksa ulang kode saya, lalu memeriksa kode-nya, dan memastikan dia tidak benar dan sayalah yang melakukan kesalahan. Jika itu adalah kesalahan saya, saya berterima kasih padanya dari bantuan, dan memastikan saya benar-benar mengerti bagaimana solusinya bekerja (daripada hanya menyalin / menempelkannya).

Dan hei, kadang-kadang saya menemukan bahwa koreksi yang ditawarkan ternyata lebih buruk daripada apa yang saya lakukan pada awalnya, pada titik mana saya mencoba membicarakan semua ini dengan orang lain. Sejujurnya, saya perhatikan bahwa tidak ada yang mendapatkan respek dari orang lain untuk Anda lebih cepat daripada ketika mereka melihat bahwa Anda dapat menerima dikoreksi ketika Anda melakukan kesalahan, tetapi pada saat yang sama, tidak takut untuk mengatakan bahwa Anda adalah orangnya. siapa yang benar ketika Anda berpikir begitu, mengingat bahwa Anda dapat segera membuktikan bahwa Anda mendasarkan afirmasi Anda pada beberapa penelitian aktual, dan bukan hanya ego.

Pada titik ini, saya pikir Anda harus benar-benar mencoba dan berbicara dengan pria itu tentang apa yang ia usulkan, dan apa yang Anda usulkan dan sebagainya. Tunjukkan padanya apa yang Anda pikirkan, bagaimana Anda sampai pada solusi tertentu, dan mengapa Anda berpikir itu lebih baik daripada miliknya (ketika Anda secara jujur ​​dan obyektif memikirkannya). Atau, jika Anda mengetahui bahwa proposisinya lebih baik daripada proposisi Anda, katakan demikian, ungkapkan penghargaan Anda atas bantuannya. Ini mungkin membangun kembali beberapa jembatan yang terbakar.

Cobalah sendiri dan pelajari semua yang Anda bisa. Setelah Anda membaca cukup banyak buku, Anda akan menemukan bahwa ada banyak buku tentang mata pelajaran tertentu dan mereka mungkin saling bertentangan. Cobalah yang menurut Anda terbaik dan cobalah keduanya jika Anda punya waktu atau ingin membandingkan / kontras.

Berurusan dengan bos Anda adalah subjek dan pendekatan yang sama sekali berbeda. Jika saya ingin seseorang melakukan sesuatu persis seperti yang ada di buku, saya akan memberi tahu mereka. Itu hanya saya karena saya tidak bergaul dengan pembaca pikiran. Bos Anda menjadikan ini kebiasaan, tanyakan apakah ia merekomendasikan buku atau referensi ketika Anda mendapatkan proyek baru.

Apa pun yang Anda lakukan, jangan berhenti mengerjakan proyek baru. Saya tahu mudah bagi kita semua untuk memberikan tips tentang bagaimana menghadapi situasi ini dan mereka mungkin berhasil atau tidak, tetapi Andalah yang harus hidup dengannya dan menderita negativitas. Anda akan menjadi lebih baik, tetapi itu biasanya berasal dari menulis lebih banyak kode pada hal-hal baru, belajar dari keberhasilan dan kegagalan.

Mengikuti buku secara membabi buta adalah ide yang buruk, tetapi ada perbedaan antara mengikuti buku dengan tepat dan mengikutinya secara membabi buta .

Ketika Anda mencoba untuk memahami hal-hal dalam sebuah buku, umumnya adalah tepat untuk mengikutinya tepat pada pertama, sementara Anda mendapatkan merasakan apa itu mencoba untuk mengajarkan Anda. Kemungkinannya adalah bahwa Anda masih tidak akan mengerti segalanya ketika Anda selesai - begitulah biasanya hal-hal seperti ini terjadi - tetapi mengikuti buku ini pada awalnya akan memberi Anda sesuatu untuk dicoba, ketika Anda mencoba memahami pertanyaan Anda. Kemungkinannya lagi bagus bahwa Anda akan menemukan cara-cara yang tidak Anda setujui dengan apa yang ada di buku itu, tetapi Anda akan memiliki pemahaman tentang masalah-masalah yang coba ditangani oleh buku itu, sehingga ketika tiba saatnya untuk menulis kode Anda sendiri, Anda dapat mengatasinya dengan cara Anda sendiri (atau mungkin cara mereka, setidaknya sebagian) daripada hanya meninggalkan masalah itu untuk menggigit Anda nanti.

Satu hal lain yang secara inheren tidak spesifik untuk Jawa, tetapi masih sangat umum di komunitas itu. Saya rasa saya bisa menebak buku mana yang sedang Anda bicarakan, dan mereka membentuk bagian utama dari leksikon komunitas Jawa. Memahami mereka, dan cara mereka menggambarkan sesuatu, akan sangat membantu ketika Anda perlu memahami kode Java lain yang Anda temukan. Itu keterampilan yang berharga dalam dirinya sendiri.

Membaca buku dan posting blog sangat membantu dalam pemrograman. Ada beberapa buku, yang harus dibaca semua pengembang.

Namun buku bukan satu-satunya sumber untuk mempelajari konsep dan teknologi pemrograman yang berbeda. Saat ini pelatihan berdasarkan permintaan video menjadi sangat populer. Anda dapat memeriksa Pluralsight , yang menyediakan pelatihan berkualitas tinggi bagi para profesional.

Bahkan, jika Anda hanya membaca buku-buku yang tidak akan membantu juga. Selain membaca ada hal lain yang perlu kita lakukan juga. Anda dapat menemukan detail lebih lanjut di sini .

Anda harus bertanya kepadanya apa yang salah dengan metode Anda. Jika dia tidak dapat menjawabnya dengan jelas, Anda mungkin cukup yakin bahwa itu hanya orang biasa yang suka merasa superior.

Hal tentang buku adalah bahwa mereka - sebagian besar - melewati revisi, yang memiliki peluang lebih baik untuk menemukan praktik buruk dan kesalahpahaman. Juga, "nama-nama besar" adalah orang-orang berpengalaman yang mengandalkan kebaikan untuk mendapatkan uang ekstra dengan menjual buku, jadi, ada beberapa jaminan kualitas minimal tentang apa yang mereka katakan.

Yang mengatakan, membaca buku, makalah, dan sumber-sumber lain adalah cara yang baik untuk tumbuh sebagai seorang profesional, tentu saja, ketika dikonfirmasi oleh latihan. Jadi, baik bagi Anda untuk membaca buku-buku itu (bahkan yang direkomendasikan oleh Infestus). Namun, buku-buku tersebut terutama harus memperbesar pemahaman Anda tentang masalah ini, karena hampir selalu ada cara lain untuk menyelesaikan masalah yang sama.

Tentang pendekatan "pergi sendiri", intinya adalah: dapatkah Anda mempertahankan sudut pandang Anda? Bagaimana Anda membuktikan solusi Anda lebih baik daripada yang lain? Beberapa kali Anda dapat menemukan solusi cerdas sendiri, tetapi, jika dibandingkan dengan solusi lain yang diketahui, Anda harus dapat memperdebatkan alasan mengapa solusi Anda lebih baik, karena yang lain menguntungkan mereka, setidaknya, kasus penggunaan. Kemudian, jadilah kreatif dan bijaksana, tetapi yang paling penting, jadilah efektif.

Jika saya, Anda saya akan membaca buku-buku itu. Itu akan membantu Anda dengan memberi Anda lebih banyak argumen, dan, pada saat yang sama, Anda mungkin menemukan bahwa Infestus - mungkin - salah mengambil buku-buku itu sebagai argumen, dan dia belum terlihat karena belum ada yang tahu isi dari buku-buku itu. Atau Anda mungkin menemukan bahwa dia sebenarnya k

Pengalaman saya adalah bahwa ketika prihatin tentang materi pelajaran pemrograman, kualitas dan penyajian informasi dengan penjelasan yang memadai dalam buku adalah lebih baik daripada ketika mencari informasi subjek yang sama di internet. Internet sering tidak memiliki penjelasan, konteks, dan kualitas yang tepat.

Jumlah informasi tersebut di internet lebih tinggi.

Jadi strategi umum saya adalah belajar dari buku untuk mendapatkan pemahaman yang lebih dalam dan setelah itu belajar dari internet untuk mendapatkan berbagai penerapan dan memperluas pengalaman saya (dan sering melihat bagaimana tidak melakukan hal-hal).

Saya akan meneliti manfaat dari setiap pendekatan dan sampai pada penilaian Anda sendiri. Jika Anda berpikir pendekatan Anda lebih baik, diskusikan dengan Infestus sampai salah satu dari Anda meyakinkan yang lain. Jika Anda tidak dapat mencapai kesepakatan, Anda bisa meminta pendapat kedua atau hanya menerima pendekatan Infestus, tergantung pada seberapa kuat Anda merasakannya.

Dalam kasus lajang, satu argumen yang dapat Anda buat menentang pendekatan enum adalah bahwa enum tidak dapat memperpanjang kelas. Saya sering menulis kode seperti ini:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Ini tidak dapat dilakukan dengan enum. Karena pendekatan enum tidak berfungsi dalam semua kasus, Anda dapat berargumen bahwa demi konsistensi, itu harus dihindari bahkan ketika tidak perlu untukextends klausa.

Beberapa argumen lain yang dapat dibuat menentang penggunaan enum:

• ini adalah retasan - menggunakan enum untuk sesuatu yang tidak dimaksudkan untuk mereka
• ini membingungkan pembaca yang belum pernah melihatnya

Saya sangat bergantung pada buku sebagai sumber pengetahuan - ini adalah fondasi yang sangat baik dan saya pikir Infestus benar karena Anda harus mengkonsumsi banyak buku di waktu luang Anda karena mereka benar-benar mempercepat keterampilan Anda. Buku bukan satu-satunya sumber informasi yang menurut saya harus Anda konsumsi - hadiri grup pengguna lokal Anda, dapatkan buletin teknologi terkait yang dikirimkan ke kotak masuk Anda, baca blog.

Namun saya tidak setuju dengan pernyataan bahwa karena itu ditulis dengan cara tertentu dalam sebuah buku, itu adalah cara yang harus dilakukan. Ya, buku memberikan saran yang bagus, dan ditulis oleh para pakar, dan ditinjau oleh para pakar, tetapi setelah terlibat dalam buku yang relatif sederhana, saya dapat memberi tahu Anda bahwa biasanya dibutuhkan waktu setidaknya dua tahun untuk menyelesaikan menulis, mengedit, dan merilis buku . Laju perubahan dalam teknologi sangat cepat dan saran dua tahun yang lalu mungkin tidak lagi menjadi saran yang tepat untuk hari ini. Prinsipal generik sering kali teruji oleh waktu, tetapi mengoptimalkan aktivitas tertentu dapat tidak valid dengan sedikit perangkat keras baru atau rilis perangkat lunak baru.

Saran meminta Infestus untuk mengikuti saran dengan Anda adalah saran yang sangat bagus - pergilah, baca semuanya, dan kembalilah dengan sekumpulan pertanyaan yang telah Anda coba jawab / pecahkan sendiri bersama dengan bukti pendukung Anda untuk Anda metode.

Ada pertanyaan tentang apakah setelah 5 tahun mengapa Anda masih junior. Bagi saya, ukuran utama apakah seseorang adalah junior bukanlah pengalaman bertahun-tahun tetapi seberapa banyak mereka membutuhkan pemberian sendok. Saya berharap pengembang tingkat menengah relatif mandiri, konsumen yang bijaksana dari sumber pengetahuan yang dapat menindaklanjutinya dan memperluasnya ke situasi mereka. Mereka juga harus berada pada tahap di mana mereka dapat mulai mengajar junior karena mereka memiliki pemahaman yang kuat tentang topik mereka sehingga mereka dapat menjelaskan berbagai hal dengan jelas. Kompetensi inti lainnya adalah kepercayaan diri - jika Anda telah melakukan pekerjaan, membaca barang-barang, dan menghasilkan sesuatu yang layak, jangan takut untuk membela di pengadilan karena junior membutuhkan validasi, pengembang meminta konsensus.

Mengesampingkan sopan santun di tempat kerja, mengesampingkan realitas peran mentor yang dimiliki pengembang senior, mengesampingkan keinginan Anda sendiri untuk mengeksplorasi, mengesampingkan perilaku menghina, dan menyisihkan jimat untuk buku ...

Tujuan tinjauan kode dalam tim adalah 1) untuk memvalidasi kode dan 2) untuk memastikan orang yang menulis kode memahami makna di balik peningkatan kode. Ini bukan tempat untuk mengatakan "ubah ini karena Martin Fowler mengatakannya dalam buku GoF". Namun, ini adalah tempat untuk mengatakan "ubah ini karena [penjelasan singkat]; ada lebih detail membahas ini dalam buku GoF".

Jika pengembang senior Anda tidak, paling tidak secara sederhana dan halus, memberikan penjelasan untuk perubahan, dan bersikeras menggunakan kata-kata "karena [buku]", ia menjadi sedikit sok dan brengsek. Bagaimana Anda menghadapinya? Sebutkan itu dalam rapat tim, secara verbal, dan minta teman satu tim Anda untuk memberikan satu atau dua pernyataan singkat yang menjelaskan keuntungan atau keperluan perubahan, bersama dengan referensi buku yang bermanfaat itu. Pastikan untuk berterima kasih padanya untuk referensi buku.

Hadapi itu, tujuan Anda adalah untuk menghargai saran perubahan dan tidak terdemotivasi untuk tugas atau pekerjaan Anda. Beritahu dia bahwa. "Saya akan lebih menghargai saran perubahan jika Anda dapat menjelaskan secara singkat keuntungan atau perlunya perubahan ketika Anda meninjau kode saya; karena saya menemukan referensi buku Anda sendiri agak mendemotivasi."

Jika dia terus menolak untuk memberikan penjelasan sederhana dengan referensi bukunya, jika Anda dapat memberikan buku lain atau sumber daya yang sama atau lebih terkenal di industri dengan pendapat yang berbeda dan itu sesuai dengan skenario Anda, Anda mungkin dapat menambahkan buku Anda sendiri. referensi dalam komentar ulasan Anda dengan pertimbangan mempertahankan kode asli. Lakukan ini cukup kali, dia mungkin mundur. Berhati-hatilah bahwa kontra-argumen itu benar dan jauh lebih penting; tidak apa-apa untuk membiarkan pengembang senior salah dan masih memiliki jalannya sendiri, ini adalah sesuatu yang saya pelajari dan terus harus pelajari.

Saya akan mengatakan bahwa belajar pemrograman hanya dari buku tidak mungkin, tetapi mereka yang bagus akan memberi Anda dorongan besar. Ini seperti karate - Anda tidak akan mendapatkan sabuk hitam hanya membaca tentang itu;) Saya percaya bahwa dalam kasus partucular ini Pak Infestus merujuk pada "Java Efektif" oleh Joshua Bloch. Ini benar-benar buku hebat tentang pengembangan Java dan Anda pasti harus membacanya jika Anda belum melakukannya.