Non dare la caccia a un ex collega per dirgli che ha fatto un errore. Puoi dire al tuo amico che ha fatto un errore.

Che sia un amico o un ex collega dipende da te.

Non fare nulla.

1. Contattare qualcuno solo per dirgli che ha rovinato tutto ma l'abbiamo risolto, non è professionale e non importa quanto sia difficile provare a essere improbabile che sia mai ricevuto in modo positivo.
2. Parlare a fondo in modo che una conversazione possa essere utile in remoto sul codice per i non dipendenti è negativo, indipendentemente dai potenziali problemi della NDA.

Se sei sotto una NDA, allora è un grande no-no parlare con qualcuno al di fuori della tua azienda di problemi relativi all'IP, sia che siano ex dipendenti o meno.

Se non sei sotto una NDA, mi azzarderei a dire che non gli interesserà.

A parte questo, quella persona era scontenta? Era qualcosa che potrebbe effettivamente essere stato intenzionale?

Con un errore così semplice, le probabilità sono buone se infastidisce il collega, probabilmente si sono resi conto del problema un paio di giorni dopo, riflettendo su ciò. So che sono tornato a casa dal lavoro e ho realizzato "... crap, quell'algoritmo è completamente imperfetto, dovrò rifarlo domani" mentre svolgo e reminiscing sulla mia giornata.

Questo collega è tuo amico che continui ad avere uno stretto contatto dopo l'uscita? Se sì, parlane se / quando stai prendendo birre sulla barra.

Altrimenti, perché preoccuparsi?

PS .: Sulla questione NDA, qual è il segreto qui? Il signor X è quello che ha scritto il codice comunque e se la partenza è recente, il software continua sullo stesso livello di divulgazione.

Le cose sarebbero diverse se questo discorso accadesse 3 anni dopo l'uscita e tu dicessi cose che non avrebbe dovuto sapere tranne te ...

Dipende da come è andata questa persona e dalla tua relazione con lui / lei.

Inoltre, cosa ti importa? Vedo che vuoi aiutarlo a "imparare dall'errore", ma lo sei davvero? Hai intenzione di mostrargli i log * e la traccia dello stack *? Hai intenzione di mostrargli i passi che hai fatto per diagnosticare il problema? Hai intenzione di mostrargli la fonte * in modo che possa vedere dove si trova il problema?

In caso contrario, probabilmente stai sprecando il suo tempo e il tuo.

* Avrai problemi a divulgare beni / dati aziendali a un non dipendente?

Se decidi di dirgli di essere sicuro di dire anche a tutti i revisori del suo codice! Sono ugualmente responsabili! A me sembra che tu non sia andato d'accordo con questo tizio e che tu abbia voglia di scervellarlo. Lascia perdere, è improbabile che gli importi.

Probabilmente non

Sembra per lo più inutile per me, sia che siate amici o colleghi. E, in alcune circostanze, probabilmente dannoso per loro, per te e per il tuo rapporto con loro.

Tutti facciamo errori occasionali.

In effetti, l'unico fattore che vorrei spingere a dire ai miei colleghi è questo: è un errore che so che di solito non farebbero / una situazione che so che saprebbero come gestire?

Se la risposta è sì, non è necessario bugarli perché probabilmente non esiste un valore educativo per loro, quindi non vedo il dovere di informarli. Se li incontri un giorno o pianifichi di bere un drink nel loro ultimo giorno e hai un buon rapporto con loro come colleghi e colleghi professionisti, certo, potresti dirlo, altro per dare da mangiare ad amici o battute innocue di ogni altra cosa.

Se la risposta è no, allora potrebbe esserci un obbligo (non lo chiamerei uno "professionale", però) per raggiungere e aiutarli a capire il loro errore.

Mantieni Civil

Alla maggior parte delle persone non piacciono le critiche sul proprio lavoro in generale, gli sviluppatori / programmatori ancora meno, e i programmatori in partenza probabilmente avrebbero anche una tolleranza inferiore. Perché correre il rischio di infastidirli e dare loro l'impressione che se ne vadano male?

Certo, se erano impiegati male dappertutto, questo non si applica, ma se fossero altri compagni programmatori sufficientemente abili, non vedo perché vorrei fare di tutto per enfatizzare i loro errori, tranne se posso essere sicuro che possiamo entrambi deriderlo. Di nuovo, supponendo che non imparerebbero molto da esso ed essere semplicemente mortificati che lo lasciarono indietro.

legali?

Da un diverso angolo di approccio, se hanno lasciato l'azienda, dipende in realtà dal contratto e dalle politiche di sicurezza della tua azienda. Potresti non avere il permesso di prendere il codice (o altre cose, se è per questo) per gli ex colleghi.

Pensa positivo

Infine, penso che le uniche situazioni in cui ho contattato l'ex collega per discutere di un codebase che hanno lasciato sono state:

• per richiedere una conferma su qualcosa di losco durante la ricerca su una particolare area del codice,
• per congratularmi con loro per un po 'di codice che ho trovato particolarmente magistrale e che avrebbe peggiorato la mia vita se non ci fosse,
• per condividere la buona notizia di un lancio di successo con loro se se ne sono andati prima che accadesse (o annunci simili simili relativi a un prodotto su cui lavoravano).

Impara dai loro errori

Ciò che puoi sicuramente fare è segnalare l'errore al resto della squadra, per assicurarti che non si ripeta con i membri rimanenti. Non c'è bisogno di indicare l'errore effettivo in SCM o all'autore, non è un gioco di biasimo.

È fuori dal campo di applicazione della domanda, ma vorrei ancora sottolineare che dovresti assicurarti di correggere l'errore, documentarne origini, impatti e risoluzioni, e implementare un test per non visualizzarlo di nuovo, se possibile.

Potrebbe non essere legale dirlo a qualcuno. A meno che il codice non sia open source, lascia dormire i cani che dormono.