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

Succede solo a me o ti è familiare?

È così: devi creare qualcosa; un modulo, una funzionalità, un'intera applicazione ... qualunque cosa. È qualcosa di interessante che non hai mai fatto prima, è una sfida.

Quindi inizi a pensare a come lo farai. Disegni alcuni schizzi. Scrivi alcuni prototipi per testare le tue idee. Stai mettendo insieme diversi pezzi per ottenere la visione completa.

Alla fine finisci con un design che ti piace, qualcosa di semplice, chiaro a tutti, facilmente gestibile ... lo chiami. Hai coperto ogni base, hai pensato a tutto. Sai che avrai questa classe, quel file e quello schema del database. Configura qui, adatta qui l'altra cosa ecc.

Ma ora, dopo che tutto è sistemato, devi sederti e scrivere effettivamente il codice per esso. E non è più una sfida .... Ci sono stato, fatto! Scrivere il codice ora è solo "formalità" e sembra reiterare ciò che hai appena finito.

Nel mio lavoro precedente a volte me ne sono liberato perché qualcun altro ha fatto la codifica in base alle mie specifiche, ma al mio nuovo concerto sono responsabile di tutto il processo, quindi devo farlo anch'io (perché sono pagato per farlo esso).

Ma ho un progetto per animali domestici a cui sto lavorando a casa, dopo il lavoro e ci sono solo io e nessuno mi sta pagando per farlo. Faccio il lavoro creativo e poi, quando arriva il momento di scriverlo, non ne ho voglia ( navighiamo un po 'sul web, vediamo le novità su P.SE , su SO ecc.).

Voglio solo passare alla prossima sfida, e poi alla prossima, e alla prossima ...

Questo succede anche a te? Come lo gestisci?

Come ti convinci ad entrare e scrivere il codice eccentrico?

Prenderò qualsiasi risposta.

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

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

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

Quando lavoro da solo, adotto un approccio più iterativo di quello che potrei 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 ancora che esiste in qualsiasi forma), quindi ho la flessibilità di sperimentare e prendermi il mio tempo. 2) Passo molti cicli di refactoring e apprendo modi migliori di fare le cose. Per conto mio, in senso figurato.

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

Hai bisogno di una prototipazione rapida, a casa.

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

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

Qual è l'obiettivo più essenziale nel tuo progetto per animali domestici? Per dimostrare l'utilità di una delle tue intuizioni? In questo caso, tagliare il progetto fino a quando non diventa un progetto di prova . Quindi, utilizzare la prototipazione rapida in modo da poter ottenere di più con meno tempo di programmazione.

Immagino 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 ed effettivamente incappare nei problemi rilevanti. Realisticamente, di solito ho solo un disegno vago nella mia testa quando inizio a scrivere qualcosa. La mia grande sfida è farmi pensare a tutti i dettagli e avere un design in anticipo.

Posso sicuramente collegarmi a questo. Adoro 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 far funzionare e far funzionare X. Di solito, una volta che vado a finire, mi diverto e faccio più di quello che ho stabilito in primo luogo, ma se non forzo un obiettivo, sto male solo per ore.

Sono anche con te nel fatto che ciò accade più a casa sul lavoro laterale che in ufficio. Non so se siano più distrazioni, essere bruciati dal lavoro o cosa ...

Sicuramente capisco la tua frustrazione come ho già vissuto prima.

Nonostante abbia paura delle fiamme della comunità poiché so che questo non è un ottimo approccio, condividerò con te il mio approccio per i progetti collaterali . Si noti che questo metodo funziona per me e lo uso su progetti a medio / lungo termine, non lo farei per qualcosa di piccolo (dato che di solito ho la motivazione per finirlo 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 qualche ora al massimo) che puoi progettare e codificare.

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

Personalmente, non mi stabilisco un periodo di tempo stimato per ogni pezzo perché mi sento solo deluso e demotivato una volta che ho fallito quella stima, quindi, non lo consiglio. Prenditi il ​​tuo tempo ma non impiegare troppo tempo.

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

Questo mantiene alta la mia motivazione perché so che dopo un paio d'ore di cose noiose di programmazione, avrò più design da fare (buonissimo). Non lasciarti allontanare dai tuoi obiettivi, continua a fare quel compito terribile e presto finirà.

Dopo aver esaminato tutti i pezzi, guarda il pacchetto. Guarda come funziona, cosa sta facendo, rivedi di nuovo l' intero pacchetto. Sono sicuro che ci saranno cambiamenti e modifiche, facciali ora. Tieni a mente le informazioni più importanti perché ne avrai bisogno quando lavori su tutti gli altri pacchetti. Prendi appunti, aiutano molto.

Esamina 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 che forse hai dimenticato.

Alla fine, quando hai finito i pacchetti, di solito lo lascio andare per qualche giorno, mi riposo e mi concentro su qualcos'altro.

Normalmente non vedo l'ora di tornare indietro e iniziare a intrecciare i pacchetti e fare alcuni test giocosi, non c'è molto più codice da scrivere e l'obiettivo è vicino, questa è la motivazione sufficiente per me.

Spero che questo ti aiuti con i tuoi sforzi.

Ho sempre scoperto che le ipotesi originali non erano del tutto valide e che più o meno del progetto originale doveva essere modificato in base all'esperienza acquisita durante l'implementazione effettiva.

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

La spedizione è una caratteristica. Se non percorri 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 fissare un altro obiettivo "implementare il sistema", ma poi è più legato alla motivazione e al modo in cui lo fai.

C'è un altro modo che ha funzionato bene per me: impostare l'obiettivo iniziale come "consegnare il sistema a utenti specifici" anziché "progettare il sistema" o "creare il sistema". In questo modo, non sarai soddisfatto fino a quando gli utenti non avranno qualcosa di prezioso. E lo fai bene dall'inizio (compresi i test e altre cose moderne di fantasia).

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

Ad esempio: se ho progettato le mie lezioni di base, le scrivo e le eseguo alcuni test. Quindi ho progettato un database sottostante, l'ho impostato e testato. Successivamente ho i metodi e le funzioni di cui ho bisogno per ottenere tutto dentro / fuori dal database, proseguo. Il test viene eseguito più facilmente poiché ho già pronto le mie lezioni di base. E quando finalmente arrivo a progettare l'interfaccia utente, ho già un intero set di codice pronto per giocare.

Ora questo presuppone che si progetta anche in blocchi collegati tramite interfacce. Non conosco la parola costosa per questo, poiché non sono un programmatore per educazione, ma sai cosa intendo.

Spero che sia di aiuto.

Quindi scrivi le tue idee di design, 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 progetto come un programma letterato! :) Quindi ti occupi della parte interessante (le tue idee di design), ma in realtà li giustifichi con il codice reale che fornisci a fianco.

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

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

Di solito in questo periodo, ho dimenticato che avevo problemi ad iniziare, e sono nella zona.

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

Sicuramente non sei solo tu! Al momento sto rimandando un progetto.

Nessuno può motivarti tranne te stesso.

Crea una linea temporale realistica e sfida te stesso per completare ogni sezione in tempo. Non hai nulla da mostrare per i progetti se non superano mai la fase di progettazione.

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

Un compito chiave nella programmazione non è fare di nuovo cose noiose , ma farlo una volta, farlo correttamente e poi riutilizzarlo. O ancora meglio: trovare qualcuno che lo abbia 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 progettare semplicemente la soluzione e far implementare gli altri?

Cose che faccio:

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

Non sempre funziona, però

PS. Lavoro da casa