Tugas pengembang senior baru


21

Saya memiliki pengembang senior dengan delapan tahun pengalaman .NET mulai besok untuk mengerjakan aplikasi kode 11.000 baris. Di tim ada saya dan programmer lain. Kami berdua memiliki pengalaman masing-masing sekitar tiga tahun.

Ini proyek pertama saya sebagai manajer (saya juga pengembang di proyek ini) dan ini adalah pertama kalinya saya harus memperkenalkan seseorang ke basis kode yang sudah ada. Jelas saya akan membahas setiap modul, proses penyebaran, dll, dan menyerahkan mereka lokasi repositori kontrol sumber, dokumentasi (yang bukan yang terbaik), dll.

Berapa lama saya harus memberi mereka sebelum mereka siap untuk mulai menulis fitur baru dan memperbaiki bug?


1
Itu benar-benar tergantung seberapa rumitnya 11.000 baris kode. Saya akan mengharapkan seseorang dengan 8 tahun (itu berarti mereka mulai menggunakannya pada tahun 2003) untuk dapat berlari dengan kecepatan penuh dalam waktu seminggu.
Ramhound

Sebagai titik data, beberapa minggu yang lalu, kami menugaskan pengembang untuk proyek dengan 13.700 baris kode JavaScript dan menganggap dia akan produktif dalam sprint (satu minggu) tanpa benar-benar memikirkannya.
Gort the Robot

@StevenBurnap: Saya suka :) Nyalakan kakinya dengan api dan lihat apakah dia membakar rumah.
Joel Etherton

Apakah saya benar-benar satu-satunya yang berpikir garis 11k tidak banyak? Saya telah memberi satu hari, karena kebaikan hati saya.
Louis Kottmann

Bagian dari tugas yang Anda pilih juga tergantung pada seberapa terlambat proyek Anda. Untuk beberapa ide tentang cara membatasi dampak staf baru pada staf yang ada, periksa programmers.stackexchange.com/questions/164781/…
DeveloperDon

Jawaban:


38

Saya akan menetapkan beberapa bug prioritas rendah pada hari pertama, dengan cara itu tidak ada yang berteriak jika mereka tidak segera memberikan pengembang baru waktu untuk mengenal dasar kode.

Hal paling penting yang harus dilakukan adalah melakukan review kode dari semua pekerjaannya dalam beberapa minggu pertama. Anda tidak ingin mengetahui bahwa orang itu pergi ke arah yang salah atau tidak mengikuti standar perusahaan pengkodean bulan menjadi hal. Lebih baik memastikan dia tahu apa yang diharapkan dari awal, dan ulasan kode memastikan hal ini. Tentu saja saya pikir tinjauan kode baik untuk semua karyawan (Kami meninjau 100% kode kami sebelum penempatan), tetapi mereka sangat penting untuk karyawan baru dan harus dilakukan secara langsung di mana Anda dapat menjawab pertanyaan dan merujuknya ke dokumentasi yang mungkin tidak mereka miliki. belum terlihat jika perlu.

Yang tidak Anda inginkan adalah seorang pria baru datang dan menggunakan gaya yang berbeda dari Anda semua. Orang sering mencoba untuk tetap menggunakan gaya kode dari pekerjaan mereka sebelumnya bahkan ketika itu bertentangan dengan gaya kode yang digunakan di tempat baru yang dapat membuat kebingungan dan gangguan di pihak pengembang lainnya.

Satu hal yang saya perhatikan bahkan dengan pengembang berpengalaman adalah bahwa beberapa dari mereka tidak sebagus dalam wawancara, review kode akan membantu Anda menemukan ini dengan cepat, sehingga Anda dapat memperbaikinya. Ini juga akan mendorong mereka untuk benar-benar menyelesaikan sesuatu, saya telah melihat karyawan baru yang tidak ditinjau kode menyeret keluar proyek tanpa menunjukkan apa yang mereka lakukan kepada siapa pun dan kemudian meninggalkan seminggu sebelum tenggat waktu yang mereka tahu tidak akan tercapai karena mereka berada di atas kepala mereka dan belum benar-benar menyelesaikan bagian dari proyek. Lebih baik periksa lebih awal dan sering dengan orang baru sampai Anda benar-benar yakin mereka sedang berolahraga.

Juga, itu normal bagi orang baru itu akan terkejut pada keadaan proyek warisan Anda. Itu tidak dirancang dengan cara yang menurutnya seharusnya. Harapkan ini, dengarkan dia dan jangan secara otomatis mengabaikan semua yang dia katakan. Secara khusus, orang ini tampaknya memiliki lebih banyak pengalaman daripada Anda atau pengembang lain, ia mungkin melihat hal-hal yang tidak Anda pertimbangkan. Namun, sebagai manajer, Anda harus menyeimbangkan perubahan yang diajukan terhadap beban kerja dan tenggat waktu saat ini. Anda semua mungkin ingin menginvestasikan waktu untuk mempelajari cara memperbaiki kode yang ada dan menginvestasikan beberapa jam dalam perkiraan waktu Anda untuk melakukan itu terutama jika orang baru tersebut memiliki masalah yang valid. Anda mungkin tidak dapat mendukung penulisan ulang total (banyak orang yang datang dengan pemikiran baru kita harus mulai dari awal dan melakukannya dengan lebih baik),

Jika Anda memiliki waktu di mana dia tidak diharapkan untuk berkontribusi penuh (dan sepenuhnya bertanggung jawab atas waktunya oleh klien), itu mungkin juga saat dia dapat memulai beberapa hal refactoring yang ingin Anda lakukan tetapi tidak ada. ' Aku tidak punya waktu untuk melakukannya. Terkadang, adalah hal yang baik untuk menggunakan periode pelatihan orang baru untuk mengatasi beberapa hal yang tidak ada dalam rencana proyek. Mereka dapat mempelajari basis kode dan jika apa yang ingin mereka lakukan tidak berhasil, Anda belum memengaruhi jadwal yang ada karena Anda belum memasukkan mereka ke dalam jadwal yang ada. Dan jika itu berhasil, Anda mungkin memiliki kemenangan besar yang membuat pemeliharaan di masa depan lebih mudah atau keamanan lebih baik atau apa pun masalahnya.


Itu jawaban yang bagus, terutama bagian tentang ulasan kode dan pendapat devs tentang keadaan proyek saat ini. Untungnya ini bukan proyek warisan, itu sebenarnya sangat baru, dan bergerak dengan sangat cepat.
MrBliz

1
+1 - Banyak poin bagus, tetapi saya ingin menegaskan kembali bahwa sangat penting untuk meninjau semua pekerjaan mereka sehingga Anda dapat mengevaluasi tingkat keterampilan mereka dan memastikan mereka masuk ke halaman yang sama dengan tim. Sayangnya, ini membutuhkan waktu lebih lama daripada beberapa minggu pertama. +1 lain untuk tidak sebagus wawancara. Apa yang terjadi pada banyak orang antara wawancara dan hari mereka muncul adalah misteri bagi saya. Apakah lobotomi benar-benar biasa? Itulah satu-satunya penjelasan yang bisa saya berikan.
Dunk

Ya, tinjau pekerjaan mereka untuk memastikan mereka tidak mengalihkan dari standar yang ditetapkan. Tetapi jika mereka memiliki pengalaman delapan tahun dan Anda memiliki tiga tahun, mereka mungkin tahu lebih banyak daripada Anda . Pastikan Anda tidak memaksa mereka untuk melakukan sesuatu dengan cara Anda.
DJClayworth

2
@DJClayworth, sementara saya setuju bahwa orang baru itu cenderung memiliki lebih banyak pengetahuan dan OP harus memperhatikan apa yang ingin dia lakukan secara berbeda, ada kalanya pengetahuan Anda tentang sistem dan persyaratannya dapat mengalahkan pengetahuan umum yang lebih baik dan Anda mungkin perlu mengarahkannya untuk mengambil jalur yang kurang optimal karena alasan yang didasarkan pada sejarah sistem dan persyaratan. Kadang-kadang Anda perlu bersikeras bahwa mereka melakukan sesuatu dengan cara Anda karena alasan yang mungkin belum mereka sadari. Tentu saja ketika Anda melakukannya, Anda perlu menjelaskan mengapa, bukan hanya kami selalu melakukannya seperti itu.
HLGEM

@Dunk: dalam pengalaman saya, bahkan orang terburuk di dunia dapat berperilaku selama beberapa jam selama wawancara, ketika mereka sangat membutuhkan pekerjaan. Itu sebabnya kontrak-untuk-merekrut, magang, dan sampel kode sangat penting dengan karyawan baru.
Jordan

18

Mulai segera pada tugas-tugas kecil - hal-hal yang tidak memerlukan gambaran lebih besar.

Saat mereka menjadi lebih percaya diri dan terbiasa dengan basis kode, pasangkan mereka ke tugas yang lebih besar dan lebih besar. Seberapa cepat itu terjadi sebagian besar tergantung pada mereka.


Ini adalah apa yang saya pikirkan.
MrBliz

+1, ini adalah no brainer, terutama karena basis kode kecil.
Louis Kottmann

8

Saya selalu ingin mendapatkan tugas yang diberikan kepada saya langsung, dengan pengertian bahwa akan butuh waktu lebih lama untuk menggali kode, dan banyak pertanyaan akan ditanyakan selama beberapa hari / minggu pertama.

Saya menemukan bahwa saya tidak dapat sepenuhnya membungkam sebuah proyek sampai saya benar-benar harus masuk dan memperbaiki atau mengubah sesuatu.

Juga ... Tidak peduli seberapa baik Anda pikir Anda telah menjelaskan bagaimana sebuah proyek bekerja, selalu ada 'oh ya saya lupa memberi tahu Anda', 'kami mengalami masalah ini, jadi kami melakukan ini' saat-saat yang tidak hilang sampai Anda benar-benar mulai bekerja.


+1 Semakin cepat karyawan baru dapat mulai menyaring proyek, semakin cepat karyawan baru akan merasa nyaman (bersedia mengambil kepemilikan / akuntabilitas) dari apa yang mereka lakukan.
Chad Harrison

3

Berapa lama?

Berapa lama tali?

Saat dia nyaman: ketika dia memperbaiki bug pertamanya -> dia siap .


3

Dalam komunitas open source, setiap orang yang ingin bergabung dengan proyek terlebih dahulu berurusan dengan beberapa masalah kecil. Jika dia dapat menangani masalah dengan sangat baik, tugas yang lebih penting akan diberikan kepadanya. Dengan cara ini, mereka akan menjadi pengembang inti proyek.

Pengembang senior ini memiliki delapan tahun pengalaman .NET, sehingga Anda dapat memberinya beberapa bug sederhana untuk diperbaiki. Jika mudah baginya untuk berurusan dengan mereka, Anda bisa menetapkan dia masalah yang kompleks untuk membantu dia akrab dengan seluruh aplikasi. Setelah itu, dia bisa mulai menulis fitur baru dan menganalisis masalah aneh. Lakukan saja, tidak ada waktu setup!


2

8 tahun pengalaman. Saya hanya akan melemparkannya. Dia harus bisa berenang. Seperti yang orang lain catat, mulailah dengan tugas-tugas kecil yang mudah. Ini akan memungkinkan dia untuk meraba-raba melalui kode check-in / proses check-out, dan setiap proses pembangunan lain yang Anda miliki.

Saya telah berganti pekerjaan berkali-kali dan saya telah menjadi kontributor dalam semuanya dalam minggu pertama. Terberat membawa saya satu minggu untuk mendapatkan kode untuk kompilasi (100k + baris kode setidaknya). Pembangunan penuh memakan waktu 8 jam untuk proyek itu.

Saya bekerja kira-kira 80 jam pada minggu pertama (proyek sangat serius).


Menarik bahwa semua orang dengan asumsi itu seorang pria ... :)
MrBliz

1. Saya akan mengatakan dalam bahasa Inggris kata ganti default adalah maskulin, mengetik "dia" sepanjang waktu akan tepat namun usaha lebih dari kebanyakan orang ingin menempatkan sebagainya. 2. Berapa persentase programmer adalah wanita? Dalam hal ini default ke maskulin memiliki statistik pada sisinya ... Jadi aku membayangkan yang lebih hanya menggunakan cara sederhana standar untuk merujuk kepada individu acak, tidak secara khusus dengan asumsi mereka adalah laki-laki atau perempuan.
Thymine

Saya seorang pria dan semua orang pasti juga :-). Hanya cara saya menulis, saya tidak cukup disiplin untuk menulis dia sepanjang waktu.
Bill Leeper

1

Untuk sebuah aplikasi yang kecil, dan pengembang yang berpengalaman, saya akan berpikir sehari sudah cukup untuk bug dasar. bug terlibat atau fitur kecil lebih dekat dengan seminggu (begitu mereka lebih jelas tentang masalah domain dan arsitektur).


2
Saya pikir standar saya mungkin terlalu tinggi, tetapi Anda ... 1 hari ... dan 1 minggu untuk benar-benar produktif? IME, itu tidak terlalu realistis.
Dunk

@Dunk: untuk ditugaskan tugas dan dapat mendekati mereka tanpa benar-benar hilang? Saya tidak mengatakan mereka akan dengan kecepatan penuh, tetapi pada saat itu mereka harus dapat memburu basis kode, tahu siapa yang harus diminta untuk belajar lebih banyak, dll.
Telastyn

ya serius. 11k LoC tidak terlalu besar. Dapatkan dia mengaturnya sehingga itu membangun dan berjalan di debugger dan kemudian menunjukkan kepadanya cara kerjanya. Itu sudah cukup.
gbjbaanb

1

Jawabannya adalah, tergantung. Jika Anda ingin dia untuk memperbaiki off dengan satu kesalahan pada sesuatu atau mengubah warna elemen GUI, maka sekitar 5 menit (di sini di mana kita menjaga kode kita), jika Anda ingin desain ulang total seluruh arsitektur aplikasi yang akan membutuhkan sedikit lebih lama.

Ini benar-benar tergantung pada tugas yang Anda harapkan darinya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.