Promemoria generale: è sempre meglio evitare un tono critico o di lezione. O rendila una semplice osservazione ("sembra che tu abbia dimenticato di implementare hashcode qui") o rendila una domanda ("c'è una ragione per cui non hai implementato hashcode?"). Lascia che la loro risposta guidi la discussione sul perché è importante, se necessario, ma inizia dal presupposto che conoscano i principi e che la stranezza fosse una semplice svista / errore di battitura o avesse qualche ragione razionale dietro di essa che può essere discussa piuttosto che picchiato.

Le persone ascoltano meglio se le tratti con rispetto.

E ricorda, a volte il malinteso sarà tuo. Ti imbarazzerai molto meno in questo modo che se fai una dichiarazione più assoluta o didattica.

Forse guardare questo da un'altra prospettiva potrebbe darti una visione migliore.

Sono un team leader e anche un manager in una piccola azienda di otto sviluppatori. Ho 15 anni di esperienza nella programmazione in Java. Ho una nuova persona nel mio team che è molto più giovane di me con solo un paio di anni di esperienza.

Il mese scorso, mentre discutevamo di alcuni moduli di codice sorgente che avevo scritto, ha iniziato a sminuire il mio codice. Anche se ha molta meno esperienza di me, ha affermato di vedere bug nel codice che funzionava perfettamente. Dopo una breve discussione mi è sembrato di essere in grado di spiegarglielo.

Ma sfortunatamente non riesce a fermare quella faccenda. Continua a minare la mia autorità chiedendo che facciamo tutto tramite libri di testo (come il libro di Joshua Bloch 'Effective Java') anche in quei casi in cui sarebbe solo una perdita di tempo e non si tradurrebbe in un vantaggio tangibile per il nostro prodotto. Come posso convincere questo sviluppatore junior a fidarsi della mia esperienza?

È difficile come un giovane convincere un anziano a cambiare le proprie pratiche. Inoltre, come manager deve mantenere un'aura di superiorità per essere in grado di guidare in modo efficace.

Quindi, quando vuoi migliorare gli standard di qualità sul tuo posto di lavoro senza l'autorità per farlo, dai il buon esempio. Fai bene ciò che gli altri fanno di sbagliato e mostra che la tua strada è migliore perché si traduce in un prodotto migliore in meno tempo. Quando indichi errori nel codice di altre persone, non farlo eseguendo il pignolo nei file del codice sorgente. Fallo presentando un difetto riproducibile nel prodotto stesso e un modo per risolverlo seguendo le migliori pratiche.

A proposito, una delle malattie professionali più comuni per i programmatori è un ego gonfiato. Potrebbe averne già uno, ma stai iniziando a mostrare anche i sintomi delle prime fasi.

Un modo per mitigare questo tipo di problema è "dare e avere". Ho avuto successo con questa strategia molte volte. Le persone sono più suscettibili ai tuoi suggerimenti e critiche quando è a doppio senso. Quindi avrei fatto domande e consigli quando ne avevo la possibilità e prendevo sul serio le loro risposte. (Ad essere onesto a volte conoscevo già la risposta, ma non si sa mai, ho anche imparato alcune cose interessanti in questo modo.)

Alla fine si costruisce un rapporto in cui ci si sostiene a vicenda e le cose vanno molto meglio in molti modi. E se ha 15 anni di esperienza, scommetto che ci sono molte cose che potrebbe dirti che vale la pena sapere.

Non mi preoccuperei per lui e la sua spalla fredda, è abbastanza normale dopo quello che è successo. Con ogni probabilità avrà preso in considerazione il tuo contributo e sta facendo attenzione intorno a te, e probabilmente lo hai turbato un po '. Ma non è un concorso di popolarità, quindi a meno che non riesca a perdere il controllo, dagli spazio. Rimani amichevole e di supporto e lui si avvicinerà.

Invece di renderla una discussione "Penso che dovresti" che ormai è chiaro che non ti porterà da nessuna parte, trasformala in una discussione tecnica.

Dopo aver esaminato il codice Ho trovato un problema e ho scritto il test X che lo dimostra.

(Puoi scriverne diversi se necessario). Spetta quindi al team discutere come risolverlo correttamente in modo che il test abbia esito positivo.

Hai alzate mattutine? o altre riunioni di gruppo in cui puoi menzionarlo in modo informale.

Presentandole a tutti in modo completamente impersonale "Oh, fastidio, ho scoperto che questo problema implementato da questa classe è uguale a non hashcode, che può davvero causare problemi se la classe viene mai utilizzato in una hashmap poiché solo l'identità dell'oggetto viene utilizzata come chiave "e quindi si discute quando può essere risolto.

Non hai accusato nessuno di scrivere codice errato, ora tutti sanno perché questo è un problema , il codice viene corretto.

Sii educato e professionale. Invia un ticket per il bug, nel tuo ticket, dettaglia il problema e una potenziale soluzione e lascia un'apertura per essere contattato per ulteriori informazioni o una spiegazione del problema. Lascia stare quello. Quando i tuoi ticket vengono esaminati, verranno assegnati a te stesso per correggere il bug che hai trovato o allo sviluppatore originale. Si spera che l'altro sviluppatore capirà e risolverà il problema o tornerà da te per ulteriori informazioni. Se nessuno dei due accade, ora è un problema di gestione.

Questo metodo non richiama alcuno sviluppatore specifico per errori e consente di tenere conto del tempo di riparazione e possibilmente anche di includere in una mischia (se lo fai quello).

Trovare bug nel codice di altre persone è pratica comune. Ogni volta che un nuovo sviluppatore entra in un progetto, trova problemi. Assegnare la colpa non è importante. Basta fare un ticket e lasciare che siano i processi aziendali a gestirlo. Gli sviluppatori esperti non dovrebbero offendersi se altri trovano problemi nel loro codice. E se lo fanno, probabilmente non dovrebbero essere sviluppatori.

Anche se penso che Keshlam abbia un buon punto. È anche importante ricordare che il team possiede il codice, non qualsiasi individuo, quindi evito di utilizzare "Tu" quando chiedi informazioni su potenziali problemi con il codice. Potresti invece chiedere

"Ciao, ho notato che non abbiamo implementato l'hashcode qui, c'è una ragione per questo?"

Sei affrontare il potenziale problema con il codice, ma anche indagare su una possibile ragione del problema e dare al team leader l'opportunità di trasformarlo in un'esperienza di apprendimento per te.

Alcuni suggerimenti generali, sebbene da queste informazioni, penso che i punti 4 e 5 potrebbero essere i più appropriati:

1. Separare il codice dal suo autore. Sei qui per valutare il primo, non il secondo. "Questo codice è [X]" è meglio di "Hai creato questo codice [X]".
2. Sii specifico. Non fornire descrizioni vaghe per l'intera codebase. "I commenti descrittivi sarebbero apprezzati in X, Y e Z riguardo alla formulazione di questa funzione" è infinitamente più apprezzato di "Per me è tutto greco".
3. Sii anche positivo! il termine per questo processo è "revisione del codice", non "macellazione verbale del codice" per una ragione. Nella maggior parte delle recensioni pubblicate, un revisore parlerà degli aspetti positivi e negativi di un prodotto. Dovresti fare lo stesso.
4. Scegli le tue battaglie. Non trattare tutto come un insuccesso. Se è un po 'strano ma funziona perfettamente, dategli una nota a piè di pagina nella migliore delle ipotesi e affrontatela come un' problema minore 'o' domanda veloce '. In generale, parlando, se dovete aprire un scenario di rottura, non conta come nulla di grave.
5. Assicurati che le cose di cui parli non siano solo "in teoria". Prova tu stesso l'applicazione o parla con il team di test di qualcosa che pensi possa essere un problema.

Scrivi un test case, descrivendo il comportamento che ti aspetti e mostra che il problema rompe il test.

(O ragazzo, che cose folli abbiamo scoperto quando abbiamo iniziato a testare hashCode e uguale sistematicamente nel nostro progetto .....)

Ottima domanda. Amo imparare, ma quando qualcuno irrita la mia dolcezza mi sento come se dovessi smettere. Consiglio di rivedere lo "stile di programmazione" dei tuoi colleghi e di identificare i suoi punti di forza in modo che non si senta come se tutto il tempo che ha trascorso ad imparare sia stato inutile. POI identificare OPPORTUNITÀ. In questo modo mostri i punti di forza in futuro che stanno aiutando l'azienda e anche lavorando su quelle "opportunità" che hai già identificato. Conduco le squadre dando un orario di 30-60-90 giorni e poi lodo i ritocchi in cui abbiamo capitalizzato le "opportunità". Funziona molto bene ed è un modo equo per identificare i leader rispetto a persone che non lo sono e non dovrebbero essere leader.

Risolvilo da solo. Crea un ramo, aggiustalo, sviluppalo e se hai bisogno di approvazione, fai semplicemente una revisione del codice. Cambia il peso per te, ma sei tu che pensi che sia importante, quindi il peso ricade davvero su di te, anche se è il codice di qualcun altro.