Progettare i difetti e affrontare l'umiliazione da esso [chiuso]

Una volta, il vp di una fortuna 500 costava all'azienda 1 milione di dollari con una decisione commerciale sbagliata. Quando ha consegnato le sue dimissioni al C.E.O la risposta che gli è stata data è stata: "Ho appena investito un milione di dollari nella tua istruzione e ora stai cercando di andartene? Non accetto."

Mi stanco di manager e altri lavoratori che sono pronti a dare la colpa a un errore su qualcuno che è un novellino o che si assume che siano incompetenti. C'è solo un modo per diventare un buon designer e questo è a f @ $% un po 'su. Non mi interessa se i miei dipendenti commettono un errore, mi interessa se fanno lo stesso più volte. La domanda è: quanto sei umile e insegnabile? Quando qualcuno ti presenta il tuo errore, ti difendi prima o ascolti? Se sei uno dei rari ragazzi che può ingoiare il suo orgoglio e imparare da esso, allora ne vale la pena. Chiunque tu abbia perso il rispetto per aver commesso un errore una volta, non è qualcuno che merita il tuo rispetto.

Personalmente ho dovuto riscrivere i primi due progetti che ho progettato almeno due volte, ma sai una cosa? Ho imparato una tonnellata e, sebbene i miei datori di lavoro fossero perturbati in quel momento, ciò è stato rapidamente compensato dall'efficienza che ho guadagnato nel tempo essendo disposto a imparare dai miei errori.

Per quanto riguarda l'aspetto dell'umiliazione e come recuperare, ho due consigli. Primo, la gente dimentica nel tempo. Inoltre, quando qualcun altro ha i riflettori su di loro, si rovinano anche loro. Allora tutto sarà uguale di nuovo. Secondo, non essere uno stronzo per gli altri quando fanno onestà, apprendimento, errori. In realtà, dovresti incoraggiarli a meno che non abbiano davvero bisogno di un calcio nel culo. Puoi nel tempo aiutare a cambiare la cultura della tua squadra ricordando come ti sei sentito quando hai fatto un errore onesto. Alla fine ispirerai le persone a diventare migliori programmatori, designer e esseri umani.

Lo faccio da molto tempo (più di 15 anni) e non riesco ancora a farlo bene la prima volta. I migliori design escono da un processo iterativo e collaborativo. Quando lavori per un po 'su un progetto, è facile rimanere intrappolati nel pensare che sia l'unico modo per farlo. Una nuova prospettiva è utile per vedere le cose che ti mancano.

Affinché ciò funzioni, il team deve fidarsi l'uno dell'altro. Non si può avere paura di mostrare alle persone un design che potrebbe essere imperfetto e devono essere in grado di accettare le critiche al design. A sua volta, il resto del team ha bisogno di capire che i difetti di un design non sono una riflessione sul designer. È una parte prevista del design. È anche il modo in cui i membri del team imparano e migliorano: dai propri errori e dagli errori degli altri.

Se sei in una squadra disfunzionale che non funziona in questo modo, hai due opzioni:

1. prova a correggere il team
2. trova una nuova squadra (internamente o presso un nuovo dipendente)

Per quanto ne so, sono sempre stato fondamentalmente difendibile . Non è esattamente la stessa cosa che fondamentalmente correggere . Spesso le circostanze cambiano tra il momento in cui devi prendere la decisione 'x' e il tempo in cui diventa chiaro che 'x' era la decisione sbagliata con il senno di poi .

È un po 'come preparare le tasse sul reddito degli Stati Uniti. Molte persone pensano che ci sia una risposta. Non c'è. Hai la tua opinione; il tuo commercialista ha la sua opinione; l'IRS ha la sua opinione.

Quando commetto errori, non perdo il rispetto di nessuno. (Per quanto ne so.) Penso che sia perché, in parte, ammetto sempre i miei errori. (In effetti, trovo spesso trovare i miei stessi errori.) Inoltre, quasi tutte le decisioni importanti relative al design hanno più di una persona che vi firma. Qualsiasi errore in quelle decisioni è di proprietà del gruppo, non interamente da una singola persona.

Per quanto riguarda l'ammissione degli errori, penso che diventi più facile man mano che acquisisci competenza ed esperienza. Nella mia esperienza, più sei nuovo nella progettazione e nello sviluppo, meno è probabile che tu debba ammettere un errore.

Succede di tanto in tanto, e non dovrebbe far deragliare la tua carriera. Nessuno in una posizione di responsabilità significativa invariabilmente prende decisioni corrette. Di fatto, nessuno in una posizione di responsabilità significativa invariabilmente prende decisioni difendibili.

Ma la maggior parte delle volte, dovresti essere in grado di prendere decisioni difendibili sulla base di informazioni incomplete. Come direbbe mia figlia, "Questo è solo essere persone."

A volte capita che qualcosa non va. Gli errori sono inevitabili. Ammetti liberamente quando hai torto, impara dai tuoi errori e mostra umiltà, soprattutto se inizialmente non sei stato convinto di aver sbagliato.

"Umiliazione" non dovrebbe mai, mai accadere. È improbabile che migliori le prestazioni di una persona.

Qui nella mia azienda abbiamo sviluppato una cultura del rispetto per quelle persone che sono ancora disposte a prendere decisioni difficili, ma possono ammettere di sbagliare e adattare il loro comportamento quando necessario.

Have you always been fundamentally correct in the software designs you proposed?

Sì, sono un superumano! Beh, certo che no.

When you give out some design that was fundamentally wrong, you tend to lose the respect of your fellow team members.

No! Se ciò accade, allora c'è qualcosa di sbagliato nello spirito di squadra.

Tutti commettono errori. Alcune soluzioni si rivelano buone, alcune cattive, più una via di mezzo. Sia i successi che i fallimenti dovrebbero essere presi come una lezione, da te e dal resto della squadra.

I primi errori potrebbero essere spiacevoli, ma dopo aver realizzato centinaia di questi, è proprio come parte del lavoro.

Succede a tutti. L'importante è imparare dai tuoi errori e cercare di non farlo accadere di nuovo. Inoltre, assicurati di ammettere che è stato un errore da parte tua. Ad esempio, una volta ho commesso l'errore di utilizzare un Data Access Layer inferiore (SubSonic3). All'epoca in cui ho preso la decisione, volevo solo allontanarmi dalle query SQL create a mano. Quindi ho scelto quello che al momento sembrava uno dei più facili da iniziare. Neanche io avevo troppa esperienza con i DAL. Bene, dopo aver risolto alcuni problemi mi stavo chiedendo perché alcune query stessero prendendo un po 'troppo tempo e ho scoperto che SubSonic stava abbattendo interi tavoli senza una buona ragione.

Quindi, ho detto al mio capo, ho spiegato che ho fatto un errore e gli ho dato il mio piano per sistemarlo. Ovviamente il mio capo non era entusiasta di me per aver commesso un errore piuttosto grande che richiedeva alcuni giorni di pura migrazione. Ma si è anche assicurato di non aver fatto di nuovo lo stesso errore. Mi ha fatto creare un progetto di proof-of-concept per il prossimo livello di accesso ai dati che ho proposto di migrare e ci siamo assicurati che avrebbe funzionato con i nostri requisiti, e che non avesse tirato giù interi tavoli. Tutto sommato, è stata una buona esperienza di apprendimento per me e ora assicurerò che una parte fondamentale del progetto soddisfi i requisiti e non abbia grossi problemi.

Quindi in pratica quello che fai è questo:

1. Accetta di aver fatto un errore
2. Crea un piano per risolverlo
3. Assicurati che il tuo piano funzioni effettivamente
4. Assicurati di nuovo.
5. Risolvi!

Se non sei sicuro di come aggiustarlo, non aver paura di coinvolgere altri membri del team.

Un'ultima cosa, rilassati! Tutti fanno degli errori. Pochissime persone lo rendono perfetto la prima volta

Questa è una roba da competizione per i pazzi, e non è una buona situazione. Nessuno ha sempre ragione, e non c'è niente di cui vergognarsi se qualcuno si presenta con un modo migliore per farlo, o se trova un problema con il modo in cui l'hai fatto.

Devi liberarti emotivamente dalla tua soluzione e passare il tempo a cercare la soluzione migliore , quindi puoi essere soddisfatto quando il problema viene risolto, anche se è risolto da qualcun altro.

C'è molto che non stai dicendo nella tua domanda. Non posso dire quale sia la tua impostazione per "dare un disegno". È la discussione iniziale con un peer sul tuo approccio pianificato o è la consegna di quello che speri sia il codice finale?

Se il primo, allora non c'è motivo di sentirsi male e nessun motivo per i tuoi pari di sospettare di te in futuro.

Se stai aspettando la consegna finale per discutere del tuo progetto con qualcun altro, allora non li biasimo per essere sospettosi del tuo altro lavoro.

Tutti devono discutere del loro design con qualcun altro. A seconda della complessità o della criticità, potrebbe essere necessario discuterne con più persone più volte. Tutti possono commettere un errore, fraintendere un requisito o perdere un caso speciale.

Gli errori identificati in anticipo sono più facili e meno costosi da risolvere. Dovrebbero essere molto perdonabili a meno che non si ripetano gli stessi errori più e più volte. Le recensioni tra pari rendono più facile cogliere gli errori in anticipo.

Se stai cercando di essere un programmatore solitario in un ambiente di squadra, stai commettendo il (quasi imperdonabile) peccato di pensare che sei abbastanza perfetto da non aver bisogno dell'aiuto di nessun altro. Il fatto che si tratti di un ambiente di squadra dimostra che il problema è abbastanza grande che nessuna persona capirà tutto. Le persone devono parlarsi o gli errori alleggeriscono le loro brutte teste troppo vicino al rilascio (o dopo il rilascio).

Ho sempre operato una distinzione tra, da un lato, decisioni buone o cattive; e dall'altra le decisioni corrette e sbagliate. Una buona decisione è quella che, nelle stesse circostanze, con le stesse informazioni, faresti allo stesso modo; una decisione sbagliata è quella che faresti diversamente. Una decisione corretta è quella che, con il beneficio del senno di poi e di ulteriori informazioni, dimostra di essere stato corretto; e viceversa con decisioni sbagliate.

È stato spesso detto che la persona che non prende decisioni sbagliate non fa mai nulla. Le decisioni sbagliate sono il modo in cui si impara. Le decisioni sbagliate sono spesso esacerbate perché il decisore si investe nella decisione e cerca di giustificare retrospettivamente la decisione, o dimostrare che è stata una buona decisione dopo tutto (la copertura è sempre più dannosa della decisione originale).

La maggior parte delle decisioni progettuali che ho preso si sono rivelate corrette, ma ho imparato di più e ho fatto progressi con quelle decisioni che erano sbagliate. Spero che pochissime delle mie decisioni siano state decisioni sbagliate, ma parte del problema con le sue decisioni sbagliate è riconoscere che una decisione era sbagliata e accettare le lezioni spesso sgradevoli che ne derivano.

Fintanto che non sono " Monday Morning Quarterback ." Non ho alcuna utilità per qualcuno che partecipa a tutte le discussioni sul design senza dire nulla solo per affermare di sapere che non avrebbe funzionato dopo il fatto. Devi essere in grado di criticare anche se non è inserito in un contesto costruttivo.

Probabilmente una delle migliori caratteristiche del sito SO è quella di essere in grado di correre il rischio e proporre soluzioni incerte. Questo è il modo in cui impari. Attraversare la vita con un sacco di schifezze nella tua testa è sbagliato, ma non ti è mai stato detto che il gioco è vero ignoranza.

Potrebbero sapere qualcosa che non conosci, ma non sapranno tutto. Passa oltre, mettiti al lavoro e fai qualcosa. Lascia perdere tempo pensando che siano così maledettamente intelligenti.

Ho sempre fornito un buon design? No! Mi sforzo di farlo, mi sforzo di migliorare, ma con ogni progetto successivo, quello che posso apparentemente sempre fare è guardare indietro a quello che ho fatto prima e rabbrividire su come ho mancato il marchio in in qualche modo.

Per quanto riguarda qualcuno che ha proposto un design meno che stellare, non lo terrei contro quella persona se quella persona dimostrasse di essere stata disposta a imparare dall'errore e fosse aperta alle critiche. Se vedo prove che la persona sta tentando allo stesso modo di migliorare e ha l'attitudine a farlo, allora una cattiva proposta di progettazione è solo un'opportunità di apprendimento.

Succede a tutti di tanto in tanto, quindi la cosa migliore da fare è capire perché il design era sbagliato e imparare da quello. Se si tratta di una mancanza di conoscenza, si spera che il fallimento del progetto ti dia qualche nuova conoscenza che puoi usare la prossima volta. Non lasciarti scoraggiare, tutti lo affrontano ad un certo punto. È il modo migliore per acquisire esperienza e catturare con un nuovo team / ambiente.

Questo succederà spesso. Il nostro settore sta cambiando così rapidamente, le possibilità di non sbagliare sono effettivamente pari a zero.

Tuttavia, hai spinto il cattivo disegno verso il basso per le loro obiezioni? Questo potrebbe essere il motivo per cui stanno esagerando.

Se l'errore è stato enorme, ovviamente ci vorrà del tempo per riguadagnare il rispetto. Se uno dei tuoi colleghi ti ha preso in cattiva direzione e ha creato problemi per tutta la squadra, non avresti bisogno che si dimostrasse più a breve termine?

Tutto quello che puoi fare è ammettere che hai torto, dare credito a chi ha ragione e sforzarti di ascoltare meglio e opzioni di ricerca migliori in futuro.

Cosa non hai considerato che abbia reso il design un errore? (Esempio non casuale: progettare un processo di importazione per utilizzare il servizio Web esistente che viene eseguito riga per riga (riutilizzo del codice e la sola necessità di modificare le regole aziendali in un unico punto) senza rendersi conto che alcune importazioni avranno milioni di record e richiederebbero giorni per fine.) Impara da esso e considera queste cose in futuro.

Ci saranno sempre errori. Errare è essere un programmatore. Continua a imparare dagli altri su Internet e in particolare dai tuoi colleghi. L'unica vergogna qui sarebbe nel rinunciare, o seppellire la testa sotto la sabbia quando si tratta di problemi come questo da qui in avanti.

Mettilo dietro di te, metti giù la testa e fai del tuo meglio. Se sei un buon programmatore, risplendi dei tuoi errori.

Se non sei sicuro che la tua idea si basi su solide basi, dovresti discuterla con alcuni colleghi fidati prima di proporla all'intera azienda o al dipartimento. In effetti, anche se SIA sicuro, dovresti comunque discuterne con le persone con cui lavori e con maggiori probabilità di conoscerti meglio. Ti aiuteranno a individuare subito i problemi.

Succede a tutti noi a volte. Usa il primo design come prototipo. Scopri esattamente cosa ha funzionato e cosa non ha funzionato e perché. Quindi puoi scrivere un prodotto finale molto migliore.

Non cercare di giustificarti o mettersi sulla difensiva. Ammetti l'errore e vai avanti.

Il problema fondamentale non sembra essere spiegato: questo è un problema social . Puoi vedere un comportamento simile in quasi tutte le professioni: se commetti un errore e gli piace "categorizzarti" in una certa roba, è per sempre. È un comportamento sociale. Anche le persone intelligenti e intelligenti tenderanno a seguire tutti.

Permettetemi di darvi un esempio che non ha nulla a che fare con la programmazione: nel mio precedente lavoro, avevo dimenticato di lavare i miei piatti dire una o due volte. Da allora, tutti i lavoratori hanno pensato che fossi il tipo di uomo che non lava mai i miei piatti. E ora non appena c'è una cosa sporca nel lavandino, sono io (chi altro potrebbe essere).

È la stessa ovunque: questo è un comportamento social , indipendentemente dal tipo di problema che potrebbe essere.

Mi dici che vuoi un feedback sincero? L'unica soluzione è uscire per un altro lavoro. Se tutta la gente della squadra pensa che tu non sia bravo nel tuo lavoro, non cambierà molto presto, mi dispiace dirlo in questo modo. Quindi cerca un altro lavoro, perché non cambierai mai questo tipo di comportamento (stupido devo confessarlo) social .

La chiave è come affermi il tuo caso e che tipo di modifiche fai. Se dichiari di essere un guru della programmazione che non ha torto ed è più fantastico di Jon Skeet, allora è abbastanza probabile che a un certo punto sarai preso per questo. La chiave è come presentate le vostre soluzioni in modo da essere in grado di dimostrare che questa è una soluzione ragionevole al problema piuttosto che la soluzione perfetta che non dovrebbe nemmeno essere controllata.

Il mio miglior esempio sarebbe scoprire gli effetti collaterali di una classe essere static in un'applicazione web in cui ho lavorato una volta. Non sapevo quanto sarebbe stato male mantenere quell'istanza ed essere condivisa tra tutti gli utenti dell'applicazione, ma ho imparato da essa e ho recuperato in tempo. A volte può succedere che qualcosa venga trovato e che vengano fatte correzioni importanti. Anch'io sono stato in quel campo dove ho dovuto setacciare un sacco di VBScript per ridurre le concatenazioni di stringhe che stavano causando problemi di memoria in cui lavoravo una volta. Riesco persino a ricordare di scrivere codice vulnerabile alle iniezioni SQL nel 1998, quando stavo scrivendo una ricerca di una parte di codice cliente che doveva generare dinamicamente l'SQL poiché avevo ~ 20 campi facoltativi in quella parte dell'applicazione.

Il perfezionismo può essere un po 'un'arma a doppio taglio qui, che è il modo in cui vedo quel terzo commento oltre ad essere un modo in cui lo sono anche io a volte. Il male sta vedendo che ci sono tutti questi errori e nulla è mai giusto. Il bello è che nel prendere il meglio che puoi, potresti incontrarti se non superando le aspettative degli altri nei tuoi confronti. Il miglioramento continuo potrebbe essere il modo per vedere il perfezionismo e, se mantenuto con moderazione, lo vedo come una buona cosa. Per tutti gli errori commessi, il tuo codice entra in produzione? Ha fatto il lavoro? Questi sono i punti su cui riflettere, come se qualcuno ci aggiustasse sempre qualcosa o è bello che tu voglia essere così bravo che preferiresti non ottenere qualcos'altro prima che sia perfetto? La pratica può essere utile per aiutare a trovare gli schemi per fare meglio il lavoro. Tuttavia, c'è qualcosa da dire per comprendere l'analisi costi-benefici al ritorno per apportare piccole modifiche quando ci sono altri incendi da gestire per primi.