Ho avuto il (probabile) stesso problema molti anni fa, è durato per alcuni anni e l'ho superato. Quindi forse sarebbe interessante per te sapere come l'ho raggiunto, anche se non sono sicuro che il mio modo si applicherà anche a te.
Dovresti anche dare un'occhiata qui: Le sette fasi di competenza in Ingegneria del software mostra che la produttività è in gran parte un effetto collaterale del livello di abilità. Può darsi che tu sia ancora ad un certo punto tra lo stadio 3 e lo stadio 4 della tecnologia che stai usando (l'abilità tecnica dipende dalla tecnologia, puoi essere padrone di alcune tecnologie mentre ancora impari altri).
Ora parto con la testimonianza biografica.
Un po 'di contesto. Ho 47 anni. Ho iniziato a programmare a 12 anni 80. Mentre ero al liceo, ho anche lavorato come programmatore di giochi professionali part time. Fondamentalmente non mi costavano così tanti soldi, quanto basta per comprare hardware, ma mi piaceva e imparavo molto. A 18 anni ho iniziato un apprendimento formale dell'informatica.
Come risultato quando ho compiuto 20 anni, ogni volta che ho iniziato un'attività di programmazione, conoscevo molti modi per risolvere i problemi indicati ed ero molto consapevole dei molti parametri e insidie alle mani, e degli svantaggi e dei limiti di qualsiasi metodo.
In alcuni punti (diciamo circa 26 anni) è diventato davvero difficile per me scrivere qualsiasi programma. Sono state aperte così tante possibilità che non potevo più scegliere tra loro. Per alcuni anni (ce l'ho fatta 6) ho persino smesso di programmare e sono diventato un giornalista tecnico.
Non ho mai smesso completamente di provare a programmare comunque. E ad un certo punto è tornato. La chiave per me era la programmazione estrema, in particolare il principio della semplicità: "Scrivi la cosa più semplice che potrebbe funzionare".
Fondamentalmente mi sono sforzato di non preoccuparmi dell'efficienza del codice (questo era il mio posto di blocco principale, evitare disegni inefficienti), ma basta andare nel modo più semplice. Inoltre, mi sono imposto di occuparmi meno degli errori e di ritardare la gestione degli errori in un secondo momento, dopo aver scritto i test che hanno generato l'errore (in realtà è TDD).
È qualcosa che ho imparato mentre stavo scrivendo. Quando non so cosa scrivere, o sapevo che cosa stavo scrivendo era cattivo . Andiamo avanti. In realtà scrivere le cose cattive. Alla fine lo correggerò più tardi. O se è davvero così brutto cancellarlo e riscriverlo, ma è più veloce scrivere cose due volte che scrivere qualcosa di perfetto la prima volta.
In realtà è molto probabile che un codice che ritieni sia valido in fase di prima scrittura avrà bisogno tanto di miglioramenti quanto di pessimo.
Se segui il percorso Simplicity ottieni anche un bonus aggiuntivo. Accetti facilmente di rimuovere / modificare la progettazione / codifica iniziale. Ottieni una mente più flessibile.
Ho anche preso l'abitudine di inserire un commento temporaneo nel codice, spiegando ciò che non stavo facendo ora e che intendevo fare più tardi quando il codice sarebbe stato funzionale nel normale caso d'uso.
Ho anche frequentato un Dojo XP con kata di codice praticato con altri programmatori per interiorizzare le pratiche XP. Ha aiutato. Ha reso istintivi i metodi formali di cui sopra. Anche la programmazione delle coppie ha aiutato. Lavorare con i giovani programmatori dà un certo slancio, ma con l'esperienza si vede anche ciò che non fanno. Per esempio nel mio caso le vedo spesso impegnate in progetti eccessivamente complicati e conosco l'incubo del design che potrebbe portare a. Andato in quel modo. Fatto. Ho avuto problemi.
Il punto fondamentale per me è mantenere il flusso. Essere veloci sta davvero riuscendo a mantenere il flusso.
Ora sono tornato come programmatore professionista e credo di essere sia migliore che più veloce con una comprensione più profonda di ciò che sto facendo. Praticare il TDD I potrebbe essere ancora un po 'più lento di quando ero un giovane toro (e non ho provato nulla), ma non ho alcun timore nel refactoring e certamente spendo molto meno tempo nel debugging (quasi per niente, rendilo meno del 10% del tempo ).
Riassumendo: ho superato il mio codice utilizzando metodi agili (XP), andando per semplicità, poi rifattiandolo e facendo pratica per renderlo istintivo. Ha funzionato per me. Non sono sicuro che possa essere generalizzato a chiunque altro.
In termini di livello di acquisizione delle competenze, ho soprattutto imparato ad accettare il fatto che ogni volta che cambio tecnologia (apprendo nuova lingua, nuovo framework, ecc.) passerò attraverso un palcoscenico quando sto rallentando. Questo è normale e alla fine lo supererà. Posso anche compensare ciò con una buona metodologia e competenze di programmazione generale e non sarà tanto un problema.
