Saya tidak setuju dengan pernyataan bahwa manajer tidak melihat kode. Ketika saya sudah mengelola tim, saya telah melihat beberapa output dari setiap insinyur - dan yang besar adalah kode. Tapi bukan satu-satunya - email, dokumen desain, whitepapers - semuanya faktor dalam.
Tapi itu jelas bukan satu-satunya faktor. Jika satu orang duduk di sudut dan menulis kode yang brilian tetapi dia binatang buas untuk diajak bicara, tidak akan menjawab pertanyaan, tidak akan berbagi status dan tidak akan berkompromi ketika masalah develoment muncul - saya tidak begitu yakin dia seorang aset ke tim. Terutama dibandingkan dengan pria yang menulis kode yang lumayan tetapi dapat melakukan semua hal di atas.
Berikut adalah beberapa hal yang saya lihat ketika saya berada dalam posisi untuk memberikan hadiah, tetapi dengan peringatan besar bahwa itu benar-benar reaksi usus, karena tidak ada yang dapat diukur:
- Status - apakah jelas, akurat, & tepat waktu? Ketika dibahas, apakah orang tersebut berada di atas status atau sedikit kabur tentang masalah saat ini? Apakah orang tersebut memiliki penilaian yang tepat untuk mengibarkan bendera merah ketika ada sesuatu yang terbakar?
- Pemecahan masalah - baik bertanya dan menjawab itu penting. Apakah orang tersebut tahu kapan harus meminta bantuan, atau di mana mereka memutar roda mereka tanpa batas? Lebih baik lagi, ketika orang lain memiliki masalah, apakah orang itu membantu menemukan solusi atau menjadi bagian dari masalah? Bahkan memiliki akal sehat untuk mundur ketika masalah tidak ada dalam bidang keahlian Anda bernilai beberapa poin. Juga ada poin untuk keluar dari grup atau perusahaan, dan pergi ke situs-situs seperti ini, atau jawaban internet lainnya.
- Perhatian terhadap proses - biasanya ini cukup jelas - bahkan di perusahaan non-anal-retensive, jika seseorang melanggar sistem, itu terlihat dalam kekacauan yang mereka tinggalkan. Jika orang lain membersihkan fitur orang lain karena mereka tidak mematuhi panduan atau arsitektur, maka kita memiliki masalah. Poin bonus diberikan kepada mereka yang mencari cara untuk membuat konsistensi dan kualitas lebih mudah .
- Tingkat penyelesaian vs bug vs kompleksitas - selesaikan semuanya, tapi selesaikan dengan benar. Semua orang punya beberapa bug, tetapi jika orang itu menyelesaikan pekerjaan dengan cepat dan bermasalah, kami memiliki masalah. Saya biasanya menemukan ini bukan sesuatu yang dapat Anda nilai dalam arti sehari-hari - itu harus melihat kembali pada rilis atau fase atau kuartal fiskal.
Dan masukan orang lain. Seringkali saya berada di posisi di mana berbagai insinyur bertanggung jawab atas berbagai bagian proyek. Kadang-kadang tim memimpin, dan kadang-kadang hanya pemilik suatu bagian tertentu dari output (seperti "the build guy"). Orang-orang CINTA untuk berbicara tentang ekstrem - tindakan kepahlawanan atau frustrasi anak-anak yang bermasalah. Biasanya dalam tindak lanjut dengan masalah-masalah itu, saya mencari tahu banyak tentang KEDUA pihak.
Ada juga faktor di sana tentang Mengelola Manusia . Tidak ada insinyur yang persis seperti yang lain. Jadi mereka tidak semua bersinar dalam cahaya yang sama. Satu menulis kode bebas bug yang brilian, tetapi yang lain membantu memecahkan masalah lintas sektor yang merusak kode semua orang. Seseorang hebat secara pribadi, satu lebih baik dalam menulis. Yang satu tidak koheren pada jam 9:00 pagi, yang lain sudah keluar dari sini jam 3:00 sore. Ada kebutuhan tertentu untuk mundur, mencari tahu apa yang paling bermanfaat bagi tim dan apa yang mungkin menjadi faktor bias pribadi (seperti keinginan untuk membunuh lelaki yang jam 4 pagi itu, hanya karena saya tidak bisa berfungsi sampai jam 11: 00 pagi).