Come diventare un programmatore "più veloce"?

La mia ultima valutazione del lavoro ha incluso solo un punto debole: la tempestività. Sono già a conoscenza di alcune cose che posso fare per migliorare questo, ma quello che sto cercando sono altre.

Qualcuno ha suggerimenti o consigli su cosa fanno per aumentare la velocità della loro produzione senza sacrificare la sua qualità?

Come stimare le tempistiche e attenersi ad esse? Cosa fai per fare di più in periodi di tempo più brevi?

Qualsiasi feedback è molto apprezzato, grazie,

Spegni il computer. Prendi una matita e un po 'di carta. Disegna il tuo design. Revisionalo con i tuoi colleghi. Quindi scrivi il codice.

Qualche idea...

• Evita la doratura: fai solo ciò che ti viene chiesto (in termini di requisiti)
• Comprendi i requisiti aziendali e fallo bene la prima volta
• Comprendi a fondo l'ambiente e gli strumenti
• Diventa una dattilografa fantastica, usa le scorciatoie da tastiera anziché il mouse
• Adottare un approccio iterativo e integrare controlli di integrità per assicurarsi di essere sulla strada giusta
• Non reinventare la ruota, considera di riutilizzare il lavoro passato e il lavoro di altri
• Elimina le distrazioni, non continuare a controllare la posta elettronica, guardare fuori, parlare con i colleghi, ecc.
• Non sovraccaricare te stesso - riconosci quando devi fare delle pause

Il tuo desiderio di essere un programmatore "più veloce" da solo è lodevole. Tuttavia, non consegnare in tempo non significa che sei lento, significa che il progetto è stato pianificato male. Essere un programmatore "più veloce" non aiuta; significa solo che supererai più velocemente la scadenza.

Tu (e la tua squadra) state commettendo uno dei seguenti errori (o tutti):

• sottovalutare il lavoro che deve essere fatto;
• manca un grande requisito o pezzo di architettura durante la pianificazione;
• stime di lavoro confuse con stime di calendario e non contabilità di cose come riunioni / telefono / altre spese generali;

Esistono diversi modi per affrontare uno dei tre precedenti. Ma prima di poter migliorare su uno di essi, devi sapere perché le cose stanno andando come stanno. Fai un post-mortem sulle ultime due o tre stime dei progetti rispetto al tempo effettivo impiegato e scopri dove è andato il tempo extra.

Lo ripeterò ancora: essere lenti a scrivere il codice non farà perdere la scadenza , se l'hai pianificato correttamente per tenere conto di quel fatto.

Davvero, impara davvero il tuo editor. Se usi un IDE assicurati di utilizzare tutte le funzionalità che offre. Ottieni un cheat sheet per imparare le scorciatoie da tastiera per il tuo editor preferito. Se stai usando una shell imposta scorciatoie per le directory di uso comune

"Qualcuno ha suggerimenti o consigli su cosa fanno per aumentare la velocità della loro produzione senza sacrificare la sua qualità?"

Molte, molte persone lottano per la qualità "finale" a scapito di qualcosa che sia (a) semplice, (b) affidabile e (c) corretto.

Il modo più importante per accelerare il tuo sviluppo è semplificare ciò che stai facendo in modo che sia assolutamente il più semplice possibile.

La maggior parte delle persone che hanno problemi con la consegna in tempo stanno offrendo troppo, troppo. E i motivi addotti sono spesso sciocchi. Spesso sono solo requisiti percepiti, non requisiti reali.

Ho sentito molte persone dirmi cosa "si aspetta" il cliente. Questa è una cattiva politica.

Costruisci la cosa più semplice possibile. Se il cliente richiede di più, crea di più. Ma prima costruisci la cosa più semplice possibile.

Evita di lucidare il tuo codice alla perfezione, fallo funzionare. Questo è ciò che l'azienda si aspetta.

Ma spesso, aumentare la velocità implica sacrificare la qualità.

Riutilizzo: cerco di estrarre elementi intelligenti dai progetti precedenti, in modo da poterli riutilizzare in progetti futuri. Vale sempre la pena chiedersi "potrei usarlo di nuovo un giorno?"

Mantienilo semplice.

Se usi TDD, dovresti seguire " rosso, verde, refactor ":

1. Scrivi un test fallito ( rosso ). (Spesso per funzionalità il tuo codice non ha ancora.)
2. Commetti orribili crimini di codifica per far passare i tuoi test ( verde ). Hardcode se necessario.
3. Refactor , probabilmente rompendo i test per un breve periodo, ma nel complesso migliorando il design.

Scarica tutta la documentazione relativa alle lingue / librerie sul tuo computer, quindi scollega il cavo di rete / disattiva il Wi-Fi .

Non sto cercando di essere divertente qui. Questo mi aiuta davvero!

Nota quando hai letto Stack Overflow per troppo tempo. La scusa "Compilazione" funziona solo per così tanto tempo. :)

Evita di cambiare attività troppo spesso. Distrazioni e cambio di attività possono uccidere un giorno, anche se usi strumenti come Mylyn per gestire le tue attività.

Capire una granularità (ad esempio, 30 minuti) e lavorare solo su cose relative all'attività da svolgere. Qualsiasi altra cosa (nuove segnalazioni di bug, e-mail su altri problemi, questioni procedurali non correlate) viene ritardata almeno fino al "prossimo checkpoint". Assicurati di disabilitare il pop-up delle notifiche e-mail in modo da non essere risucchiato.

È particolarmente efficace se hai un amico nella tua squadra che ti farà sapere se le cose si sciolgono davvero e richiedono la tua attenzione immediata.

Fallo nel modo migliore, la prima volta. Se ciò significa che devi fermarti e pensarci un po 'prima di iniziare, allora fallo. Funziona il 90% delle volte.

Impara a digitare il più rapidamente possibile .

Lo faccio domani .

Anche fare cose è immensamente utile.

Ho comunque un breve intervallo di attenzione, quindi questi libri mi aiutano a mantenere la concentrazione ... cosa stavo facendo di nuovo?

Pratica e duro lavoro.

Devi dedicare tempo e fatica. Man mano che diventi più a tuo agio e sicuro degli strumenti che dovrebbero seguire, velocità e creatività.

Se vuoi migliorare qualche particolare abilità, può anche aiutare a progettare esercizi che ti permetteranno di lavorare specificamente su quello. Se la tua lentezza è in fase di progettazione, prova a trovare problemi di progettazione su cui lavorare online. Ripetere lo stesso esercizio ti permetterà di completarlo più velocemente e di esercitarti nella velocità. Personalmente mi piacciono gli esercizi con algoritmo di TopCoder per esercitarmi nella pura velocità di programmazione. Hanno anche sfide di progettazione, ma non le ho provate.

Scopri di più su The Zone, scopri come coinvolgerti e impara a riconoscere quando non ci sei.

Una volta che sono "nella zona", sono estremamente produttivo e il codice scorre appena fuori di me, spesso posso ottenere la codifica di 2 o 3 giorni in 1 giorno. Ma trovo che spesso è difficile arrivare in quel posto, mi trovo a rimandare, distratto da altre cose (Stack Overflow per esempio).

Cita da cosa-trucchi-che-usi-per-entrare-nella-zona

Conoscere bene l'IDE e il framework. Dover rivolgersi a Google per ogni piccola cosa richiede tempo.

Emacs

Prima di iniziare a sviluppare:

• Esci dalla tua casella di posta
• Disattiva tutti i client di messaggistica istantanea
• Chiedi educatamente ai colleghi di darti il ​​tempo di concentrarti
• Naturalmente, smetti di navigare in Internet

Ogni volta che vieni interrotto, rallenti perché ti ci vuole tempo per tornare in pista con i suoi pensieri. Ho sentito cifre che per ogni interruzione, la mente umana impiega 5-10 minuti per ripristinare il processo di pensiero che aveva prima dell'interruzione. Con così tanto tempo per interruzione, non ci vuole molto da perdere tutto il giorno.

Le persone della nostra azienda si sono effettivamente impegnate a bloccare il tempo nei loro calendari e poi a trasferirsi in una sala conferenze vuota per un paio d'ore ogni giorno.

Scopri il tuo IDE di sviluppo dentro e fuori. Impara i tasti di scelta rapida. Impara a usare meno il mouse. Trovo che questo mi faccia risparmiare molto tempo.

Sei più lento dei tuoi colleghi o le tue stime sono più ottimistiche?

Per produrre software più velocemente, ho scoperto che la cosa migliore da fare è imparare l'API di runtime nel miglior modo possibile. Non digitare la logica dell'elenco quando verrà eseguita un'estensione LINQ; non creare un gruppo di ascoltatori di eventi quando l'associazione funzionerà, ecc.

Per quanto riguarda la stima, ciò deriva dall'esperienza. È possibile utilizzare il software di stima là fuori per aiutarti a capire stime migliori.

Personalmente, ho trovato con gli sviluppatori di livello junior, prendere qualunque sia la loro stima iniziale e moltiplicarla per 2, quindi raddoppiarla. Ciò spiegherà tutto l'apprendimento, le riunioni, il tempo perso, ecc. Gli sviluppatori di livello più avanzato tendono a lavorare con un fattore 2 rispetto alle loro stime.

Spesso, la domanda non è se la tua stima fosse sbagliata. Ha fatto il tuo conto preventivo per tutte le cose giuste? Stai fornendo le tue stime e le scadenze in termini di sforzo di codifica o in termini di tempo di calendario? Pensa a tutto il tempo della tua giornata e a quanto è reale, codifica produttiva rispetto a riunioni, apprendimento, debug, ecc.

Due cose che potrebbero essere implicite, ma non ho ancora visto tra le risposte qui che un aumento della produttività sono:

• Usa una sorta di script di compilazione e distribuzione. Compilare, distribuire, riavviare il server delle applicazioni e non deve rischiare di perdere tempo o concentrazione, dovrebbe essere un tipo di cosa con un clic.

• Avere una sorta di controllo della versione. Dover codificare senza essere in grado di ripristinare un cambiamento è come provare a camminare sulle uova

Mi vengono in mente un paio di idee:

1. Ottieni altre opinioni sulle tue stime - Ci sono altri sviluppatori che potresti chiedere qualcosa del tipo "Ehi, pensi di poter realizzare questo tipo di funzionalità in questo lasso di tempo?" L'idea è che l'input di altre persone può aiutare con precisione in alcuni casi, in quanto qualcuno potrebbe notare un sacco di cose che hai perso nel fare la stima.

2. Affina la tua abilità di stima: inizia a monitorare la tua stima e perché non lo sei: altri oggetti di lavoro fanno sì che le scadenze non vengano rispettate? Stai costantemente sottovalutando quanto è complicato qualcosa? Stai dando un'intera linea temporale quando non è pratico, ad esempio ciò che viene chiesto è abbastanza vago che il semplice completamento di un prototipo richiederà settimane e quindi ci dovrebbe essere una rivalutazione di cos'altro deve essere fatto? Questo può aiutare di più a sviluppare quell'abilità in modo che se dici che qualcosa impiegherà x ore, puoi avere fiducia in ciò perché l'hai fatto più e più volte. Un modo alternativo per affermarlo è semplicemente pratica, pratica, pratica.

Probabilmente hai già preso in considerazione questi, ma ho pensato che valesse la pena affermarlo per quegli altri là fuori che potrebbero non aver preso in considerazione queste idee.

1. Conosci la tecnologia dentro e fuori.
2. Fermare! Pensare! Partire!
3. Architetto per qualunque cosa possa sorgere, ma implementa solo ciò che è veramente richiesto.
4. BACIO - Keep It Simple Stupid
5. Se sta diventando troppo complesso, probabilmente, non è ben pensato. (Torna a 2 e 4)
6. Non rimanere bloccato in 5. Spesso paga ricominciare da zero (Torna a 2 e 4)
7. Torna a 1.

Penso che la parola chiave qui sia "tempestività". Non hanno detto che eri troppo lento, piuttosto che non eri puntuale.

Nella gestione del progetto, è importante che il manager sia in grado di stimare quando gli articoli di lavoro saranno completi con precisione. Ho il sospetto che il motivo principale per cui i tuoi sforzi non sono stati ritenuti tempestivi è che spesso hai avuto articoli che non sono stati consegnati nei tempi previsti e sono stati consegnati molto più tardi del previsto.

Per migliorare la tua tempestività, potresti voler dedicare più tempo a capire quanto tempo ci vorrà per completare un particolare oggetto di lavoro date le tue abilità, esperienza e dominio. Ciò ti consentirà di fornire stime migliori al tuo project manager. La chiave qui è "migliore" ... si potrebbe consegnare in tempo più frequentemente riempiendo tutto con un fattore di sfumatura, ma ciò che si vuole davvero lottare è una stima più accurata.

Ne discuterò con il tuo manager per vedere se questo è effettivamente il problema. Altrimenti, potresti finire per programmare due volte più velocemente, promettendo cose nella metà del tempo che hai usato, e ancora essere criticato per la tua tempestività perché le tue stime avranno ancora lo stesso fattore di errore.

Diventa stabile, resta stabile.

Crea qualcosa che implementa un po 'di funzionalità e assicurati che funzioni, end-to-end. Quindi, continua a funzionare mentre aggiungi nuovi bit di funzionalità. Sì, questa è in parte una pratica TDD, ma ha senso anche se non fai TDD.

La logica è che ogni volta che ho visto qualcuno con 2 settimane di codice che non erano mai stati stabili, ci vuole sempre un altro 2 settimane per ottenere stabile.

Se rimani stabile, rimuovi tale incertezza e, se necessario, ti dai anche un modo per scendere in campo vicino alla scadenza.

L'ovvio contro-argomento è che fare questo richiederà più tempo che scrivere semplicemente una volta, poiché farai un lavoro extra stabilizzando il codice non finale. Non lo compro per un secondo. Quando hai un codice che funziona , cambi 5 righe e qualcosa si rompe, sai esattamente dove deve essere avvenuta la pausa.

Se hai 10.000 righe di codice che non hanno mai funzionato e devi trovare una pausa, hai un sacco di codice da cercare.

Piccoli cambiamenti incrementali su un sistema che è costantemente stabile FTW. Vai piano per andare veloce.

Per me, ottenere una buona produttività è avere un'idea chiara di ciò che stai cercando di ottenere e di come ci arriverai.

Praticamente tutte le risposte sono state dette a morte in numerosi luoghi qui e altrove. O almeno l'ho sentito morire. Impara il tuo IDE, impara a digitare più velocemente, usa i framework, usa la generazione di codice, ecc. Sì, certo, queste cose aiuteranno e dubito che ci siano molti programmatori che ne sono i padroni. Ma essendo il tipo di programmatore che pone queste domande e frequenta siti come Stack Overflow , sapevi già queste cose . Volevi semplicemente ripeterli qui o volevi solo sfogarti un po '?

E se fossimo in grado di raggiungere quello stato? Intendo padroneggiare tutti questi suggerimenti? Cosa succederebbe allora? Bene. Immagino che i tempi saranno ridotti ulteriormente. E ancora, torneremo a una percezione della qualità. Voglio dire, il nostro mestiere è decisamente migliorato e diventa sempre più produttivo nel corso dei decenni. Ma la qualità è aumentata in questo periodo (esclusi ovviamente i primissimi anni)?

La mia risposta è semplice: un software di qualità richiede tempo ! Puoi scambiare solo uno con l'altro (qualità / velocità). Ma sì, sappiamo tutti che, tuttavia, non siamo onesti riguardo al grado in cui tale compromesso finisce spesso per la velocità della scala. E siamo bugiardi ancora più grandi all'inizio dei progetti!

Dico che non sei in colpa qui. Il problema è la percezione che le persone hanno di quanto tempo dovrebbe impiegare un software di qualità. Ci prendiamo in giro credendo di essere in grado di creare software di qualità con i tipi di scadenze che i nostri manager o addirittura indoviniamo. Non realizziamo software di qualità . Scriviamo software che funziona ma a volte con lampi di qualità in alcuni angoli di un'applicazione.

Quindi cosa possiamo fare al riguardo? Non possiamo semplicemente convincere i nostri capi che dobbiamo raddoppiare o triplicare l'investimento in ciascuno dei nostri progetti. Dico l'esempio. Crea un software davvero eccezionale come progetto secondario. Dedica il tuo tempo e non scendere a compromessi. Nel frattempo presta attenzione a come progredisci. Prendi nota delle attività apparentemente non correlate in cui hai dovuto trascorrere un periodo di tempo inaspettato e vedi se riesci a giustificarlo. Contrasta questo con tutti gli altri progetti che hai lavorato. Sii brutalmente onestocon te stesso e tutti gli aspetti di questa analisi. Le cose extra che hai fatto con il tuo software di qualità possono essere trascurate in progetti "reali" al lavoro? Ma forse il tuo tentativo è fallito. Qual è stata la ragione? Ti sei annoiato e ti sei precipitato a fare le funzioni principali? Devo ancora fare qualcosa del genere, motivo per cui concludo questo pensiero con qualche dubbio, ma ho intenzione di provarlo. Vi terrò aggiornati :).

Infine, penso che la maggior parte (se non tutte) le valutazioni delle prestazioni siano distorte e straordinariamente manipolative. Non puoi limitare la qualità e la velocità al 100%. Il tuo capo dovrebbe farti segnare contro uno standard stabilito dall'organizzazione. Lo standard dell'organizzazione sul compromesso tra qualità e velocità. Immaginiamo che OrangeSoft Inc. si aspetti una qualità del 33% e una velocità del 66%. Quindi, se stai scrivendo un codice che ha forse un terzo dei test dell'unità, dovrebbe farlo, ma compensandolo con velocità e tempi di consegna ridotti, dovresti ottenere un punteggio vicino al 100% sulla tua recensione! (Queste sono analogie piuttosto approssimative, ma ottieni il punto). Ma invece, ciò che accade è che Bob scrive codice in modo estremamente veloce ma che è notoriamente difettoso. Quindi nella sua revisione delle prestazioni segnerà 3/5 per qualità e 5/5 per velocità. Carol invece scrive il codice molto più lentamente ma produce molti meno bug. Segna 5/5 per qualità ma 3/5 per velocità. In ogni caso, Bob e Carol sono ancorati al rilancio. È possibile per qualsiasi dipendente ottenere un punteggio perfetto? È giusto?

La tecnica che utilizzo è la prototipazione evolutiva

Puoi cercare su Google ulteriori informazioni, ma se la necessità è quella di produrre rapidamente qualcosa, è l'unica strada da percorrere. Inoltre, ha il vantaggio che quando gli utenti dicono che gli piace, hai finito (... e puoi iniziare a fare la documentazione).