Cosa può rallentare uno sviluppatore? [chiuso]

Quali cose tendono a rallentare uno sviluppatore?

Si prega di astenersi dal pubblicare risposte che:

• sono lenti ma utili nella funzione. (TDD, refactoring, ...)
• elencare una distrazione .

Oh, questi sono facili:

1. incontri
2. Altre riunioni
3. Riunioni sull'ultimo incontro
4. Riunioni per preparare il prossimo incontro
5. Sviluppare una presentazione in power point per una riunione
6. Sviluppare una presentazione in power point per una riunione che discute le funzionalità che non sono state implementate, non dovrebbero essere implementate, e per qualsiasi motivo quel ragazzo delle vendite salterà dappertutto. Non riesco a prevedere quale documento desideri visualizzare nell'app in base alla posizione corrente senza una connessione Internet o l'accesso al disco rigido. No davvero, rinuncia a chiederlo anche tu.

Un computer lento

Tutto ciò che provoca il cambio di contesto .

StackOverflow, programmers.stackexchange.com, ecc. :)

Direi burnout.

Qualsiasi tentativo di seguire un processo non adatto all'attività in corso.

Questo può essere di ogni genere, ma quelli comuni che vedo includono:

• metodologie di test che non si adattano al codice testato
• processi che sono drammaticamente più agili o tradizionali del mandato o dei risultati finali
• linee guida intese per un set di strumenti diverso rispetto al set di strumenti selezionato
• principi di progettazione che sono fuori scala con le esigenze del progetto
• utilizzando un set di strumenti non adatto all'attività

Tutte queste cose possono essere immensamente utili in alcuni progetti o in alcune situazioni, ma alcune organizzazioni cercano di fare tutto in un modo e ciò porta a una scarsa adattamento ad altri progetti che spesso è la morte della produttività.

Politica

ad esempio: quando più di una persona possiede i requisiti (o peggio, due diversi interessi acquisiti) e apportano modifiche concorrenti e contrastanti ai requisiti mentre lo sviluppo è in corso.

Conversazioni di altri

e rumore in generale

Molte risposte parlano del cambio di contesto e dell'uscita dalla zona e il rumore, in particolare la conversazione, è una di quelle cose che portano a quelle per me.

Nel mio cubeworld, sono circondato dal rumore e dalla conversazione su tutti i lati. Dopo una riga, il team mainframe tiene riunioni di pianificazione costanti nella riga del cubo. A volte, si incontrano con i consulenti in un ufficio lungo il muro, e questo tende a provocare rumori rumorosi, urla e risate e devo andare oltre e chiedere loro di chiudere le porte.

Dall'altro lato, il tavolo da conferenza del team Web si trova dall'altra parte della parete del mio cubo ovest, quindi faccio parte di ogni incontro, piaccia o no. C'è anche una stampante dall'altra parte del muro del cubo sud, ed è sempre utile per le chiacchiere da parte di persone che escono in attesa delle loro stampe.

La risposta immediata e ovvia di " Non riesci a procurarti le cuffie con cancellazione del rumore" non aiuta quando ciò che vuoi è il silenzio.

A volte per le revisioni del codice, porto la mia pila di fogli in sala da pranzo (a orari diversi da quelli del pranzo, ovviamente), ma c'è una TV che di solito squilla. Lo spegnerò se nessuno sta guardando. Altrimenti, andrò a trovare un cubo vuoto in un altro dipartimento in un'altra parte dell'edificio.

Se vuoi che i tuoi programmatori facciano il lavoro che devono fare, che è principalmente il pensiero, la riflessione e la considerazione, hanno bisogno di un ambiente in cui possano farlo.

Scrivere troppe righe di codice senza test adeguati.

Mancanza di caffè di alta qualità.

dovendo fare stime perfette da cui non bisogna deviare una volta iniziato lo sviluppo, secondo me è uno scenario da uovo di gallina

Risolto il problema con la build danneggiata di qualcun altro

Riunioni senza agenda.

Una macchina lenta.

Mancanza di un secondo monitor.

Un vecchio topo che ha una palla al posto di quelle nuove carine.

Mancanza di accesso a Internet sulla macchina, rendendo un po 'problematico interrogare MSDN / stackoverflow / ecc.

Trascorso troppo tempo a programmare

Anche se ti piace davvero programmare, passare troppo tempo su di esso alla fine ti brucerà ...

Evita tutto ciò che ti fa uscire dalla "zona". Ciò significa che la posta in arrivo, l'applicazione popup di Twitter, la chat aziendale, ecc.

Avere una condizione di lavoro silenziosa significa evitare anche quel rumore del desktop .

Qualsiasi richiesta di modifica che sarebbe stata più semplice da implementare se l'avessi saputo prima.

Codice scadente.

Dover riscrivere la parte di qualcun altro che avrebbe potuto fare il lavoro in primo luogo è il più grande affondamento di tempo che posso immaginare.

Il molto che ti rallenta è un buon post sul blog per questo.

...

Molti progetti ripetono ripetutamente le funzionalità di base a livello di infrastruttura, rallentando l'attività nel fornire funzionalità che differenziano l'azienda dai suoi concorrenti.

...

È inevitabile che i prodotti e le innovazioni contribuiscano a ridurre il tempo che gli sviluppatori dedicano ad attività non differenzianti. La domanda è: quale forma assumeranno tali servizi e strumenti.

...

Bene, ultimamente il più grande rallentamento è perché stiamo sviluppando molte cose contemporaneamente che avrebbero dovuto essere fatte in un ordine specifico. Quindi sto aspettando che (i nomi cambiati per proteggere l'innocente) John finiscano il suo componente di cui ho bisogno per il mio pacchetto SSIS e Harry è rallentato aspettando che io importi i record perché ha bisogno di alcuni dati per vedere per testare la sua esportazione (mai provare scrivere un rapporto di esportazione complesso quando non ci sono dati in nessuna delle tabelle?) e tutti sono rallentati perché la progettazione non è stata eseguita e le tabelle del database che dobbiamo svolgere le nostre attività non sono state ancora create e potrebbero non finire essere quello che hanno detto che sarebbero stati, ecc.

Rispondere alle domande su stackexchange.com, come questo.

Anche se hai chiesto di non elencare le distrazioni, possono essere un grande fattore. Guarda il loro ambiente di lavoro, controlla se vengono interrotti frequentemente o se ti viene chiesto di fare altre cose che non sono correlate al progetto.

A volte, uno sviluppatore potrebbe rimanere bloccato perché stanno facendo qualcosa che non hanno mai fatto prima e non sanno dove cercare aiuto. Se è una piccola squadra o un individuo, può essere ancora più difficile. Tendiamo ad essere un po 'orgogliosi e non amiamo ammettere quando non sappiamo come fare le cose. Inoltre, non ci piace chiedere aiuto agli altri. Non c'è modo semplice per convincere uno sviluppatore ad ammetterlo, tranne forse per chiedere se sono in grado di rispettare la scadenza, o di cosa hanno bisogno per rispettare la scadenza, e quindi sperare che siano onesti. Potrebbe essere necessario offrirti per portare altro aiuto o trovare qualcuno che possa aiutarlo.

Mancanza di requisiti chiaramente definiti, che li porta a dover capire le cose o prendere decisioni.

• Dover attendere circa 15 minuti per l'avvio del PC in uno stato utilizzabile
• In attesa che il PC passi da un'applicazione all'altra
• Essere l'unica persona in ufficio a dover preparare il suo tè / caffè.
• Una tastiera rotta (risolta!)
• Lavorare al di fuori dell'ufficio del CEO (US CEO) (e non in un ufficio), con solo una partizione in mezzo (specialmente quando c'è una riunione)
• Il boss è raggiungibile solo via e-mail, ma tutti gli altri sono nell'edificio
• Non avere il permesso di usare un VCS - apparentemente dovrebbe essere nel mio cervello
• Piccolo schermo
• Non concedere tempo per pause diverse dal pranzo
• Dover fare i backup del server remoto nonostante abbia un amministratore di sistema nell'edificio
• Viene detto di eseguire manualmente i backup.
• Essere costretti a usare uno stupido sistema di gestione del tempo inutilmente complicato
• Solo una vaga idea dei requisiti per due mesi nel lavoro

Potrei continuare, ma è venerdì e voglio dimenticare il lavoro.

• Mancanza di documentazione (sistema, azienda, ecc.)
• Mancanza di codice commentato
• Una comprensione incompleta del sistema
• Politica (ovvero riunioni non necessarie, scartoffie, ostacoli da parte della direzione ...)
• Documentazione dei requisiti incompleta
• Facebook!
• Dormire troppo?

Troppe persone nel progetto.

Visto più volte in cui la direzione decide sulla base di dati non reali di cui hanno bisogno per aggiungere più persone al progetto. Questo finisce nel ppl che sa cosa sta succedendo e che deve fermare tutto per tenere le mani di persone che sanno poco di quello che sta succedendo. Ho visto più di un progetto di dimensioni di funghi e poi andare in bagno rapidamente da lì, mentre prima andava bene, anche se forse un po 'lento.

Quindi si passa dall'essere in ritardo di un mese a causa della velocità insufficiente / troppo da fare per non consegnare affatto perché hai fatto saltare completamente il budget su tutte quelle persone in più.

A parte le cose menzionate da altri, la lunga strada tra la decisione di compilare ed eseguire il codice e ottenere un risultato positivo / negativo . Idealmente, questo RTT sarebbe solo un secondo, ma ho visto un esempio di ore. A proposito, i test unitari cercano di affrontare questo problema.

Un'altra correlazione è una latenza generale dell'ambiente di lavoro. Immagina di dover lavorare tramite una connessione desktop remoto al computer dall'altra parte del mondo, tramite una connessione inquietante. Ci sono stato. L'ho odiato.

• Scartoffie eccessive

• Avere una dipendenza da qualcuno che non c'è mai stato (come il tuo capo - se devi fare una domanda ma è sempre nelle riunioni)

• Strumenti e attrezzature inadeguati.

• Le persone che spingono il loro remo senza motivo (qualsiasi modifica visibile dell'interfaccia utente è soggetta a questo) o semplicemente discutono del lancio di cose banali.

• Macchina per il caffè rotto

• A cui sono stati assegnati compiti sbagliati

L'aria condizionata non funziona.

Quindi la temperatura in ufficio arriva fino a 40 gradi in estate di -5 in inverno.

Il -5 non è buono per la digitazione, in quanto non posso indossare guanti e digitare. Il 40, rallenta il mio pensiero.

Questa è un'opinione molto personale e forse controversa, ma pianificare e pensare troppo alla progettazione anticipata o alla scrittura di codice di "qualità" per tutto il tempo. C'è un detto che "settimane di programmazione possono farti risparmiare ore di pianificazione" che in alcuni casi potrebbe essere vero.

Tuttavia, spesso vedo i programmatori provare a disegnare un buon disegno prima di iniziare a scrivere codice. Trovo che sia più semplice "iniziare", mentre programmerai imparerai di più sul tuo problema e sulla tua soluzione che ti permetteranno di trasformare rapidamente la tua soluzione in un buon design. La maggior parte dei problemi che sorgono sono praticamente inconoscibili all'inizio della programmazione (almeno per la mia mente debole), quindi perdere molto tempo a progettare in anticipo è solo una perdita di tempo.

Questo è anche il motivo per cui non mi piace il TDD, perdi troppo tempo a scrivere i test, il che ti rende meno propenso al refactoring o impiega molto tempo a riscrivere i test. I test unitari sono ottimi per alcuni casi e alcune fasi di un progetto, ma l'inizio di uno non è uno di questi IMHO :)

Fai in modo che qualcosa funzioni rapidamente e miglioralo.

Programmer's Block : a differenza di altri rallentamenti, questo è più difficile da risolvere.