Bisakah Anda menjadi manajer dan sekaligus programmer? [Tutup]

Mengelola programmer lain sementara Anda sendiri adalah bagian dari tenaga kerja pemrograman.

Ini skema yang sangat umum, setidaknya di perusahaan tempat saya bekerja.

Bisakah Anda menjadi programmer yang baik atau manajer yang baik jika Anda melakukan keduanya sekaligus?

Saya mempertanyakan efektivitas seorang individu yang harus berada dalam dua peran yang sangat berbeda, yang membutuhkan keterampilan, lingkungan, konsentrasi, organisasi, dll yang sangat berbeda.

UPDATE : pertanyaan saya termasuk manajemen perusahaan (yang merupakan kasus saya), bukan manajemen tim khusus. Tapi tentu saja saya tertarik pada keduanya.

Itu tergantung pada jumlah dan jenis pemrograman yang harus Anda lakukan dan jumlah dan jenis tugas manajerial yang harus Anda lakukan.

Menjadi seorang manajer berarti banyak gangguan, perubahan taktik dan hal-hal seperti rapat, dll.

Jika pemrograman Anda "terbatas" untuk pekerjaan kecil yang tidak mendesak maka Anda dapat menyesuaikannya dengan tugas-tugas manajerial Anda. Jika Anda perlu menghabiskan banyak waktu "kualitas" untuk tugas pemrograman maka Anda tidak akan mendapatkan waktu karena tanggung jawab manajerial Anda.

Jika tim Anda besar dan / atau kompleks, maka Anda perlu menghabiskan lebih banyak waktu untuk mengelola daripada jika tim kecil yang didedikasikan untuk satu satu atau dua produk / proyek. Anda akan menemukan bahwa Anda tidak punya waktu untuk melakukan pemrograman yang berarti - bahkan pada tugas-tugas kecil.

Dalam pekerjaan sebelumnya saya memiliki peran ini dan itu berhasil bagi saya karena saya menjaga tugas pemrograman saya kecil. Ini benar-benar bekerja untuk keuntungan kita.

Pertama, saya bisa menilai semua permintaan yang masuk dan jika kecil, tambahkan ke antrian saya (yang selalu pendek) atau kembali ke klien (dalam hal ini manajer lain) dengan skala waktu yang lebih akurat untuk saat pekerjaan akan dilakukan.

Kedua itu berarti bahwa pengembang di tim tidak mendapatkan terus-menerus melakukan pekerjaan mereka saat ini untuk memperbaiki bug kecil atau melakukan peningkatan kecil.

Ketiga, klien senang karena masalah mendesak mereka diperbaiki dengan cukup cepat.

Itu membuat saya tetap berhubungan dengan basis kode sehingga saya bisa melakukan percakapan yang bermakna dengan tim saya tentang masalah dan dengan manajer dan klien saya tentang rentang waktu tanpa harus melibatkan tim sepanjang waktu.

Saya adalah bagian dari tim pengembang di mana satu programmer juga manajer kami. Hal ini menyebabkan kehancuran total apa pun yang menyerupai produktivitas. Singkatnya, semua keputusan dibuat oleh pria itu + dia adalah manajer mikro yang lengkap. Setiap ide dan saran yang tidak dia setujui akan ditembaki atau diabaikan. Ini akhirnya membunuh semua kreativitas dan motivasi.

Jadi, saya pikir itu adalah ide yang buruk memiliki siapa pun di tim dev di posisi "lebih tinggi". Dalam kasus saya, orang itu adalah manajer perintah-dan-kontrol, tetapi saya bahkan seorang manajer hebat akan (secara tidak sengaja) mempengaruhi pengembang lain yang akhirnya mengarah pada kinerja yang lebih rendah. Setidaknya tim melapor kepadanya.

Ya
saya telah melihat beberapa manajer yang merupakan Programmer dan Manajer pada saat yang sama, Percayalah saya bekerja di bawah orang-orang ini luar biasa.
Menjadi manajer dan programmer tidak hanya memungkinkan manajer untuk memimpin dari depan tetapi juga memotivasi bawahan untuk memberikan yang terbaik.
Sebagian besar Karyawan mengeluh tentang manajer mereka bahwa manajer tidak ada nilainya tetapi manajer yang tidak hanya Mengelola tetapi juga menulis kode selalu memberikan hasil terbaik.
Kedua manajer yang saya sebutkan, pemrograman adalah hasrat mereka yang tidak hanya membantu orang lain tetapi juga menghasilkan satu aplikasi yang hampir bebas bug.

Saya telah menjadi manajer proyek pemrograman selama bertahun-tahun, dengan berbagai perusahaan, proyek, dan tim.

Manajemen dan pemrograman proyek adalah jenis pekerjaan / peran yang sangat berbeda, sehingga saya berpendapat bahwa Anda tidak dapat melakukan keduanya pada saat yang sama pada level "luar biasa". Ini adalah kompromi - master of none, jack of all trades, semacam itu.

Bagi saya rasa sakit terbesar adalah perubahan konteks antara mode manajer dan programmer. Mereka tampaknya melibatkan bagian otak yang berbeda (atau sesuatu). Suatu hari pemrograman, suatu hari mengelola saya bisa melakukannya dengan baik, tetapi beralih di antara peran-peran itu terus-menerus sulit.

Saya telah melihat kedua skenario. Manajer pengembang melakukan {beberapa persen dari waktu mereka} melakukan pengkodean, dan manajer pengembang, tidak melakukan pengkodean sama sekali.

Masalahnya adalah, semakin senior Anda dapatkan, semakin besar kemungkinan Anda ingin dibayar lebih, dan satu-satunya cara untuk mendapatkannya di banyak tempat adalah beralih ke manajemen. (tidak semua tentu saja, tetapi banyak tempat). Jadi ini dapat menyebabkan orang yang benar-benar tidak siap untuk menjadi manajer terjebak dalam situasi itu.

(Tentu saja, ada perusahaan di mana Anda dapat naik melalui Dev, Dev memimpin - berbeda dari manajer Dev tentu saja - ke posisi seperti Arsitek dll)

Kemungkinannya, sebagai seorang teknisi, Anda mungkin tidak berguna di manajemen orang, plus yang membawa Anda lebih jauh dari kode. Jadi Anda menjadi manajer yang buruk, dan melakukan lebih sedikit hal yang Anda sukai, dan mungkin masuk ke dalam pengembangan!

Bagi saya, untuk menjadi seorang manajer Anda harus benar-benar lepas tangan dari pengkodean, tetapi benar-benar menjaga diri Anda tetap mutakhir dengan teknologi sehingga Anda setidaknya masih dapat berbicara tentang masalah-masalah secara koheren.

Ketika itu terjadi, saya mulai lepas untuk alasan yang tepat ini. Saya tidak tertarik pada manajemen orang, dan saya pikir saya tidak akan terlalu bagus dalam hal itu, ditambah lagi saya tidak akan mendapatkan kode sebanyak itu.

Itu bisa dilakukan, tetapi penuh dengan jebakan. Ukuran kelompok dan tingkat interupsi memainkan peran besar, tetapi risiko yang paling signifikan adalah memiliki manajer juga menjadi pemimpin teknis. Pendapat yang terlalu berat ketika tidak ada cukup waktu / upaya untuk membenarkan pendapat dapat menyebabkan beberapa keputusan buruk. Dan, perdebatan tentang arah bukanlah bidang permainan yang sangat datar antara seorang manajer dan anggota tim lainnya.

Bagi mereka yang mempertimbangkan jalan ini, beberapa saran:

• Kerjakan jalan keluar dari peran arsitektur dan kenali prospek dalam grup Anda.

• Jangan bekerja pada item jalur kritis. Perbaiki bug, kerjakan prototipe atau item lain yang dapat dengan cepat dibuang ketika bos Anda menemukan lebih banyak 'hal penting' untuk mengalihkan perhatian Anda.

• Tingkatkan tingkat perhatian Anda dan fokuskan pada efisiensi keseluruhan, membela dan mempromosikan tim, proses, moral, dan aspek lain yang diperlukan untuk memiliki tim yang sukses. Sasaran Anda mungkin lebih dari sekadar proyek yang berhasil (terlepas dari apa yang dikatakan bos Anda, PM, atau lainnya).

• Bantu tim Anda tumbuh: menjadi lebih mandiri, berorganisasi, mahir teknis, tingkat kesadaran yang lebih tinggi.

• Dalam banyak hal, Anda adalah jembatan antara tim dan dunia luar. Sebagian besar fokus Anda harus berada di luar tim.

Untuk menjawab pertanyaan, ya, itu bisa dilakukan. Tidak, itu tidak mudah dan terlalu banyak manajer baru dari sisi teknis rumah, yang mungkin merupakan pemimpin besar, tidak dapat beralih ke pekerjaan manajer yang sukses.

Manajer yang baik bisa, ya. Selama Anda tetap asertif dan konsisten, biasanya tidak ada masalah.

Jika karyawan disuruh mengemukakan masalah dengan rekan satu tim dengan manajer mereka .. dan manajer juga rekan satu tim, itu bisa menjadi lengket. Sangat penting untuk melihat semua umpan balik secara objektif dan menyadari bahwa Anda mungkin salah dari waktu ke waktu. Anda juga harus memberikan semacam cara anonim untuk umpan balik.

Sangat umum (seperti yang Anda katakan) untuk melihat ini di perusahaan start up.

Saya pikir tidak.

Kedua pekerjaan itu membutuhkan banyak fokus, energi, dan dedikasi. Sangat sulit untuk melakukan keduanya sekaligus. Ketika saya harus mengambil beberapa tanggung jawab pimpinan tim, jumlah waktu yang saya habiskan dalam pemrograman (dan akibatnya jumlah pemrograman terkait pekerjaan yang saya lakukan) berkurang.

Saya tahu ada kolega lain yang mengambil peran manajerial dari peran pemimpin tim dan sepenuhnya berhenti mengkodekan dalam waktu sebulan (meskipun ia mencoba melakukan keduanya).

Saya juga kenal seorang arsitek yang diminta menjadi manajer. Dia juga berhenti coding dalam waktu satu bulan setelah mengambil tanggung jawab manajerial. Arsitek yang sama setelah 8 bulan harus kembali ke pengkodean karena masalah lapangan kritis. Dia berkontribusi secara signifikan dalam memperbaiki bug, tetapi dalam sebulan, mereka harus menemukan manajer pengganti untuk mengambil tanggung jawab manajerialnya.

Dalam pengalaman saya yang terbatas, saya belum menemukan orang yang mengelola programmer dan kode lain seperti programmer penuh.

Menurut pendapat saya meskipun mungkin dalam kebanyakan skenario itu bukan pengaturan yang baik. Ada banyak artikel tentang bagaimana orang yang mahir sebagai pengembang diperhatikan dan diangkat ke peran manajemen tim meskipun ini bukan keahlian khusus mereka atau bahkan posisi yang diinginkan. Mereka berjuang untuk tetap fokus pada "manajemen" karena mereka melihat "pekerjaan" sebagai menyelesaikan pemrograman, tidak membuat laporan dan pergi ke pertemuan.

Spolsky menulis dalam artikelnya tentang Lapisan Abstraksi Pengembang sebagai berikut:

"Dengan perusahaan perangkat lunak, prioritas pertama manajemen perlu menciptakan abstraksi untuk para programmer."

Dalam artikel itu, (menurut pendapat saya, tetapi saya pikir beralasan), peran manajer bukan tentang masuk ke dalam kode atau pengembangan perangkat lunak, tetapi menciptakan lingkungan di mana mereka yang memproduksinya dapat fokus sepenuhnya padanya.

Mantan bos saya mencoba. Terlalu banyak interupsi dari peran manajemennya.

Dia masih salah satu pengembang terbaik yang saya tahu.

Tentu saja bisa, tetapi itu tidak berarti itu mudah. Dibutuhkan orang tertentu untuk menjadi pengembang yang baik, dibutuhkan orang tertentu untuk menjadi manajer yang baik dan orang tertentu untuk menjadi keduanya. Jika Anda dapat menemukan orang itu (atau orang itu), ada keuntungan pasti. Manajer level pertama atau kedua dari programmer perlu benar-benar memahami apa yang orang-orang lakukan dan temui setiap hari. Sulit dilakukan jika Anda bukan pengembang dan sulit untuk tetap berhubungan / mutakhir tanpa terus berkembang.

Manajer terbaik yang pernah saya miliki (saya sudah berada di biz ~ 25 tahun), adalah pengembang aktif, manajer saya dan setengah pemilik perusahaan (sekitar 40 emp). Dia istimewa tetapi dia jelas berhasil dalam pertanyaan ini.

PASTI TIDAK !!

Anda dapat mencoba, tetapi pada akhirnya Anda akan mengelola lebih dari segalanya. Masalahnya adalah Anda tidak dapat membuat kode ketika orang memanggil Anda setiap 5 menit atau mencoba membuat pertemuan "status" setiap jam. Konyol ... Saya melakukannya sekarang, itulah sebabnya saya menemukan thread ini.

Meskipun seorang manajer di sebuah perusahaan teknologi HARUS .. tidak ... HARUS tahu cara kode. Anda tidak akan dapat memperkirakan atau memahami masalah klien. Pengkodean dan pengelolaan adalah dua tipe orang. Satu sisi geek dan canggung dengan orang-orang (hadapi itu, geek Anda tahu apa yang saya bicarakan), dan yang lain baik dengan orang-orang. Anda harus memilih sisi. Anda tidak akan mendapatkan tempat dengan pengkodean jika Anda melakukan keduanya. Jika Anda suka coding dan bisa melakukannya 24/7 jika istri Anda tidak menghalangi Anda, TINGGAL JAUH DARI PENGELOLAAN. Bahkan ambil potongan gaji jika Anda harus. Saya akan melakukan ini, tetapi saya tidak berpikir bos akan menyukai ini karena saya membuat hidup mereka lebih mudah melakukan bagian manajemen. Saya harus kembali ke lepas jika mereka tidak setuju karena kebahagiaan dan melakukan apa yang Anda sukai jauh lebih penting daripada uang dan ilusi yang dibelinya.

Salam hangat dengan usaha Anda dan tetap posting ini datang. Kalian luar biasa.

Baca bagian "Kurangnya Jalur Karir Pemrograman-Sentris" di situs ini. Cukup bagus dan sangat relevan: http://c2.com/cgi/wiki?ProgrammingIsNotFun

Ada kemungkinan bahwa seseorang memiliki manajer yang baik dan keterampilan pemrograman yang baik, meskipun pepatah "jack of all adalah master of none" muncul di pikiran ...

Namun, menggabungkan kedua fungsi pada saat yang sama bagi saya cenderung melakukan kedua pekerjaan hanya setengah. Itu tergantung pada jumlah pengelolaan yang harus dilakukan, tetapi mau tidak mau Anda menyulap dua tugas yang sepenuhnya berbeda, dan pergeseran fokus tuntutan ini cukup besar. Saya perhatikan sendiri bahwa saya melakukan sedikit kurang di bagian coding ketika saya memiliki beberapa tugas mengelola juga (dalam kasus saya, mengelola kursus dan menulis laporan).

Perangkap lain adalah Anda mengelola grup, tetapi Anda juga merupakan pihak yang terlibat langsung. Terkadang itu terbayar, terkadang itu bisa menyebabkan masalah besar. Jika programmer lain tidak setuju dengan pekerjaan Anda, fakta bahwa Anda adalah manajer dapat menjaga mereka agar tidak sepenuhnya terbuka.

Kemudian lagi, ketika Anda mengkodekan pada proyek yang sama dengan yang Anda kelola, Anda tetap merasa sedikit lebih dengan kode itu sendiri, jadi dalam hal itu bit pemrograman sebenarnya dapat membantu bit pengelolaan. Semuanya tergantung pada apa yang harus Anda kelola, berapa banyak waktu yang dibutuhkan, dan berapa banyak yang tetap terkait dengan kode yang sedang Anda kerjakan.

Jadi saya kira tidak ada jawaban yang jelas, tetapi saya cenderung menghindari terlalu banyak bergaul. 2 sen saya

baik, saya pernah membaca bahwa manajer proyek perangkat lunak pasti harus coders sendiri.

Saya pikir seorang manajer adalah seorang manajer karena satu alasan - untuk mengelola. Saya akan menganggap ini sebagai aturan praktis ... beberapa bisa menjadi pedang bermata dua.

Saya tahu satu kasus di mana ia bekerja. Lelaki itu semacam pekerja keras, jadi dia bekerja penuh waktu sebagai manajer, dan hampir penuh waktu sebagai programmer.

Mengingat jam kerja normal, saya tidak berpikir bahwa peran ganda seperti itu adalah ide yang bagus. Seorang programmer pengelola (atau manajer pemrograman) selalu tergoda untuk melakukan banyak hal pemrograman sendiri, alih-alih membuat programmernya melakukannya. Selalu ada alasan ini "butuh waktu lebih lama untuk menjelaskan daripada melakukannya" tetapi dalam jangka panjang, 50% pekerjaan programmer yang dia lakukan hilang pada bagian manajemen, sehingga programmer lain kurang efisien.