Come evitare di saltare a una soluzione quando si è sotto pressione? [chiuso]

Ricordo di aver letto uno studio sul modo in cui gli artificieri formano un piano d'azione all'arrivo sulla scena di un incendio; lo studio ha osservato (e li ha condannati) per aver avuto un'idea, quindi ha cercato immediatamente quella prima idea. A causa della pressione del tempo, era praticamente "questo potrebbe funzionare" seguito da "ok, facciamolo". Lo studio ha rilevato che erano disponibili opzioni migliori, più rapide e più sicure, ma non sono state seguite semplicemente perché i marshall non hanno pensato prima a loro.

Se vuoi un approccio strutturato per affrontare gli "incendi", prendi una foglia dal loro (nuovo) libro che prescrive diverse fasi:

R.R.A.P.I.D.

1. Reaction - Mobilize resources to incident
2. Ricognizione: raccogli dati sulla situazione
3. Apprezzamento: scegli una linea d'azione basata sugli scenari dei casi migliori e peggiori
4. Pianifica - sviluppa un piano basato sul corso dell'azione
5. Emissione di ordini - Utilizza il formato di briefing standard
6. Distribuzione - Esegui e monitora

o in termini più generali:

1. Riattiva tutti e fatti spostare
2. Scopri cosa sta succedendo
3. Soluzioni di brainstorming
4. Scegline uno e programmalo
5. Dì a tutti qual è il loro lavoro
6. Esegui e monitora

Comincio sempre a comprendere i requisiti ea cercare lacune in essi che richiedono risposte.

Quindi disegno (molto approssimativamente e su carta o lavagna) due o tre soluzioni possibili. Quindi mi chiedo: "C'è qualcos'altro che devo sapere per implementare qualcuno di questi?"

Una volta che ho le mie domande iniziali (ci sono domande il 100% delle volte, se non ne hai nessuna, non hai davvero approfondito il requisito in profondità), torno alle parti interessate per ottenere le mie risposte.

Mentre indago sulle loro risposte, considero le mie soluzioni e vedo se alcune sono migliori delle altre o sarebbero migliori una volta ottenute le risposte alle domande. Ad esempio, se la domanda di cui hai bisogno è immediata, potrei scegliere quella con lo sviluppo più veloce, ma lasciare aperto un modo per migliorare il design in un secondo momento. Se mi dicono che le prestazioni sono critiche, allora guardo le soluzioni e stabilisco quale è più probabile che funzioni meglio (queste sono ipotesi a questo punto, ma generalmente quelle informate). Se è coinvolta una GUI, potrei inventare un prototipo cartaceo di diversi disegni diversi e convincere gli stakeholder a guardarli prima che io codifichi qualsiasi cosa (di solito vedranno che si sono dimenticati di dirti di XYZ che è qualcosa che è centrale per il disegno!)

Una volta ottenute le mie risposte, scelgo un progetto approssimativo e quindi faccio un elenco di tutte le cose che dovrò fare per implementarlo. Quindi inizio la codifica.

...my tendency is to jump into coding without a real plan and hope I figure it out as I go along.

L'ho fatto mentre ero all'università. È diventato un problema reale e in genere comportava la riscrittura del codice. Ho iniziato a parlare di questo non scrivendo il codice. Ho posto l'accento sul pensiero sul problema. Con abbastanza pratica, istintivamente raggiungo i miei pensieri piuttosto che una tastiera.

...in an interview it's been pretty unsuccessful, if not downright counter-productive. I'm not always comfortable sitting there thinking while the clock ticks away.

In un'intervista, deve esserci un'implementazione ragionata e ben pensata per una soluzione e non sempre è facile. Quello che non vuoi fare è sputare fuori le risposte senza pensare. Se conosci la risposta, dammela velocemente. Se non lo fai, affidati ai tuoi pensieri per ragionare su una soluzione. Sempre indica quando non sai e dimostri come faresti per trovare una soluzione.

Is there a checklist or are there techniques to recognize when you understand the problem well enough to start coding?

Scorporò questo perché potresti fare affidamento su di esso rigidamente. Piuttosto, chiediti se hai capito bene il problema abbastanza da iniziare a programmare. Come lo sapresti? Perché quando ragionate sul vostro approccio e poi lo esaminate, data la vostra attuale conoscenza della lingua, avrà senso. Avere sempre un piano e un approccio Ricorda inoltre che il codice non è mai terminato e il codice che non si è evoluto morirà quindi ti preghiamo di tornare spesso al tuo codice.

When is it most productive to think and design more vs. code some experiments and figure out the over-all design later?

Dovresti conoscere il design generale e pensarci. Quindi inizi a creare la struttura della classe e gli stub. Quindi rivedi di nuovo. Ha senso? Gli esperimenti di codifica sono un ottimo modo per dimostrare che qualcosa funziona bene e devono essere utilizzati, ma non per fare affidamento sulla moda o sulla forma del codice che scrivi.