Jeg skulle have været forfatter
Neil Gaiman er forfatter, bla. har han, sammen med Terry Pratchett, skrevet den morsommeste og mest eftertænksomme bog der er skrevet om religion: Good Omens[1].
Han har også skrevet en masse andet, men idag røg låget af på hans blog (læs den!) som reaktion på et usædvanligt umodent brev fra en læser.
Læseren piver til Neil Gaiman over at en anden forfatter ikke leverer det bind to der blev lovet til tiden, i en tone der stort set kun kan komme fra en 20-something der stadig bor hjemme i kælderværelset og ikke har planer om at få et job.
Svaret er en meget tiltrængt afklapsning, med en gennemtænkt argumentation.
Der er mange måder og niveauer at skrive ord og sætninger på, fra køkkenets huskeliste over Universets historie på højest 200 ord og Jeg skulle have været taxachaffeur, til historier som Good Omens.
Neil Gaiman forklarer, meget taktfuld, at når man skriver i den tunge ende, er det ikke længere bare noget man gør, nogle gange gør man det ikke og det er der ikke noget at gøre ved.
Der er også mange måder og niveauer at programmere på[2], fra en formel i et regneark til en operativsystemskerne.
Noget af det værste jeg ved, er at starte på et helt nyt, større program, der er tusinde beslutninger at tage og man skal helst få det hele til at hænge sammen på en konsistent måde[3], præcist som en forfatter må gøre det med en novelle: man kan ikke skifte morder undervejs.
Jeg kan 100% genkende Neil Gaimans beskrivelse, nogen gange kan jeg sidde og kigge på min xterm og efter nogen tid konstatere, at det var der der ikke nogen neuroner der gad idag.
Som regel skifter jeg til noget lettere kost, læser fejlrapporter igennem, kører FlexeLint eller kaster mig over den altid alenlange liste over ting jeg skal have læst.
Bortset fra pivede 20-somethings, er der vist ikke nogen der bliver stødt over at en forfatter kan rende ind i en skriveblokering.
Men bortset fra nære venner som også programmerer, har jeg aldrig kunnet få mig selv til at indrømme en "programmeringsblokering".
I stedet har jeg som regel fundet på en eller anden grænseplausibel undskyldning for ikke at være på min plads ("jeg var nødt til at afpolarisere kablerne til backup-centeret"), eller for at rode med noget helt andet.
Er det bare mig der ikke har fået memo'et, eller burde vi programmører prøve at få "programmeringsblokering" gjort socialt acceptabelt ?
Eller burde vi i det mindste hive nye folk i branchen til side og forklare dem, at selvom vi ikke tale åbent om det, så er det helt normalt og ikke noget at skamme sig over ?
phk
[1] Læs den ikke hvis du nyder "Queen: Greatest Hits".
[2] Jvf. debatten om abers evner desangående, vil jeg blot notere at det meste HTML ser sådan ud.
[3] På filmproduktioner har man en hel særlig afdeling der hedder "continuity", hvis job det er at sikre at sceneskift og klip hænger sammen, så overtøj f.eks ikke forsvinder når folk vender sig om.
Om Poul-Henning KampSelvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (16)
Jeg oplever det meget! Jeg skal skrive et nyt program eller rette i et monster, jeg ikke selv har lavet. Jeg sidder og stirrer blankt ind i skærmen, og det går ikke op for mig, at jeg er gået i stå.
Min teknik er at begynde med en række brokker af eksperimenter, jeg er parat til at kassere med det samme. Det kan være en algoritme, et library, en datastruktur eller bare et tilfældigt hjørne.
Faktum er, at det er 10 til 100 gange hurtigere at skrive noget om, end at sidde og tænke sig til en masse løse ideer. Men tanken om, at designet skal sidde i skabet med det samme, er langt mere dræbende end at lave noget klytkode og lave det om.
Men der er en tendens til, at jo dygtigere man bliver, desto større er de blokkeringer, man skal overvinde. Er det hybris eller bare frygten for hybris? Jeg ved det ikke.
Thomas
-
0 -
0
Jeg var til foredrag i dag af Andy Hunt, som har skrevet bogen Pragmatic Thinking and Learning. Jeg har ikke læst bogen, men foredraget var spændende på en meget lidt peptalk-agtig måde (han var ellers en af ophavsmændene til The Agile Manifesto, hvilket nok skulle få hårene til at rejse sig på PHK). Bare et forslag til litteratur-huskelisten.
-
0
-
0
Foredrag med Andy Hunt? Hvorhenne??
Pragmatic Thinking and Learning er en rigtigt god bog - lissom stort set alle andre bøger i The Pragmatic Programmers-serien. God, sund fornuft skrevet ned, så man kan reflektere over det.
Jeg kan rigtigt godt lide hans Novice/Expert gennemgang. I det hele taget er der meget i bogen, som jeg kan bruge, både når jeg skal arbejde sammen med andre og når jeg skal arbejde alene.
Læs den!
-
0
-
0
Jeg taler altid åbent om det, alle omkring mig ved at hvis jeg ikke har knækket nøden eller kan overskue et projekt lige nu så lader jeg det ligge og tager hul på et andet. Så kører det lidt i baghovedet indtil en løsning dukker op.
Har jeg ikke nogle andre projekter (sker sjældent), eller hvis det er så vigtigt at det bare skal løses nu, så lader jeg bare helt være med at lave noget. Det dummeste er at side og nedstire skræmen. Så tager jeg mig en kop kaffe og står og ser lidt ud af vinduet. Og det hjælper, hvis man ikke fokuserer på det så kommer ideerne mærkeligt nok hurtigere.
Men det er bare mine personlige erfaringer. Oftest kommer ideerne hurtigst ved ikke at fokusere på dem.
Det er præcist disse situationer der viser at udvikling er en kreativ process. Skal en musiker skrive et stykke musik så bliver det jo ikke bedre af at han får en deadline på 2 dage og det bliver kun et hit hvis han er heldig og får den gode ide.
-
0
-
0
Det hjælper mig at finde papir og blyant frem, og erklære (overfor mig selv) at papiret kun er til skitser og kladder. Og så prøver jeg ellers at "tegne" mig frem til en struktur der viser min nuværende forståelse af området. Der sprøjter hurtigt en håndfuld A4-ark ud. De er ikke kønne og overholder som regel ingen form for notationsregler. På den måde fastholder jeg nogle tanker og ideer, som efterfølgende kan sammenlignes, afvises eller forfines. Det er min oplevelse at denne uformelle, 'sløsede', tilgang kan være det der 'løsner op', og gør det muligt for mig at beskrive problemområdet og/eller løsningen formelt, med en notation der nu passer - hvis det er nødvendigt.
-
0
-
0
Man skal aflevere til den lovede deadline, og kan man ikke det så skal man lade være med at love deadlines for arbejdet. Det gælder hvad enten man skriver en bog, programmerer, tegner, ...
-
0
-
0
Jeg gør det samme, uanset om det er et program, en struktur en maskine eller hvad pokker, så er det små og store udefinerbare skitser. Gerne af et lille hjørne af projektet, som man kan få på papir, så et nyt, og efter et par papirer begynder det at ligne noget.
Og ellers laver man bare noget andet, indtil det dukker op en morgen når man vågner :-)
-
0
-
0
I love deadlines. I like the whooshing sound they make as they fly by.
Douglas Adams
- Det er (var) vist ikke alle forfattere der følger dén regel. ;)
-
0
-
0
Når jeg bygger programmer op, har jeg også tit oplevet blokeringer imod at skrive noget kode. Det er ofte på et helt følelsesmæssigt plan: "arggh, jeg gider bare ikke skrive den funktion lige nu". Men når jeg har det sådan er det næsten altid fordi den pågældende kode ikke SKAL skrives, men en mindre eller større del af strukturen skal tænkes om og forbedres.
God kode er næsten altid let og sjov at skrive!
-
0
-
0
Men når jeg har det sådan er det næsten altid fordi den pågældende kode ikke SKAL skrives, men en mindre eller større del af strukturen skal tænkes om og forbedres.
Sådan har jeg det sjovt nok også - og det er meget svært at forklare. Som jeg plejer at sige - god kode skal "syltes". Man skal lige vente, til man har lyst. Så bliver koden bedst.
Tager du dig sammen, for at lave koden til tiden - så bliver det ofte mere uoverskueligt, dårligere, og i nogle tilfælde, bliver det mere svært at overskue bagefter, hvorefter kompleksiteten faktisk bliver større, end hvis man havde slappet af, og skrevet koden, når den havde lyst at komme.
-
0
-
0
Så lad være med at sætte en deadline på opgaven eller hvis den bliver givet til dig, så lad være med at acceptere den satte deadline.
-
0
-
0
Som jeg plejer at sige - god kode skal "syltes". Man skal lige vente, til man har lyst. Så bliver koden bedst.
Jep, når vi programmører laver overspringshandlinger, er det en vigtig del af faget :) det må jeg prøve at forklare min chef.
@Jon
Ja, men det er bare rigtig ondsindet når man selv har sagt hvor lang tid en opgave vil tage, og så konstaterer halvvejs henne, at det man har bygget op ikke lige var den smarteste løsning på problemet...
-
0
-
0
ja, jeg kender det godt Lars. Men så kunne man jo sætte en deadline som er langt ude i fremtiden, så der er tid til at gøre det RIGTIGT. Eller også må man bare acceptere at bare det er godt nok, så er det godt nok.
-
0
-
0
Hvor mange chefer eller kunder accepterer en deadline hvor man er (næsten) sikker på at kunne nå det? Altså så langt ude i fremtiden så det virker overkommeligt, med en margen.
Ok, det er sådan set kun et problem hvis der er uforudsigelige elementer, men det er der som regel hvis det er en lille smule interessant.
-
0
-
0
Hvor mange chefer eller kunder accepterer en deadline hvor man er (næsten) sikker på at kunne nå det?
Hvor mange chefer/kunder accepterer overskredne deadlines? Den slags kan nemt koste mere end hvis man slet ikke fik ordren til at starte med. Altså i forbindelse med at andre ordrer fra samme kunde går i vasken.
Men nu sidder jeg også lige nu ude i det Vilde Østen, hvor spaghetti er lige meget, så længe det virker.
-
0
-
0
Tilføj kommentar
