Evitare di diventare un programmatore "teorico"

Ho trovato questo articolo in diversi post su SO. Mi ritrovo a cadere nel sesto archetipo; il "teorico".

Definisce il "teorico" come:

Il teorico sa tutto quello che c'è da sapere sulla programmazione. Lui o lei può trascorrere quattro ore a tenere conferenze sulla storia di un oscuro linguaggio di programmazione o fornire una prova di come il codice che hai scritto sia meno che perfettamente ottimale e potrebbe richiedere altri tre nanosecondi per essere eseguito. Il problema è che il teorico non sa nulla dello sviluppo del software. Quando il Teorico scrive il codice, è così "elegante" che i semplici mortali non riescono a capirlo. La sua tecnica preferita è la ricorsione e ogni blocco di codice è ottimizzato al massimo, a spese della tempestività e della leggibilità.

Anche il teorico si distrae facilmente. Un semplice compito che dovrebbe richiedere un'ora richiede ai teorici tre mesi, poiché decidono che gli strumenti esistenti non sono sufficienti e devono costruire nuovi strumenti per costruire nuove librerie per costruire un sistema completamente nuovo che soddisfi i loro elevati standard. Il Teorico può essere trasformato in uno dei tuoi migliori giocatori, se riesci a farlo giocare entro i confini del progetto stesso e smettere di passare il tempo a lavorare su The Ultimate Sorting Algorithm.

Anche quando lavoro su quello che dovrebbe essere un semplice progetto, tendo a impantanarmi nel cercare di progettare tutto da zero (probabilmente questo spiega perché ho perso circa 2 anni a cercare di creare un sistema operativo da zero. Ma anche ho visto che era inutile alla fine).

Cosa può aiutarmi a evitare di farlo? E attenersi ai principi KISS?

Grazie

Essendo un teorico per natura, io stesso, posso dirti che lavorare in un negozio Agile risolverà in modo rapido e deciso tutte queste tendenze. In particolare, un'operazione di programmazione eXtreme, con programmazione in coppia (idealmente ruotando frequentemente di frequente), sviluppo guidato dai test, time boxing e sprint limitati, mette immediatamente a nudo il tuo lavoro affinché tutti i tuoi colleghi possano vedere e richiede di aprirti e collaborare una base minuto per minuto. Si tratta di un enorme cambiamento rispetto ai compiti separati nell'ambiente di uffici isolati in cui fiorisce il lavoro in stile teorico. Richiede totale onestà e totale integrità, poiché tutti dipendono attivamente da tutti gli altri continuamente.

Faccio ancora tesoro del mio sguardo sull'ombelico, ma devo lasciarlo andare a casa, o in quelle rare occasioni in cui posso lavorare su un progetto sul lato che non fa parte dello sviluppo della linea principale.

1. Avere obiettivi per quello che dovresti sviluppare.

2. Restringi quegli obiettivi a qualcosa di realizzabile nel prossimo futuro.

3. Quindi concentrati su quegli obiettivi, eliminando tutte le altre considerazioni. Nessuno sfondo. Nessuna storia Nessuna estensione. Niente di generale o astratto.

4. Quindi restringili ulteriormente nel minimo che puoi fare che sarà consegnabile. Non bene. Non flessibile. Non mantenibile. Accettabile.

5. Quindi dai la priorità al minimo assoluto necessario per ottenere il minimo che puoi fare. Il punto è scegliere una data in circa una settimana e costruire verso quella data. Se non riesci a consegnare qualcosa in una settimana. Stretto. Messa a fuoco. Trim. Ridurre.

6. Quindi eliminare la lanugine. Hai solo una settimana. Continua a tagliare.

7. Quindi concentrati solo su un'implementazione ridotta che verrà eseguita il prima possibile. Idealmente, meno di una settimana, quindi hai tempo per scrivere la documentazione.

Ho lavorato con i teorici. Considero gli "extra" una scusa per evitare di fare effettivamente qualcosa che potrebbe essere etichettato come un fallimento.

Fare - e fallire - è difficile. Parlare di fare qualcosa è più facile che fare qualcosa. Molta ricerca e pensiero sono un modo per evitare di fare la cosa sbagliata e poi rielaborarla dopo aver appreso che gli utenti hanno mentito.

Metti il ​​codice davanti a loro. Chiameranno il codice un fallimento. Succede. Ma nel processo di fallimento imparerai quali sono i requisiti reali. E imparerai che hanno mentito.

Non sono sicuro che sia una brutta cosa. Chiaramente devi essere produttivo o non farai il tuo lavoro, ma avere un interesse nel campo, essere uno studente d'arte, per così dire non è una brutta cosa.

Giocherei ai tuoi punti di forza, cerco opportunità in cui il tuo stile e le tue preferenze sono un vantaggio.

Per assicurarti di rimanere produttivo mentre ti concedi di scrivere un framework MVC a Erlang (o qualunque cosa tu ritenga interessante) dovresti forse programmare il tempo del tuo lavoro più essenziale per, diciamo, un'ora al giorno. Per il resto della giornata, concentrati solo sul lavoro grugnito e fai il lavoro. Quando vedi qualcosa di interessante che potrebbe distrarti, aggiungilo ai segnalibri o prendi nota, ma vai avanti, quindi torna ad esso nel tuo intervallo di tempo assegnato.

Personalmente ho risme di URL che sembrano interessanti, e anche una pila di libri di biblioteca. Forse alla fine ottengo circa il 10% di quegli URL e alla fine leggo il 50% dei libri, ma riesco anche a svolgere il lavoro di giorno.

Ho avuto questo problema da solo. Due tecniche hanno aiutato:

1. Usa la tecnica Pomodoro o qualche altra tecnica di gestione del tempo in cui imposti una sequenza di obiettivi a breve termine. Quando devi capire cosa puoi realizzare nei prossimi 25 minuti, ti mantiene concentrato su un lavoro utile.
2. Sviluppo guidato dai test. Se devi scrivere un test concreto prima di scrivere qualsiasi codice, riduce al minimo i sogni ad occhi aperti. (Non c'è modo di scrivere un test per "elegante".) Dopo aver fatto funzionare qualcosa, potresti passare più tempo di quanto dovresti riformattarlo, ma almeno lavorerai sul codice reale piuttosto che su un ideale immaginario.

Non ti picchiare troppo. È più facile convincere un teorico a concentrarsi e fare un lavoro utile piuttosto che convincere le persone che non si preoccupano di espandere i propri orizzonti.

Evita stackoverflow.com . Non fraintendetemi - sono un grande fan - ma SO e altri forum orientati alla programmazione rendono perfetto il nemico del bene . Dopo un po ', potresti iniziare a sentire che migliaia di persone intelligenti ti guardano alle spalle e nulla di ciò che scrivi è abbastanza buono. Basta far funzionare qualcosa e provare a renderlo comprensibile. Puoi sempre rivisitare se ha bisogno di miglioramenti.

Inoltre, evita articoli come quello che hai collegato. Credi davvero che ci siano dieci tipi di programmatori? O che qualcuno che conosci rientri esattamente in una delle categorie descritte? Articoli come questo hanno un certo fascino perché contengono un po 'di verità: puoi vedere te stesso e / o alcuni dei tuoi colleghi in alcuni degli stereotipi. Ma le categorie contengono quanta più acqua dei segni astrologici. Prova questa volta la prossima volta che parteciperai al mixer post-conferenza: "Ciao, sono un cowboy del codice! Qual è il tuo tipo?"

Questo non vuol dire che la tua domanda non sia valida - se stai pensando troppo alle cose, è bene imparare come evitare quella tendenza. Ma non lasciare che questo puttanaggio ti spinga a incazzare te stesso.

Esiste una semplice linea guida che, una volta decompressa, spiega in modo completo come evitare questo scenario.

Fai la cosa più semplice che potrebbe funzionare.

- Kent Beck

Penso che un modo per tenere la testa fuori dalle nuvole sia forzarti a scrivere applicazioni reali dall'inizio alla fine, oltre a scrivere le tue API o framework teorici. Prova a mettere una casella temporale attorno a qualcosa e prova a "finirla" entro quel tempo. La scrittura di framework richiede una buona comprensione dei modelli di progettazione e dell'architettura, ma ho scoperto che scrivere un'applicazione completa in un intervallo di tempo fisso richiede competenze diverse rispetto alla scrittura di un framework super ben progettato.

Se vuoi mai completare una domanda, a un certo punto devi portarti sulla terra e farlo. Ciò potrebbe richiedere sacrifici nei progetti o essere costretto a implementare una funzionalità in un modo che non ti soddisfa, a causa di un certo tipo di vincolo. Sono un po 'come te, propenso a scrivere e riscrivere le cose un milione di volte, ma se mi trovo di fronte a compiti che devono essere svolti entro un certo periodo di tempo, trovo che scelgo le mie battaglie, e solo nitpick il cose più importanti.

Semplice:

1. Sii pragmatico .

Il lato opposto del Teorico (che ha i suoi vantaggi sul lato informazione / conoscenza del dominio di programmazione) è il Pragmatico.

Applicare KISS, DRY, SOC e altri modi di pensare, come descritto in questa risposta , significa essere pragmatici.

Puoi anche imparare ad essere pragmatico leggendo questo libro:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

Non dimenticare che la teoria e la pratica lavorano insieme, non da sole. Senza molta pratica, la tua conoscenza non è nulla. Senza molte conoscenze non puoi migliorare la tua pratica rapidamente.

Quindi, esercitati molto. E impara molto. Ma non lasciare che l'uno superi l'altro.

Nei tuoi progetti, fissa una scadenza. Attenersi ad esso. Quindi pensa pragmaticamente al modo in cui terminare il tuo progetto prima di tale termine. (leggi il libro, davvero) Quindi inizia a scrivere codice, inizia a leggere ciò che devi sapere, passa dalla lettura alla codifica e al limite o al tempo di lettura.

Hrm ... Forse forse prova a trovare un lavoro in un'azienda che richiede di scrivere applicazioni in una sequenza temporale. Direi per me stesso che probabilmente sono il più lontano possibile dall'essere un teorico, almeno al lavoro. Fare quel tipo di lavoro ha il suo posto e il suo tempo ed è importante per svilupparti. Tuttavia, mentre apprezzo quel tipo di abilità, non ha posto nel mondo degli affari, specialmente dove lavoro. Un ambiente di sviluppo frenetico in cui a volte scrivi applicazioni in settimane e il cliente le vuole ieri! Sono stato benedetto con sviluppatori straordinari ed è stato necessario del tempo perché tutti lavorassero in gruppo.

Ho avuto un ragazzo il più brillante possibile, ma come te, ho sempre dovuto spremere l'ultimo bit dal suo codice anche quando funzionava bene, fino al punto in cui ha iniziato a scrivere controlli personalizzati che erano essenzialmente i uguale a quelli forniti dall'ambiente. È stato tutto molto bello ma è stata una tale perdita di tempo quando abbiamo dovuto fare le cose in tempo. Spesso questi progetti secondari hanno sostenuto la squadra e alla fine ha iniziato a sentire la pressione degli altri e si è formato. Vorrei suggerire di iniziare a lavorare in un ambiente di squadra con alcuni altri buoni sviluppatori che devono eliminare i prodotti. C'è sempre tempo dopo per refactoring e rifare le cose o scrivere il MergeSort più accattivante di sempre; ma a volte devi portare il prodotto a un punto in cui funziona e portarlo al cliente.

Non c'è niente di sbagliato nell'essere un "teorico" nel solito senso della parola. Avere conoscenze di base e essere in grado di comprendere le ultime ricerche CS è una grande capacità di avere, in quanto è una miniera d'oro di idee buone e originali.

La "vera domanda" qui è più evidente nella seconda metà del post. Conoscere l'obiettivo specifico del progetto e lavorare a tale scopo, non a qualsiasi altro fine. In questo caso è davvero solo una questione di autodisciplina. Vedi la risposta di S. Lott per ulteriori informazioni al riguardo :).

Rifletti la tua mente dalla programmazione e persino dal realizzare cose per fornire software funzionante. Stabilisce le tue priorità.

Come raggiungere questo è un'altra storia. Il modo migliore è concepire un progetto e seguire tutte le fasi per avviarlo in produzione. Dopodiché avrai una mentalità diversa rispetto a prima.

Grazie per questo post. Rende ancora più utile il mio lavoro. Mi sento lo stesso avere una formazione in architettura dell'informazione che lavora come sviluppatore di software. Spesso mi trovo alle prese con "dove cambiare le cose" piuttosto che con "cosa cambiare". Ci sono troppe relazioni, troppe cose intelligenti e generiche in giro che ci vuole troppo tempo per scoprire come funzionano le cose.

Quindi inizio a fare domande e ancora più domande fino a quando non conosco COME e DOVE questo è davvero costruito. E lascia che te lo dica: funziona. Più domande un incendio, meno importante è mantenere l'architettura originale e infine tornare alle origini

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Chiedi al tuo capo di ottenere un mentore, quindi fai come dice il mentore.

La parte difficile è concentrarsi e riconoscere che "ehi, riscriviamo il sistema operativo" non trarrà beneficio sostanziale per il completamento dell'attività che ti è stata assegnata (motivo per cui un project manager non lo farà).

Inoltre, fai in modo che il tutor riveda TUTTI i tuoi progetti prima della codifica e il codice effettivo dopo la codifica. Questo ti aiuterà a concentrarti su ciò che deve essere fatto.

Ho la stessa tentazione di progettare troppo le cose e ci vuole autodisciplina e organizzazione per superarle. Quando codifico per qualcun altro, ecco come lo faccio:

1. Quando si avvia un'attività discreta, dedicare qualche minuto a pensare a ciò che è veramente necessario in termini di funzionalità, qualità, data di consegna, ecc.
2. Prenditi un po 'più di tempo per pianificare come farlo , suddividendolo in sotto-attività, sotto-sotto-attività, ecc., Tenendo conto degli obiettivi del cliente del codice.
3. Stimare il tempo per ogni articolo , aggiungendo fino al 50% per incognite. Se un articolo richiederà più di quattro ore, suddividilo un po 'di più. (Se avessi fatto progetti universitari, avrei usato un foglio di calcolo, ma come consulente con più clienti, avrei usato un sistema di tracciamento dei problemi chiamato Redmine.)
4. Ancora più importante: fai solo gli oggetti che mi sono venuti in mente .

Certo, succede qualcosa. A volte scopro di dover fare più cose, quindi ricomincio da # 1. A volte trovo che un'attività richieda molto più tempo di quanto pensassi - ricominciare da # 1. A volte so in anticipo che il mio progetto avrà bisogno di maggiori dettagli in seguito, quindi pianifico una sottoattività di rivalutazione in cui ricomincio da # 1.

Più lo faccio, meglio ci riesco. L'autodisciplina è un muscolo mentale che si rafforza con l'esercizio fisico, e anche io riesco a stimare quanto tempo ci vorranno e facendo scambi tecnici. E trovo utile ricordare una citazione del generale Patton: "Un buon piano eseguito violentemente ora è meglio di un piano perfetto eseguito la prossima settimana".

Come sviluppatore solitario, il mio flusso di lavoro combina questo con aspetti di Agile, tra cui una scheda Kanban. A volte vado in tangenti, ma cerco di limitare le deviazioni a poche ore a settimana e funziona abbastanza bene.

Se hai intenzione di lavorare nel settore privato, è davvero importante controllare l'impulso "teorico". Il programmatore più brillante che conosco vive nella Silicon Valley, ma non ha un lavoro da anni perché ha una tale reputazione per la consegna del codice perfetto troppo tardi.