In qualità di manager, è tuo compito evitare che i tuoi dipendenti si distraggano. Se fossi stato io, non menzionerei i punti negativi di queste persone o il codice sbagliato. Allo stesso tempo, non incoraggiare nemmeno le cose cattive che ha fatto.

Qualcosa sulla falsariga di:

Bob è stato davvero un grande programmatore e ci mancherà moltissimo . Ha scelto di perseguire un'altra opportunità e gli auguriamo ogni bene. Sono davvero orgoglioso di te come squadra e di come ti stai unendo per mantenere le nostre tempistiche in movimento e continuare a fare l'ottimo lavoro di cui so che sei capace.

Questo non dice qualcosa di specifico, ma allo stesso tempo loda la tua squadra. Nel corso del tempo puoi svelare con attenzione alcuni pasticci e rendere le cose più complesse.

Una volta che la polvere si sarà depositata, sarebbe il momento di introdurre la discussione sui vari standard di codifica. Non abbatterli dall'alto, ma incoraggia il team a svilupparli e poi chiedi loro di ritenersi responsabili a vicenda. Questo dovrebbe eliminare alcuni dei problemi che hai avuto.

Dicendo qualcosa di negativo su di loro, corri il rischio di sembrare meschino. In qualità di leader, è molto meglio lasciare che i risultati parlino da soli e lasciare che il team elabori la propria teoria sulla causa. Se disponi di metriche sulle prestazioni che stai monitorando, puoi sicuramente congratularti con il team per "un netto miglioramento della metrica X nelle ultime settimane Y" per promuovere quell'idea, ma sicuramente non menzionare nulla se la tua impressione di miglioramento è puramente aneddotica .

Devo affrontare questo problema in una riunione del team affermando fatti e ragioni per cui era fuori? o dovrei semplicemente non dire niente? Qual è la cosa migliore da fare in una situazione come questa?

Non credo sia necessario.

Se i progressi sono molto più rapidi mentre lo descrivi, noteranno anche i miglioramenti e trarranno le proprie conclusioni.

Chiamare una riunione o qualcosa di simile in pratica "Non sentirti in errore che se ne sia andato, ora siamo molto migliori ed efficienti" non è qualcosa che consiglierei (in quanto fondamentalmente sta gettando del terriccio alla sua reputazione deliberatamente).

Forse non era il miglior programmatore in circolazione, ma dal tuo post posso vedere che era molto entusiasta e appassionato, e anche la tua persona "a cui rivolgersi", quindi direi che dovresti dagli il merito e lascia che il tuo rapporto professionale finisca senza intoppi.

Ne avevamo uno qui prima di iniziare. Amati nuovi framework, modelli di design e strumenti. Davvero non li capivo.

Il problema era che aveva il vecchio management innamorato delle sue "abilità". È arrivato un nuovo management con abilità architettoniche reali e "Bob" * (non il suo nome) ha capito che era nei guai. Bob * è appena andato via e non è più tornato, non poteva supportare il codice che ha scritto, quindi spettava ad altri (uno dei motivi per cui sono stato assunto) decifrare il casino che ha lasciato. Gran parte del suo codice è stato appena copiato da stackoverflow. Il problema era che non capiva cosa stava copiando.

Come gestisci la tua squadra? Di '"Bob * si è dimesso. So che mancherà ad alcuni. Ora tocca a noi continuare ad andare avanti". Chiunque abbia esperienza saprà cosa è realmente accaduto e gli sviluppatori junior alla fine (quando dovranno supportare alcune delle cose scritte da 'Bob') perché è stato meglio che se ne andasse.

* Senza offesa per chiunque si chiami Bob.

Sceglierei di spiegare molto brevemente (30 secondi o meno, se possibile) le ragioni tecniche e professionali per cui questa persona non era una buona misura, pur valutando chi è come persona. Quindi non parlarne mai più mentre si passa al lavoro da svolgere.

Anche se sono d'accordo con la maggior parte delle risposte qui, credo che un po 'di trasparenza possa fare molto bene al morale e alla cultura generale delle persone che sono ancora qui.

• Lasciare che traggano le proprie conclusioni potrebbe ritorcersi contro e creare sfiducia
• Questo può stabilire un buon precedente per gli sviluppatori junior comunicando chiaramente cosa da non fare (in questo caso, cedere a certe "tentazioni degli sviluppatori" egoistiche)
• Rafforzare il fatto che questo è un team e che tutti dovrebbero programmare come un team
• Mitiga la paura che potrebbero essere i prossimi (dal momento che hanno ammirato e ammirato le capacità e gli approcci di questo sviluppatore)
• Ricorda ai dipendenti che c'è un futuro stabile fintanto che sono consapevoli di servire l'azienda esigenze

Se utilizzi un approccio di programmazione agile, puoi sempre parlarne durante la riunione retrospettiva di Scrum una volta che l'attuale Scrum termina. Discutere gli eventi della mischia, come hanno influenzato la squadra e come puoi usarli per migliorare andando avanti è fondamentalmente il punto di loro, giusto? Discutere argomenti come questo sembra adattarsi perfettamente.

Menziona gli aspetti positivi e ignora gli aspetti negativi:

Abbiamo nuove opportunità per introdurre nuovi modelli e migliorare la nostra architettura

se vuoi ancora volare it ... oppure ...

Abbiamo una nuova opportunità per introdurre standard di codifica e best practice

Se stai cercando di iniziare a ripulire quello che hai e implementare le migliori pratiche.