In futuro, quando si lavora su cose come questa, archiviarle in un ramo piuttosto che nel master. Oppure vai a bassa tecnologia e salvalo altrove sul tuo disco rigido personale. A meno che tu non sia in crisi, il problema non era il tempo speso, ma il rischio che qualcosa di sconosciuto, non testato e potenzialmente scoppiasse.

Cosa fare: parla con il tuo capo. Spiegagli che capisci che quello che hai fatto è sbagliato. Digli perché, così sa che hai capito. Proponi un processo per assicurarti che non accada mai più (il processo è la revisione del codice. Con le revisioni del codice questo non verrebbe mai superato. A meno che tu non abbia revisioni del codice e le aggiri, nel qual caso la risposta è un blocco tecnico che impedisce l'unione al master a meno stato rivisto - e in quel caso sei nella merda molto più profonda, perché aggirare la revisione del codice sembra losco). E accetta che rimarrai nella cuccia per un po '.

I guai in cui ti trovi dipendono dal tuo lavoro e dalle funzionalità. Se lavori in qualcosa come difesa, banca, ecc., Hai finito. Se crei un sito web e il tuo codice non ha nulla a che fare con l'accesso agli account di altre persone o alle informazioni di pagamento, probabilmente stai bene. Informazioni insufficienti da raccontare qui.

Quello che hai fatto è stato brutto, in effetti arriverei al punto di dire spaventoso , ma poi sono sicuro che non hai bisogno che te lo dica. E di certo non hai bisogno di un randomer su Internet che ti provi.

Cosa fare ora?

Rimani praticamente sulla falsariga che hai già seguito:

1. Chiedi scusa senza riserve, spiega che capisci che quello che hai fatto è sbagliato e che sai perché. E forse la cosa più importante è sottolineare che questo non accadrà mai più.

2. Non cercare di giustificare ciò che hai fatto. Usare l'iniziativa e abbozzare i PoC per dimostrare le idee non è di per sé una cosa negativa, e ho sempre incoraggiato gli sviluppatori a lavorare per me a fare proprio questo. Ma quando stai lavorando a una scadenza di rilascio ravvicinata non è il momento e inviarlo nella build per il live non è sicuramente il posto giusto e cercare di spiegarmi il tuo pensiero in questo senso (se fossi il tuo manager) in questo caso sarebbe solo mi irritano ulteriormente.

3. non cercare di diffondere alcuna colpa. Come altre risposte hanno sottolineato, ciò evidenzia una potenziale debolezza nel processo di revisione del codice della tua organizzazione e non sto dicendo che si sbagliano, ma non sei la persona che glielo dice in questo momento. In questo modo ti verrebbe solo l'impressione che tu dica "Non avrei dovuto essere in grado di commettere questo" crimine ", avresti dovuto catturarmi", che è immaturo nella migliore delle ipotesi e incolpato di vittime nel peggiore.

4. Scusati anche con il team di QA, non solo hai sprecato il loro tempo, stavi tentando di sfuggirgli qualcosa che è fondamentalmente disonesto. Dovresti essere dalla stessa "parte"!

Supponendo che il programma di rilascio possa essere recuperato senza un costo troppo significativo per l'azienda e il tuo track record è altrimenti molto buono con questo incidente fuori dal personaggio, potresti sopravvivere ma mi aspetto che ci vorrà un po 'di tempo prima che tu lo sia più bianco del bianco per ricostruire la fiducia dell'organizzazione in te. Buona fortuna!

Bene, hai imparato nel modo più duro che devi sempre chiedere consiglio prima di includere una funzionalità.

La prima cosa sarà parlarne al tuo capo, per mostrarti pienamente era quello il problema e non lo farò più. Ammettere apertamente che un errore è una cosa davvero professionale.

Il prossimo passo, riconquistare la fiducia del tuo capo. Potresti dover stare tranquillo per un po ', ma poi puoi dimostrargli che la sua opinione è importante, chiedergli consiglio, anche per decisioni che non sono importanti come mettere in produzione una nuova funzionalità.

Tu incasinato, sai perché, sii paziente e bravo nel tuo lavoro e dovresti essere bravo.

Messaggio per il tuo capo: capo, il tuo processo di revisione del codice è totalmente e completamente interrotto. I tuoi processi dovrebbero essere impostati in modo che uno sviluppatore non possa aggiungere codice che verrà aggiunto alla produzione senza che il codice stesso venga esaminato e accettato da un altro sviluppatore. Quindi è colpa tua tanto quanto colpa dello sviluppatore.

Messaggio per te: non è così che funziona. Non puoi semplicemente andare avanti e fare le cose da solo. Se hai un'idea, vai dal tuo capo e parlagliene. E se è una buona idea, lui o lei ti ordinerà di implementarla e tutto andrà bene. Ma devi renderti conto che ciò che pensi sia una buona idea e ciò che l'azienda pensa sia una buona idea possono essere molto diversi. La prima domanda da porsi per ogni idea è: faremo più soldi? Venderemo più prodotti? I clienti saranno più felici e ci daranno recensioni migliori? D'altra parte: avremo bisogno di documentazione? Creerà problemi per il supporto? Renderà più difficile lo sviluppo futuro? Sono tutte cose che il tuo capo prenderebbe in considerazione. Non è tuo compito considerare queste cose, ma devi passare attraverso il tuo capo.

La buona notizia: questo non è qualcosa per cui normalmente verresti licenziato. Il problema è stato individuato, nessun danno è stato fatto (sei stato fortunato lì, compra una birra al tester quando ne hai la possibilità). Questo è stato un momento educativo per te. Il tuo capo è molto bravo con te più duro del necessario per migliorare la parte educativa di questo bastone, senza conseguenze reali per la tua carriera. Se questo fosse andato ai clienti, sarebbe diverso.

@Lilienthal: Se al capo viene detto che il suo processo di sviluppo, di cui è responsabile, non funziona, non è mai un consiglio non tempestivo.

Primo, la cattiva notizia: hai agito in modo molto sciocco e impulsivo.

Lo sai, non c'è bisogno di aggiungere altro.

Ora, la buona notizia: probabilmente hai vinto essere licenziato.

Dagli qualche giorno, scusati e spiega al tuo capo quanto segue

1. COSA hai fatto
2. Cosa c'era che non andava it
3. Che danno avrebbe potuto causare
4. Ammetti di non aver visto le ripercussioni in quel momento.
5. Assicurati che il tuo capo non accada di nuovo
6. Esprimi il tuo rammarico
7. Vai avanti

Se fossi il tuo capo, probabilmente non ti licenzierei, ma guardarti da vicino per il prossimo futuro. Probabilmente farei anche una risatina privata tra me e me quando la polvere si calmerà, poi penserei a come canalizzare la tua creatività.

I programmatori sono un tipo malizioso, e questa è una conoscenza abbastanza comune, quindi quello che hai fatto non era completamente fuori dal regno delle aspettative. Sfortunatamente, i tempi sono cambiati e questo male è disapprovato in questi giorni.

Ricostruisci la fiducia del tuo manager e, in futuro, impara a sostenere le tue modifiche / funzionalità. Sii in grado di quantificare ciò che stai spingendo e segui le procedure descritte. Dimostrate in una demo, ma non tentate mai più di introdurre di nascosto nulla nella produzione.

Prima di tutto: respira”

Svolgiamo la catena di eventi:

Penso che questo potrebbe essere qualcosa che il mio capo potrebbe licenziarmi al di sopra di. Sebbene io sia uno degli artisti più forti della squadra, potrebbe essere che questa rottura della fiducia sia sufficiente per giustificare la mia risoluzione.

Potrebbe portare al tuo licenziamento, ma non 't . In effetti, ti ha dato la possibilità di correggere il tuo errore a breve termine. Ti ha persino fornito un feedback positivo.

Oltre a quanto sopra, ha detto che ora avrebbe dovuto parlare con il suo capo per decidere cosa avrebbero fatto al riguardo. A quanto pare, si è avvicinato poco dopo a me, chiedendomi se sarei stato in grado di apportare la più piccola modifica possibile al codice per rimuovere la funzionalità, potendo forse bypassare un controllo completo del controllo di qualità e salvare la nostra finestra di rilascio. Ho immediatamente spinto una modifica di una riga che ha rimosso la funzionalità, mostrandogli il codice che ho modificato per farlo. Mi ha ringraziato , ma non ho più parlato con lui da (oggi).

Una piccola nota tecnica a margine:

Ho pensato che con la mia bacheca "passcode" nessuno l'avrebbe visto accidentalmente.

Esamina la funzione di commutazione corretta. Molti framework lo supportano. Eseguito correttamente, questo ti aiuterà a disabilitare rapidamente le funzionalità difettose dal vivo mentre risolvi il problema sottostante e questo errore potrebbe benissimo essere un punto di svolta per il tuo team software.

Sfortunatamente, molte volte il mio capo e il mio direttore vedranno una caratteristica parzialmente completata (da me o da un altro sviluppatore) o ascolteranno un'idea descritta verbalmente e rifiuteranno la caratteristica o la funzionalità, a causa di ciò che ritengo sia una mancanza di visione per che caratteristica potrebbe essere nella sua forma finale. Quando invece ho preso l'approccio di presentare loro qualcosa di più raffinato, è quasi sempre approvato. Di recente abbiamo discusso di una funzionalità come quella in questione, quindi ho impiegato un'ora di lavoro per ottenere solo la funzionalità approssimativa, da utilizzare come dimostrazione.

Questo qui è uno dei miei più grandi punti deboli (non completare le idee abbastanza spesso). Riconosci questa debolezza e scopri come combatterla. Sforzati di non lavorare su nuove cose eccitanti finché non avrai risolto un certo numero di problemi non risolti.

Infine, chiedi un incontro con il tuo capo e dì che ti piacerebbe parlare. Poi spiega come lavorerai per non ripetere questo tipo di errore. Fai un elenco di punti utilizzabili (ad esempio): - esamina la commutazione delle funzionalità - esamina il completamento del lavoro sui problemi prima di inviarlo - Ricordati di parlare anche dei tuoi sentimenti (insicurezza sul tuo lavoro). Qualsiasi persona buona e comprensiva (presumo lo sia il tuo capo) sicuramente non ti riterrà responsabile per essere insicuro dopo aver commesso un errore.

Buona fortuna!