Mengapa hanya meningkatkan pengkodean Anda tidak akan membuat Anda menjadi pengembang yang lebih baik

Mengapa hanya meningkatkan pengkodean Anda tidak akan membuat Anda menjadi pengembang yang lebih baik

Pemimpin Teknologi Skyeng Kirill Rogovoy (flashhhhh) memberikan presentasi di konferensi di mana dia berbicara tentang keterampilan yang harus dikembangkan oleh setiap pengembang yang baik untuk menjadi yang terbaik. Saya memintanya untuk berbagi cerita ini dengan pembaca Habra, saya memberikan kesempatan kepada Kirill.

Mitos tentang pengembang yang baik adalah dia:

  1. Menulis kode bersih
  2. Tahu banyak teknologi
  3. Mengkodekan tugas lebih cepat
  4. Mengetahui banyak algoritma dan pola desain
  5. Dapat memfaktorkan ulang kode apa pun menggunakan Kode Bersih
  6. Tidak membuang waktu untuk tugas-tugas non-pemrograman
  7. 100% menguasai teknologi favorit Anda

Beginilah cara HR melihat kandidat yang ideal, dan lowongan pun terlihat seperti ini.

Namun pengalaman saya mengatakan bahwa hal ini tidak sepenuhnya benar.

Pertama, dua penafian penting:
1) pengalaman saya adalah tim produk, mis. perusahaan yang produknya sendiri, bukan outsourcing; dalam outsourcing segalanya bisa sangat berbeda;
2) jika Anda seorang junior, maka tidak semua saran dapat diterapkan, dan jika saya jadi Anda, saya akan berkonsentrasi pada pemrograman untuk saat ini.

Pengembang yang baik: kenyataan

1: Lebih baik dari kode rata-rata

Pengembang yang baik tahu cara membuat arsitektur yang keren, menulis kode yang keren, dan tidak membuat terlalu banyak bug; Secara umum, kinerjanya lebih baik daripada rata-rata, namun ia tidak termasuk dalam 1% spesialis teratas. Sebagian besar pengembang paling keren yang saya kenal bukanlah pembuat kode yang hebat: mereka hebat dalam pekerjaannya, tetapi mereka tidak bisa melakukan sesuatu yang luar biasa.

2: Memecahkan masalah daripada menciptakannya

Bayangkan kita perlu mengintegrasikan layanan eksternal ke dalam proyek. Kami menerima spesifikasi teknis, melihat dokumentasi, melihat ada sesuatu yang ketinggalan jaman di sana, memahami bahwa kami perlu meneruskan parameter tambahan, membuat beberapa penyesuaian, mencoba menerapkan semuanya entah bagaimana dan membuat beberapa metode bengkok berfungsi dengan benar, akhirnya, setelah beberapa hari-hari kami memahami bahwa kami tidak dapat terus seperti ini. Perilaku standar seorang pengembang dalam situasi ini adalah kembali ke bisnis dan berkata: “Saya melakukan ini dan itu, yang ini tidak berfungsi seperti itu, dan yang itu tidak berfungsi sama sekali, jadi cari tahu sendiri. ” Sebuah bisnis mempunyai masalah: Anda perlu menyelidiki apa yang terjadi, berkomunikasi dengan seseorang, dan mencoba menyelesaikannya. Telepon yang rusak dimulai: "katakan padanya, saya akan mengiriminya pesan, lihat apa yang mereka jawab."

Pengembang yang baik, ketika menghadapi situasi seperti itu, akan menemukan kontaknya sendiri, menghubunginya melalui telepon, mendiskusikan masalahnya, dan jika tidak ada yang berhasil, dia akan mengumpulkan orang yang tepat, menjelaskan semuanya dan menawarkan alternatif (kemungkinan besar, ada yang lain layanan eksternal dengan dukungan yang lebih baik). Pengembang seperti itu melihat masalah bisnis dan menyelesaikannya. Tugasnya ditutup ketika dia memecahkan masalah bisnis, dan bukan ketika dia mengalami sesuatu.

3: Berusaha mengeluarkan tenaga minimal untuk mendapatkan hasil maksimal, meskipun harus menulis dengan tongkat

Pengembangan perangkat lunak di perusahaan produk hampir selalu merupakan pengeluaran terbesar: biaya pengembangnya mahal. Dan pengembang yang baik memahami bahwa bisnis ingin mendapatkan jumlah uang maksimal dengan pengeluaran minimum. Untuk membantunya, pengembang yang baik ingin menghabiskan waktu mahalnya sesedikit mungkin untuk mendapatkan keuntungan maksimal bagi pemberi kerja.

Ada dua ekstrem di sini. Salah satunya adalah Anda secara umum dapat menyelesaikan semua masalah dengan kruk, tanpa mengganggu arsitektur, tanpa melakukan refactoring, dll. Kita semua tahu bagaimana ini biasanya berakhir: tidak ada yang berhasil, kami menulis ulang proyek dari awal. Cara lainnya adalah ketika seseorang mencoba menghasilkan arsitektur yang ideal untuk setiap tombol, menghabiskan satu jam untuk tugas tersebut dan empat jam untuk pemfaktoran ulang. Hasil dari pekerjaan seperti itu terlihat bagus, tetapi masalahnya adalah dari sisi bisnis dibutuhkan sepuluh jam untuk menyelesaikan sebuah tombol, baik dalam kasus pertama dan kedua, hanya karena alasan yang berbeda.

Pengembang yang baik tahu bagaimana menyeimbangkan kedua kondisi ekstrem ini. Dia memahami konteksnya dan membuat keputusan optimal: dalam masalah ini saya akan mengambil tindakan, karena ini adalah kode yang disentuh setiap enam bulan sekali. Tapi yang ini saya akan bersusah payah dan melakukan semuanya seakurat mungkin, karena seratus fitur baru yang belum dikembangkan akan bergantung pada keberhasilan saya.

4. Memiliki sistem manajemen bisnis sendiri dan mampu mengerjakan proyek dengan kompleksitas apa pun di dalamnya.

Bekerja berdasarkan prinsip Getting Things Done – ketika Anda menuliskan semua tugas Anda dalam semacam sistem teks, jangan lupa perjanjian apa pun, dorong semua orang, datang ke mana saja tepat waktu, ketahui apa yang penting dan apa yang tidak penting saat ini, Anda tidak akan pernah kehilangan tugas. Ciri umum orang-orang seperti itu adalah ketika Anda menyepakati sesuatu dengan mereka, Anda tidak pernah khawatir mereka akan lupa; dan Anda juga tahu bahwa mereka menuliskan semuanya dan kemudian tidak akan menanyakan seribu pertanyaan, yang jawabannya sudah dibahas.

5. Mempertanyakan dan mengklarifikasi segala kondisi dan perkenalan

Di sini juga terdapat dua ekstrem. Di satu sisi, Anda mungkin skeptis terhadap semua informasi pengantar. Orang-orang sebelum Anda memberikan beberapa solusi, tetapi Anda berpikir bahwa Anda dapat melakukan lebih baik dan mulai mendiskusikan kembali semua hal yang ada sebelum Anda: desain, solusi bisnis, arsitektur, dll. Hal ini membuang banyak waktu baik bagi pengembang maupun orang-orang di sekitarnya, dan berdampak negatif pada kepercayaan dalam perusahaan: orang lain tidak mau mengambil keputusan karena mereka tahu orang itu akan kembali dan menghancurkan segalanya. Ekstrem lainnya adalah ketika seorang pengembang menganggap pengantar, spesifikasi teknis, dan keinginan bisnis apa pun sebagai sesuatu yang terpahat di atas batu, dan hanya ketika dihadapkan pada masalah yang tidak terpecahkan barulah dia mulai memikirkan apakah dia melakukan apa yang dia lakukan atau tidak. Pengembang yang baik juga menemukan jalan tengah di sini: ia mencoba memahami keputusan yang dibuat sebelum atau tanpa dia, sebelum tugas dilanjutkan ke pengembangan. Apa yang diinginkan bisnis? Apakah kita menyelesaikan masalahnya? Perancang produk memberikan solusi, tetapi apakah saya memahami mengapa solusi tersebut akan berhasil? Mengapa ketua tim menciptakan arsitektur khusus ini? Jika ada sesuatu yang tidak jelas, maka Anda perlu bertanya. Dalam proses klarifikasi ini, pengembang yang baik mungkin melihat solusi alternatif yang belum pernah terpikirkan oleh siapa pun sebelumnya.

6. Meningkatkan proses dan orang-orang di sekitar Anda

Ada banyak proses yang terjadi di sekitar kita - rapat harian, pertemuan, scrum, tinjauan teknologi, tinjauan kode, dll. Pengembang yang baik akan berdiri dan berkata: lihat, kita berkumpul dan mendiskusikan hal yang sama setiap minggu, saya tidak mengerti mengapa, sebaiknya kita menghabiskan waktu ini di Contra. Atau: untuk tugas ketiga berturut-turut saya tidak bisa masuk ke kodenya, tidak ada yang jelas, arsitekturnya penuh lubang; Mungkin kode ulasan kita lemah dan perlu melakukan refaktorisasi, mari kita refaktorisasi pertemuan setiap dua minggu. Atau selama peninjauan kode, seseorang melihat bahwa salah satu rekannya tidak menggunakan alat tertentu dengan cukup efektif, yang berarti dia perlu datang lagi nanti dan memberikan beberapa saran. Pengembang yang baik memiliki naluri ini; dia melakukan hal-hal seperti itu secara otomatis.

7. Pandai mengatur orang lain, meskipun bukan seorang manajer

Keterampilan ini sangat sesuai dengan tema “memecahkan daripada menciptakan masalah.” Seringkali, dalam teks lowongan yang kami lamar, tidak ada yang tertulis tentang manajemen, tetapi kemudian, ketika dihadapkan dengan masalah di luar kendali Anda, Anda masih harus mengelola orang lain dengan satu atau lain cara, mencapai sesuatu dari mereka, jika Anda lupa - dorong, pastikan mereka memahami segalanya. Pengembang yang baik tahu siapa yang tertarik pada apa, dapat mengadakan pertemuan dengan orang-orang ini, menuliskan perjanjian, mengirim mereka ke waktu luang, mengingatkan mereka pada hari yang tepat, memastikan semuanya sudah siap, bahkan jika dia tidak secara langsung bertanggung jawab secara pribadi. tugas ini, tetapi hasilnya tergantung pada pelaksanaannya.

8. Tidak menganggap ilmunya sebagai dogma, selalu terbuka terhadap kritik

Setiap orang dapat mengingat seorang kolega dari pekerjaan sebelumnya yang tidak dapat berkompromi dengan teknologinya dan berteriak bahwa setiap orang akan terbakar di neraka karena beberapa mutasi yang salah. Seorang pengembang yang baik, jika dia bekerja selama 5, 10, 20 tahun di industri, memahami bahwa separuh dari pengetahuannya busuk, dan separuh sisanya dia tidak mengetahui sepuluh kali lebih banyak daripada yang dia ketahui. Dan setiap kali seseorang tidak sependapat dengannya dan menawarkan alternatif, itu bukanlah serangan terhadap egonya, melainkan sebuah kesempatan untuk mempelajari sesuatu. Hal ini memungkinkan dia untuk tumbuh jauh lebih cepat daripada orang-orang di sekitarnya.

Mari kita bandingkan ide saya tentang pengembang ideal dengan ide yang diterima secara umum:

Mengapa hanya meningkatkan pengkodean Anda tidak akan membuat Anda menjadi pengembang yang lebih baik

Gambar ini menunjukkan berapa banyak poin yang dijelaskan di atas yang terkait dengan kode, dan berapa banyak yang tidak. Pengembangan di perusahaan produk hanya sepertiga pemrograman, 2/3 sisanya tidak ada hubungannya dengan kode. Dan meskipun kami menulis banyak kode, efektivitas kami sangat bergantung pada dua pertiga yang “tidak relevan” ini.

Spesialisasi, generalisme dan aturan 80-20

Ketika seseorang belajar memecahkan suatu permasalahan yang sempit, belajar lama dan keras, namun kemudian menyelesaikannya dengan mudah dan sederhana, namun tidak mempunyai keahlian di bidang terkait, inilah yang disebut spesialisasi. Generalisme adalah ketika separuh waktu pelatihan diinvestasikan pada bidang kompetensinya sendiri, dan separuh lainnya pada bidang terkait. Oleh karena itu, dalam kasus pertama, saya melakukan satu hal dengan sempurna dan sisanya dengan buruk, dan dalam kasus kedua, saya melakukan semuanya dengan kurang lebih baik.

Aturan 80-20 memberi tahu kita bahwa 80% hasil berasal dari 20% usaha. 80% pendapatan berasal dari 20% pelanggan, 80% keuntungan berasal dari 20% karyawan, dan seterusnya. Dalam mengajar, ini berarti 80% pengetahuan kita peroleh dalam 20% waktu pertama yang kita habiskan.

Ada sebuah gagasan: pembuat kode hanya boleh membuat kode, desainer hanya boleh mendesain, analis harus menganalisis, dan manajer hanya boleh mengelola. Menurut pendapat saya, ide ini beracun dan tidak akan berhasil. Ini bukan berarti setiap orang harus menjadi prajurit universal, ini tentang menghemat sumber daya. Jika seorang pengembang memahami setidaknya sedikit tentang manajemen, desain, dan analitik, ia akan mampu menyelesaikan banyak masalah tanpa melibatkan orang lain. Jika Anda perlu membuat beberapa jenis fitur dan kemudian memeriksa bagaimana pengguna bekerja dengannya dalam konteks tertentu, yang akan memerlukan dua kueri SQL, maka bagus untuk tidak mengganggu analis dengan hal ini. Jika Anda perlu menyematkan tombol dengan analogi dengan yang sudah ada, dan Anda memahami prinsip umumnya, Anda dapat melakukannya tanpa melibatkan desainer, dan perusahaan akan berterima kasih untuk itu.

Total: Anda dapat menghabiskan 100% waktu Anda mempelajari suatu keterampilan hingga batasnya, atau Anda dapat menghabiskan waktu yang sama di lima area, dengan level masing-masing hingga 80%. Dengan mengikuti perhitungan naif ini, kita bisa memperoleh keterampilan empat kali lebih banyak dalam waktu yang sama. Ini berlebihan, namun menggambarkan gagasan tersebut.

Keterampilan terkait dapat dilatih bukan sebesar 80%, tetapi sebesar 30-50%. Setelah menghabiskan 10-20 jam, Anda akan mengalami peningkatan yang nyata di bidang terkait, memperoleh banyak pemahaman tentang proses yang terjadi di dalamnya, dan menjadi lebih mandiri.

Dalam ekosistem TI saat ini, lebih baik memiliki keterampilan sebanyak mungkin dan tidak menjadi ahli dalam bidang tersebut. Karena, pertama, semua keterampilan ini cepat memudar, terutama dalam hal pemrograman, dan kedua, karena 99% waktu kita tidak hanya menggunakan keterampilan dasar, tetapi tentu saja bukan keterampilan yang paling canggih, dan ini sudah cukup bahkan dalam coding, bahkan dalam perusahaan keren.

Dan yang terakhir, pelatihan adalah investasi, dan diversifikasi penting dalam investasi.

Apa yang harus diajarkan

Jadi apa yang harus diajarkan dan bagaimana caranya? Pengembang tipikal di perusahaan yang kuat secara rutin menggunakan:

  • komunikasi
  • organisasi mandiri
  • perencanaan
  • desain (biasanya kode)
  • dan terkadang keterampilan manajemen, kepemimpinan, analisis data, menulis, perekrutan, pendampingan, dan banyak lainnya

Dan praktis tidak ada keterampilan ini yang bersinggungan dengan kode itu sendiri. Mereka perlu diajarkan dan ditingkatkan secara terpisah, dan jika hal ini tidak dilakukan, level mereka akan tetap sangat rendah, sehingga tidak memungkinkan untuk digunakan secara efektif.

Bidang apa saja yang layak untuk dikembangkan?

  1. Soft skill adalah segala sesuatu yang tidak berhubungan dengan penekanan tombol di editor. Beginilah cara kita menulis pesan, cara kita berperilaku dalam rapat, cara kita berkomunikasi dengan rekan kerja. Semua ini tampak jelas, namun sering kali diremehkan.

  2. Sistem pengorganisasian mandiri. Bagi saya pribadi, ini telah menjadi topik yang sangat penting selama setahun terakhir. Di antara semua pekerja TI keren yang saya kenal, ini adalah salah satu keterampilan yang paling berkembang: mereka sangat terorganisir, mereka selalu melakukan apa yang mereka katakan, mereka tahu persis apa yang akan mereka lakukan besok, dalam seminggu, dalam sebulan. Penting untuk membangun suatu sistem di sekitar diri Anda di mana semua hal dan semua pertanyaan dicatat; ini sangat memudahkan pekerjaan itu sendiri dan sangat membantu untuk berinteraksi dengan orang lain. Saya merasa bahwa selama setahun terakhir, pengembangan ke arah ini telah meningkatkan lebih banyak kemajuan bagi saya daripada peningkatan keterampilan teknis saya; Saya mulai melakukan lebih banyak pekerjaan secara signifikan per unit waktu.

  3. Proaktif, berpikiran terbuka dan terencana. Topik-topiknya sangat umum dan penting, tidak khusus untuk TI, dan setiap orang harus mengembangkannya. Proaktif berarti tidak menunggu sinyal untuk mengambil tindakan. Anda adalah sumber peristiwa, bukan reaksi terhadapnya. Keterbukaan pikiran adalah kemampuan untuk memperlakukan informasi baru secara objektif, untuk mengevaluasi situasi dalam isolasi dari pandangan dunia dan kebiasaan lama. Perencanaan adalah visi yang jelas tentang bagaimana tugas hari ini menyelesaikan masalah selama seminggu, bulan, tahun. Jika Anda melihat masa depan di luar tugas tertentu, akan lebih mudah untuk melakukan apa yang Anda perlukan, dan tidak takut seiring waktu untuk menyadari bahwa itu sia-sia. Keterampilan ini sangat penting untuk karier: Anda dapat berhasil mencapai hasil selama bertahun-tahun, tetapi di tempat yang salah, dan akhirnya kehilangan semua beban yang terkumpul ketika menjadi jelas bahwa Anda bergerak ke arah yang salah.

  4. Semua bidang terkait hingga tingkat dasar. Setiap orang memiliki bidang spesifiknya masing-masing, namun penting untuk dipahami bahwa dengan menghabiskan 10-20 jam waktu untuk meningkatkan beberapa keterampilan “asing”, Anda dapat menemukan banyak peluang dan titik kontak baru dalam pekerjaan sehari-hari Anda, dan jam-jam ini mungkin cukup sampai akhir karir.

Apa yang harus dibaca?

Ada banyak sekali buku tentang pengorganisasian mandiri; ini adalah keseluruhan industri di mana beberapa orang aneh menulis kumpulan nasihat dan mengumpulkan pelatihan. Pada saat yang sama, tidak jelas apa yang telah mereka capai dalam hidup. Oleh karena itu, penting untuk memasang filter pada penulisnya, melihat siapa mereka dan apa yang ada di belakang mereka. Perkembangan dan pandangan saya paling dipengaruhi oleh empat buku, semuanya terkait dengan peningkatan keterampilan yang dijelaskan di atas.

Mengapa hanya meningkatkan pengkodean Anda tidak akan membuat Anda menjadi pengembang yang lebih baik1. Dale Carnegie “Cara Mendapatkan Teman dan Mempengaruhi Orang Lain”. Sebuah buku kultus tentang soft skill, jika Anda tidak tahu harus mulai dari mana, memilihnya adalah pilihan yang saling menguntungkan. Itu dibangun berdasarkan contoh, mudah dibaca, tidak memerlukan banyak usaha untuk memahami apa yang Anda baca, dan keterampilan yang diperoleh dapat segera diterapkan. Secara keseluruhan, buku ini membahas topik komunikasi dengan orang-orang.

Mengapa hanya meningkatkan pengkodean Anda tidak akan membuat Anda menjadi pengembang yang lebih baik2. Stephen R. Covey “7 Kebiasaan Orang yang Sangat Efektif”. Perpaduan berbagai keterampilan, mulai dari proaktif hingga soft skill, dengan penekanan pada pencapaian sinergi ketika Anda perlu mengubah tim kecil menjadi kekuatan besar. Ini juga mudah dibaca.

Mengapa hanya meningkatkan pengkodean Anda tidak akan membuat Anda menjadi pengembang yang lebih baik3. Ray Dalio "Prinsip". Mengungkapkan tema keterbukaan pikiran dan proaktif, berdasarkan sejarah perusahaan yang penulis bangun, yang dikelolanya selama 40 tahun. Banyak contoh kehidupan yang diperoleh dengan susah payah menunjukkan betapa berprasangka dan bergantungnya seseorang, dan bagaimana cara menghilangkannya.

Mengapa hanya meningkatkan pengkodean Anda tidak akan membuat Anda menjadi pengembang yang lebih baik4. David Allen, “Menyelesaikan Sesuatu”. Bacaan wajib untuk belajar mengatur diri sendiri. Ini tidak mudah untuk dibaca, tetapi ini menyediakan seperangkat alat yang komprehensif untuk mengatur kehidupan dan urusan, memeriksa semua aspek secara mendetail, dan membantu Anda memutuskan apa yang sebenarnya Anda butuhkan. Dengan bantuannya, saya membangun sistem saya sendiri yang memungkinkan saya untuk selalu melakukan hal terpenting tanpa melupakan sisanya.

Anda harus memahami bahwa membaca saja tidak cukup. Anda dapat menelan setidaknya satu buku dalam seminggu, tetapi efeknya akan bertahan selama beberapa hari, dan kemudian semuanya akan kembali ke tempatnya. Buku hendaknya dijadikan sumber nasehat yang segera diuji dalam praktek. Jika Anda tidak melakukan ini, mereka hanya akan memperluas wawasan Anda.

Sumber: www.habr.com

Tambah komentar