Motivare te stesso a scrivere effettivamente il codice dopo aver progettato qualcosa [chiuso]

Se la sfida per te è nel progettare e non implementare, forse hai bisogno di un altro fattore motivante:

Se si tratta di un progetto per animali domestici (non per lavoro), in realtà non vedo l'ora di vederlo prendere vita, quindi progettarlo non è abbastanza per me. Quando vieni con i tuoi progetti di animali domestici, qual è l'obiettivo? È per qualcosa che devi usare? Se è così, puoi usarlo come motivazione per implementarlo. Per vederlo funzionare. Per fornire la funzionalità che stavi cercando di uscire da esso.

Hai intenzione di renderlo disponibile per gli altri? Un fattore motivante potrebbe essere vederli beneficiare del prodotto finale. Non ne otterranno l'utilità se è solo in modalità progettazione. E se hai intenzione di commercializzarlo, usa il fatto che nessuno pagherà il tuo progetto per animali domestici mentre è bloccato in modalità progettazione, come fattore motivante.

Quando lavoro per conto mio, ho un approccio più iterativo di quello che potrei fare al lavoro - non mi preoccupo di tutti i dettagli prima di generare qualcosa. Potrebbe richiedere più tempo, ma 1) poiché è solo per me (o per qualcuno che non sa nemmeno che esiste in qualsiasi forma), quindi ho la flessibilità di sperimentare e prendermi il mio tempo. 2) Trascorro un sacco di cicli di refactoring e apprendimento di modi migliori di fare le cose. Sulla mia moneta, figurativamente parlando.

In definitiva, però, non è la vera soddisfazione nel vedere qualcosa prendere vita dal nulla? Questo è ciò che fa per me. Se questo non lo fa per te, a meno che la tua motivazione sia il prodotto finale, allora non sono sicuro di capire perché vuoi lavorare sul progetto per animali domestici. Se progettare è quello che ti succhi, e lo fai al lavoro, sembra che tu abbia già la soddisfazione che stai cercando.

Hai bisogno di prototipazione rapida, a casa.

Quando si applica lo stesso livello di rigore professionale a un progetto personale privato, si ottiene facilmente un eccesso di ingegnerizzazione.

È perfettamente accettabile stabilire uno standard elevato per un progetto personale, ma devi capire che potresti non avere abbastanza risorse (ore di programmazione, oltre alle 8 ore di lavoro quotidiano) per fare progressi nel progetto.

Qual è l'obiettivo più importante nel tuo progetto per animali domestici? Per dimostrare l'utilità di uno dei tuoi approfondimenti? In tal caso, ritaglia il progetto finché non diventa un progetto proof-of-concept . Quindi, utilizza la prototipazione rapida in modo da poter ottenere di più con meno tempo di codifica.

Credo che sia solo io, ma ho il problema opposto. Di solito ho problemi a pensare a tutti i dettagli prima di iniziare a scrivere il codice e ad incappare nei problemi rilevanti. Realisticamente, di solito ho in testa solo un disegno vago quando inizio a scrivere qualcosa. La mia grande sfida è farmi pensare a tutti i dettagli e avere un design in anticipo.

Posso sicuramente identificarmi con questo. Mi piace affrontare la sfida di cose che non ho incontrato, ma ho difficoltà a iniziare a lavorare su tutto ciò che ho già risolto. La cosa più grande che faccio è costringermi a sedermi con l'obiettivo di ottenere X e il funzionamento. Di solito, una volta che vado, finisco per divertirmi e ottenere più del necessario rispetto a quando partecipo in primo luogo, ma se non costringo un obiettivo, malato solo per ore.

Sono anche con te, nel senso che questo succede di più a casa a parte che in ufficio. Non so se le sue più distrazioni, essere bruciato dal lavoro o cosa ...

Sicuramente comprendo la tua frustrazione, come ho già sperimentato prima.

Nonostante temendo alcune fiamme dalla comunità, perché so che questo non è un buon approccio, condividerò il mio approccio per side projects con voi. Tieni presente che questo metodo funziona per me e io lo uso su progetti a medio / lungo termine, non lo farei per qualcosa di piccolo (dato che di solito ho la motivazione di terminarlo in una volta sola).

Prendi l'intero progetto e suddividilo in "pacchetti", ognuno costituito da parti che interagiranno spesso tra loro. Quindi dividi ogni pacchetto in piccoli pezzi (pensa un paio d'ore al massimo) che puoi progettare e codificare.

Idealmente saresti in grado di completare ogni pezzo in qualsiasi momento assegnerai per il tuo progetto parallelo per un giorno, ma ciò non è obbligatorio (dipende dalla persona).

Personalmente, non mi propongo un lasso di tempo stimato per ogni pezzo, perché rimango deluso e demotivato non appena esito una stima, quindi non lo consiglio. Prenditi il tuo tempo ma non impiegare troppo tempo.

Ora ogni piccolo pezzo ottiene tutte le fasi del normale processo di sviluppo, progettazione, test, implementazione e qualsiasi altra cosa tu debba fare. L'idea è di dare a ogni pezzo un buon inizio ma non un tocco finale completo, ancora.

Ciò mantiene la mia motivazione perché so che dopo un paio d'ore di codifica reale di cose noiose avrò più progettazione da fare (gustoso). Non lasciarti sfuggire i tuoi obiettivi, continua a fare quel terribile compito e presto sarà finito.

Dopo aver esaminato tutti i pezzi, guarda il pacchetto. Guarda come funziona, cosa sta facendo, rivedi il pacchetto intero . Sono sicuro che ci saranno cambiamenti e ritocchi, fallo ora. Tieni le informazioni più vitali nella tua mente come ne avrai bisogno quando lavori su tutti gli altri pacchetti. Tieni anche le note, aiutano molto.

Passa attraverso ogni pacchetto e continua a ricordare tutti gli altri che hai fatto prima, in che modo il nuovo codice che stai scrivendo interagirà con le cose che hai scritto una settimana fa? Non aver paura di cercare cose che hai già scritto e magari dimenticato.

Infine, quando non hai più pacchetti, di solito lo lascio andare per qualche giorno, mi concedo una pausa e mi concentro su qualcos'altro.

Normalmente non vedo l'ora di tornare indietro e iniziare ad intrecciare i pacchetti e fare qualche test scherzoso, non c'è molto più codice da scrivere e l'obiettivo è vicino, questa è una motivazione sufficiente per me allora.

Spero che questo ti aiuti con i tuoi sforzi.

Ho sempre trovato che le ipotesi originali non erano valide e più o meno il progetto originale doveva essere modificato sulla base dell'esperienza acquisita durante l'implementazione effettiva.

Se consideri il tuo progetto assolutamente infallibile e perfetto dopo aver disegnato alcune scatole, ma prima di provarlo effettivamente, ti considererei un candidato perfetto per alcune implementazioni di progetto.

La spedizione è una funzionalità. Se non vai per l'intera distanza, sei solo un architetto.

Penso che il problema sia nell'obiettivo sbagliato. Sembra che tu abbia fissato l'obiettivo "sistema di progettazione". E poi lo fai bene, e l'obiettivo è raggiunto. Quindi un suggerimento è quello di impostare un altro obiettivo "implementare il sistema", ma in questo caso è più correlato alla motivazione e al modo in cui lo fai.

C'è un altro modo che ha funzionato bene per me: fissare l'obiettivo iniziale come "consegnare il sistema a utenti specifici" invece di "sistema di progettazione" o "sistema di creazione". In questo modo, non sarai soddisfatto finché gli utenti non avranno qualcosa di prezioso. E lo fai bene sin dall'inizio (compresi i test e altre cose moderne e fantasiose).

Oltre ad essere davvero una questione di motivazione, penso che una parte della soluzione possa essere trovata nel combinare la progettazione e il processo di codifica. È così che lo faccio principalmente. Fondamentalmente si tratta di implementare le basi del tuo progetto quando ci hai pensato, e quindi passare al passaggio successivo.

Ad esempio: se ho progettato le mie lezioni di base, le scrivo ed eseguo alcuni test su di esso. Quindi ho progettato un database sottostante, l'ho configurato e testato. Poi ho i metodi e le funzioni di cui ho bisogno per ottenere tutto dentro / fuori dal database, ci vado sopra. Il test è fatto più facilmente dato che ho già preparato le mie lezioni di base. E quando finalmente arrivo a progettare l'interfaccia utente, ho già un intero set di codice pronto a giocare con.

Ora questo presuppone anche la progettazione in blocchi collegati tramite interfacce. Non conosco la parola cara per questo, dato che non sono un programmatore per educazione, ma tu sai cosa intendo.

Spero che questo aiuti.

Quindi scrivi le tue idee di progettazione, pubblicale (in un blog), fai del tuo meglio per spiegare il problema e la soluzione che hai trovato agli altri.

Un trucco: scrivi la tua spiegazione del design come programma per la scrittura! :) Quindi ti occupi della parte interessante (le tue idee di progettazione), ma in realtà giustifichi con il vero codice che fornisci a fianco.

E pubblica il programma di alfabetizzazione come presentazione delle tue nuove idee agli altri!

Questo sembrerà banale, ma appena iniziato. Probabilmente avrai bisogno di aprire il tuo ambiente di sviluppo, quindi fallo. Probabilmente avrai bisogno di definire ciascuna delle classi nel tuo progetto e scrivere le loro firme del metodo, quindi fallo. Dovrai iniziare a implementare i metodi più importanti, quindi fallo.

Di solito in questo periodo, ho dimenticato che ho avuto problemi a partire, e sono nella zona.

Funziona circa l'80% delle volte. Per il resto, c'è Tetris.

Non è sicuramente solo te! In questo momento sto facendo un progetto.

Nessuno può motivarti tranne te stesso.

Crea una linea temporale realistica e sfidati a completare ogni sezione in tempo. Non hai nulla da mostrare per i progetti se non vengono mai passati alla fase di progettazione.

A giudicare dalla tua domanda, il tuo problema è che sembra che tu stia reinventando la ruota. Se hai già fatto tutto questo, perché hai bisogno di farlo di nuovo? Non esiste una struttura per farlo per te? In caso contrario (anche se questo piuttosto improbabile), perché non scriverne uno?

Un compito chiave nella programmazione è non fare cose noiose da capo , ma farlo una volta, facendolo correttamente e quindi riusarlo. O ancora meglio: trovare qualcuno che lo ha già fatto una volta e correttamente.

Capisco perfettamente da dove vieni. È il problema che ti interessa e, una volta capito, l'implementazione funziona.

Perché non architetti la soluzione e altri la implementano?

Le cose che faccio:

• Metti un grande timer davanti a me (può essere in modalità inversa, in blocchi di 1 ora)
• Costringermi a rimanere sveglio fino a raggiungere un obiettivo (a volte con una birra, ho trovato che un po 'di alcol aiuta)

Non sempre funziona, anche se

PS. Lavoro da casa