Membantu programmer junior melewati kekurangan mereka? [Tutup]

Apa keluhan Anda tentang pengembang junior yang bergabung dengan tim Anda atau dengan siapa Anda harus bekerja? Jelas mereka tidak berpengalaman sehingga Anda tidak dapat mengharapkan mereka mengetahui segalanya, tetapi keterampilan apa yang sering kali hilang secara tidak dapat dijelaskan - dan bagaimana, secara khusus, kami dapat membantu mereka membangun keterampilan yang hilang ini?

Maksud saya bukan keterampilan antar-pribadi seperti 'mendengarkan saran,' Maksud saya masalah teknis seperti (jika berlaku):

• "Anda belum pernah melakukan SQL?"

• "Kau belum pernah menulis unit test?"

• "Anda tidak tahu bagaimana cara menggunakan baris perintah Unix?"

Hal-hal yang Anda lakukan harapkan - Saya ingin mendengar pengamatan dan teknik untuk mengajar programmer baru untuk melewati kekurangan tertentu tersebut.

Tidak tahu apa itu kontrol versi, atau bagaimana menggunakannya dengan benar .

Salah satu pengembang junior yang telah berada di perusahaan saya selama beberapa bulan baru-baru ini harus diajarkan dasar-dasar Subversion. Itu benar-benar membuat saya merasa ngeri ... dia sudah memeriksa kode untuk menjalankan proyek sepanjang waktu ... dan tidak tahu apa yang dia lakukan ...?

Tidak banyak bertanya

Saya tahu mereka junior, saya berharap mereka akan membuat kesalahan dan tidak tahu apa-apa. Begitu banyak royal f ** k up bisa dihindari dengan hanya mengajukan pertanyaan alih-alih mengasumsikan sesuatu. Jujur, saya tidak bisa direcoki cukup.

Saya punya TONNES pertanyaan ketika saya mulai - meminta mereka menyelamatkan pantat saya pada beberapa kesempatan. Sial, saya masih punya banyak pertanyaan ... Saya hanya ingin berpikir itu pertanyaan yang lebih baik sekarang.

Salin tempel dan coba-coba alih-alih berusaha memahami dasar-dasarnya

Banyak pengembang junior akan menyalin kode yang terlihat dekat, kemudian hampir secara acak mencoba berbagai permutasi modifikasi oleh brute force sampai mereka menemukan yang berfungsi. Jika Anda tidak tahu mengapa itu bekerja, kemungkinan Anda memperkenalkan bug dalam kasus batas yang harus dipecahkan oleh seseorang yang memang mengerti.

Menyimpan "draf pertama" kode mereka

Ketika pengembang yang berpengalaman menulis fungsi baru dari kompleksitas tertentu, mereka memulai dengan tulisan rintisan yang tidak melakukan apa pun kecuali mengkompilasi, kemudian menulis ulang untuk menambahkan komentar kode pseudo tingkat tinggi untuk keseluruhan algoritma, kemudian menulis ulang komentar-komentar itu satu per satu dengan kode aktual, menambah dan menghapus kode dummy sesuai kebutuhan untuk pengujian, kemudian menulis ulang untuk menghapus redundansi yang muncul selama implementasi, dan seterusnya dalam serangkaian peningkatan berurutan dan bertahap.

Pengembang junior memiliki kecenderungan untuk menuliskannya dalam satu potongan besar, kemudian melakukan debugging besar-besaran. Mereka tidak suka menghapus satu baris kode begitu itu diketikkan ke editor, dan sangat senang mereka akhirnya berhasil sehingga mereka enggan menulis ulang untuk perbaikan yang tidak fungsional, tetapi mereka adalah orang-orang yang perlu melakukan jadi yang paling.

Percayalah Anda yang pertama kali menghadapi suatu situasi.

Setiap masalah pemrograman yang Anda hadapi telah dihadapi oleh orang lain, dalam bentuk umum. Ada banyak hal yang dapat dipelajari dari programmer yang berpengalaman. Saya cukup tua untuk mengingat pemrograman sebelum Google, dan itu mengisap . Lebih buruk lagi ketika kami memiliki mesin pencari, tetapi belum ada informasi yang bagus di web. Pemrograman sekarang jauh lebih produktif karena Anda memiliki akses ke pengetahuan global dalam hitungan detik. Orang yang tidak menggunakannya mengabaikannya.

Edit :

Untuk lebih jelasnya, saya tidak menganjurkan pemrograman copy / paste. Saya yakin, bagaimanapun, bahwa Anda perlu meninjau kembali pengetahuan yang ada sebelum Anda dapat membuat keputusan yang baik sendiri.

Berpikir bahwa mereka tahu segalanya.

Saya punya jr. intern yang mencoba menyelesaikan semuanya dengan javascript. Mencoba menjelaskan beberapa konsep, tetapi dia selalu berpikir dia bisa melakukannya dengan lebih baik. Sekarang dia berhenti dan sedang mengerjakan ulang program besar yang dia buat untuk hasil cetak menggunakan HTML alih-alih teknologi siap cetak seperti PDF. Belum lagi setumpuk masalah besar lainnya.

Pelajarannya adalah meminta senior untuk panduan menyeluruh utama di awal proyek, jangan pergi arsitek tanpa bantuan. Anda dapat menulis kode dan detailnya sendiri, tetapi pastikan Anda setidaknya menggunakan teknologi yang tepat.

Saya jarang kesal ketika yunior tidak tahu dasar-dasarnya, mereka tidak diajarkan keterampilan industri seperti SCC di Universitas. Ini tugas para senior dev untuk mengajar mereka. Saya hanya terganggu oleh pertengkaran kepribadian. Tapi aku sangat kesal oleh para devs senior yang tidak tahu dasar-dasarnya.

Tidak ingin memajukan pengetahuan mereka - alih-alih menempuh jalan dengan resistensi yang rendah.

Suatu hari magang bersama dengan desainer grafis (yang sangat ahli dalam pemrograman) meminta bantuan karena mereka mengalami kesulitan dalam mengimplementasikan sesuatu di jQuery - penutupan bisa menyakitkan jika Anda tidak bisa melihatnya datang.

Saya duduk bersama magang dan menjelaskan apa yang salah dan mengapa. Kami memperbaiki bug, kemudian saya menunjukkan beberapa perbaikan tambahan yang dapat dibuat ("karena saya di sini") dan kami akhirnya menulis ulang fungsi bersalah dalam 10 baris, bukan 20 dan tanpa bug. Setelah menjawab pertanyaan, puas bahwa semuanya baik-baik saja di dunia, saya pergi.

Keesokan harinya, pekerja magang datang dengan pertanyaan yang mengungkapkan dia "um, ingin membuat beberapa perubahan dan menulis ulang fungsi dengan cara saya karena saya merasa sulit untuk dipahami" (sebagian besar membatalkan perbaikan saya).

Dia bisa baik mencoba lebih keras bukan (mengajukan pertanyaan tambahan, membaca tentang konsep-konsep yang saya sebutkan) - kode begitu pendek tidak pernah bisa yang sulit untuk memahami - atau mengambil jalan keluar yang mudah. Saya sedih setiap kali saya melihat seseorang melakukan yang terakhir.

Tidak mengerti OOP. Sayangnya ini jauh lebih umum daripada yang kita sadari.

Mengetahui cara membuat kelas, kelas abstrak, antarmuka, atau bahkan mengetahui polimorfisme adalah satu hal; Memahami cara menggunakannya dengan benar untuk kepentingan program Anda adalah hal lain .

Jika Anda ingin menghindari yang ini, saya menemukan pertanyaan-pertanyaan ini dan jawaban untuk mereka yang mencerahkan:

• Kode Bau: Pelanggaran Warisan - Bahaya warisan
• Dari mana konsep "komposisi kesukaan daripada warisan" ini berasal? - Bahaya mantra tentang menghindari warisan

Tidak tahu apa yang tidak Anda ketahui, dan dalam ketidaktahuan berpikir Anda tahu segalanya.

(Dan sepupu dekatnya, tidak ingin bertanya.)

Sebagian ini adalah masalah organisasional - induksi masuk yang sesuai akan sangat membantu mencegah beberapa hal ini menjadi masalah. Tetapi sangat sedikit perusahaan memiliki waktu atau orang yang tersedia untuk induksi masuk - sesuatu yang harus berlangsung dari beberapa hari hingga beberapa minggu dan membuat pengembang berhenti bekerja. Jadi kita harus memadamkan api sebagai gantinya.

Saya kagum pada berapa banyak programmer junior yang relatif baru keluar dari program CS yang lemah dengan algoritma. Pilihan algoritme yang buruk mungkin tidak terlalu cocok dengan aplikasi bisnis, tetapi ketika memproses miliaran permintaan layanan web sehari, itu benar-benar penting.

Inilah pertanyaan wawancara yang saya gunakan yang hampir semua programmer Junior lewatkan yang menyoroti masalah ini:

Tulis kode yang menghitung angka Fibonacci Nth .

Mereka hampir selalu pergi untuk menulis yang paling jelas tapi tidak efisien

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Ketika diminta untuk mengomentari kompleksitas algoritmik, saya biasanya mendapatkan "ini lebih buruk daripada O (N) ... uhm ... O (N logN)". Ini sebenarnya (jauh) lebih buruk dari itu ...

Melakukan lekukan kode mundur!

Tentu saja itu tidak terlalu "khas". Saya tidak pernah percaya itu mungkin, tetapi pengembang seperti apa yang akan menulis

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

dia akan menulis seperti (Tuhan, sepertinya masih mustahil bagiku!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Membuat frustrasi bukan?