Mendapatkan kembali kepercayaan diri programmer senior [ditutup]

Bos saya tahu saya tidak sepandai yang dia kira.

Contoh dari pengalaman saya:

Saya seorang programmer junior, dan saya bekerja dalam tim yang terdiri dari dua orang, bos saya (programmer senior) dan saya sendiri.

Saya ditugaskan mengembangkan aplikasi web internal untuk perusahaan tempat kami bekerja. Saya menulis back-end ke front-end (desain database sudah ada dan teknologi server telah dipilih). Dia secara berkala akan memeriksa kemajuan saya dengan mengamati aplikasi web yang sedang beraksi dan senang karena itu akan datang. Ketika saya menyelesaikan aplikasi web, dia senang dengan seberapa baik produk akhir yang dihasilkan.

Beberapa hari yang lalu dia menjadi tertarik pada kode jadi saya mengatakan kepadanya teknologi apa yang saya gunakan (untuk front-end), dan ini adalah di mana ia pergi ke selatan. Untuk front-end dari web-aplikasi saya menggunakan kerangka Javascript (Backbone.js). Ketika ditanya mengapa saya melakukan hal seperti itu. Tanggapan saya adalah karena saya merasa kerangka kerja tersebut cocok dengan aplikasi ini dengan baik, dan akan membantu saya menyusun kode lebih baik daripada jika saya menulisnya dari awal .... "Ya, itu mengecewakan" adalah jawabannya.

Jadi diberikan contoh ini pertanyaan saya adalah:

Jika Anda seorang programmer senior dan telah kehilangan kepercayaan pada kemampuan programmer junior Anda, apa yang akan Anda ingin melihat dari junior Anda untuk mendapatkan kembali kepercayaan?

EDIT : Terima kasih semuanya atas jawaban yang bagus dan umpan balik yang mendukung!

Jika dia menyukai produk yang Anda buat, tetapi tidak bisa menggunakan Backbone, Anda berdua perlu berbicara tentang tumpukan teknologi yang diinginkan.

Sebagai pengembang, kita harus menggunakan alat yang tersedia, dan akibatnya, dengan lancar memindahkan aliran pekerjaan kita. Jika dia mengharapkan Anda untuk membangun front-end dari awal, ia seharusnya eksplisit dan memiliki alasan yang kuat.

Fakta bahwa ia awalnya menikmati produk adalah bukti yang cukup bahwa Anda melakukannya dengan baik dan cukup "pintar".

tl; dr Anda melakukannya dengan baik. Bicaralah dengan senior Anda dan lihat apa yang dia harapkan dari Anda.

Dia tidak tampak "senior" bagi saya untuk membuat keputusan penilaian cepat seperti itu. Saya selalu cenderung menggunakan kerangka kerja yang tepat alih-alih anti-pola "Reinvent the square wheel". Jika dia benar-benar senior, dia akan mengerti dan tahu nilai dari kerangka kerja yang baik. Paling-paling saya berharap dia mempertanyakan pilihan Backbone.js atas kerangka kerja JavaScript MVC lain dan jauh lebih awal dalam prosesnya. Dia gagal dalam membimbing dan memeriksa Anda dengan benar sebagai junior dan membantu Anda sepanjang jalur pengembangan yang tepat (dalam benaknya.)

Sepertinya Anda membuat pilihan yang tepat dalam mengembangkan proyek mengingat kurangnya arahan di pihaknya (asumsi) dan bekerja untuk menjadi pengembang yang lebih kompeten. Saya akan berpikir mungkin ada nilai dalam menjelaskan kepadanya pilihan kerangka kerja Anda, mengapa Anda merasa kerangka kerja itu tepat, dan menunjukkan bahwa proyek itu dilakukan dan memuaskannya sebagian karena menggunakan kerangka kerja yang terdokumentasi dan didukung dengan baik. Jika Anda tidak dapat membuat kemajuan, mungkin tidak ada gunanya tampil lebih baik di matanya. Hanya Anda yang bisa menjawabnya.

Mayoritas jawaban dan komentar memiliki ide yang tepat karena Anda dan senior perlu berdiskusi dan mungkin penting bagi Anda untuk meningkatkan dan mempertahankan keputusan Anda, bahkan jika senior Anda tidak setuju dengan pilihan Anda. .

Untuk menjawab pertanyaan Anda tentang apa yang ingin saya lihat sebagai senior:

Saya ingin melihat apakah pengembang junior saya dapat berdiri dan mempertahankan keputusannya, meskipun sedikit kekecewaan. Jika saya senang dengan produk tetapi tidak dengan implementasi maka saya akan mengharapkan junior untuk menunjukkan bahwa saya seharusnya lebih spesifik dalam spesifikasi saya ketika memberi mereka produk. Saya ingin mereka dapat berdiri di tanah mereka tetapi juga untuk mengakui bahwa mereka mungkin tidak membuat pilihan yang tepat jika itu terjadi.

PS: Saya harus menyebutkan bahwa saya seorang senior yang suka dibuktikan salah pada tingkat profesional karena itu memberi saya kesempatan untuk belajar sesuatu yang baru. Dan saya ingin mengetahui bagaimana orang lain di tim saya melakukan sesuatu sehingga tidak ada / kurang kejutan di akhir Sprint / tugas.

Pertama-tama, saya pikir ini perlu dilihat sebagai peluang, bukan kegagalan. Jelas ada ketidakcocokan dalam harapan dan tidak jelas dari mana datangnya, apa yang perlu terjadi untuk mengembalikan semuanya ke jalur dan sejenisnya.

Kedua, jika Anda menganggap ini sebagai kegagalan saat ini atau bahwa Anda tidak secerdas yang Anda pikirkan yang mengatur hubungan kekuatan yang tidak Anda inginkan. Jadi, jika Anda membuat keputusan yang Anda yakini dapat dipertahankan, Anda harus mau mempertahankannya sampai batas tertentu.

Sementara saya setuju dengan duggieawesome bahwa Anda ingin melakukan percakapan, itu tidak cukup. Anda harus siap untuk masuk, mendiskusikan ide-ide desain Anda, menjelaskan mengapa Anda melakukan apa yang Anda lakukan, dan mempertahankan alasannya. Anda juga harus menerima bahwa tidak hanya ada satu jawaban yang benar dan bahwa programmer senior mungkin memiliki alasan yang sah untuk memilih desain yang berbeda dan karenanya Anda ingin bersedia mendengarkan alasan-alasan itu tanpa mengakui bahwa keputusan Anda didasarkan pada keputusan yang buruk. pada apa yang Anda tahu (kecuali Anda memutuskan bahwa Anda seharusnya tahu lebih baik, dan kemudian itu masalah lain).

Ingatlah bahwa desain biasanya merupakan masalah pengorbanan. Anda ingin bersedia untuk membahas apa pengorbanan itu, dan melihat apa yang Anda berdua bisa lakukan untuk memastikan Anda dapat mendiskusikan pengorbanan desain di masa depan. Mungkin Anda berdua hanya berharap Anda lebih pada halaman yang sama daripada Anda? Mungkin bos Anda idiot (mungkin kadang-kadang terjadi)? Mungkin Anda benar-benar membuat keputusan yang salah mengingat apa yang Anda ketahui tentang persyaratan? Masuklah dengan pikiran terbuka dan dengan percaya diri, dan berkeinginan untuk benar-benar membicarakan hal ini.

Sunting: Saya ingin menambahkan sesuatu tentang menjadi pintar. Orang terpintar yang saya kenal adalah orang yang menganggap mereka memiliki sesuatu untuk dipelajari dari semua orang. Orang-orang yang tertutup dan percaya bahwa hanya ada satu cara yang benar tidak berakhir membuat keputusan yang baik secara imajinatif dalam bidang-bidang seperti desain dan mereka tidak dapat menghubungkan hal-hal bersama dengan cara yang dapat dipelajari oleh orang-orang yang mau belajar dari semua orang. Masuk dan berkeinginan untuk berbagi dan bahkan memantulkan ide bolak-balik adalah tanda keduanya cerdas dan percaya diri. Perbedaan dalam desain tidak selalu menjadi masalah satu menjadi lebih baik dari yang lain. Dengan asumsi desainer yang kompeten, desain yang berbeda akan dioptimalkan berbeda.

Saya dengan pendapat umum di sini bahwa Anda tidak melakukan kesalahan. Sebagai pengembang senior, ia seharusnya menaruh minat pada bagaimana Anda mengembangkan aplikasi serta hasilnya. Untuk datang setelah proyek selesai dan mengatakan dia tidak suka bagaimana itu dilakukan tidak terlalu profesional di pihaknya.

Tetapi, untuk menjawab pertanyaan utama Anda: bagaimana Anda mendapatkan kembali pendapat senior tentang Anda setelah itu mungkin hilang? Pertama-tama, tanyakan bagaimana perasaan mereka seharusnya Anda lakukan. Ajukan pertanyaan jika Anda tidak mengerti dan mencatat. Tunjukkan bahwa Anda ingin belajar.

Kedua, pada tugas Anda selanjutnya, jika ada sesuatu yang terlewatkan dari uraian itu, buatlah ide-ide Anda kemudian jalankan ide tersebut oleh senior dev. Jangan bertanya bagaimana melakukannya, karena ini tidak akan membantu pendapat mereka tentang Anda. Tetapi, jika Anda datang dengan ide-ide Anda sendiri dan solusi Anda sendiri, kemudian tanyakan apakah Anda berada di jalur yang benar, itu akan menunjukkan kepada mereka bahwa Anda sedang berusaha dan bahwa Anda memang memiliki keterampilan untuk menyelesaikan pekerjaan. Ini bisa sesederhana email singkat yang mengatakan "Hei, saya berencana menggunakan x saat melakukan y . Ada pikiran?"

Ketiga, ketika mereka membuka kepala untuk melihat apa yang Anda lakukan, jangan biarkan mereka pergi tanpa melihat kode Anda.

Pada dasarnya, buka jalur komunikasi. Pengembang senior Anda sepertinya bukan tipe yang ada pada Anda atau kode Anda, jadi Anda perlu meningkatkan dan menjadi orang yang berkomunikasi. Lebih baik bagi semua orang yang terlibat untuk menemukan sesuatu yang pada awalnya tidak dipikirkan lebih awal daripada nanti.

Satu hal yang perlu Anda ketahui secara langsung adalah apakah dia kecewa karena Anda tidak bisa memberikan pembelaan komprehensif atas kerangka kerja pilihan Anda, atau jika itu karena Anda menggunakan kerangka kerja.

Dalam kasus sebelumnya, penting bagi Anda untuk belajar bagaimana mengevaluasi dan memilih kode pihak ketiga untuk dimasukkan dalam suatu proyek, dan Anda tahu bagaimana mengartikulasikan keputusan itu kepada atasan Anda dan bersiaplah untuk mendukungnya dengan justifikasi. Ini adalah keterampilan yang sulit untuk dipelajari, tetapi disertai dengan pengalaman. Ini juga merupakan keterampilan yang baik untuk dipelajari karena segera setelah Anda memasukkan perpustakaan pihak ketiga ke dalam proyek Anda memperkenalkan komponen yang mungkin tidak sepenuhnya dipahami oleh pengembang lain, bahwa mereka tidak memiliki kontrol penuh atas, dan mungkin mengandung bug, lubang keamanan dan hal-hal lain yang perlu mereka perhatikan.

Jika dia kecewa karena Anda tidak menulisnya dari awal maka itu masalah yang sama sekali berbeda. Mungkin ia memiliki alasan kuat untuk mencegah penggunaan kerangka kerja (seperti yang saya jelaskan di atas), atau mungkin ada kebijakan perusahaan yang menentangnya atau membatasi pilihan kerangka kerja yang dapat Anda buat. Bagaimanapun dia harus menyampaikan hal itu kepada Anda dan fakta bahwa ia tidak menunjukkan kegagalan di pihaknya. Di sisi lain ia mungkin hanya memiliki kasus prasangka kerangka kerja, karena terlepas dari masalah yang dapat menyebabkan kerangka kerja, mereka juga memiliki manfaat besar karena saya yakin Anda tahu. Dia mungkin berpikir Anda harus membuat semuanya sendiri, bahkan jika itu berarti mengulang pekerjaan yang sudah dilakukan dan tersedia untuk umum karena "sindrom Not Invented Here".

Bahwa dia tidak menjelaskan mengapa dia kecewa pada Anda karena menggunakan kerangka kerja tentu saja merupakan kegagalannya untuk berkomunikasi secara efektif. Dia membuat Anda bertanya-tanya apa yang telah Anda lakukan salah, ketika jawabannya bisa jadi "tidak ada". Dia juga membuat Anda mempertanyakan diri Anda sendiri, dan itu membuat Anda kurang cenderung menggunakan inisiatif Anda sendiri di masa depan. Jika ada satu sifat yang tidak mampu dimiliki oleh programmer yang baik, itu adalah kurangnya inisiatif. Dan sementara saya yakin itu tidak disengaja, sikapnya merusak moral karena dia tiba-tiba menarik pujian untuk pekerjaan yang dilakukan dengan baik pada satu detail kecil tentang bagaimana Anda menyelesaikan tugas.

Hanya karena dia adalah programmer senior yang tidak membuatnya sempurna.

Komentar tindak lanjut Anda yang mengatakan bahwa bos kesal dia harus belajar sesuatu yang baru ....

Kecuali ada lebih dari itu yang belum Anda sebutkan, saya akan kesal pada DIA.

Mempelajari teknologi baru adalah bagian besar dari pekerjaan kami dan setiap tim harus merangkul pembelajaran dan peningkatan diri.

NAMUN, manajemen punya hal lain yang perlu dikhawatirkan. Mereka memiliki tenggat waktu untuk dipenuhi, mereka memiliki anggaran pelatihan terbatas atau tidak ada.

Dari sudut pandang manajemen manusia, mungkin orang lain yang mengerjakan fase 2 proyek Anda, bukan Anda. Bos Anda mungkin memiliki telinga orang lain yang ditandai untuk melakukan pekerjaan itu, dan dia tahu orang itu sekarang memiliki kurva belajar untuk sesuatu yang baru.

Dan sekarang TETAPI pada TETAPI sebelumnya ....... ini adalah kesalahan bos Anda. Jika Anda baru dan junior, ia seharusnya memberikan setidaknya beberapa panduan. Pada tingkat lebih rendah, Anda bisa meminta panduan tentang teknologi untuk digunakan juga.

Jika Anda seorang programmer senior dan telah kehilangan kepercayaan terhadap kemampuan programmer junior Anda, apa yang ingin Anda lihat dari junior Anda untuk mendapatkan kepercayaan diri kembali?

Mengingat Anda telah mengatakan bahwa dia tidak ingin belajar bagaimana menggunakan kerangka yang Anda gunakan, saya pikir pertanyaannya seharusnya: " Jika Anda seorang programmer senior dan Anda kehilangan kemampuan untuk belajar dari Anda programmer junior, apa yang harus Anda lakukan untuk menyortir diri sendiri? "

Sebagai pengembang profesional, Anda tidak berhenti belajar. Pernah. Jika Anda melakukannya, Anda akan mandek. Dan itu mungkin baik di beberapa daerah. Perbankan memiliki banyak sistem warisan dalam operasi yang perlu dipertahankan sehingga pengetahuan tentang sistem lama yang bergerak sangat lambat baik-baik saja. Seorang teman saya sedang mengedit COBOL untuk bank untuk menemukan bahwa kode sumber yang dia perbaiki belum tersentuh dalam waktu sekitar 30 tahun (dan penulis aslinya adalah dosen COBOL kami di universitas) ... Karena itu, dia masih harus pelajari hal baru karena sistem lama harus diintegrasikan ke dalam sistem baru.

Kembali ke pengembang senior Anda. Anda berkata " dia kesal karena harus belajar sesuatu yang baru ", dan menurut saya itu adalah bunyi beberapa lonceng alarm yang cukup keras.

Saya selalu belajar. Sementara saya benar-benar ingin majikan saya mengambil tagihan pendidikan saya setiap tahun, jarang mereka menghabiskan sesuatu yang dekat dengan apa yang saya rasa sebenarnya saya butuhkan, namun saya tahu bahwa saya harus tetap dapat dipekerjakan sehingga saya menghabiskan suatu tempat di wilayah £ 2000 GBP (sekitar $ 3000 USD) untuk pendidikan saya sendiri setiap tahun.

Jika senior Anda tidak mempelajari hal-hal baru maka mereka akan mulai membuat keputusan yang buruk (mungkin mereka sudah) dan kualitas kode yang Anda hadapi akan turun karena mereka terjebak dalam liang dan tidak merasa perlu untuk mendapatkan keluar dari kebiasaan itu.

Salah satu pengembang terbaik yang pernah saya bekerja dengan adalah pengembang junior yang tahu segala macam hal yang saya tidak pernah punya kesempatan untuk melihatnya. Dia membawa begitu banyak ke meja sehingga aku sering kewalahan. Tetapi saya menghargai usahanya dan saya tidak pernah "kecewa" dengan semua itu. Saya senang dia meluangkan waktu untuk menghargai semua kemungkinan dan menyajikannya kepada tim. Dia sekarang memimpin tim dan dia terus memberi tahu saya tentang pengembang yang membawa hal-hal baru dan apa yang dia pelajari dari mereka.

Pengembang senior Anda perlu mempelajari berbagai hal. Mereka perlu belajar untuk tidak menggunakan kata-kata emotif (seperti "dis-heartening") untuk menyembunyikan kekurangan mereka sendiri, karena itu akan mengetuk kepercayaan orang lain. Mereka perlu belajar kerangka kerja baru (bahkan jika mereka tidak dapat mempelajari semuanya, mempelajari apa yang dilakukannya dan bagaimana memecahkan masalah, dan jika mereka membutuhkannya di masa depan maka mereka dapat menginvestasikan waktu untuk belajar lebih dalam). Dan mereka perlu belajar bahwa mereka berada dalam pekerjaan di mana mereka harus terus belajar sepanjang waktu.