Pensateci, biologi fare tutti quegli esperimenti ... dando una droga per centinaia di topi non possono essere automatizzate. I medici hanno di ispezionare fisicamente i loro pazienti, i professori devono dare lo stesso anno dopo anno conferenze, architetti di disegnare i loro piani in tutte le prospettive manualmente e fino a poco tempo fece cova a mano.
Guardando più corsa delle professioni mulino diventa ancora peggio, di marketing dare lo stesso passo più e più volte, parrucchieri fare praticamente la stessa cosa il giorno dopo giorno, commessi di gestire la spesa stessa per i clienti nello stesso modo tutto il tempo ... le persone in fabbriche ...
Si ottiene l'immagine, il mondo è pieno di persone che fanno praticamente lo stesso giorno cosa dopo giorno, ora dopo ora, per anni, a volte tutta la loro vita.
Immagine tramite Wikipedia
Inserisci programmatori, sulla sinistra del palco.
Ogni volta che facciamo la stessa cosa due volte di fila - cerchiamo di pensare ad un modo per automatizzare il processo. Ogni volta che si scrive il codice fare la stessa cosa, si avvia alla ricerca di una biblioteca. Ogni volta che si avvia progetti su un piede simile, è andare a cercare per un boilerplate.
Immagine di Riebart via Flickr
La vita dei programmatori 'sono dedicati ad eliminare repetivity.
Rimozione dei lavori umili da nostri flussi di lavoro, rendendo la vita più facile per tutti. E 'uno scherzo comune che un programmatore preferirebbe passare una settimana facendo uno script bash che copia incolla lo stesso file due volte e da fare con esso in due minuti.
Inferno, abbiamo anche il DRY ( Non Repeat Yourself ) linea di principio, in cui si afferma in sostanza che è meglio per creare una astrazione contorto che scrivere codice diverso-ma-molto-simile due volte.
Questo ovviamente porta ad un sacco di problemi.
Il progetto software medio è così pieno di astrazioni costruito in cima ad astrazioni che vengono create su di astrazioni che è diventato praticamente impossibile sapere cosa sta succedendo o che cosa il vostro codice sta facendo a tutti.profondità vertiginosa, ma invisibile , tocca questo argomento ed è una lettura veramente buono breve.
D'altra parte, la pigrizia ha dimostrato di essere la forza trainante dietro a molti dei più importanti progressi scientifici e di ingegneria nella storia. E 'molto più facile da usare una ruota che per portare le cose in giro, è molto più facile da usare imbarcazioni di quello che è a nuotare, l'inferno, anche cadere un figlio di puttana solo di una bomba è molto più facile che cadere un migliaio di piccole bombe, se si desidera rovinare una città per alcuni decenni ...
Così forse non è che i programmatori sono pigri. Forse è davvero ingegneri che sono pigri e si dà il caso che in questo punto della storia i programmatori sono il tipo più ovvio di ingegnere di lavoro più follemente verso un futuro migliore e più luminoso. La maggior parte dei campi hanno già sorta di stabilizzato e / o richiedere più tempo per adattarsi ai nuovi strumenti.
Una domanda importante da porsi è: sono programmatori naturalmente pigro? Sono intelligenti le persone pigredisegnato alla programmazione o si tratta di un effetto sociale? Ha origine la pigrizia dal best practice di programmazione? O fare le migliori pratiche di programmazione derivano dalla pigrizia?
Un confronto
Recentemente ho avuto una bella occasione per confrontare come una architettura più importanti va della sua giornata e di come una scienza del computer principale come me passa la sua giornata.
La maggior parte della vita dell'architetto è pieno di lavoro, facendo questo o quel compito intensivo come parte dei suoi compiti. In qualsiasi momento è probabile che sia incollaggio dei pezzi di un modello insieme, disegnare l'oggetto stesso da cinquanta prospettive in autocad, o ridisegnare la stessa cosa ancora una volta in un software di modellazione 3D ... che poi viene importato in photoshop per diventare veramente bella .
Immagine di Jon Olav via Flickr
E 'un fuoco di sbarramento costante. Secondo le mie stime trascorre probabilmente il doppio del tempo a corsi di lei effettivamente frequentanti. [** Ha detto che è in realtà 5 volte di più] E per peggiorare le cose, sempre meglio a questa roba in realtà non accelerare il processo, significa solo sapere alcune scorciatoie da tastiera più e fare meno errori al momento dell'elaborazione.
Competenza non ottimizza la sezione critica a tutti .
Contrasto che con me. Quando non sto frequentando classe sto lavorando su di solito i miei progetti. Perché posso, perché c'è un sacco di tempo. Compiti a casa quando viene intorno, se lo fa, di solito può essere affrontato in poche ore ... anche i progetti più criticamente folle che ci danno raramente prendere più di una settimana di lavoro intenso, due settimane al massimo.
La competenza nella codifica non significa digitare più in fretta (l'equivalente di competenza in architettura). Significa pensare a soluzioni che sono più facili da implementare, utilizzando strumenti che fare metà del lavoro che dovresti fare e così via. Alla fine, come giudicato da internet cazzo concorsi di misura, realizzazione è la parte irrilevante, perché tutti possono farlo. Se hai un giorno, di implementare qualcosa, se hai più tempo si rendono anche bella e modulare e riutilizzabile, e così via.
Fondamentalmente il gioco è fatto attuare la cosa così in fretta, la maggior parte del vostro lavoro è dedicato a rendere più bella la realizzazione. Ma questo non è veramente importante per il compito a portata di mano, lo si fa perché si può .
Sembra quasi come quando i programmatori si annoiano anche di fare le loro implementazioni più bella, si rivolgono alla creazione di strumenti per rendere l'attuazione bella destra fuori del blocco.
E il ciclo si ripete.
Il ragazzo prossimo utilizzerà quel nuovo strumento per realizzare qualcosa di ancora più veloce, quindi iniziare a lucidare fino a quando lui alla fine si stufa e crea un nuovo strumento ancora migliore.
Quindi ... un duro lavoro?
Ma per eseguire il ciclo sulla mia punto originale, quanto lavorando sodo anche in fattore di produttività dei programmatori '? Cosa significa questo per tutti coloro startup lavorano 13 ore al giorno per guadagnare un vantaggio sulla concorrenza? È questo anche un vantaggio da prendere in considerazione?
Immagine di Frodrig via Flickr
Il duro lavoro potrebbe anche avere un effetto negativo sulla produttività dei programmatori . Oscura ottimizzazioni dietro "Oh, io posso farlo a mano, ci vorranno solo dieci minuti" (ci vogliono 20). E la prossima volta che un compito simile rotola intorno dovete farlo manualmente di nuovo e così via.
Ma soprattutto, il duro lavoro rende stupidi. Essere stanchi porta a decisioni sbagliate, anche facendo troppe decisioni porta a decisioni sbagliate ( affaticamento decisione ) come molti studi hanno dimostrato. In realtà, che potrebbe essere il miglior uso di tutte le astrazioni ci piace produrre - lasciare che qualcun altro per la maggior parte delle decisioni così posso concentrarmi solo su quelli critici.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.