Bagaimana manajer tahu jika seseorang adalah programmer yang baik atau buruk?

Di sebagian besar perusahaan yang melakukan tim dan divisi pemrograman terdiri dari programmer yang merancang dan menulis kode dan manajer yang ... yah, melakukan hal-hal manajemen. Selain tidak menulis kode, manajer biasanya bahkan tidak melihat kode yang dikembangkan tim, dan bahkan mungkin tidak memiliki IDE yang tepat diinstal pada mesin kerja mereka.

Tetap saja, para manajer harus menilai apakah seseorang bekerja dengan baik, apakah dia harus bertanggung jawab atas sesuatu, atau jika pengembang tertentu harus ditugaskan untuk tugas yang paling penting dan bertanggung jawab. Dan yang terakhir, namun tidak kalah pentingnya: para manajer biasanya memberikan bonus triwulanan!

Untuk melakukan hal di atas secara efektif, seorang manajer harus tahu apakah seseorang adalah programmer yang baik — tentu saja di antara sifat-sifat lain. Pertanyaannya adalah, bagaimana mereka melakukannya? Mereka bahkan tidak melihat kode yang ditulis orang, mereka tidak dapat secara langsung menilai kualitas komponen yang dikembangkan oleh programmer ... tetapi perkiraan mereka tentang siapa yang merupakan pembuat kode yang baik, dan siapa yang "tidak sebagus" tetap benar dalam Kebanyakan kasus!

Apa rahasianya?

Biasanya seorang manajer akan melihatnya

• Apakah programmer menyelesaikannya?
• Apa pendapat rekan kerja mereka tentang mereka? Kode yang mereka tulis?
• Apakah programmer berkomunikasi dengan jelas kepada manajer?
• Apakah programmer senang mempelajari hal-hal baru? Apakah mereka membimbing orang lain dengan baik?
• Apakah mereka membutuhkan banyak perhatian manajemen untuk menyelesaikan pekerjaan?
• Apakah programmer sepertinya mendapatkan kesenangan dari pekerjaan mereka?

Memang benar bahwa mereka biasanya tidak melihat (atau sering mengerti) kode karyawan, tetapi di atas bagi mereka berfungsi sebagai proxy yang masuk akal untuk mengukur seberapa baik seorang karyawan cocok dengan peran pemrograman yang dikenakan pada mereka oleh majikan mereka. Jika seseorang tidak menyelesaikan pekerjaan, mendapat nilai rendah dari kolega mereka, tidak dapat berkomunikasi dengan baik, frustrasi dengan teknologi yang berbeda dari yang biasa mereka lakukan, selalu membutuhkan pengawasan, dan selalu tidak bahagia, itu indikasi yang baik bahwa mereka tidak t berhubungan baik dengan pekerjaan ini. *

* Mungkin, bagaimanapun, bahwa dalam konteks dan lingkungan yang berbeda mereka akan sangat bahagia dan antusias. Mungkin itu hanya jenis programmer yang mereka keberatan, dan mereka mungkin melakukan pemrograman dengan sangat baik dalam konteks yang berbeda. "Programmer" dapat berarti pekerjaan yang sangat berbeda di tempat yang berbeda. Tetapi manajer kebanyakan peduli tentang peran "programmer" mereka dan seberapa cocok seorang karyawan.

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).

Ini sangat bervariasi tergantung pada keahlian teknis manajer.

• Sebagian besar, mereka mungkin menilai Anda tentang cara Anda berkomunikasi . Bagaimana Anda berkomunikasi dengan manajer dan bagaimana Anda terlihat berkomunikasi dengan kolega Anda.
• Jika Anda beruntung memiliki pengembang utama yang lebih dekat dengan manajer, manajer dapat meminta masukan dari pengembang utama.
• Ingatlah bahwa tanggung jawab utama manajer adalah menyelesaikan pekerjaan . Dia perlu melihat menghasilkan berbagai hasil dan tujuan untuk memenuhi rencana bisnis. Jadi, jika Anda entah bagaimana bisa terlihat seperti Anda memiliki pengaruh langsung pada hasilnya , ini akan menjadi pertanda baik bagi Anda.

Umumnya tidak.

Itulah sebabnya pemrograman adalah "Pasar untuk Lemon." http://en.wikipedia.org/wiki/The_Market_for_Lemons

Kode menjadi kacau, dan umumnya tidak selama 2-3 tahun sebelum Anda tahu. Programmer biasanya bertahan selama 18 bulan, jadi Anda tidak akan pernah melihat penjahat gagal.

Manajer harus mengambil kata-kata Anda itu, misalnya rilis membutuhkan empat bulan dan seratus iterasi. Mungkin Anda mengedit banyak file penerapan dengan tangan dan membaca file log untuk kesalahan yang bercampur dengan status? Mereka tidak tahu bahwa itu bisa dilakukan dengan lebih baik.

Jadi jujur, dan profesional dan cobalah untuk meningkatkan. Dengan pengalaman, seorang manajer akan mulai melihat pola perilaku yang baik dan buruk.

Bagaimana manajer tahu jika seseorang adalah programmer yang baik atau buruk?

Saya akan mulai dengan generalisasi menyeluruh: sebagian besar manajer tidak dapat memberi tahu programmer "baik" dari programmer "buruk".

Dengan hal itu, apa yang oleh sebagian besar manajer (saya temui atau bekerja) dianggap "baik" dalam seorang programmer bukanlah keahlian yang sama dengan yang oleh programmer lain dianggap "baik."

bagaimana mereka melakukannya?

Seorang manajer yang berorientasi pada hasil akan mencari hal-hal seperti "pintar" dan "menyelesaikan sesuatu." Mereka tidak akan peduli jika Anda muncul untuk bekerja di celana olahraga selama Anda menyelesaikannya tepat waktu dan sesuai anggaran.

Seorang manajer yang berorientasi pada proses lebih peduli dengan "bagaimana hal-hal dilakukan." Ini berarti mulai bekerja tepat waktu, mengenakan pakaian yang tepat dan apakah Anda memiliki sampul yang tepat pada laporan TPS.

orang bekerja dengan baik, jika dia harus bertanggung jawab atas sesuatu

Menjadi "penanggung jawab" membutuhkan keterampilan yang berbeda dari menulis kode. Jika seseorang memiliki keterampilan orang yang dibutuhkan untuk memimpin sebuah tim, maka orang itu harus disadap untuk melakukannya. Jika Anda mempromosikan orang berdasarkan elemen pekerjaan utama dari pekerjaan yang saat ini mereka lakukan, pada akhirnya mereka mencapai tingkat di mana mereka sekarang tidak kompeten. Ini disebut Prinsip Peter .

Jelas itu selalu membantu untuk memiliki manajer melek pemrograman yang benar-benar dapat membaca kode dan bahkan lebih penting menggali ke dalam sistem pelacakan bug dan memahami apa yang terjadi, tahu bahwa tidak semua bug dibuat sama dan hanya memberikan kode buruk tepat waktu tidak masuk hitungan banyak.

Tapi itu kasus yang ideal. Untuk seorang manajer untuk mendapatkan ukuran seorang programmer dari sudut pandang non teknis saya punya beberapa saran.

• Apakah mereka segera / secara teratur / konsisten menyoroti di mana ada masalah dengan menyelesaikan sesuatu untuk memenuhi persyaratan yang ditentukan saat ini ... dan benar-benar menyebalkan karenanya (ini adalah pengembangan perangkat lunak, jika tidak cukup kompleks untuk memiliki masalah ini, ini bukan proyek pengembangan nyata).
• Jika mereka tidak yakin tentang sesuatu, apakah mereka langsung berkata begitu - hanya seorang programmer yang yakin dengan kemampuan mereka sendiri yang akan melakukan ini (dan mereka tahu jika Anda tidak menyukainya, mereka dapat dengan mudah mendapatkan pekerjaan lain). Sebaliknya seseorang yang tahu bahwa mereka benar-benar keluar dari kedalamannya cenderung bersembunyi dan mencari perlindungan.
• Apa yang dikatakan / disiratkan oleh programmer lain dalam tim tentang programmer lain? Jika Anda seorang manajer setengah layak, Anda berada di parit dengan tim pemrograman Anda - terutama selama waktu pengujian integrasi / perbaikan bug. Jadi, jika Anda tidak mendapatkan umpan balik semacam ini, orang lain harus melakukan pekerjaan Anda.
• Dan favorit saya: apa yang saya sebut programmer 'tomcat'. Jika setelah beberapa saat Anda terus-menerus memperhatikan berbagai pemrogram selalu berseliweran di meja pemrogram yang sama (dengan asumsi mereka melakukan pekerjaan dan membahas beberapa masalah yang merepotkan, dan bukan penemu tetap webstuff keren & lucu) ... maka ada alasan mengapa pemrogram lain tertarik ke meja orang itu. Jika mereka belum menjadi pemimpin tim, maka mereka mungkin harus dibuat sesegera mungkin.

Jika ada atau semua ini berlaku, Anda cenderung memiliki programmer yang baik. Perhatikan bahwa oleh programmer yang baik saya tidak hanya menilai kemampuan pengkodean mereka tetapi hal-hal berguna lainnya seperti dapat berkomunikasi dengan manusia lain ;-)

Manajer mungkin tidak tahu kapan kode yang Anda tulis itu brilian atau apakah itu bisa diperbaiki oleh faktor besar, tetapi yang ia tahu adalah: Apakah Anda memenuhi tenggat waktu dengan kode yang berfungsi? Apakah Anda orang yang bisa ia percayai untuk memperbaiki masalah yang diciptakan orang lain? Apakah klien atau pengguna melihat masalah yang semakin meningkat ke manajernya? Adakah bencana besar pada arloji Anda (Menghapus tabel pengguna, lupa mengatur cadangan, mengirim email ke pelanggan dengan data hak milik dari pelanggan lain yang seharusnya tidak mereka lihat, dll. Apakah ada yang memuji pekerjaan Anda kepadanya (terutama secara tertulis) Apakah orang mengatakan hal-hal baik atau buruk di belakang Anda?

1. Dalam kebanyakan kasus di mana kode Anda tidak dievaluasi oleh manajer Anda, itu dievaluasi oleh rekan-rekan Anda (baik secara formal, atau informal ketika mereka mencoba untuk bekerja dengan kode Anda). Bos Anda akan menggunakan pendapat rekan kerja Anda (sekali lagi, baik formal maupun informal) sampai batas tertentu.
2. Keandalan umum Anda dan seberapa cepat Anda maju dan menyelesaikan tugas sering kali merupakan faktor yang sangat penting, terpisah dari kemampuan pengkodean Anda.
3. Komunikasi. Jika Anda mendapatkan banyak hal dan melakukannya dengan baik, manajer Anda perlu mengetahuinya! (Hindari membual, tentu saja). Belajarlah untuk "mengelola manajer Anda" dan tidak hanya bersikap pasif. Bantu atasan Anda untuk mengetahui cara Anda bekerja.

Manajer adalah pembuat kode sendiri dan oleh karenanya dapat, dengan pengamatan sederhana, mencari tahu apakah pembuat kode itu baik atau tidak.

Jika manajer Anda bukan coders (dan Anda berada dalam bisnis perangkat lunak), Anda kacau.

Sebagai seorang manajer, berikut adalah beberapa hal yang saya lihat ketika mengevaluasi programmer saya:

• Umpan balik teman. Saya bertanya kepada programmer di tim saya, dan programmer dari tim lain untuk mengirim saya umpan balik tentang orang-orang saya.

• Hormat rekan . Ketika programmer saya menemukan masalah yang tidak bisa mereka selesaikan, mereka berkata, "Mari kita tanyakan saran ini dan itu."

• Melakukan sesuatu . Saya mengatakan "Saya ingin X" dan hari berikutnya, X selesai.

• Mendapat hal-hal yang pintar . Saya mengatakan "Saya ingin X" dan keesokan harinya, tidak hanya X dilakukan, tetapi semua hal seperti X diselesaikan dan tidak perlu perhatian lebih lanjut.

• Memperbaiki saya . Saya mengatakan "Saya ingin X" dan programmer mengatakan "X tidak benar, kita harus melakukan Y, dan inilah sebabnya."

Tidak banyak manajer yang baik di luar sana (lihat pertanyaan terkait: bagaimana progammers tahu jika seseorang adalah manajer yang baik atau buruk?). Mengelola orang dengan baik itu sulit, dan membutuhkan banyak waktu dan kerja keras. Segera setelah saya mengelola 5 orang, saya hampir tidak punya waktu untuk pemrograman. Ketika saya mengelola 8+ orang, saya tidak bisa lagi mengelola mereka sebaik yang seharusnya.

Saya pikir premis pertanyaan Anda agak cacat karena menegaskan bahwa manajer tidak benar-benar melihat kode. Saya telah bekerja dalam banyak situasi di mana manajer saya adalah sesama insinyur dan berpartisipasi aktif dalam ulasan kode.

Namun, pasti ada sejumlah situasi di mana orang non-teknis bertanggung jawab atas insinyur perangkat lunak, dan mereka tidak dapat mengandalkan pengetahuan dan pengalaman mereka sendiri.

Dalam kasus ini, manajer yang bertanggung jawab akan meminta saran dari insinyur. Mereka akan bertanya kepada orang-orang non-teknis dalam organisasi yang berinteraksi dengan insinyur tersebut untuk melihat apakah ia memiliki keterampilan orang-orang baik yang sesuai dengan tanggung jawab yang meningkat.

Yang tidak bertanggung jawab hanya akan pergi dengan "usus" reaksi mereka menggunakan semacam "metrik" yang umumnya tidak didukung.

Ini adalah omong kosong, tetapi Anda selalu dapat berhenti dan berharap untuk sesuatu yang lebih baik di tempat lain.

Di mana saya bekerja, ketika evaluasi karyawan datang, manajer mengirim seorang penanya tidak resmi yang tidak resmi kepada mereka yang secara teratur berinteraksi dengan karyawan; baik sesama pengembang maupun pelanggan. Ini memberikan peluang kepada sesama pengembang untuk memberikan masukan tentang kinerja sebagai pembuat kode yang mungkin diabaikan oleh manajer.

Manajer harus melihat yang terukur. Apa aspek pekerjaan, yang diukur dalam hal pekerjaan yang dilakukan, kualitas pekerjaan. Mereka mungkin tidak tahu apakah Anda melakukan pekerjaan yang berkualitas, kecuali jika Anda menghasilkan banyak kesalahan, atau tidak mengizinkan pengguna akhir untuk melakukan apa yang seharusnya dilakukan.

Pekerjaan Anda membebani uang manajer dalam pengeluaran, jadi Anda harus menguntungkan secara finansial untuk melanjutkan pekerjaan.

Saya tidak mengatakan ini adalah cara terbaik untuk melakukannya, tetapi mereka dapat mendasarkannya pada kepuasan pelanggan. Jika mereka menyukai aplikasi, menerima jumlah bug, dan merasa Anda menambahkan fitur baru secara tepat waktu, dapatkah pengembang Anda seburuk itu?

Tentu saja mereka bisa. Mereka dapat memaksa melalui coding karena Anda memiliki 10 orang melakukan pekerjaan dua. Atau pelanggan puas karena Anda menjual aplikasi Anda dengan sangat murah.

Masalah lain dengan pendekatan ini, adalah Anda harus menunggu sampai aplikasi hampir selesai sebelum manajer non-teknis bisa mendapatkan umpan balik pelanggan. Buat aplikasi hanya selama setahun untuk merilisnya dan tidak ada yang suka.

Hidup akan lebih sederhana jika Anda bisa mengandalkan memberi tahu orang-orang untuk 'Buat saja itu berhasil.' Ketika Anda memahami dan membuat orang mematuhi proses yang benar, Anda menghilangkan banyak masalah. Anda dapat memiliki tenggat waktu yang menuntut yang realistis. Orang bodoh mana pun dapat memunculkan tuntutan yang tidak realistis dan berisiko kehilangan orang-orang berbakat.

Saya pikir sebagian besar dari kita di tim teknis tahu siapa yang mengganggu dan siapa yang menyebalkan. Kecuali jika Anda memiliki pergantian yang luar biasa, krim akan naik ke atas dan bobot mati akan tenggelam. Devs payah selalu dalam beberapa masalah - mereka lupa untuk menguji kode mereka sebelum mereka memeriksanya jadi build break, mereka selalu punya alasan ketika mereka tidak menyelesaikan sesuatu, dan terus dan terus.

Saya pikir mereka tidak tahu apakah seseorang adalah programmer yang baik , karena mereka tidak memiliki keterampilan untuk melakukannya. Mereka memeriksa apakah seseorang adalah pengembang yang baik . Pemrograman adalah kegiatan pengembangan, tetapi pengembangan memiliki banyak hal lain. Jadi mereka memeriksa apakah Anda tepat waktu, apakah estimasi Anda baik, jika ada banyak cacat pada hal-hal yang telah Anda lakukan dalam sistem pelacakan bug, keterampilan lunak, komitmen, komunikasi, dll.

Apa yang kadang-kadang terlupakan oleh para guru dan menjadi kesal adalah bahwa pekerjaan kami tidak hanya pemrograman, kami memiliki banyak hal lain untuk dilakukan yang juga sangat penting. Meskipun manajer Anda tidak akan melihat bagaimana kode Anda terlihat (karena sama sekali tidak penting baginya), dia akan memeriksa apakah Anda seorang pemain tim, bertanggung jawab, penuh hormat dan melakukan pekerjaan berkualitas tinggi secara keseluruhan .

Terkadang saya berpikir kode itu berlebihan.

Saya pikir ada sangat sedikit orang (apalagi manajer) yang tidak memiliki pemahaman umum yang baik tentang urutan kekuasaan untuk pengembang. Semua orang berpikir mereka adalah pengembang terbaik, satu-satunya orang yang tidak tahu siapa pengembang yang buruk, adalah mereka sendiri yang pengembang buruk. Ngomong-ngomong, jika Anda berkeliling dan meminta seseorang untuk memberi peringkat pada pengembang yang bekerja dengan saya, saya yakin itu akan menjadi tugas yang mudah bagi kebanyakan orang. Jadi tidak ada keajaiban dalam menentukan siapa yang berkinerja sangat baik dan siapa yang berkinerja rata-rata atau buruk dll ... Satu-satunya gotcha di mana pengembang dan manajer tidak akan setuju adalah dengan tipe-tipe tenaga penjualan, yang keras yang terdengar seperti mereka tahu apa yang mereka bicarakan tentang tetapi benar-benar tidak. Sebagian besar manajer diperdaya oleh mereka tetapi para pengembang tidak.

Setelah itu, bias manajer Anda yang menentukan peringkat Anda. Bagi sebagian orang, pengkodean adalah tugas tingkat pemula, jadi meskipun Anda mungkin mahir dalam pengkodean, itu tidak akan membuat Anda mendapatkan promosi yang Anda cari. Sementara yang lain memandang aspek desain atau arsitektur sebagai yang paling penting. Dan yang lain percaya definisi dan pengumpulan persyaratan (mis. Analisis bisnis) adalah yang paling penting. Jika Anda ingin tahu apa yang penting bagi manajer Anda dan Anda tidak mendapatkan peringkat berkinerja tinggi, tanyakan kepada mereka apa yang harus saya lakukan untuk mendapatkan peringkat berkinerja tinggi? Anda akan belajar apa yang penting bagi mereka dalam jawaban itu dan kemudian terserah Anda untuk memastikan bahwa Anda unggul dalam bidang-bidang yang penting.