Ho avuto lo (probabilmente) stesso problema molti anni fa, è durato alcuni anni e l'ho superato. Quindi forse sarebbe di tuo interesse 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 esperienza nell'ingegneria del software Mostra che la produttività è in gran parte un effetto collaterale del livello di abilità. È possibile che tu sia ancora ad un certo punto tra la fase 3 e la fase 4 sulla tecnologia che stai attualmente utilizzando (la competenza delle competenze dipende dalla tecnologia, puoi essere padrone di alcune tecnologie mentre ne stai ancora imparando altre).
Ora parto con una testimonianza biografica.
Un po 'di contesto. Ho 47 anni. Ho iniziato a programmare alle 12 negli anni '80. Al liceo ho anche lavorato come programmatore di giochi professionali part-time. Fondamentalmente non mi ha procurato così tanti soldi, quanto bastava per comprare hardware, ma mi sono divertito e ho imparato molto. A 18 anni ho iniziato un apprendimento formale di Informatica.
Di conseguenza, quando ho compiuto 20 anni, ogni volta che iniziavo qualsiasi attività di programmazione conoscevo molti modi per risolvere i problemi indicati ed ero molto consapevole dei numerosi parametri e insidie che avevo, nonché degli svantaggi e dei limiti di qualsiasi metodo.
In alcuni punti (diciamo circa 26 anni) è diventato davvero difficile per me scrivere qualsiasi programma. C'erano così tante possibilità aperte che non potevo più scegliere tra di loro. Per alcuni anni (ce la faccio 6) ho persino smesso di programmare e sono diventato un giornalista tecnico.
Non ho mai smesso del tutto di provare a programmare comunque. E ad un certo punto è tornato. La chiave per me era la programmazione estrema, in particolare il principio di Semplicità: "Scrivi la cosa più semplice che potrebbe eventualmente funzionare".
Fondamentalmente mi sono costretto a non preoccuparmi dell'efficienza del codice (quello era il mio principale ostacolo, evitare progetti inefficienti), ma semplicemente andare nel modo più semplice. Mi sono anche costretto a preoccuparmi meno degli errori e a ritardare la gestione degli errori in un secondo momento, dopo aver scritto i test che hanno sollevato l'errore (in realtà è TDD).
È qualcosa che ho imparato mentre scrivevo. Quando non so cosa scrivere, o sapevo che cosa stavo scrivendo era male . Andiamo avanti. In realtà scrivi cose cattive. Alla fine lo correggerò più tardi. O se è davvero così brutto cancellarlo e riscriverlo, ma è più veloce scrivere cose due volte che scrivono qualcosa di perfetto la prima volta.
Davvero è molto probabile che un codice che ritieni buono all'inizio abbia bisogno di miglioramenti tanto quanto uno davvero negativo.
Se segui il percorso della Semplicità otterrai anche un bonus aggiuntivo. Accetti facilmente di rimuovere / modificare il design / la codifica iniziale. Ottieni una mente più flessibile.
Ho anche preso l'abitudine di inserire un commento temporaneo nel codice, spiegando cosa non stavo facendo ora e intendevo farlo in seguito quando il codice sarebbe stato funzionale nel normale caso d'uso.
Ho anche partecipato a un XP Dojo praticando code katas con altri programmatori per interiorizzare le pratiche XP. Ha aiutato. Ha reso istintivi i metodi formali sopra indicati. Anche la programmazione delle coppie ha aiutato. Lavorare con i giovani programmatori dà un po 'di slancio, ma con l'esperienza vedi anche cosa non fanno. Ad esempio, nel mio caso, li vedo spesso impegnarsi in progetti troppo complicati e conosco l'incubo del design che può portare a. Andato in quel modo. Fatto quello. Ha 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 TDD Potrei essere ancora leggermente più lento di quando ero un giovane toro (e non ho testato nulla), ma non ho nemmeno paura di eseguire il refactoring e certamente dedico molto meno tempo al debug (quasi nessun tempo, rendilo meno del 10% del tempo ).
Riassumendo: ho superato il mio codeblock usando metodi agili (XP), cercando semplicità, poi refactoring e praticando 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 imparato principalmente ad accettare che ogni volta che cambio tecnologia (imparo nuove lingue, nuove strutture, ecc.), Passerò attraverso una fase in cui rallento. Questo è normale e alla fine lo supererà. Posso anche compensare questo con una buona metodologia e capacità di programmazione per scopi generali e non sarà un problema.
