Evita di diventare un programmatore "Theoretician"

Essendo un teorico per natura, io stesso, posso dirti che lavorare in un negozio Agile curerà in modo rapido e decisivo tutte queste tendenze. In particolare, un'operazione di programmazione eXtreme, con la programmazione delle coppie (che ruota idealmente frequentemente), lo sviluppo basato sui test, il time box e gli sprint limitati, mette immediatamente a nudo il tuo lavoro per tutti i tuoi colleghi e richiede di aprirti e collaborare un minuto per minuto. Questo è un enorme cambiamento rispetto ai compiti separati in un ambiente di uffici isolati in cui fiorisce il lavoro in stile teorico. Richiede onestà totale e totale integrità, poiché tutti dipendono attivamente da tutti gli altri continuamente.

Ricordo ancora il mio sguardo sull'ombelico, ma devo concedertelo a casa, o in quelle rare occasioni in cui posso lavorare a un progetto in-the-side che non fa parte dello sviluppo della linea principale.

1. Avere degli obiettivi per ciò che dovresti sviluppare.

2. Restringi questi obiettivi a qualcosa di disponibile nel prossimo futuro.

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

4. Quindi restringili ulteriormente, il minimo che puoi fare sarà consegnabile. Non bene. Non flessibile. Non mantenibile Meramente accettabile.

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

6. Quindi elimina il fluff. 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 qualcosa che potrebbe essere etichettato come un fallimento.

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

Basta inserire il codice di fronte a loro. Chiameranno il codice un fallimento. Succede. Ma nel processo di fallimento imparerai quali sono le reali esigenze. E imparerai che hanno mentito.

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

Vorrei giocare con i tuoi punti di forza, cercare opportunità in cui il tuo stile e le tue preferenze sono un vantaggio.

Al fine di assicurarti di rimanere produttivo mentre indulgi nello scrivere un framework MVC in Erlang (o qualsiasi cosa tu trovi interessante) dovresti forse impiegare il tempo per inscatolare il tuo lavoro più essenziale, diciamo, un'ora al giorno. Per il resto della giornata concentrati solo sul lavoro da sballo e ottieni il lavoro. Quando vedi qualcosa di interessante che ti distragga, aggiungi un segnalibro o prendi nota, ma prosegui, quindi torna ad esso nella finestra temporale assegnata.

Personalmente ho delle risme di URL che sembrano interessanti e anche una pila di libri di biblioteca. Forse alla fine ottengo il 10% di questi URL, e forse alla fine leggo il 50% dei libri, ma continuo a fare anche il lavoro giornaliero.

Ho avuto questo problema anch'io. Due tecniche hanno aiutato:

1. Utilizza la tecnica del Pomodoro o qualche altra tecnica di gestione del tempo in cui imposti una sequenza di obiettivi a brevissimo termine. Quando devi capire cosa puoi realizzare nei prossimi 25 minuti, ti tiene concentrato sul lavoro utile.
2. Sviluppo basato sui test. Se devi scrivere un test concreto prima di scrivere qualsiasi codice, minimizza il sogno ad occhi aperti. (Non c'è modo di scrivere un test per "elegante".) Dopo aver lavorato, potresti dedicare più tempo del necessario a rifarlo, ma almeno lavorerai su un codice reale piuttosto che su un ideale immaginario.

Non picchiarti troppo. È più facile ottenere un teorico che si concentri e faccia un lavoro utile piuttosto che convincere le persone che non si preoccupano di espandere i propri orizzonti.

Evita stackoverflow.com . Non fraintendermi - Sono un grande fan - ma SO e altri forum orientati alla programmazione rendono perfetto il nemico di buono . Dopo un po ', potresti iniziare a sentirti come se migliaia di persone intelligenti guardassero da dietro le spalle e nulla di quello che scrivi fosse abbastanza buono. Prendi qualcosa lavorando e cerca di 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 si adatti perfettamente a 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 stereotipi. Ma le categorie trattengono tanta acqua quanto i segni astrologici. Provalo la prossima volta che ti trovi in un mixer post-conferenza: "Ciao, sono un Code Cowboy! Qual è il tuo tipo?"

Questo non vuol dire che la tua domanda non sia valida - se stai pensando troppo a qualcosa, è bene imparare come evitare quella tendenza. Ma non lasciare che questo punditry ti parli di incasellarti da solo.

C'è una semplice linea guida che, quando completamente decompressa, spiega in pieno come evitare questo scenario.

Do the simplest thing that could possibly work.

- Kent Beck

Penso che un modo per tenere la testa fuori dalle nuvole è forzare te stesso a scrivere applicazioni reali dall'inizio alla fine, oltre a scrivere le tue API teoriche o framework. Prova a mettere una scatola del tempo intorno a qualcosa, e prova a "finirlo" 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 una casella di tempo prestabilita richiede competenze diverse rispetto alla scrittura di un framework ben progettato.

Se vuoi completare un'applicazione, a un certo punto devi portarti con i piedi per terra e basta farlo. Ciò potrebbe richiedere di fare sacrifici sui disegni o essere costretti a implementare una funzionalità in un modo che non ti soddisfa, a causa di un qualche tipo di vincolo. Sono un po 'come te - incline 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 il 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.

Per applicare KISS, DRY, SOC e altri modi di pensare, come descritto in questa risposta , significa essere pragmatico.

Puoi anche imparare ad essere pragmatico leggendo questo libro:

link

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

Quindi, pratica molto. E impara molto Ma non lasciarti sfuggire l'altro.

Nei tuoi progetti, imposta una scadenza. Attenersi ad esso. Poi pensa pragmaticamente al modo di finire il tuo progetto prima di quella scadenza. (leggi il libro, davvero) Quindi inizia a programmare, inizia a leggere ciò che devi sapere, passa dalla lettura alla codifica e al limite o al tempo di lettura.

Hrm ... Forse potresti provare a trovare un lavoro in un'azienda che richiede di scrivere applicazioni sotto una timeline. Direi per me, che probabilmente sono il più lontano dall'essere un teorico come puoi essere, almeno sul lavoro. Fare quel tipo di lavoro ha il suo posto e il suo tempo ed è importante per lo sviluppo di te stesso. 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! Ho avuto la fortuna di sviluppatori fantastici e ci è voluto del tempo per far lavorare tutti come una squadra.

Avevo un ragazzo che era geniale come può essere, ma come te, ha 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 uguali a quelli forniti dall'ambiente. Era tutto molto bello ma una tale perdita di tempo in cui dovevamo fare in tempo. Spesso questi progetti collaterali 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 altri buoni sviluppatori che devono spingere fuori i prodotti. C'è sempre tempo dopo per refactoring e rifare le cose o scrivere il MergeSort più kick-ass di sempre; ma a volte è necessario portare il prodotto a un punto in cui funziona e portarlo al cliente. Per premiare te stesso per il tuo nuovo zen di programmazione puoi andare a casa e creare una nuova distro Linux!

Non c'è niente di sbagliato nell'essere un "teorico" nel solito senso della parola. Avere una conoscenza di base ed essere in grado di comprendere l'ultima ricerca di 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 del progetto specifico e lavorare verso quel fine, non da nessun altro fine. In questo caso è solo una questione di autodisciplina. Vedi la risposta di S. Lott per ulteriori informazioni su questo:).

Rifocalizza la tua mente dalla programmazione e persino alla realizzazione di cose per la fornitura di software funzionante. Imposta le tue priorità.

Come ottenere questo è un'altra storia. Il modo migliore è concepire un progetto e passare attraverso tutti i passaggi per avviarlo alla produzione. Dopo avrai una mentalità diversa rispetto a prima.

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

Così comincio a porre domande e ancora più domande fino a quando non conosco COME e DOVE questo è veramente costruito. E lascia che te lo dica: funziona. Più domande un incendio, meno importante è mantenere l'architettura originale e infine tornare alle basi

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 avere un mentore e poi fallo come dice il mentore.

La parte difficile è mantenere l'attenzione e riconoscere che "hey, riscriviamo il sistema operativo" non apporterà un vantaggio sostanziale verso la conclusione dell'attività che ti è stata assegnata (motivo per cui un project manager non lo farà).

Inoltre, il mentore esamina TUTTI i disegni prima e il codice effettivo dopo codifica. Ciò ti aiuterà a concentrarti su ciò che deve essere fatto.

Ho la stessa tentazione di sovra-ingegnerizzare le cose, e ci vuole auto-disciplina e organizzazione per superarle. Quando si scrive codice per qualcun altro, ecco come lo faccio:

1. Quando si avvia un'attività discreta, dedica alcuni minuti alla riflessione su ciò che è veramente necessario per quanto riguarda funzionalità, qualità, data di consegna, ecc.
2. Prenditi un po 'più di tempo per pianifica come farlo , suddividendolo in sotto-attività, sotto-attività secondarie, ecc., tenendo a mente gli obiettivi del cliente del codice.
3. Valuta il tempo per ciascun elemento , aggiungendo fino al 50% per le incognite. Se un oggetto richiede più di quattro ore, scomporlo ancora. (Se facessi progetti per il college, utilizzerei un foglio di calcolo, ma come consulente con più client, utilizzo un sistema di tracciamento dei problemi chiamato Redmine.)
4. Soprattutto: fai solo gli elementi che ho trovato .

Certo, succede qualcosa. A volte trovo che devo fare più cose - quindi ricomincio da # 1. A volte trovo che un compito richiederà molto più tempo di quanto pensassi - ricomincia dal primo. A volte so in anticipo che il mio design necessiterà di maggiori dettagli in seguito, quindi pianifico una sottotask di re-estimation in cui ricomincio da # 1.

Più faccio questo, meglio ci riesco. L'autodisciplina è un muscolo mentale che si rafforza con l'esercizio fisico, e inoltre miglioro nel valutare quanto tempo ci vorrà e fare dei compromessi 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, inclusa una scheda Kanban. A volte vado in tangenti, ma cerco di limitare le deviazioni a poche ore a settimana, e funziona piuttosto bene.

Se hai intenzione di lavorare nell'industria privata, è molto importante controllare l'impulso del "teorico". Il programmatore più brillante che conosca vive nella Silicon Valley, ma non ha avuto un lavoro da anni perché ha una tale reputazione per aver consegnato un codice perfetto troppo tardi.