Aiutare i programmatori junior a superare le loro carenze? [chiuso]

Quali sono le tue lamentele comuni sugli sviluppatori junior che si uniscono al tuo team o con i quali devi lavorare? Ovviamente sono inesperti, quindi non puoi aspettarti che sappiano tutto, ma quali abilità spesso sono inspiegabilmente mancanti - e come, in particolare, possiamo aiutarli a sviluppare queste abilità mancanti?

Non intendo competenze interpersonali come "ascoltare consigli", intendo questioni tecniche come (se applicabile):

• 'non hai mai fatto SQL?'

• "non hai mai scritto un test unitario?"

• 'non sai come usare una riga di comando Unix?'

Le cose che non aspetta - mi piacerebbe sentire le vostre osservazioni e le tecniche per insegnare nuovi programmatori per superare queste carenze specifiche.

Non sapere cos'è il controllo versione o come utilizzarlo correttamente .

Uno degli sviluppatori junior che è stato nella mia azienda da diversi mesi di recente ha dovuto imparare le basi di Subversion. Mi ha davvero fatto rabbrividire ... ha controllato il codice per vivere progetti per tutto il tempo ... e non aveva idea di cosa stesse facendo ...?

Non fare abbastanza domande

So che sono giovani, mi aspetto che commettano errori e non conoscano le cose. Così tanti fottuti reali avrebbero potuto essere evitati semplicemente facendo una domanda invece di assumere qualcosa. Onestamente, non posso essere infastidito abbastanza.

Avevo tonnellate di domande quando ho iniziato - chiedendogli di salvarmi il culo in diverse occasioni. Diavolo, ho ancora un sacco di domande ... Mi piace solo pensare che siano domande migliori ora.

Copia incolla, prova ed errore invece di cercare di comprendere i fondamenti di base

Molti sviluppatori junior copieranno codice che sembra vicino, quindi provano quasi casualmente diverse permutazioni di modifiche con la forza bruta fino a quando non colpiscono uno che funziona. Se non sai perché funziona, è probabile che tu stia introducendo dei bug nei casi limite che qualcuno che lo capisce dovrà ripulire in seguito.

Mantenere la loro "prima bozza" di codice

Quando uno sviluppatore esperto scrive una nuova funzione di una certa complessità, inizia con uno stub che non fa altro che compilare, quindi riscrive per aggiungere commenti pseudo-codice di alto livello per l'algoritmo globale, quindi riscrive quei commenti uno alla volta con codice effettivo, aggiungendo e rimuovendo il codice fittizio come necessario per il test, quindi riscrivendolo per rimuovere la ridondanza emersa durante l'implementazione e così via in una serie di miglioramenti successivi e incrementali.

Gli sviluppatori junior hanno la tendenza a scriverlo in un grosso pezzo, quindi eseguire un massiccio debug della forza bruta. A loro non piace eliminare una riga di codice una volta che è stata digitata nell'editor, e sono così felici di averlo finalmente fatto funzionare che non amano riprogrammare per miglioramenti non funzionali, ma sono quelli che devono fare quindi di più.

Credere di essere il primo a incontrare una situazione.

Ogni problema di programmazione che affronti è stato affrontato da altri, in una forma generale. C'è così tanto da imparare da programmatori esperti. Sono abbastanza grande da ricordare la programmazione prima di Google, e mi ha fatto schifo . Era ancora peggio quando avevamo i motori di ricerca, ma non c'erano ancora molte buone informazioni sul web. La programmazione ora è molto più produttiva perché hai accesso alla conoscenza globale in pochi secondi. Le persone che non lo usano lo stanno ignorando a loro rischio e pericolo.

Modifica :

Giusto per essere chiari, io non sostenendo copia / incolla di programmazione. Sono certo, tuttavia, che è necessario rivedere le conoscenze esistenti prima di poter prendere le decisioni giuste da soli.

Pensando di sapere tutto.

Ho avuto un jr. stagista che ha cercato di risolvere tutto con javascript. Ho cercato di spiegare diversi concetti, ma ha sempre pensato di poterlo fare meglio. Ora ha lasciato e sto rielaborando un programma importante che ha creato per l'output di stampa usando HTML anziché una tecnologia pronta per la stampa come PDF. Per non parlare di un mucchio di altri problemi importanti.

La lezione è di chiedere agli anziani una guida generale di primo piano all'inizio di un progetto, non abbandonare l'architettura senza aiuto. Puoi scrivere il codice e i dettagli da solo, ma assicurati almeno di usare la giusta tecnologia.

Raramente mi infastidiscono quando i giovani non conoscono le basi, non vengono insegnate competenze del settore come SCC all'università. È compito degli sviluppatori senior insegnare loro. Mi infastidiscono solo gli scontri di personalità. Ma sono molto seccato dagli sviluppatori senior che non conoscono le basi.

Non voler far avanzare le proprie conoscenze - prendendo invece il percorso di minor resistenza.

L'altro giorno uno stagista insieme al progettista grafico (che è sorprendentemente abile nella programmazione) ha chiesto aiuto perché si sono trovati in difficoltà nell'implementazione di qualcosa in jQuery - la chiusura può essere dolorosa se non riesci a vederlo arrivare.

Mi sono seduto con il tirocinante e ho spiegato esattamente cosa non andava e perché. Abbiamo corretto il bug, quindi ho sottolineato diversi miglioramenti che potevano essere apportati ("dato che sono qui") e abbiamo finito per riscrivere la funzione colpevole in 10 righe anziché in 20 e senza bug. Dopo aver risposto a qualsiasi domanda, soddisfatto che tutto andasse per il meglio nel mondo, me ne sono andato.

Il giorno dopo, il tirocinante ha ricevuto una domanda che ha rivelato che "um, voleva apportare alcune modifiche e riscrivere la funzione a modo mio perché ho trovato difficile da capire" (per la maggior parte annullando i miei miglioramenti).

Avrebbe potuto tentare di più, invece (fare domande aggiuntive, leggere i concetti che ho citato) - un codice così breve non può mai essere così difficile da capire - o prendere la via più semplice. Mi rattrista ogni volta che vedo qualcuno fare quest'ultimo.

Non capire OOP. Purtroppo questo è molto più comune di quanto molti di noi probabilmente capiscano.

Saper creare una classe, una classe astratta, un'interfaccia o persino conoscere il polimorfismo è una cosa; capire come usarli correttamente a beneficio del tuo programma è un altro .

Se vuoi evitare questo, ho trovato queste domande e le risposte illuminanti:

• Odore di codice: Abuso di ereditarietà - I pericoli dell'eredità
• Da dove viene questo concetto di "favorire la composizione sull'eredità"? - I pericoli dei mantra sull'evitare l'eredità

Non sapendo ciò che non sai, e nell'ignoranza pensando di sapere tutto.

(E suo cugino vicino, non volendo chiedere.)

In parte è una cosa organizzativa: un'induzione in entrata appropriata farebbe molto per evitare che alcune di queste cose diventino problemi. Ma pochissime aziende hanno tempo o persone disponibili per un'induzione in arrivo - qualcosa che dovrebbe richiedere da pochi giorni a poche settimane e toglie agli sviluppatori il loro lavoro. Quindi dobbiamo spegnere gli incendi.

Sono stupito di quanti programmatori junior relativamente freschi di un programma CS sono deboli con gli algoritmi. La scelta sbagliata dell'algoritmo potrebbe non distinguersi davvero nella linea di applicazioni aziendali, ma quando si elaborano miliardi di richieste di servizi Web al giorno, è davvero importante.

Ecco una domanda di intervista che uso che manca a quasi tutti i programmatori Junior che evidenzia il problema:

Scrivi il codice che calcola l'ennesimo numero di Fibonacci .

Quasi sempre vanno per la maggior parte a scrivere l'ovvio ma inefficiente

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

Quando mi viene chiesto di commentare la complessità algoritmica, di solito ottengo "è peggio di O (N) ... uhm ... O (N logN)". In realtà è (molto) peggio di così ...

Fare rientro del codice all'indietro!

Ovviamente non è molto "tipico". Non potrei mai credere che fosse nemmeno possibile, ma come scriverebbe un normale sviluppatore

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

avrebbe scritto come (Dio, mi sembra ancora impossibile!)

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

Frustrante non è vero?