Come codificare più velocemente (senza sacrificare la qualità) [chiuso]

Sono stato un programmatore professionista per diversi anni. I commenti sul mio codice sono stati generalmente gli stessi: scrive ottimo codice, ben testato, ma potrebbe essere più veloce .

Quindi, come posso diventare un programmatore più veloce, senza sacrificare la qualità? Per il bene di questa domanda, ho intenzione di limitare l'ambito a C #, dal momento che è principalmente quello che codice (per divertimento) - o Java, che è abbastanza simile in molti modi che contano.

Cose che sto già facendo:

• Scrivi la soluzione minima per completare il lavoro
• Scrivi una serie di test automatici (previene le regressioni)
• Scrivi (e usa) librerie riutilizzabili per ogni genere di cose
• Utilizzare tecnologie ben note dove funzionano bene (ad es. Hibernate)
• Usa i motivi di design dove si adattano al loro posto (es. Singleton)

Sono tutti fantastici, ma non credo che la mia velocità stia aumentando nel tempo. Io faccio la cura, perché se posso fare qualcosa per aumentare la mia produttività (anche del 10%), che è il 10% più veloce rispetto i miei concorrenti. (Non che ne abbia.)

Oltre a ciò, ho ottenuto costantemente questo rimborso dai miei manager, sia che si trattasse di sviluppo Flash su piccola scala o di sviluppo Java / C ++ aziendale.

Modifica: sembrano esserci molte domande su cosa intendo per veloce e su come so di essere lento. Vorrei chiarire con qualche dettaglio in più.

Ho lavorato in team di piccole e medie dimensioni (5-50 persone) in varie aziende su vari progetti e varie tecnologie (Flash, ASP.NET, Java, C ++). L'osservazione dei miei manager (che mi hanno detto direttamente) è che sono "lento".

Parte di ciò è dovuto al fatto che un numero significativo dei miei colleghi ha sacrificato la qualità per la velocità; hanno scritto codice errato, difficile da leggere, difficile da mantenere e per cui è difficile scrivere test automatici. Il mio codice è generalmente ben documentato, leggibile e testabile.

In Oracle, risolverei costantemente i bug più lentamente degli altri membri del team. Lo so, perché vorrei ottenere commenti in tal senso; ciò significa che altri sviluppatori (sì, più esperti ed esperti) potrebbero svolgere il mio lavoro in meno tempo di quanto mi occorresse, quasi alla stessa qualità (leggibilità, manutenibilità e testabilità).

Perché? Cosa mi sto perdendo? Come posso migliorare in questo?

Il mio obiettivo finale è semplice: se riesco a realizzare il prodotto X in 40 ore oggi e posso migliorare me stesso in qualche modo in modo da poter creare lo stesso prodotto a 20, 30 o anche 38 ore domani, questo è quello che voglio sapere - come ci arrivo? Quale processo posso usare per migliorare continuamente? Avevo pensato che si trattasse di riutilizzare il codice, ma non è abbastanza, a quanto pare.

Mi piace l'approccio di Jeff Atwood a questo, che può essere trovato qui http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Fondamentalmente nell'articolo fa riferimento a un brano del libro Art & Fear di David Bayles e Ted Orland. Il passaggio va:

L'insegnante di ceramica ha annunciato il giorno di apertura che stava dividendo la classe in due gruppi. Tutti quelli sul lato sinistro dello studio, ha detto, sarebbero stati valutati solo in base alla quantità di lavoro che hanno prodotto, tutti quelli a destra unicamente in base alla sua qualità. La sua procedura era semplice: l'ultimo giorno di lezione portava le sue bilance da bagno e soppesava il lavoro del gruppo "quantità": cinquanta libbre di pentole valutavano una "A", quaranta libbre una "B" e così via. Coloro che venivano valutati in base alla "qualità", tuttavia, dovevano produrre solo una pentola - sebbene perfetta - per ottenere una "A". Bene, sono arrivati ​​i tempi di valutazione ed è emerso un fatto curioso: le opere di alta qualità sono state tutte prodotte dal gruppo in base alla quantità. Sembra che mentre la "quantità"

Essenzialmente sporcarsi le mani più velocemente e più spesso migliora meglio le tue abilità, piuttosto che passare il tempo a studiare e teorizzare il modo "perfetto" per farlo. Il mio consiglio, continua a praticare, tieniti aggiornato con la tecnologia e studia design.

Una possibilità che nessun altro sembra aver menzionato è che stai andando bene e che i tuoi manager non sono molto bravi. Come misurano la produttività? Possono darti esempi specifici o è solo una percezione generale? Hanno preso in considerazione la quantità di tempo impiegata per riparare il lavoro di altre persone rispetto alla tua?

Ho visto molte persone ottenere credito per aver fatto le cose, mentre il resto della loro squadra risolve il pasticcio che si sono lasciati alle spalle.

La maggior parte di ciò che la gente pensa sia importante non è importante. La velocità di digitazione non è importante. Macchine o strumenti più veloci non sono importanti. Non siamo dattilografi o operatori di macchine. Siamo pensati lavoratori. Siamo responsabili delle decisioni .

Ciò che è importante è utilizzare il feedback per migliorare continuamente il processo decisionale. L'unico modo per farlo, come acquisire qualsiasi altra abilità, è attraverso l'esperienza, la pratica intenzionale e il feedback continuo.

• Lavora su progetti secondari.
• Lavora su progetti open source.
• Lavora con sviluppatori che sono migliori di te. Abbina il programma!
• Esponiti a nuovi strumenti e tecniche. Mantieni ciò che funziona.
• Fai esercizi di programmazione progettati per addestrare il tuo apparato decisionale *.
• Monitora il tuo miglioramento in base a metriche oggettive come velocità e velocità dei difetti e metriche soggettive come qualità del codice e idoneità.

Infine: ricorda che la velocità senza qualità è inutile e viceversa. Per massimizzare la tua utilità, trova un equilibrio tra queste tensioni.

* http://codekata.pragprog.com/

È possibile che in realtà ti venga chiesto di sacrificare un po 'di qualità, per una maggiore velocità.

In alcuni ambienti di sviluppo ¹ , non vale semplicemente il tempo extra per produrre qualcosa di raffinato, quando "abbastanza buono" farà.

^{1 - Sto pensando al "fabbro interno" in particolare, ma probabilmente ce ne sono altri.}

Sembra che tu stia facendo tutte le cose buone - che a medio termine ti renderanno più veloce, quindi non è ovvio se sei effettivamente lento. Solo tu lo sai davvero. (ma è una possibilità molto reale - PeopleWare afferma una differenza di produttività fino a 10 volte tra gli sviluppatori per la stessa attività).

Quindi ho alcuni suggerimenti per te:

1. Il tempo è una cosa relativa, quindi forse il problema non è la tua velocità effettiva, ma piuttosto la percezione del tempo che stai dando. Potresti implicare che ci vorrà una settimana, ma alla fine passerai due settimane, mentre gli altri potrebbero passare 3 settimane ... ma sembri solo 1 settimana lenta.

2. Dato che ricevi spesso questo feedback, forse è il momento di parlare con il tuo manager e colleghi per vedere cosa dicono - ci deve essere molto da imparare da loro.

3. Fai un paio di programmazione con uno sviluppatore di "qualità veloce" per vedere se riesci a individuare la differenza.

In effetti, ciò che si riduce è l' esperienza . Per essere più veloci in quello che fai è come guidare un'auto, inizialmente hai paura poiché altri sono guidatori veloci (o ubriachi) (o entrambi) e vuoi raggiungere tranquillamente casa (in termini software, vuoi assicurarti che il tuo codice funziona come sviluppato e funziona bene).

Nel corso degli anni / mesi, una volta che hai appeso la guida e le autostrade, impari alcuni trucchi lungo il percorso che rendono divertente la tua guida. Questo è ciò che chiamiamo esperienza. Quei "trucchi" (che io chiamo tratti) è ciò che aiuta.

Nel mio caso, ho imparato il vero uso dei modelli di progettazione codificando (anche @ home) e imparando gli usi di alcuni. Pertanto, quando incontro un problema che richiede un modello di progettazione, utilizzo l'esperienza passata per vedere quali hanno funzionato e perché avrebbe funzionato / non funzionerebbe per la mia situazione.

In sintesi:

• L'esperienza crea tratti che aumentano la fiducia e un software migliore.

PS: l'esperienza viene anche dall'apprendimento dagli altri. Ad esempio, aiuto da SO, accoppiamenti di programmazione, peer review, ecc. Non puoi avere un'esperienza se non puoi guardare indietro e imparare dagli errori (o se qualcuno non sfida mai i tuoi sforzi).

La domanda è se si è meno costosi se si guarda al costo totale a lungo termine.

In altre parole, le tue correzioni di bug accuratamente realizzate sono di così alta qualità (compresi casi di test e documentazione) che supera i costi di mantenimento delle correzioni di bug fatte dai tuoi colleghi più veloci?

Se sì, allora devi informare i tuoi superiori di questo fatto. Potrebbe essere difficile discutere se non misurano e dispongono dei dati necessari per confermare la tua valutazione.

Se no, allora devi considerare seriamente perché questo è il caso:

• Sei troppo inesperto?
• Passi troppo tempo a fare cose non richieste che ritieni debbano essere lì?
• Hai difficoltà a determinare quando la correzione è terminata?
• Il tuo codice è di qualità inferiore dopo tutto quello che pensi che sia?
• Dovresti affrontare lo sviluppo del codice in modo diverso perché ti ci vuole troppo tempo per accelerare il modo in cui lo fai ora?
• Hai trascorso troppo tempo su cose come questo sito?

Pensaci e modifica la tua domanda con i risultati.

Tutti gli interrogatori che hanno fatto se sei veramente lento o no sono sciocchi. Diventare un programmatore più veloce senza sacrificare la qualità è sempre un buon obiettivo, non importa quanto tu sia già lento o veloce. Questo è il mio obiettivo numero 1 come programmatore e non lo farò mai. Cerco sempre di andare più veloce senza sacrificare la qualità, ne sono ossessionato. Ecco cosa ha funzionato per me finora in ordine di disponibilità, insieme ad alcune idee sperimentali alla fine:

1) Non smettere mai di imparare: impara tutto ciò che puoi sulla programmazione e sull'uso dei computer in generale. Trova le aree in cui sei debole e imparale. Anche se sembra completamente estraneo al tuo lavoro e al C #, ti garantisco che se lo stai cercando, troverai spesso modi per applicarlo a quello che fai. L'apprendimento riguarda anche l'esperienza, quindi non limitarti a leggere cose ma provale ed espandi le tue abilità. Se sei abituato a usare Windows, prova Unix o viceversa. Se normalmente ti piace usare gli IDE, prova gli strumenti da riga di comando e gli editor di testo o viceversa. Se hai sentito parlare di uno strumento o di una tecnologia di cui non hai mai sentito parlare o di cui non sai molto, non lasciarti andare alla tentazione di andare avanti. Cerca! Non abbiate paura di pensare fuori dagli schemi e apprendere nuove tecnologie sperimentali che altri dicono essere poco pratiche;

2) Suddividi progetti: prova a suddividere i tuoi progetti in mini progetti. Prova a fare una nuova versione ogni giorno o al massimo una volta ogni pochi giorni. Chiediti "Qual è la quantità minima di funzionalità che posso rilasciare e rilascia ancora qualcosa che è utile per l'utente." Questa è un'abilità che imparerai facendola. Potrebbe essere necessario convincere i tuoi manager a lasciarti fare questo, ma di solito saranno contenti dei risultati abbastanza rapidamente. In questo modo inizierai a notare che le cose che pensavi fossero essenziali per la tua funzionalità sono in realtà funzionalità aggiuntive che possono essere sviluppate in seguito. Ciò consente a te e ai tuoi manager di dare la priorità solo alle funzionalità più importanti anziché a tutte le funzionalità correlate a quella su cui state lavorando. Ciò ti consente di pensare più velocemente mantenendo la mente chiara e focalizzata. A sua volta, programmerai legittimamente più velocemente. È probabile che anche i tuoi manager o almeno i manager del tuo manager percepiscano che stai programmando ancora più velocemente di quanto tu sia realmente perché stai ottenendo più rilasci. Un altro enorme vantaggio di questo è che sarai molto più bravo a stimare il tempo necessario per il completamento delle pubblicazioni e che i tuoi manager ti adoreranno per questo. Dato che stai già facendo molti test automatici, non dovresti avere problemi a fare rilasci frequenti stabili. Tuttavia, potrebbe essere necessario potenziare il sistema di build automatizzato. Consiglio vivamente di leggere il libro La consegna continua della serie Martin Fowler. È una lettura difficile e perché è estremamente ripetitiva, ma comunque molto utile. È probabile che anche i manager percepiscano che stai programmando ancora più velocemente di quanto tu sia perché stai ottenendo più rilasci. Un altro enorme vantaggio di questo è che sarai molto più bravo a stimare il tempo necessario per il completamento delle pubblicazioni e che i tuoi manager ti adoreranno per questo. Dato che stai già facendo molti test automatici, non dovresti avere problemi a fare rilasci frequenti stabili. Tuttavia, potrebbe essere necessario potenziare il sistema di build automatizzato. Consiglio vivamente di leggere il libro La consegna continua della serie Martin Fowler. È una lettura difficile e perché è estremamente ripetitiva, ma comunque molto utile. È probabile che anche i manager percepiscano che stai programmando ancora più velocemente di quanto tu sia perché stai ottenendo più rilasci. Un altro enorme vantaggio di questo è che sarai molto più bravo a stimare il tempo necessario per il completamento delle pubblicazioni e che i tuoi manager ti adoreranno per questo. Dato che stai già facendo molti test automatici, non dovresti avere problemi a fare rilasci frequenti stabili. Tuttavia, potrebbe essere necessario potenziare il sistema di build automatizzato. Consiglio vivamente di leggere il libro La consegna continua della serie Martin Fowler. È una lettura difficile e perché è estremamente ripetitiva, ma comunque molto utile. e i tuoi manager ti adoreranno per questo. Dato che stai già facendo molti test automatici, non dovresti avere problemi a fare rilasci frequenti stabili. Tuttavia, potresti dover rinforzare il tuo sistema di compilazione automatizzato. Consiglio vivamente di leggere il libro La consegna continua della serie Martin Fowler. È una lettura difficile e perché è estremamente ripetitiva, ma comunque molto utile. e i tuoi manager ti adoreranno per questo. Dato che stai già facendo molti test automatici, non dovresti avere problemi a fare rilasci frequenti stabili. Tuttavia, potrebbe essere necessario potenziare il sistema di build automatizzato. Consiglio vivamente di leggere il libro La consegna continua della serie Martin Fowler. È una lettura difficile e perché è estremamente ripetitiva, ma comunque molto utile.

3) Usa la tecnica pomodoro e adatta / modifica ciò che non funziona per te. Se lo combini con il numero 2 in questo elenco, otterrai un ENORME aumento della produttività.

4) Impara Vim. Anche se finisci per usare questi comandi all'interno di Visual Studio tramite ViEmu o all'interno di Eclipse tramite un plug-in o all'interno di Emacs, otterrai produttività. Il modo migliore per imparare Vim è iniziare a usarlo e non forzarti mai (disabilitarlo / tornare ai tuoi vecchi strumenti) fino a quando non lo avrai imparato. All'inizio è doloroso, ma non vorrai mai tornare indietro e persino rabbrividire quando devi lavorare senza di essa. Alcuni direbbero che questo non aumenterà di molto la tua velocità. Ma più veloce è più veloce, specialmente quando leggere e modificare il codice è COSA FACCIAMO, e in alcune occasioni mi sono ritrovato a risparmiare molto tempo con questo.

5) Quest'ultimo non è necessariamente raccomandato in quanto non sono sicuro che sia una buona idea e potrebbe effettivamente ridurre la produttività, ma lo farò comunque. Potresti provare a fare più test di collaudo e meno test unitari, o almeno assicurarti di fare dei test di collaudo. Ho avuto successo con SpecFlow, ma sospetto che ci sia qualcosa di meglio là fuori. Anche scrivere le specifiche può essere piuttosto tecnico, quindi potresti volere solo che il tuo manager / cliente scriva prima una versione approssimativa della bozza che cambi in modo significativo, oppure potresti scrivere tutto da solo e farlo leggere e OK. Questo ti aiuterà con il numero 2 da questo elenco. Inoltre, i test di accettazione possono essere più pratici e richiedono meno codice rispetto ai test unitari. Questo non vuol dire che li sostituiscono, strumenti diversi per cose diverse.

6) Questo è ancora più sperimentale e controverso. In realtà non l'ho fatto da solo, quindi non posso esattamente consigliarlo. Impara e usa il Meta Programming System da JetBrains. Usalo per creare strumenti che il tuo manager / cliente utilizza per creare da soli il software desiderato. Potresti anche essere in grado di smettere di fare test di unità e accettazione se puoi usarlo per creare strumenti che il tuo manager / cliente utilizza per specificare il comportamento in modo molto semplice e non contorto. L'idea è di non sbarazzarsi del programmatore. I programmatori dovrebbero comunque aggiungere nuove funzionalità a questi strumenti utilizzati dal cliente / gestore ogni volta che (le persone, non gli strumenti) non possono facilmente creare alcune funzionalità desiderate. Credo che l'MPS o altri strumenti simili ad esso siano la via del futuro.

Usa di più il tuo cervello e fai meno test. Ad essere onesti, il test ha il suo posto, ma è costoso.

Leggi anche The Art of Unix Programming (online gratis, libro che vale il prezzo)

Infine, potresti non essere nel posto giusto. Piolo tondo per lavori quadrati, ecc.

Alla fine è come la scuola: "Produrre ciò che l'insegnante vuole" diventa "produrre ciò che la direzione chiede e paga".

Se prendi un grande progetto finito e ottieni il numero di righe "finali" di codice per ora uomo, scoprirai che i programmatori programmano MOLTO più lentamente di quanto tu possa immaginare.

Stiamo parlando di poche righe di codice al giorno. Il resto del tempo viene impiegato per il debug, la riscrittura e l'esecuzione di attività di programmazione generale.

Potresti aver sentito il vecchio detto: se rilevi un errore durante la digitazione, ti farà risparmiare 10 volte il tempo se lo rilevi in ​​fase di costruzione, che è 10 volte meglio rispetto a colpirlo durante il QA, che è 10 volte migliore che catturarlo dopo il rilascio ..

Quindi, come si accelera? Non mi concentrerei su nessuna forma di velocità di battitura: ridurre gli errori e migliorare altre "interazioni future" con il codice dovrebbe essere un investimento molto migliore del tuo tempo.

Il codice leggibile e chiaro è fondamentale. Scrivi il tuo codice una volta, ma verrà letto decine di volte. Scrivere per leggibilità ti farà risparmiare un sacco di problemi lungo la linea (che ti farà anche risparmiare molto tempo). Se MAI torni indietro e leggi il tuo codice e devi pensarci anche solo per un secondo, allora stai sbagliando.

La programmazione in coppia può ridurre i tempi di QA e, se si considera che un programmatore produce solo poche righe al giorno, se due possono codificare alla stessa velocità di uno ma con meno errori, allora si va avanti.

La codifica difensiva (ad esempio, il controllo dei parametri) può ridurre i problemi ... Se hai un ottimo analista / architetto nel tuo team, puoi risparmiare un po 'di tempo con una buona progettazione iniziale.

Altrimenti continua a migliorare le tue capacità di progettazione. Man mano che acquisisci esperienza, ti troverai più in grado di riconoscere schemi che non funzioneranno e di evitarli, sarai in grado di identificare prima i temporali, ecc.

Hai considerato di fare un controllo dettagliato di te stesso mentre lavori? Tieni traccia di carta e penna di come passi il tuo tempo o usa qualcosa come Rescue Time per rintracciarti.

Una volta che sei più consapevole di esattamente come trascorri il tuo tempo, puoi avere un'idea migliore di ciò che deve migliorare e concentrare i tuoi sforzi lì.

Idealmente, puoi sfidare alcuni dei tuoi colleghi a fare anche questo, confrontare i tuoi risultati e ottenere idee gli uni dagli altri. Probabilmente hai anche dei punti di forza che potrebbero trarre beneficio.

Forse scopri che stai spendendo troppo tempo su una parte del tuo processo che potrebbe essere automatizzata o semplicemente che hai molte distrazioni durante una certa parte del giorno e un'altra parte della giornata è tranquilla, quindi puoi pianificare le tue attività in giro quello, ecc.

O forse scopri che i test richiedono più tempo di quanto pensassi e devi ripensare la tua percezione che ti sta rendendo più veloce.

Se non altro ti dà alcuni parametri di riferimento su cui puoi lavorare.

Dalla tua lista stai andando bene.

Se i tuoi colleghi stanno realizzando un codice con un numero CRAP più alto, andranno più velocemente. CRAP è una metrica dal nome comico che combina la complessità ciclomatica e la copertura del test.

Non scrivere codice più CRAP di quello che devi. ;)

La mia unica modifica da suggerire per te è usare le librerie, non scriverle a meno che:

1. La tua azienda vende biblioteche
2. Hai refactored il codice ricorrente in una libreria

Stai leggendo e facendo ed è fantastico. Ma potresti essere bloccato pensando al codice procuedural o OO, ti sei esposto alla programmazione funzionale (diciamo Haskell?) E Prolog?

Per affinare la tua tecnica di programmazione OO, hai giocato con Smalltalk / Squeak?

E infine, teoria. Hai almeno una comprensione rudimentale della teoria dei grafi? (Alcuni programmi funzionano con alberi, DAG o semplicemente grafici ad un certo punto. Le reti sono grafici)

Citerò lo zio Bob :

L'unico modo per andare veloce è andare bene.

Ogni volta che cerchi la tentazione di scambiare la qualità con la velocità, rallenti. Ogni volta.

- "Vehement Mediocrity", Robert C. Martin

Per quanto ne so è:

1. bene
2. veloce
3. economico

Come manager, puoi scegliere qualsiasi 2.

Non preoccuparti dei commenti che stai ricevendo velocemente. Come collega programmatore preferirei mantenere un codice che è ben pensato e ben scritto rispetto a qualcosa che è stato schiaffeggiato insieme.

Le cose principali che mi vengono in mente sono le seguenti

• Aumenta la velocità di battitura.
• Utilizzare strumenti che offrono incrementi di produttività. Ad esempio ReSharper.
• Macchine o strumenti più veloci. Come più RAM o un'unità a stato solido.

Sono sicuro che ci sono alcune cose che puoi fare anche nell'area delle abilità di programmazione, ma sembra che tu sia in tutto quel genere di cose. Le cose che ho elencato sopra sono in genere trascurate dagli sviluppatori.

Potresti seguire un corso di digitazione rapida. Non so se la digitazione più veloce sia un problema, ma la "codifica troppo lenta" potrebbe essere causata da velocità di digitazione semplicemente lente.

E i generatori di codice? A volte il codice diventa ripetitivo. Il refactoring può rimuoverne una parte, ma anche in questo caso potresti avere chiamate ripetitive alla stessa funzione refactored. A seconda dei dati e del codice con cui lavori, i generatori di codice (scritti in Excel, Perl, Java, qualunque cosa ...) potrebbero risparmiare molto tempo. E l'utilizzo di strumenti per la generazione di codice per lo sviluppo dell'interfaccia utente è di solito un gioco da ragazzi.

E infine, forse le metriche sono sbagliate. Hai considerato che stai programmando alla massima velocità possibile, dato tutto il resto, e che le linee temporali sono troppo brevi, facendoti sembrare un programmatore lento?

Sulla base delle modifiche alla tua domanda, sembra che potresti prendere la strada di alcuni dei tuoi colleghi e hackerare insieme la soluzione più veloce che funzionerà - e la documentazione e il QA saranno dannati!

Oppure ... ottieni più esperienza e pratica in un'area specifica in modo da conoscere così bene la base di codice e l'API da poter codificare le soluzioni nel sonno. Questo può essere fatto ma richiede più tempo. Se gli altri sviluppatori che sono più veloci di quanto si sono conosciuti per essere più anziano e più esperto allora c'è solo una cosa da fare - si deve diventare più anziano ed esperto!

Ho un'obiezione alla visione "qualità sacrificata per la velocità" di OP.

I programmatori professionisti (programmatori) devono soddisfare 3 oggetti:
1) Il codice deve essere eseguito come previsto
2) La consegna deve avvenire in tempo
3) Avere buona qualità, documentazione, ecc.
4) Altro ecc.

Penso che l'OP sia stato accusato come lento probabilmente perché OP non è stato fatto in tempo.

Questa è una cattura 22 che è difficile aggirare. Anche se potresti ancora mancare di esperienza e una certa quantità di conoscenza in molti aspetti è già più veloce della maggior parte, la cattura è che è più difficile da misurare .

Personalmente il meglio che puoi fare a questo punto è misurare te stesso. Fornisci feedback su come lavori, forse semplici cambiamenti nelle tue abitudini di lavoro possono renderti più produttivo.

Ho scoperto che le mail stavano mangiando molto più di quanto pensassi semplicemente a causa dell'interruzione. Ora rispondo alle mail solo due volte al giorno e ho guadagnato quasi 1 ora di produttività alcuni giorni. Prova metodi come il pomodoro , l'ho usato come mezzo di misura. A intervalli regolari (15 minuti) annoterei cosa stavo facendo in quel momento. Questo mi ha permesso di vedere come erano strutturate le mie giornate e cosa avrei potuto fare per massimizzare l'efficienza.

Il vantaggio di Squeak per la codifica rapida va ben oltre il semplice "affinamento delle proprie capacità OOP". C'è un motivo per cui le moderne GUI, così come gli IDE, sono stati inventati su Smalltalk, per non parlare del fatto che JUNIT era un porto di SUNIT per Java, il termine "OOP" è stato inventato per descrivere Smalltalk, ecc., Ecc.

Bisogna sempre usare il linguaggio e l'ambiente più adatti a tutto ciò che si spera di ottenere, ma per la prototipazione generale, almeno, abbinerei il cigolio a qualsiasi cosa, con la possibile eccezione di HyperCard, e anche questo richiederebbe un benchmark per vedere quale fosse in realtà più veloce dato che ci sono strutture simili a hypercard integrate in Squeak.