Progettare difetti e gestire l'umiliazione da esso [chiuso]

Sei sempre stato fondamentalmente corretto nei progetti software che hai proposto? Quando dai un disegno che era fondamentalmente sbagliato, tendi a perdere il rispetto dei tuoi compagni di squadra. Non importa cosa fai dopo che finirai per essere controllato per tutto ciò che proponi dopo quell'incidente. Questo è particolarmente peggio quando sei nuovo in una squadra e non conoscono il tuo passato in cui hai avuto delle buone storie di successo.

Forse il motivo per cui hai dato un cattivo design è stato a causa della mancanza di esperienza o conoscenza o di entrambi in quella zona. In che modo hai affrontato una situazione del genere? È come una volta nella tua carriera o succede e si accende e si spegne? Uno lo mette dietro o uno in una situazione del genere deve cercare una nuova linea di lavoro? Un feedback onesto per favore ...

Grazie.

Una volta, il vp di una fortuna 500 è costato all'azienda 1 milione di dollari con una decisione commerciale sbagliata. Quando ha rassegnato le dimissioni al CEO, 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 dei manager e degli altri lavoratori che si affrettano a incolpare l'errore di essere un novellino o di presumere che siano incompetenti. C'è solo un modo per diventare un buon designer ed è f @ $% di alcuni. Non mi importa se i miei dipendenti commettono un errore, mi importa se lo fanno più volte. La domanda è: quanto sei umile e capace di insegnare? Quando qualcuno ti presenta il tuo errore, ti difendi per primo o li ascolti? Se sei uno dei rari ragazzi che possono ingoiare il suo orgoglio e imparare da esso, allora vale la pena tenerlo d'occhio. Chiunque perdi 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 disegnato almeno due volte, ma sai cosa? Ho imparato un sacco, e sebbene i miei datori di lavoro fossero turbati all'epoca, 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. Innanzitutto, le persone dimenticano nel tempo. Inoltre, quando qualcun altro ha i riflettori su di loro, anche loro si rovinano. Quindi tutto sarà di nuovo uguale. Secondo, non fare lo stronzo agli altri quando commettono errori onesti, di apprendimento,. In effetti, dovresti incoraggiarli a meno che non abbiano davvero bisogno di un calcio deciso nel culo. Nel tempo puoi aiutare a cambiare la cultura della tua squadra ricordando come ti sei sentito quando hai fatto un errore onesto. Alla fine ispirerai le persone ad essere migliori programmatori, designer ed esseri umani.

Lo sto facendo da molto tempo (15+ anni) e non riesco ancora a farlo bene la prima volta. I migliori progetti nascono da un processo iterativo e collaborativo. Quando hai lavorato su un progetto per un po ', è facile rimanere intrappolati nel pensare che è l'unico modo per farlo. Una nuova prospettiva è utile per vedere le cose che ti mancano.

Affinché ciò funzioni, il team deve fidarsi reciprocamente. Non puoi aver paura di mostrare alle persone un design che potrebbe essere difettoso e che devi essere in grado di accettare le critiche al design. A sua volta, il resto del team deve capire che i difetti in un design non riflettono il 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 fai parte di un team disfunzionale che non funziona in questo modo, hai due opzioni:

1. prova a sistemare la squadra
2. trovare una nuova squadra (internamente o presso un nuovo datore di lavoro).

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

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

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 realtà, ho spesso trovare i miei errori.) Inoltre, le decisioni di progettazione quasi tutti significativi hanno più di una persona che firma fuori su di loro. Eventuali errori in tali decisioni sono di proprietà del gruppo, non interamente di una sola persona.

Per quanto riguarda l'ammissione di errori, penso che diventa più facile man mano che acquisisci competenza ed esperienza. In base alla mia esperienza, più è recente progettare e sviluppare, meno è probabile che si ammetta un errore.

Succede a intermittenza e non dovrebbe far deragliare la tua carriera. Nessuno in una posizione di significativa responsabilità prende invariabilmente decisioni corrette. Di fatto, nessuno in una posizione di significativa responsabilità prende invariabilmente 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 tutti sbagliano. Gli errori sono inevitabili. Ammetti liberamente quando sbagli, impara dai tuoi errori e mostra umiltà soprattutto se inizialmente non eri convinto di aver effettivamente torto.

L '"umiliazione" non dovrebbe mai e poi mai accadere. È probabile che non migliori affatto le prestazioni di una persona.

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

Sei sempre stato fondamentalmente corretto nei progetti software che hai proposto?

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

Quando dai un disegno che era fondamentalmente sbagliato, tendi a perdere il rispetto dei tuoi compagni di squadra.

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

Tutti sbagliano. Alcune soluzioni risultano essere buone, altre cattive, la maggior parte nel mezzo. Sia i successi che i fallimenti dovrebbero essere presi come una lezione, da te e dal resto della squadra.

I primi errori possono sembrare brutti, ma dopo averne commessi centinaia, è proprio come parte del lavoro.

Succede a tutti. La cosa principale è imparare dai tuoi errori e cercare di non lasciare che accada di nuovo. Inoltre, assicurati di ammettere che è stato un errore da parte tua. Ad esempio, una volta ho commesso l'errore di utilizzare un livello di accesso ai dati inferiore (SubSonic3). Al momento in cui ho preso la decisione, volevo solo scappare da query SQL create a mano. Quindi ho scelto quello che all'epoca sembrava uno dei più facili da iniziare. Neanche io avevo molta esperienza con i DAL. Bene, dopo aver risolto alcuni problemi, mi chiedevo perché alcune query richiedessero 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 risolverlo. Il mio capo ovviamente non era entusiasta del fatto che facessi un errore piuttosto grave che richiedeva alcuni giorni di pura migrazione. Ma si è anche assicurato che non avessi commesso di nuovo lo stesso errore. Mi ha fatto creare un progetto di prova del concetto per il prossimo livello di accesso ai dati che ho proposto di migrare e ci siamo assicurati che funzionasse con i nostri requisiti e che non abbattesse intere tabelle. Tutto sommato, è stata una buona esperienza di apprendimento per me e ora sarò sicuro che una parte chiave del progetto soddisfi i requisiti e non abbia enormi problemi.

Quindi sostanzialmente quello che fai è questo:

1. Ammetti di aver fatto un errore
2. Fai un piano per risolverlo
3. Assicurati che il tuo piano funzioni davvero
4. Assicurati di nuovo.
5. Aggiustalo!

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

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

Questa è roba da gara pisciata geniale, e non è una buona situazione in cui trovarsi. Nessuno ha sempre ragione, e non c'è nulla di cui vergognarsi se qualcuno trova un modo migliore per farlo, o se trovano un problema con il come l'hai fatto.

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

C'è molto che non stai dicendo nella tua domanda. Non so dire quale sia la tua impostazione per "dare un design". È una 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 stare male e non c'è motivo per i tuoi colleghi 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 sospettoso del tuo altro lavoro.

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

Gli errori identificati in anticipo sono più facili ed economici da correggere. Dovrebbero essere molto perdonabili a meno che non si ripetano ripetutamente gli stessi errori. Le revisioni tra pari facilitano la rilevazione precoce degli errori.

Se stai cercando di essere un programmatore solitario in un ambiente di squadra, stai commettendo il peccato (quasi imperdonabile) di pensare di essere 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 da impedire a nessuno di capirlo. Le persone devono parlare tra loro o gli errori porteranno la loro brutta testa troppo vicino al rilascio (o dopo il rilascio).

Ho sempre fatto una distinzione tra, da un lato, decisioni buone o cattive; e dall'altra decisione corretta e non corretta. Una buona decisione è quella che, nelle stesse circostanze, con le stesse informazioni, si prenderebbe allo stesso modo; una decisione sbagliata è una decisione da prendere in modo diverso. Una decisione corretta è quella che, con il senno di poi e le informazioni aggiuntive, si rivela corretta; e viceversa con decisioni errate.

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

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

Purché non siano il " Monday Morning Quarterback ". Non ho alcuna utilità per qualcuno che affronta tutte le discussioni sul design senza dire nulla solo per affermare che sapevano che non avrebbe funzionato dopo il fatto. Devi essere in grado di prendere le critiche anche se non sono inserite in un contesto costruttivo.

Probabilmente una delle migliori caratteristiche del sito SO è quella di poter correre un rischio e proporre una soluzione incerta. Ecco come impari. Passare attraverso la vita con un mucchio di merda nella tua testa che è sbagliato, ma non ti è mai stato detto il contrario, è vera ignoranza.

Potrebbero sapere qualcosa che tu non sai, ma non sapranno tutto. Superalo, mettiti al lavoro e fai qualcosa. Lascia che perdano tempo pensando di essere così dannatamente intelligenti.

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

Per quanto riguarda qualcuno che ha proposto un design tutt'altro che stellare, non lo terrei contro quella persona se quella persona dimostrasse che era disposto a imparare dall'errore ed era aperto alle critiche. Se vedo le prove che la persona si sta sforzando allo stesso modo di migliorare e ha l'attitudine a farlo, allora una cattiva proposta di design è 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 l'errore di progettazione ti fornisca alcune nuove conoscenze che puoi utilizzare la prossima volta. Non lasciare che ti scoraggi, tutti lo affrontano ad un certo punto. È il modo migliore per acquisire esperienza e interagire con un nuovo team / ambiente.

Questo accadrà spesso. Il nostro settore sta cambiando così rapidamente, le possibilità di non sbagliarsi sono effettivamente zero.

Tuttavia, hai spinto il cattivo design giù le loro gole sopra le loro obiezioni? Questo potrebbe essere il motivo per cui stanno reagendo in modo eccessivo.

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

Tutto quello che puoi fare è ammettere di aver sbagliato, dare credito a chiunque avesse ragione e cercare di ascoltare meglio e ricercare meglio le opzioni in futuro.

Cosa non hai considerato che ha reso il design un errore? (Esempio non casuale: progettare un processo di importazione per utilizzare un servizio Web esistente che esegue riga per riga (riutilizzo del codice e che necessita solo di modificare le regole aziendali in un unico posto) senza rendersi conto che alcune importazioni avranno milioni di record e richiederebbero giorni fine.) Impara da esso e considera quelle 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 di arrendersi o seppellire la testa nella sabbia quando si tratta di problemi come questo da qui in poi.

Mettilo dietro di te, abbassa la testa e fai del tuo meglio. Se sei un buon programmatore, brillerai dei tuoi errori.

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

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

Non cercare di giustificarti o di difenderti. Ammetti l'errore e vai avanti.

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

Lasciate che vi faccia un esempio che non ha nulla a che fare con la programmazione: nel mio lavoro precedente, avevo dimenticato di lavare i miei piatti 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).

È lo stesso ovunque: questo è un comportamento sociale , indipendentemente dal tipo di problema che potrebbe essere.

Mi dici che vuoi un feedback onesto? L'unica soluzione è uscire per un altro lavoro. Se tutte le persone del team pensano che non sei bravo nel tuo lavoro, non cambierà presto, mi dispiace dirlo in questo modo. Quindi cerca un altro lavoro, perché non cambierai mai questo tipo di comportamento sociale (stupido devo confessare) .

La chiave è come dichiarare il caso e quali tipi di modifiche apportate. Se affermi di essere un guru della programmazione che non fa nulla di sbagliato ed è più fantastico di Jon Skeet, allora è molto probabile che a un certo punto verrai abbattuto per questo. La chiave è come presentare le soluzioni in modo da poter dimostrare che questa è una soluzione ragionevole al problema piuttosto che la soluzione perfetta che non dovrebbe nemmeno essere verificata.

Il mio miglior esempio sarebbe scoprire gli effetti collaterali di avere una classe staticin un'applicazione web dove ho lavorato una volta. Non sapevo quanto male sarebbe che un'istanza persistesse e fosse condivisa tra tutti gli utenti dell'applicazione, ma ho imparato da essa e ho recuperato in tempo. A volte può essere trovato qualcosa e devono essere apportate correzioni importanti. Sono stato anche in quel campo dove ho dovuto setacciare un mucchio di VBScript per ridurre le concatenazioni di stringhe che stavano causando problemi di memoria in cui ho lavorato una volta. Ricordo persino di aver scritto codice vulnerabile alle iniezioni di SQL nel 1998 quando stavo scrivendo un pezzo di codice per un cliente che doveva generare dinamicamente l'SQL poiché avevo ~ 20 campi opzionali in quella parte dell'applicazione.

Il perfezionismo può essere un po 'un'arma a doppio taglio qui, ed è così che vedo quel terzo commento, oltre ad essere un modo in cui sono anche io a volte. Il male è vedere che ci sono tutti questi errori e niente è mai giusto. Il bello è che per ottenere il meglio che puoi, potresti benissimo incontrarti se non superassi le aspettative degli altri su di te. Il miglioramento continuo potrebbe essere il modo in cui il PC vede il perfezionismo e, se mantenuto con moderazione, lo vedo come una cosa positiva. Per tutti gli errori commessi, il tuo codice entra in produzione? Fa fare il lavoro? Questi sono punti su cui riflettere e se qualcuno ci ripara sempre qualcosa o è bello che tu voglia essere così bravo che preferiresti non fare altro fino a quando non sarà perfetto? La pratica può essere utile per aiutare a trovare gli schemi per fare meglio il lavoro. Però,