Come gestire il codice "quasi buono" di uno sviluppatore junior? [chiuso]

Ho una domanda sulla gestione della squadra. In questo momento ho a che fare con uno sviluppatore junior che lavora in remoto da una fabbrica di codifica. Il ragazzo è aperto alle critiche e disposto a imparare, ma ho qualche dubbio su quanto dovrei spingere alcune cose.

In questo momento quando qualcosa è chiaro ed evidente una violazione delle buone pratiche: come violazione di SRP, oggetti di Dio, nomi non significativi per metodi o variabili; Sottolineo cosa deve risolvere e cerco di spiegare perché è sbagliato.

La mia domanda è: quando mi fermo? In questo momento se ci sono alcune piccole violazioni dello stile di codifica come nomi di variabili nella lingua sbagliata (la squadra precedente ha mescolato spagnolo e inglese e sto cercando di risolverlo), o alcuni problemi strutturali minori sto lasciando andare e risolverlo se Ho del tempo libero o ho bisogno di modificare la classe problematica. Sento che questo è un bene per il morale della squadra, quindi non sto spingendo costantemente indietro il codice su ciò che un principiante potrebbe sembrare dettagli minori, il che può essere abbastanza frustrante, ma mi preoccupo anche che essere troppo "morbido" potrebbe impedire al ragazzo dall'imparare come fare alcune cose.

Come bilanciare la linea tra insegnare al ragazzo e non bruciarlo con continue critiche? Per un giovane può essere frustrante se gli dici di rifare cose che ai suoi occhi sta funzionando.

Se ritieni che il codice debba essere corretto prima dell'unione, fai dei commenti. Preferibilmente con "why" in modo che lo sviluppatore possa imparare.

Tieni presente che il codice viene letto molto più spesso di quanto scritto. Quindi le cose che sembrano "minori" possono effettivamente essere davvero importanti (ad esempio nomi di variabili).

Tuttavia, se ti ritrovi a fare commenti che sembrano noiosi, forse considera:

• Il tuo processo CI dovrebbe catturarli?
• Hai una chiara "guida per sviluppatori" a cui fare riferimento (o è tutto documentato nella tua testa)?
• Questi commenti contribuiscono effettivamente alla qualità del codice?

Molte persone sacrificano la produttività all'altare del processo o della perfezione. Fai attenzione a non farlo.

Prova a visitare il tuo collega di persona, se possibile. Oppure usa le videochiamate. Costruire una relazione rende le critiche (anche le revisioni del codice) più facili da gestire.

Se scopri che un pezzo di codice ha troppi problemi di risposta, richiedi la revisione su pezzi di codice più piccoli. Le modifiche incrementali hanno maggiori probabilità di evitare alcuni dei problemi di progettazione più significativi, poiché per definizione sono più piccoli.

Ma assolutamente non unire le cose e poi tornare indietro e ripararlo. Questo è passivo aggressivo e se lo sviluppatore ti trova a farlo, ucciderai il loro morale.

Mantieni le critiche sul codice piuttosto che sullo scrittore.

Ogni lavoro prodotto ha un attaccamento emotivo intrinseco. Prendi in considerazione l'idea di alleggerire dissociando il codice dallo scrittore il più possibile. La qualità del codice dovrebbe essere stabilita costantemente come un obiettivo comune che entrambi affrontate, insieme, piuttosto che un punto di attrito tra voi.

Un modo per raggiungere questo obiettivo è scegliere saggiamente le tue parole. Sebbene agli STEM piaccia pensare se stessi come altamente logici, le emozioni fanno parte della natura umana. La verbosità usata può essere la differenza tra sentimenti feriti o risparmiati. Dire "Questo nome di funzione sarebbe più coerente con le convenzioni se fosse in inglese" è preferibile a "Hai scritto questo nome di funzione in modo errato e dovrebbe essere in inglese". Mentre quest'ultimo è ancora docile e da solo sembrerebbe bene, rispetto al primo i suoi difetti diventano evidenti - quando si prepara cosa dire di persona o un'e-mail esaminare se il tuo contesto, le parole e il focus sono o meno sui problemi piuttosto che la persona .

Linguaggio del corpo

Mentre le parole sono importanti, la maggior parte delle comunicazioni non è verbale. Presta attenzione al linguaggio del corpo, anche sottigliezze apparentemente insignificanti come l'orientamento più opaco, ad es. Molte interazioni senior-junior si verificano faccia a faccia, ma un approccio side-by-side sarebbe molto più favorevole al risultato desiderato.

Dare un feedback positivo onesto

Una moltitudine di studi mostra che le informazioni vengono apprese più rapidamente e conservate meglio quando premiamo i buoni comportamenti piuttosto che punire quelli cattivi. A volte notando semplicemente che le prestazioni sono state migliorate con un semplice "buon lavoro" o uno più specifico "Ultimamente ho notato che il tuo stile ha adattato i nostri standard a un tee, un ottimo lavoro!" anche integrare questo riconoscimento di miglioramento facendogli consigliare a loro volta qualcun altro sulle questioni che hanno modificato può fare la differenza per il tuo sviluppatore e il suo lavoro.

Il ragazzo è aperto alle critiche e disposto a imparare, ma ho qualche dubbio su quanto dovrei spingere alcune cose.

Spingi tutto il possibile. Se il ragazzo sta imparando, ed è il tuo lavoro rivedere il suo codice, entrambi hai molto da guadagnare se fa un buon lavoro.

Ciò significherà meno codice da rivedere in futuro e possibilmente dare alla tua squadra un obiettivo di assunzione.

Inoltre, se ti tratteni, non stai aiutando, ma con condiscendenza.

Solo per il fatto che hai pubblicato la tua domanda qui, chiedendoti se stai facendo troppo, mi segnala già che non hai bisogno di questo consiglio specifico, ma per gli altri, ecco che arriva: ricorda solo che spingere forte non significa essere un coglione.

Essere un mentore non è un compito facile. Dovrai anche lasciare un po 'di spazio per fargli fare degli errori e correggerli da solo, assicurati solo che lo farà da qualche parte che non faccia un danno reale.

Sulla base della tua descrizione, la lascerei a: "va bene. Ci sono alcune cose che avrei fatto diversamente ma non sono molto importanti".

Come sembri capire, la critica ha un costo e se passi molto tempo a sgranocchiare i dettagli, diventa un problema morale. Idealmente, tutti gli standard di codifica vengono controllati automaticamente e non è possibile crearli se non li si sta seguendo. Questo è un enorme risparmio di tempo e ti consente di iniziare a lavorare. Se riservi le tue critiche a "cose ​​che contano", i tuoi consigli avranno un impatto molto maggiore e verrai considerato come un mentore apprezzato. È davvero cruciale distinguere tra cose che non vanno bene e cose che non sono esattamente come lo faresti tu.

Credo nel concetto del momento insegnabile . Se lo sviluppatore ha abbastanza capacità mentale, potrebbe chiedere i dettagli su cosa faresti diversamente. (S) potrebbe non farlo e va bene. Le persone si esauriscono e all'inizio di una carriera può richiedere molta energia mentale per realizzare cose che sembrano semplici in seguito.

Prenderei in considerazione l'idea di accettare il suo lavoro quando è accettabile, non perfetto. E poi il prossimo compito è dopo una discussione per riformattarlo immediatamente apportando tutti i piccoli ma importanti cambiamenti che desideri.

Quindi, quando il lavoro viene accettato per la prima volta, il tuo messaggio è che non era male, e alcuni posti lo avrebbero accettato abbastanza bene, ma non i luoghi in cui vorresti essere uno sviluppatore junior che vuole imparare il suo mestiere correttamente.

Quindi non dici "Rifiuto il tuo lavoro perché non è abbastanza buono". Dici (a) "Accetto il tuo lavoro perché è abbastanza buono", e poi (b) "Ma lo voglio meglio".

Domanda piuttosto aperta, ma qui ci sono un paio di idee.

1. Revisioni tra pari (dallo sviluppatore junior)

   Il modo migliore per qualcuno di imparare il modo "giusto" è vedere gli altri farlo. Tutti i tuoi sviluppatori eseguono revisioni del codice? Potrebbe non essere una cattiva idea lasciare che anche il tuo sviluppatore junior li esegua (anche se dovresti anche richiedere almeno una recensione da uno sviluppatore senior). In questo modo vedrà buoni programmatori in azione, inoltre osserverà che ci sono commenti di revisione diretti a ingegneri diversi da se stesso, il che significa che non è personale.

2. Feedback anticipato / Revisioni delle attività

   Consentire allo sviluppatore di partecipare alla propria suddivisione delle attività. Chiedigli di registrare il progetto previsto nelle note dell'attività e di inviare una "revisione del codice" senza modifiche e solo l'attività. In questo modo puoi rivedere il suo piano prima che abbia scritto una singola riga di codice. Una volta che il suo compito è stato rivisto, può iniziare la codifica (dopodiché invierà un'altra revisione del codice). Questo evita la situazione demoralizzante in cui lo sviluppatore ha scritto un sacco di cose e devi dirgli di riscriverlo.

Se il codice viola oggettivamente uno standard scritto e inequivocabile, penso che dovresti continuare a respingere fino a quando non viene risolto ogni problema. Certo, potrebbe essere leggermente fastidioso per lo sviluppatore i primi pochi impegni, ma potrebbero anche imparare le linee guida prima e poi.

Inoltre, se permetti alcune violazioni degli standard qua e là, questi creeranno un precedente negativo - vedi la teoria delle finestre rotte . Inoltre, è molto più facile ricordare di seguire gli standard se è già costantemente applicato alla base di codice. Quindi davvero, vincono tutti, compresi gli sviluppatori junior in questione.

Non penso che il morale sia un grosso problema fintanto che lo standard di codifica è scritto. Solo se entrasse in un territorio più "soggettivo", lo avrei fatto diversamente ", allora dovresti preoccuparti, poiché l'approccio degli sviluppatori potrebbe essere altrettanto valido.

Prendi in considerazione l'adozione di un flusso di lavoro di revisione del codice, in cui gli sviluppatori pubblicano i loro commit proposti su uno strumento come Github Pull Requests o Phabricator Diffusion e ottieni il peer sign-off prima di apporre le loro modifiche sul ramo master condiviso.

In questo modo, piuttosto che criticare retroattivamente o chiedere a qualcuno di ripetere ciò che è già stato fatto, il lavoro non è ancora finito fino a quando non passa la revisione tra pari. Il avanti e indietro con i peer fa parte del processo di ingegneria del software quanto il avanti e indietro con il compilatore.

Puoi pubblicare le tue preoccupazioni come commenti su determinate righe e intrattenere discussioni su di esse. Può fare lo stesso con il tuo codice. La discussione rimane focalizzata sulle modifiche specifiche al codice proposto e non sulle prestazioni o le competenze di qualcuno in generale.

Anche i geniali ingegneri senior della mia azienda sono grati quando le revisioni del codice catturano errori di battitura o li costringono a rendere le cose più chiare. È del tutto normale che i nuovi assunti richiedano più cicli di iterazione. Nel tempo, inizi a risolvere in modo riflessivo i tipi di problemi che conosci attireranno i commenti prima di pubblicare un diff. Ottenere una percentuale più alta delle tue differenze accettate al primo tentativo è come sai che stai migliorando.

Non sto inviando costantemente il codice su cosa potrebbe sembrare un principiante dettagli minori, il che può essere abbastanza frustrante, ma mi preoccupo anche che essere troppo 'soft' potrebbe impedire al ragazzo di imparare a fare alcune cose.

Queste sono sia reali possibilità che preoccupazioni valide. Chiedi allo sviluppatore come si sentono al riguardo.

Supponendo che tu abbia qualche richiesta pull o flusso di lavoro di revisione del codice, e sembra che tu lo faccia, consiglierei di notare cose che sono "non critiche" o "preferite".

Se vedi un PR in uno stato simile a quello che stai descrivendo, con alcuni problemi stilistici minori o che necessitano di refactoring non critico, lascia un commento, ma sentiti anche libero di approvare. Dire qualcosa come "In futuro, forse provare a evitare nomi di metodi come questo a favore di qualcosa come descrittivoMethodName" documenta la tua opinione senza costringerli a cambiarlo o bloccarne lo sviluppo.

Ora conoscono le tue preferenze e, se stanno cercando di migliorare, si spera che notino una situazione del genere in futuro. Inoltre lascia la porta aperta a loro in realtà cambiandolo in quel momento, se sono d'accordo con te e lo considerano abbastanza critico.

Ho a che fare con uno sviluppatore junior che lavora in remoto da una fabbrica di codici.

Purtroppo questa non è una situazione ideale: un programmatore avanzato responsabile di un programmatore principiante, con separazione geografica. Non sorprende che ci sia una certa tensione, ma la disparità può essere mitigata.

Sono curioso, cosa intendi con "fabbrica di codifica"? Questa terminologia, per me, indica un atteggiamento preoccupante che potrebbe esacerbare alcuni dei problemi di gestione che hai citato.

... violazione di SRP, oggetti di Dio, nomi non significativi per metodi o variabili; Sottolineo cosa deve risolvere e cerco di spiegare perché è sbagliato.

Il problema, penso, è che il tuo sviluppatore junior sta emettendo codice senza aver attraversato un corretto processo di progettazione. Questo è un errore da parte tua, in qualità di manager e sviluppatore senior, nel fornire indicazioni e insegnare buone abitudini di sviluppo del software. In primo luogo è possibile impedire la scrittura di codice errato se si lavora per la prima volta insieme per disegnare uno schema. Sarebbe preferibile criticare e riscrivere il codice dopo che è stato prodotto, sia in termini di efficienza che di morale.

Probabilmente dovrai regolare nuovamente il flusso di lavoro. Sembra che al momento ti aspetti che ti consegni dei prodotti. Ciò di cui hai bisogno è una collaborazione più stretta, in modo da poter fornire assistenza in ogni fase dello sviluppo. Parla del design e dell'interfaccia prima dell'inizio della codifica. Durante la codifica, esegui checkpoint più frequenti per rilevare i problemi in anticipo. Se possibile, prova a programmare la coppia, tramite condivisione dello schermo con un canale audio.

Tutto ciò richiederà maggiori sforzi da parte tua, ma probabilmente ne varrà la pena, considerando la relazione problematica che hai attualmente.

Se si tratta di una violazione degli standard di codifica, mostragli dove si trova in modo che lui / lei sappia. Se devi continuare a mostrargli lo stesso errore, potresti avere un problema con qualcuno che non può conformarsi alle regole o si rifiuta di farlo. Non usare il tuo tempo libero per correggere gli errori. Questa persona dovrebbe correggere i propri errori in modo da non farli più.

Digli sempre cosa hanno fatto bene e come possono migliorare la prossima volta. Possiamo sempre migliorare in alcune aree. Il feedback è fondamentale per migliorare in qualsiasi cosa.

Un'altra idea per affrontare "troppe critiche" è quella di fare di tanto in tanto un compito da solo e lasciare che uno sviluppatore junior esegua una revisione del codice per te. Questo ha almeno due vantaggi:

• possono imparare come dovrebbero essere fatte le cose.
• nei casi in cui esistono più soluzioni valide o nomi di variabili, accetto suggerimenti di approcci diversi ma (quasi?) ugualmente buoni. Quando aggiusto il mio codice a causa del commento di qualcuno, sto mostrando alle persone che sono rispettate e le critiche riguardano sempre solo il codice, indipendentemente da chi sia l'autore.