Puoi effettivamente produrre un codice di alta qualità se sei privato del sonno? [chiuso]


37

Ho sentito parlare di programmatori che programmano per due giorni senza dormire e bevendo caffè e Red Bull . Anche in film come The Social Network , in una scena mostrano che Mark Zuckerberg ha programmato per 36 ore. Ho anche letto da qualche parte che in aziende come Facebook, Google, Foursquare , ecc. Possono programmare per più di 24 ore senza dormire.

È davvero vero? Puoi effettivamente produrre un codice di alta qualità se sei privato del sonno? Cose come Red Bull possono compensare il sonno?


4
Holy Crap! Non credo siano umani / programmatori. Possono essere alieni? :)
Gopi,

25
"The Social Network" non è un documentario. Si basa solo vagamente sugli eventi reali relativi alla fondazione di Facebook. Come stratagemma di marketing è stato interpretato l'aspetto della "storia vera", ma ogni volta che l'autore e il regista sono stati messi alle strette da un intervistatore, hanno ammesso che era soprattutto la loro immaginazione su "cosa avrebbe potuto essere".
Charles E. Grant,

8
Forse questo dovrebbe essere spostato su skeptics.stackexchange.com ...
Evan,

6
Alcuni possono farlo, perché normalmente producono un codice di qualità superiore. Sfortunatamente è molto più comune produrre un codice di qualità media anche quando è completamente riposato ...

4
Ho letto questa domanda il giorno dopo essere stato sveglio per 38 ore, 32 delle quali al lavoro. Volevo dire qualcosa al riguardo, ma praticamente qualsiasi tempo non distratto speso per la programmazione fa bene al tuo output, ma quando sei totalmente stanco non sei distratto. Puoi comunque costruire, testare, eseguire il debug, documentare e lucidare se sei ossessionato dal portarlo a uno stato corretto immaginato.
dlamblin,

Risposte:


77

Semplicemente no . La codifica per 36 ore non ha nulla a che fare con la programmazione, piuttosto è un attributo di umano. Pochissime persone possono rimanere svegli per 24 ore e anche quando rimangono svegli, la loro mente perde davvero capacità di risoluzione dei problemi. I conducenti che hanno sonno, semplicemente colpiscono altre macchine. I contabili che hanno sonno, semplicemente fanno errori nei loro calcoli. Anche molti programmatori quando assonnati, scrivono meno codice di qualità.

PS: esiste una malattia chiamata insonnia che ti fa dormire meno. Ma non credo che Google assuma persone con tale malattia. :)


28
+1: I programmatori davvero bravi passano la maggior parte del loro tempo a pensare a un problema prima di toccare un compilatore. Quando lo fanno la soluzione è generalmente ben ponderata, semplice, astratta e facilmente gestibile, la codifica diventa quindi banale.
Justin Shield,

1
@EOL: D abbastanza vero, che dovrebbe leggere "tastiera"
Justin Shield il

4
La mia esperienza personale è che verso le 21:00, dopo l'inizio delle 9:00 (quindi 12 ore), sono stanco, irritabile, non riesco a pensare direttamente e non sono in grado di scrivere nulla o eseguire il debug. La casa e il sonno sono MOLTO più efficaci delle cose sciocche come tirare tutti i nottambuli. Che ciò avvenga, per non dire efficace, è un mito.
quick_now il

3
@quickly_now Esattamente. Il codice peggiora in modo esponenziale in funzione del tempo. Quindi, tecnicamente, potresti programmare fino a quando sarai in grado di sederti davanti a un computer. Ma poi, non venire a SO e chiedere come può essere ottimizzata la tua funzione di ordinamento O (n ^ n);).
Dr McKay,

20
Aspetta, ti è permesso dormire dopo solo 24 ore di programmazione? Ho saputo che questo lavoro suonava pesce quando ho iniziato!
Nick Craver

41

È probabilmente uno di quei miti noti e persistenti. Ne ascolti molto perché è un'idea convincente, ma in realtà non ha basi reali.

Oh, certo, forse un ragazzino appena uscito dal liceo può realizzare quello che sembra essere una sorta di miracolo del codice in 36 ore. Ma il codice è scritto in quel modo mantenibile? È anche leggibile? Scala? Segue pratiche di programmazione sensate? È documentato?

Twitter ha hackerato insieme un sito che ha funzionato, e poi ha finito per riscriverlo nel modo "corretto", perché è caduto quando il carico è diventato troppo grande. Facebook ha messo insieme il loro sito originale in un periodo di tempo relativamente breve per un tale progetto, ma in seguito ha portato un gruppo di nuovi sviluppatori per riscrivere la piattaforma PHP su cui era in esecuzione il sito Web, perché non si sarebbe ridimensionato.

Le eccezioni dimostrano la regola.


6
Si potrebbe anche considerare questi come motivi convincenti per non preoccuparsi di farlo bene la prima volta, almeno non quando si sta creando potenzialmente un nuovo mercato.
Aaronaught,

1
La riscrittura di Twitter non era vera secondo quel post a cui ti sei collegato. Guarda l'aggiornamento.
jjnguy,

@jjnguy: Abbastanza giusto, ma l'esempio sembra ancora rilevante, dati i tempi di inattività e i problemi di scalabilità di Twitter.
Robert Harvey,

2
Potrebbe non portare a un codice di alta qualità, ma se hai le basi e riesci a fare TDD "nel sonno", il codice non sarà poi così male. La cosa grande che codificare quando sei stanco fa che il tuo cervello ha meno probabilità di ignorare i pensieri casuali e quindi diventi più creativo. it.wikipedia.org/wiki/Sleep_and_creativity
Ape-inago

29

L'unica parte che potrebbe essere vera su questo mito è che i programmatori funzionano meglio quando sono ininterrotti per un lungo periodo di tempo. Mentre stai programmando, più cose puoi destreggiarti nella testa, più veloce puoi programmare perché non hai bisogno di cercare cose come gli usi delle API o come una parte diversa del codice è stata scritta da te o da qualcun altro. Trovo che quando vengo interrotto, ci vuole sempre un po 'di tempo misurabile per tornare alla massima velocità, e se sto facendo qualcosa di importante (o divertente), a volte rinuncerò a tornare a casa all'ora normale perché dopo ore è quando le tue interruzioni tornano a casa. Sono stato anche conosciuto per stare sveglio fino alle 3 o alle 5 del mattino per lo stesso motivo.

Tuttavia, come ho detto, la velocità e la qualità del codice dipendono da quanta attenzione stai prestando e da quante cose puoi destreggiarti nella memoria. Quando il sonno diventa un problema, potresti pensare di lavorare a pieno regime, ma in realtà non lo sei. La maggior parte dei software sviluppati come negli esempi forniti, decolla rapidamente ma allo stesso tempo digiuna diventa un'enorme responsabilità e mal di testa da manutenzione.

Puoi sicuramente produrre un sacco di codice se lavori molto e con uno sforzo sufficiente puoi far girare le funzionalità dopo le funzionalità. Ma senza prestare attenzione all'architettura / design non produrrete software facilmente scalabili, gestibili o estendibili. Parlando per esperienza, è MOLTO più difficile pensare a progettare e manipolare componenti / interfacce / strati di astrazione nella tua testa (o sulla carta) piuttosto che continuare a scrivere codice puro.


3
+1 per aggiungere l'idea che il tempo ininterrotto può essere tempo di qualità (ma solo a dosi ragionevoli).
Eric O Lebigot,

1
La concentrazione di @DXM aiuta molto. Qualità del tempo su quantità di tempo
lovesh

1
@lovesh - Non direi esattamente questo. (qualità del tempo) x (quantità di tempo) = risultati. L'aumento di uno dei due aumenta i risultati. Tuttavia, aumenta nel tempo, infine diminuisce la qualità. Il nostro obiettivo è sempre quello di massimizzare i risultati.
DXM,

13

L'intera cosa suona solo come un'esagerazione di essere "nella zona". Quando sei completamente concentrato, come programmatore, il tempo è distorto, i minuti diventano secondi, ecc. Probabilmente sei al massimo della tua produttività. A volte è difficile entrare in quello stato, e abbastanza facile uscirne (principalmente fattori esterni), ma quando lo sei .... wow!


2
Stavo scrivendo il mio post pensando a come includere la frase "nella zona" quando hai pubblicato questo.
Knb

Lo stavo solo postando come commento perché a questo punto tutte le risposte sono "anche io", ma ho pensato che fosse strano che nessuno avesse ancora menzionato il fenomeno.
MPelletier,

2
Infatti, se ti trovi nella zona, è molto più facile programmare molto a lungo. Tuttavia, perdere la concentrazione dopo aver codificato così a lungo è sgradevole per non dire altro.
Dal

10

Posso - e lo ho fatto a volte - programmare per 36 ore di fila.
Penso che la cosa peggiore che abbia mai vissuto sia stata una settimana con circa 10 ore di sonno o giù di lì.
Per me, la caffeina e le bevande energetiche non hanno aiutato. In effetti, a lungo termine, la caffeina può avere effetti piuttosto negativi. Il mio consiglio è di bere molto . Ti mantiene idratato e le passeggiate in bagno sono un piacevole effetto collaterale: allunghi un po 'le gambe e fai automaticamente brevi pause.

Detto questo, lo trovo sempre più difficile. Suppongo che sia una capacità, che è prosciugata e infine esaurita. E forse ha alcuni effetti negativi sulla salute - fisici o mentali, a lungo o breve termine, non posso dirlo.
Quello che posso dire è che ti senti come uno zombi e continuerai a sentirti così i giorni dopo una tale maratona. Personalmente, ho avuto un grande esaurimento dopo averlo fatto frequentemente per circa un anno.
Vale a dire: alcune persone possono lavorare in modo efficiente per un periodo di tempo simile, ma ha un costo .
Di solito era la conseguenza di una cattiva pianificazione e non avendo avuto esperienza nel colmare le lacune lasciate dai lead non tecnici del progetto, era l'unica opzione.

Ora raramente troverai codice di qualità prodotto durante tali maratone. Tuttavia, la causa principale di ciò sono le circostanze in cui si verificano quelle maratone: Situazioni in cui è necessario fornire funzioni X, Y e Z in un arco di tempo molto breve. A quel punto nessuno si preoccupa davvero della qualità del codice, motivo per cui accumuli un sacco di debiti tecnici attraverso correzioni rapide e altri hack.
Allo stesso tempo, questo indica le prestazioni intatte del cervello: correzioni rapide e hack richiedono sia una visione d'insieme che una creatività.

Non dovresti dimenticare che quel codice di qualità viene raramente scritto in una sola esecuzione. Soprattutto se il codice ha una lunga durata. La qualità del codice si ottiene attraverso la revisione e il refactoring. Nessuno si preoccuperà di farlo 48 ore prima della scadenza.

La linea di fondo è: dovresti lavorare solo il più a lungo possibile e non più a lungo . Se riesci a lavorare solo per 4 ore, allora ok. Fai una pausa e lavora in seguito. Cercare di rimanere sveglio per 36 ore entro le quali si ottengono 8 ore di lavoro è inutile. Otterrai il doppio del lavoro se fai 4 sessioni di 4 ore ciascuna e usi le restanti 20 ore per rigenerarti.
Se riesci a lavorare così a lungo, significa che sei più flessibile nel rispondere alla sottovalutazione. Tuttavia, la soluzione a lungo termine sta migliorando il processo di pianificazione e stima. Se ciò è impossibile sul posto di lavoro, cambiare lavoro. Se le persone si aspettano che tu lavori così a lungo, cambia lavoro. Non devi dimostrare nulla a nessuno.


Sembra una grande bugia lontana. Nessuno può lavorare per 36 ore e effettivamente produrre qualcosa di utile
BЈовић

@VJovic: Beh, se lo dici tu, allora credo che dovremo crederci tutti;)
back2dos

5

I bravi programmatori possono davvero programmare per 36 ore. Ciò non significa che possano produrre il loro miglior codice di qualità per 36 ore. Sono Non un buon programmatore, e l'ho fatto più volte al college, e anche un paio di volte nei miei anni '30 quando si cerca di bug fix per le scadenze delle navi. In genere è un'idea stupida e riflette scarse capacità di pianificazione e programmazione.


1
E solo perché si può non significa che si è efficace , soprattutto dopo circa il marchio 12 a 15 ora.
quick_now il

10
I programmatori errati possono anche programmare per 36 ore. La durata del tempo di programmazione non ha nulla a che fare con la qualità del programmatore.
Marjan Venema,

5

Puoi rimanere sveglio e lavorare per 36 ore se sei sano. Ma in questo momento non scriverai il tuo codice migliore o risolverai problemi molto complicati. Di tanto in tanto ho lavorato per ore molto lunghe. Il più delle volte questo era per rispettare alcune scadenze. Ma il lavoro consisteva principalmente nell'aggiungere funzionalità minori come la stampa di alcuni elenchi, la lucidatura di alcuni layout. Niente in cui hai bisogno di molto pensiero, più come un sacco di battitura a macchina. Le caratteristiche principali e le parti complicate dei programmi erano già finite.

A volte la tua mancanza di concentrazione è il motivo principale delle lunghe ore. Una volta abbiamo avuto una scadenza il giorno successivo. Dopo una giornata già molto lunga avevamo finito tutto ed erano le 2 del mattino. Rimaneva solo un brutto bug. Il mio capo aveva un appuntamento con il cliente alle 9 del mattino, quindi c'era un sacco di tempo. Mi ci sono volute diverse ore per trovare e riparare qualcosa che altrimenti avrei riparato in mezz'ora. Sapevo per certo che sarei stato in grado di trovarlo comunque e non c'era motivo di deludere il mio capo, dato che in qualche modo la notte era andata via.


5

Sì. Molte informazioni aneddotiche indicano che è possibile. Dubito che chiunque possa fisicamente abituarsi alle maratone del lavoro. I tirocinanti medici trascorrono questo tipo di ore.

È probabile che tu faccia più errori, probabilmente. Immagino che tutto questo presupponga che tu possa scrivere il codice di qualità in primo luogo. In queste situazioni, sei sotto la pistola e vuoi solo farlo funzionare. La qualità non è una considerazione. Lo ripareremo dopo aver ottenuto il finanziamento.


4
+1 per il riferimento al personale medico. Penso che i medici ospedalieri oberati di lavoro lo stiano facendo regolarmente ... lavorando a turni notturni stressanti seguiti da turni diurni ... un modo sicuro per essere bruciati dopo alcuni mesi o addirittura anni.
Knb

6
Ora c'è un pensiero confortante;) Stagisti privati ​​del sonno e persone con condizioni di salute potenzialmente letali. Prova a correggere quegli errori "più tardi".
Leigh,

1
I rischi posti dagli stagisti privati ​​del sonno sono ben riconosciuti e molte organizzazioni stanno eliminando la pratica. In parte dura perché i dottori che stanno facendo la formazione hanno fatto quei lunghi turni.
BillThor,

4

Non è impossibile ed è successo davvero. Poiché il capitolo è lungo, vorrei citare il paragrafo attuale:

I membri del gruppo affiatato si definivano "hacker". Nel tempo, hanno esteso la descrizione di "hacker" anche a Stallman. Nel fare ciò, hanno inculcato Stallman nelle tradizioni etiche dell '"etica degli hacker". Essere un hacker significava molto più che scrivere semplicemente programmi, Stallman ha imparato. Significava scrivere i migliori programmi possibili. Significava stare seduti in un terminal per 36 ore di fila se era quello che ci voleva per scrivere i migliori programmi possibili. Soprattutto, significava avere sempre accesso alle migliori macchine possibili e alle informazioni più utili. Gli hacker hanno parlato apertamente di cambiare il mondo attraverso il software e Stallman ha imparato il disprezzo dell'istintivo hacker per qualsiasi ostacolo che ha impedito a un hacker di soddisfare questa nobile causa. Il principale tra questi ostacoli era il software scadente,

Naturalmente questo non significa che questa sia una regola per tutti. Alcune persone possono farlo, mentre altri no. La cosa più importante è non essere interrotto e lavorare durante i periodi in cui ti senti molto produttivo. Quindi, puoi provare tu stesso e trarre le conclusioni :)


3

Immagino sia possibile, se sei una macchina, non dubito che qualcuno possa farlo. Ma l'esperienza mi ha insegnato che la stragrande maggioranza dei programmatori scriverà codice peggiore poco dopo le 8-10 ore e un codice orribile dopo le 16 ore.

Le poche volte in cui il nostro team è stato costretto a fare un giro notturno, abbiamo effettivamente ottenuto un codice che doveva essere ripristinato.


bene se la qualità è influenzata come mai i ragazzi di Facebook fanno tutto il tempo (almeno si dice che lo facciano)
amore

4
... basandomi sulle mie recenti esperienze con Facebook, direi che è abbastanza coerente con il mio argomento. Ho ricevuto circa 3 o 4 errori usando diverse parti di Facebook oggi.
Kaleb Brasee,

3
@lovesh "Si dice che lo facciano" e "lo fanno" sono due cose diverse.
Scott C Wilson,

3

Dubito che sia sincero. Infatti, nonostante i miti e le storie sulle persone che raggiungono X, Y e Z siano state svegli per 24 ore, si trovano in circostanze estreme e sono rare.

Nel lontano passato, ero solito fornire un pool di battitura a un difensore che occasionalmente aveva persone che tiravano tutti i vicini per cercare di tirar fuori cose per momenti particolari. Chiunque abbia fatto ore folli nella stesura di documenti, in genere ha finito con l'invio di quei documenti per fare in modo che le loro modifiche durante la notte venissero annullate. A mio avviso, non è possibile esibirsi costantemente ad un livello elevato per più di circa 12 ore alla volta (e anche questo è eccessivo) sopravvivere a una mancanza di sonno aumentando i livelli di caffeina. Penso che sia una storia che alla gente piace raccontare, ma se sono onesti, ammetteranno che il loro lavoro medio su sessioni a lungo raggio, indipendentemente da quale sia il lavoro, sia che si tratti di codificare o scrivere documenti legali, raramente, se mai, è abbastanza buono per abbinare la loro produzione se avessero un riposo adeguato.

Non c'è niente di speciale nei programmatori, non importa quanto siano bravi, come i conducenti, gli operatori di macchinari pesanti, sono soggetti a fatica e sarei sbalordito se qualcuno potesse dimostrare che un programmatore potrebbe fornire un output di alta qualità senza riposo entro circa 12 ore .


2

Quando studiavo programmazione all'università c'erano alcune sere in cui mi sentivo più produttivo che durante il giorno. Ha a che fare con il fatto che di notte ci sono meno distrazioni, l'erba mi ha fatto sentire abbastanza a mio agio da stare fermo e in realtà non mi sono alzato quel giorno fino alle 14:00, quindi non ero troppo stanco. Potrei programmare fino alle 8 del mattino prima di essere follemente affamato per la mia colazione. Detto questo, il giorno dopo sarei crollato mentalmente alle 17:00 e non c'era modo di essere produttivo. Programmare di notte può essere più produttivo, ma privarti del sonno non aumenta mai la qualità del codice e non penseresti mai di essere stanco durante la programmazione.


2

Io e molte altre persone creative dimostriamo le caratteristiche della personalità bipolare. Durante la progettazione di software, tendo a seguire l'algoritmo di Feynman:

  1. Scrivi il problema. (Minuti)

  2. Pensa intensamente. (Tra giorni e anni)

  3. Scrivi la soluzione. (giorni)

Un episodio ipomanico con un sonno drasticamente ridotto (caffeina o no) è solo il biglietto per finire al terzo posto.


2

Si prega di consultare questo post correlato in Skeptics.SE: il Ballmer Peak è reale? , e in particolare questa risposta di ESultanik .

Perché penso che queste due domande siano correlate? Mi sembra che la menomazione causata dalla privazione del sonno sia in qualche modo simile all'ubriacarsi, anche se non ho riferimenti a sostegno della mia richiesta.

Citando dal riferimento citato da ESultanik,

... un modesto consumo di alcol inibisce aspetti della creatività basati principalmente sul processo secondario (preparazione, alcune parti dell'illuminazione e verifica) e disinibisce quelli basati principalmente sul processo primario (incubazione, alcune parti dell'illuminazione e restituzione).

Direi che si potrebbe essere migliori nel creare modelli di architettura astratti mentre si è privati ​​del sonno, ma l'attuale codice sorgente digitato sulla tastiera sarebbe ancora inebriato.


2

Quando uno è costretto a programmare per 36 ore, di solito è a causa di una scadenza per spedire il prodotto. Quando si è in una scadenza del genere, la qualità del codice è in genere la prima cosa da buttare fuori. "Basta farlo" è il mantra. "Lo ripareremo nella versione 2" è un altro mantra.

Quindi, in genere, quando si codifica per 36 ore di fila, la qualità del codice ne risente ... ma non importa dal punto di vista aziendale ... perché se non spedisci qualcosa, anche qualcosa rotto, potresti non essere in affari per farlo bene.

Quando uno VUOLE codificare per 36 ore di fila, è perché hai un forte picco creativo in corso e non vuoi interromperlo. Non scriverai un codice di qualità per quelle 36 ore, ma scriverai un codice creativo. Poi torni più tardi e guardi quel codice e ti chiedi come funziona.

La creatività è una di quelle cose che spesso arrivano a scatti. Non puoi controllarlo, quindi ne approfitti quando si mostra. Puoi sempre correggere il codice quando sei meno creativo.


1

Qualche mese fa, ero fuori con i miei colleghi a bere. Il giorno dopo siamo tornati in ufficio sospesi ... ma con nostro grande stupore abbiamo chiuso un numero record di bug.

In apparenza, questi bug non sono stati facili da trovare e la maggior parte non ha avuto alcun passo di replica, tuttavia essere ancora "fuori di testa" deve farci "pensare fuori dagli schemi" quando si trattava di correggere i bug.

Anche se non eravamo "privati ​​del sonno", non eravamo ancora nella giusta mentalità per lavorare sul codice ... è solo bizzarro quello che è successo quel giorno, lo citiamo sempre.

Oh, e per i più inclini la maggior parte di noi stava facendo il massimo su JD & Coke :)


+1 Non sono sicuro che questo risponda alla domanda, ma mi è piaciuta comunque la risposta :-)
Danny Varod

0

Penso che lavorare in modo produttivo per così tanto tempo senza dormire a lungo sia impossibile per la maggior parte delle persone.

Ma penso che tu possa fare un lavoro straordinario con, per esempio, 3-4 ore di buon sonno. Questo funziona anche per diversi giorni consecutivi di intenso lavoro (intellettuale) con poco sonno.

Tuttavia, per me, questo deve essere seguito da un periodo di recupero in seguito; diciamo un paio di notti con le solite 7-8 ore di sonno.


Questo è il tipico programma di uno studente CS, vero?
user16764,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.