Come gestisco la paralisi dell'analisi?

Due semplici regole:

1. Fai la cosa più semplice che possa funzionare.
2. Refactor continuamente.

Quando inizi a fare ognuna di queste cose, acquisirai la certezza che ora puoi prendere decisioni semplici senza compromettere la tua capacità di rispondere ai cambiamenti più tardi.

Ricorda che la verifica futura rende il codice facile da modificare, non tentando di anticipare ogni possibile modifica del codice.

Di solito quando mi sento in quel modo significa che devo provare:

1. Alzati, cammina e assicurati che tutta la biologia funzioni correttamente.
2. Passa a una lavagna e disegna fino a quando non provo una sensazione di sicurezza.
3. Trova un "compagno di lamentele sul design" con il quale puoi semplicemente risolvere il problema.

Se il problema riguarda sintassi e piccoli pezzi, allora:

1. Soddisfa te stesso che, anche se è brutto, è graziosamente incapsulato da qualche parte e rappresenta un tipo di cruft puramente locale.
2. Aggiungi marcatori TODO o solo commenti che spiegano perché il codice ti blocca.
3. Passa alla prossima attività.

È molto facile pensare di rimanere inattivo. Anche se in qualche modo riesci a trovare la soluzione migliore adesso che potrebbe facilmente cambiare prima di completare il progetto, e poi?

È meglio scegliere una soluzione decente e correre con essa, piuttosto che sedersi e dither su quale sarebbe la soluzione migliore . La soluzione migliore è sfuggente e peggio, soggettiva. Se i requisiti cambiano anche leggermente, la tua soluzione potrebbe rivelarsi peggiore di una soluzione che hai scartato perché non era la migliore al momento.

Sto imparando anche a evitare la paralisi dell'analisi, quindi complimenti per noi =) Ciò accade spesso perché vogliamo fare il "miglior design". In realtà, "migliore" è negli occhi di chi guarda . La mia formula per evitare la paralisi dell'analisi consiste nell'applicare il principio design abbastanza buono . Come lo faccio? Conduco variabili come i limiti di tempo, programma e mi chiedo quale sia il design più semplice che può portare a termine il lavoro (questo non significa il più semplice) senza compromettere la qualità, ma allo stesso tempo, mi assicuro che sia un testabile e un aperto per estensione chiuso per modifica (OCP) design pure. Cosa intendo per testabile e OCP? Beh, invece di cercare ciò che considero migliore, ho considerato un design che può dirmi quando le cose vanno male e provare a fare quel codice che mi permette di rifattorizzare e migliorare in seguito. Inoltre, prova a separare il codice che cambierà con il codice che rimane invariato. Il refactoring diventa più semplice, perché il codice che non dovrebbe cambiare è più sicuro dal tuo futuro tu o qualcun altro.

Che ne dici di lasciare che il tuo istinto decida per una delle opzioni? Dovrebbe andare piuttosto veloce e combinarsi bene con timebox , che ammoQ anche proposto . Puoi provare un limite di 1 minuto se le opzioni sono già stabilite o 2 minuti se devi definirle per prime. O tutto ciò che sembra appropriato (definito in anticipo). Quando impari ad ascoltare il tuo istinto istintivo, la tua scelta intuitiva diventerà più veloce e migliore con la pratica .

Nel caso in cui sei tormentato da preoccupazioni riguardo alla possibilità di scegliere non perfettamente, ecco alcuni pensieri per affrontarlo:

• Se ci fosse un'opzione con un vantaggio chiaro sugli altri, non ti chiederei quale scegliere. Quindi, con questo ragionamento, ogni volta che non siete decisi a proposito di una scelta su una questione non troppo complicata, ciò indica che le opzioni sono tutte in tutto uguali; quindi non c'è molto da perdere semplicemente optando per uno qualsiasi di essi.
• Detto questo, l'intuizione non è affatto casuale, ma una bella ipotesi buona e istruita per la soluzione ottimale. Spesso migliore di quello che si potrebbe ottenere con un infinito frugare.
• Approfittando del perfezionismo, si potrebbe valutare la rapidità della decisione più alta dell'ottimalità della scelta quando si valuta in modo semi-cosciente la propria performance. Che ha perfettamente senso con scelte poco importanti, ma non è banale da ricordare.

Buona fortuna! :)

Penso che vada via con una piccola esperienza. La maggior parte della mia paralisi accade perché cerco di immaginare quale sarà il codice base molto più avanti di quello che mi serve per superarlo. Faccio solo la cosa più semplice possibile che funzionerà e poi andrò avanti. Una volta che il progetto ha una forma definita, le unità di codice ripetitive iniziano a risaltare ed è abbastanza semplice astrarre i pattern ripetitivi e semplificare il codice.

Per superare la tua riluttanza a decidere, applica timebox : imposta una sveglia partire in pochi minuti; tormenta la tua mente fino ad allora, ma quando scatta la sveglia, scegli l'opzione migliore che hai trovato fino ad allora.

Crea un prototipo. Ricorda, un prototipo è fatto per essere gettato via, quindi non importa quali funzioni, nome di variabile o anche grande architettura che usi. Lo stai solo costruendo per dimostrare che funziona.

Una volta creato e buttato fuori, sarei disposto a scommettere che avresti un tempo più semplice per prendere quelle decisioni.

Anch'io soffro di questo problema. Quello che vorrei dire è che non hai abbastanza incentivi al completamento.

Ad esempio, quando stavo scrivendo il codice di rendering, allora avevo un grande incentivo al completamento perché sapevo che se avessi continuato, avrei visto il sistema in azione e pensare a quanto ero fantastico per il texturing un quad, o trasformare un vert. Ma ora che sto ri-factoring (tentativo 4, se ti piacerebbe saperlo) allora sto soffrendo perché è un sacco di lavoro e anche se finisco, vedrò lo stesso vecchio quad. E davvero non voglio più rifattorici e sono stufo di vedere lo stesso vecchio quad più e più volte, e non è più una ricompensa per me.

Devi abbatterlo in componenti e premiarti per averli ultimati, anche se è solo con alcuni i / o della console che mostrano che funziona.

Stavo leggendo la tua domanda e pensando le cose lungo la linea degli altri poster: non sei adatto a questo lavoro; concediti un limite di tempo; fai qualcos'altro per un momento. Dopo qualche riflessione, non sono sicuro che nessuna delle risposte sia davvero così utile

Il problema con problemi mentali come questo è che non sono facili da risolvere, sono parte di te, e ovviamente ti preoccupi (forse troppo) del tuo lavoro, non avere la sicurezza di essere d'accordo con te stesso , sono troppo inesperto per ritenere che la prima scelta sia stata giusta, o lo stress troppo per farlo perfettamente. Perché altrimenti ti preoccuperesti di queste banalità?!

Ora ho problemi simili, ma non con il codice così tanto .. di solito è cosa per cena .. pizza o curry .. hmm ... pizza ma poi curry è bello, ma mi sento come un curry, la pizza costa meno, ma poi ottieni più curry, ma ... e così via. :)

Quindi ho pensato - perché non ho problemi simili con la codifica, e penso che sia semplicemente perché ho una serie di schemi che uso regolarmente. Se ho bisogno di una definizione di funzione, è facile .. sarà nella stessa vena di ogni altra definizione di funzione che abbia mai codificato. Se ho bisogno di un flusso di controllo, prima decido se ho bisogno di un ciclo for o di un ciclo while e quindi di creare lo stesso vecchio codice che ho usato l'ultima volta ho avuto bisogno di una di queste cose. Lo stesso vale per tutto, voglio una coda? Certo, lascia andare il mio codice di coda "standard" (recuperato dall'ultimo progetto su cui ho lavorato, o qualcuno che riesco a ricordare usando una di queste cose). Risultato finale ... Mi preoccupo solo di cose nuove, e ad essere onesti, è un piacere.

Quindi, il mio consiglio è di iniziare a costruire una libreria di frammenti di codice - li ho mandati per email a me stessa e li ho messi in una cartella ma qualsiasi cosa con cui lavori è la migliore - e poi inizierai a sapere cosa fare ogni volta . Andrai sempre al vecchio codice che hai scritto e risolvi il problema, pronto per il prossimo problema. Scoprirai che diventi uno sviluppatore molto più veloce (seriamente, questo è l'unico modo per ottenere la produttività del programmatore) e spero che troverà il tempo per i pezzi divertenti, non per il rozzo lavoro quotidiano che hai già risolto molte volte sopra.

Naturalmente, anche l'ultima parte di tutto ciò è importante: più lavoro hai, meno lusso hai a disposizione per pensare.

Ecco una strategia che combina i suggerimenti di Rein Henrichs ( start simple, refactor ) e ammoQ ( timeboxing ):

1. Concediti un limite di tempo piuttosto rigoroso per una prima soluzione che funziona correttamente. Per esempio. 30 secondi per un nome variabile. Per prima cosa potresti trovare qualcosa come x , quindi perfezionarlo in string , quindi name fino al termine del tempo.
2. Quindi procedi con altre attività per un periodo di tempo specificato, ad es. 10 minuti.
3. Solo allora consenti a un altro intervallo di tempo per migliorare ulteriormente la tua decisione, ad es. a userHandle

Possibili vantaggi di questo approccio:

• la conoscenza di tornare indietro più tardi può facilitare il lasciar andare del problema per ora
• mentre prosegui con altri compiti, potresti trovare una soluzione soddisfacente senza rovinarti tempo
• aver lasciato andare dopo il passaggio 1 e trovarsi nel flusso del passaggio 2 , potrebbe essere facile mantenere il passaggio 3 molto veloce, mentre vuoi continuare con il passaggio 2, quindi scegli semplicemente una soluzione decente e accettala

Quando ho terminato la ricerca e sono rimasto senza una scelta migliore, mi concedo un limite di tempo (in genere 5 minuti) per sceglierne uno, quindi proseguo con esso . Anche quando ti imbatti in ostacoli, a questo punto, non c'è garanzia, non avresti incontrato un ostacolo uguale prendendo una decisione diversa. Non riesco a pensare a un momento in cui mi sono pentito della mia decisione.

Di solito il motivo per cui non puoi decidere è che la differenza è insignificante o che non hai abbastanza informazioni.

Nel caso a) Impostare un limite di tempo per trovare opzioni ragionevoli da considerare. Non decidere quale ancora. Alla fine del tempo, sceglierne uno (a caso se non c'è una chiara preferenza) delle opzioni identificate e un altro limite di tempo. Se non viene presa una decisione chiara alla fine del tempo, il già scelto è. Inizia la codifica e refactoring se hai chiaramente capito male. Se il capo chiede perché, dì "Ho lanciato una moneta, hai un modo migliore?"

Nel caso b) - hai bisogno di più informazioni, e stai seduto sul tuo grosso grasso A .... tutto il giorno non lo fornirà. Esci dalla modalità di progettazione e entra nella modalità di raccolta delle informazioni. Prototipi, porre domande, leggere riviste tecniche. Qualunque cosa tu faccia, non dormire per troppo tempo.

Spesso, la soluzione migliore è provare a spiegare la tua decisione a un collega. Tuttavia, dato che non vuoi farlo molto spesso, la cosa migliore da fare è pensare su carta, con carta / penna o con una finestra vuota per il blocco note.

Inizia scrivendo assolutamente qualsiasi cosa - solo per entrare nel ritmo della scrittura. In una finestra del blocco note puoi semplicemente digitare "Sto pensando sulla carta" e poi continuare semplicemente con un flusso di coscienza. Dopo pochi secondi sarai al ritmo della scrittura, quindi premi Invio alcune volte e inizia a spiegare il tuo dilemma.

Indica il problema, quindi indica le possibili soluzioni, cosa c'è di buono in ciascuna di esse, ecc.

Anche se non sempre funziona, il processo di estrarre pensieri dalla tua testa (RAM) e su media esterni (il documento del blocco note) ti dà più libertà per creare nuove connessioni e visualizzare la decisione da diverse prospettive.

Soffro dello stesso problema. Per piccoli problemi, il modo in cui cerco di affrontarlo è di andare con il primo disegno che penso non sia stupido. Non ha senso cercare di trovare un design ottimale; è difficile se non impossibile ragionare su tutte le sfumature di qualsiasi disegno a cui si possa pensare senza scriverlo. Mentre codifichi, scoprirai che puoi fare piccoli miglioramenti. Fatto bene, trovo che sia abbastanza facile convergere su una soluzione ragionevolmente buona in questo modo.

Per problemi più grandi, penso che ci sia un merito nel pensare prima attraverso le opzioni, ma nel timebox. Grandi problemi hanno grandi spazi di soluzione, non puoi valutare ogni possibilità, né dovresti provarci.

TLDR; Scegli una soluzione ragionevole, migliorala man mano.

Questo è anche rilevante:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

dal link .

Non l'ho mai capito. Quando ero un istruttore, vorrei dire qualcosa del tipo:

"OK, create an integer variable and assign the return value of strlen() to it."

Non troppo complicato, potresti pensare, e il 95% delle persone ha scritto qualcosa del tipo:

int x;   // or y, or len, or whatever
x = strlen( s );

Ma di tanto in tanto qualcuno si sedeva come un coniglio paralizzato dai fari. Chiederei con simpatia quale fosse il problema, e loro avrebbero risposto "non so come chiamarlo!".

Queste sono le persone che dovrebbero cercare un'altra carriera. Come forse dovresti.