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

Non sapendo che cos'è il controllo di versione o come usarlo correttamente .

Uno degli sviluppatori junior che è stato nella mia azienda per diversi mesi 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 fai abbastanza domande

So che sono juniores, mi aspetto che facciano errori e che non sappiano nulla. Così tante potenzialità reali potevano essere evitate semplicemente facendo una domanda invece di assumere qualcosa. Onestamente, non posso essere tormentato abbastanza.

Ho avuto TONNES di domande quando ho iniziato - chiedendo loro di salvarmi il culo in diverse occasioni. Diavolo, ho ancora un sacco di domande ... Mi piace pensare che ora siano domande migliori.

Copia incolla e tentativi ed errori invece di cercare di capire i fondamentali sottostanti

Molti sviluppatori junior copieranno il codice che sembra vicino, quindi provano quasi casualmente diverse permutazioni di modifiche con la forza bruta fino a quando non colpiscono su una che funziona. Se non sai perché funziona, è probabile che tu introduca bug nei casi limite che qualcuno che lo capisca dovrà pulire in seguito.

Mantenendo la "prima bozza" del 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 generale, quindi riscrive quei commenti uno a un tempo con codice effettivo, aggiunta e rimozione di codice fittizio come necessario per il test, quindi riscrittura 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 eseguono un debugging di forza bruta. Non gli piace cancellare una riga di codice una volta che è stata digitata nell'editor, e sono così contenti che alla fine hanno funzionato che non hanno voglia di riscrivere per miglioramenti non funzionali, ma sono loro che devono fare quindi il più.

Credendo 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 dai programmatori esperti. Sono abbastanza vecchio da ricordare la programmazione prima di Google, e risucchiato . 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 ignorano a loro rischio e pericolo.

Modifica :

Per essere chiari, sono non che sostiene la programmazione di copia / incolla. Sono certo, tuttavia, che è necessario rivedere le conoscenze esistenti prima di poter prendere buone decisioni da soli.

Pensando di sapere tutto

Ho avuto un jr. stagista che ha provato a risolvere tutto con javascript. Ho cercato di spiegare diversi concetti, ma ha sempre pensato che avrebbe potuto farlo meglio. Ora ha lasciato e sta rielaborando un programma importante che ha creato per l'output di stampa utilizzando HTML invece di una tecnologia pronta per la stampa come PDF. Per non parlare di una serie di altri problemi importanti.

Lezione è quella di chiedere agli anziani una guida generale importante all'inizio di un progetto, non abbandonare l'architettura senza aiuto. Puoi scrivere solo il codice e i dettagli, ma assicurati di utilizzare almeno la tecnologia giusta.

Raramente mi infastidisco quando i giovani non conoscono le basi, non vengono insegnate abilità del settore come SCC in Università. È compito degli sviluppatori senior insegnare loro. Mi infastidisco solo per gli scontri di personalità. Ma sono molto infastidito dagli sviluppatori senior che non conoscono le basi.

Non voler avanzare le loro conoscenze, prendendo invece il percorso di minor resistenza.

L'altro giorno uno stagista e il designer grafico (che è sorprendentemente abile nella programmazione) hanno chiesto aiuto perché si sono imbattuti in problemi nell'implementazione di qualcosa in jQuery - la chiusura può essere dolorosa se non riesci a vederlo arrivare.

Mi sono seduto con lo stagista e ho spiegato esattamente cosa stava andando storto e perché. Abbiamo corretto il bug, quindi ho indicato alcuni miglioramenti aggiuntivi che potrebbero essere apportati ("poiché sono qui") e abbiamo finito per riscrivere la funzione colpevole in 10 righe anziché 20 e senza bug. Dopo aver risposto a qualsiasi domanda, ho verificato che tutto andava bene per il mondo ancora una volta, me ne sono andato.

Il giorno dopo, lo stagista arrivò con una domanda che rivelava che "um, volevo apportare alcune modifiche e riscrivere la funzione a modo mio perché trovavo difficile capire" (per lo più annullando i miei miglioramenti).

Poteva invece aver provato di più (facendo domande aggiuntive, leggendo i concetti che ho menzionato) - il codice così breve non può mai essere quello difficile da capire - o prendere la via più facile . Mi rattrista ogni volta che vedo qualcuno che fa il secondo.

Non comprendi l'OOP. Purtroppo questo è molto più comune di quanto molti di noi probabilmente realizzino.

Sapere come creare una classe, una classe astratta, un'interfaccia o anche 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 a loro illuminanti:

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

Non sai quello che non sai, e nell'ignoranza pensando di sapere tutto.

(E il suo cugino vicino, non volendo chiedere.)

In parte questa è 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 a disposizione per un'induzione in entrata - qualcosa che dovrebbe richiedere da pochi giorni a qualche settimana e porta gli sviluppatori fuori dal loro lavoro. Quindi dobbiamo spegnere gli incendi.

Sono stupito di quanti giovani programmatori relativamente freschi di un programma CS siano deboli con gli algoritmi. La scarsa scelta dell'algoritmo potrebbe non essere rilevante nelle applicazioni aziendali, ma quando si elaborano miliardi di richieste di servizi Web al giorno, è davvero importante.

Ecco una domanda di intervista che uso quasi tutti i programmatori Junior che mancano per evidenziare il problema:

Scrivi il codice che calcola il numero n. Fibonacci .

Quasi sempre vanno per lo più 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 viene chiesto di commentare la complessità algoritmica, di solito ottengo "è peggio di O (N) ... uhm ... O (N logN)". In realtà è (molto) peggio di quello ...

Esecuzione del rientro del codice di ritorno!

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

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

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

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

Non è frustrante?