15. Kodlukter
lyssna! 
Anton har blivit med bloggpost om “code smells” i React så vi pratar bland annat om hur man kan tänka för att förhindra för stora useEffects, useReducers okändhet, att få perspektiv på sin egen kunskap och att skriva för att lära sig. Dessutom är Anton exalterad över möjligheten av bygga egna “renderers” för React och det leder in på en diskussion om motivation för att nörda ner sig och skillnaden på att bygga produkter eller lära sig detaljer. Till sist en gemensam liten rant om att inte alla utvecklare bloggar, poddar eller producerar andra saker “utanför jobbet”, och att det är 100% OK.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Avsnittets skämt:
Varför går det så dåligt när programmerare testar att baka surdegsbröd?
Ingen jest.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Varför går det så dåligt när programmerare testar att baka surdegsbröd?
Jag vet inte.
Ingen jest.
Det är ju fan bra! Jag blir mer och mer imponerad tror jag.
Ja men nu är vi verkligen ner i botten.
Ja, nu är vi bra.
Nu är de snart slut, nu är det panik.
De bästa skämten är ju skämt som man kanske måste förklara för vissa, eller hur?
Ja, men det här funkar ju för att den är dubbel.
Jag har ju inte gestisur deg och jag slänger in testar.
Ja, det är sant.
Det var bra, det lever upp till.
Jag måste också börja leverera sen.
Två skämt kanske.
Och sen ligger du på tolv andra.
Eller vad vi nu är uppe för avsnitt.
Välkommen till ett nytt avsnitt av ASTF.
Avsnitt 14 kanske. 15.
Jag vet inte riktigt.
Vi behöver inte säga avsnittsnummerna.
Efter det här så kommer aldrig någon höra avsnittsnummer igen.
- Oj, press. Okej.
Ja.
- Vi tänkte väl att vi skulle snacka lite React, typ.
- Ja, för du skrev ju en bloggartikel nyligen om
smelly patterns i React-contenter.
- Exakt.
- Som blev väldigt uppskattad.
Som jag läst och tyckte var riktigt bra.
- Ja, men jag har filat på den här artikeln sen maj, tror jag.
att jag skapade det initiala dokumentet.
Och sen har vi liksom inte behov av det.
Jag tror att från början hade jag kanske 12 olika patterns i den.
Och jag tror att jag landade på sju nu, när jag faktiskt publicerade den offentligt.
– Jag tror också att du efterfrågade lite tips i vår slackkanal på jobbet,
och så blev det lite interna slitningar i slacktråden kring vilka patterns som är bra och vilka som inte är bra.
Nej, men jag tror att mycket var också vad som är ett pattern.
Eller vad som är, inte pattern, men kanske mer vad som är en codesmell.
Som liksom är det jag egentligen skrev om.
För att pattern är ju en grej, men codesmell är mer så här...
Indikerar något som är...
Något underliggande som kan vara ett problem.
Ja.
Typ.
Det behöver ju i sig inte vara ett problem egentligen.
Men om man gör det så kan det liksom leda till fler problem.
Eller liksom, ja.
Det är någonting som luktar lite illa här, så att säga.
Ja.
Jag skrev den och den blev väldigt uppskattad, vilket var kul.
Jag tycker det är ganska kul att diskutera sådana här grejer.
Sen var det inte så många som inte höll med mig, vilket var lite tråkigt.
Men vi kan ju inte diskutera några nu.
En som jag tycker är mest, det var ju väldigt många som var uppenbara.
Alltså typ skriv små komponenter. Eller jag vet inte vad jag skrev, jag kommer inte ihåg hur jag skrev riktigt.
Men tips här, använd use reducer istället för att använda jättemånga use state.
- Ja. - Typ. Eller dela upp din ljuseffekt i flera istället för att göra en jättestor.
Typ så. - Ja, det är intressant ändå att du säger det. Det är många självklara, för det där är inte alltid självklart skulle jag säga.
- Nej, men det kanske inte är. För att när du säger det, jag upptäckte också, särskilt den här ljuseffekt, att det var ganska många som kommenterade
"Aha, kan man ha flera ljuseffekt?"
Och det känns ju som en väldigt misslyckande från Reacts sida,
alltså dokumentationens sida, eller liksom community-sidan, att inte ha kommunicerat det.
Jag tror kanske att de flesta fattar det efter ett tag,
men när man börjar med det så kan det nog vara ganska enkelt att säga "Okej, det här är den här komponentens effekt".
Ja, alltså jag vill ändå minnas att de har varit ganska tydliga med,
i alla fall i sina initiala presentationer,
av Hux att du kunde ha flera ljuseffekter i samma som gör olika saker.
För att det är i alla fall så jag har lärt mig det, tror jag.
Däremot så har jag märkt själv att när jag väl sitter där och bara kodar
så kan det vara väldigt lätt att glömma bort den grejen
för att man börjar med en ljuseffekt och tänker "det här ska jag göra"
och sen så blir det "ja just det, jag skulle göra det här med"
och så stoppar man bara in det i samma ljuseffekt
så jag tror det är lätt att hamna i det tillståndet.
Ja, men exakt. Det är knepet som jag skrev om nu som jag tycker är ganska bra,
är att titta på den här dependency-arrayen och se vad innehåller den,
och läsa då, när den här ändras, gör det här. Alltså när dependencies ändras, gör det här.
Och om man då lägger in massa eller och där, då vet man att det är ett problem.
Ja, precis. Det var ett riktigt bra tips, tycker jag. Jag har också funderat på om det kan vara,
Jag tittar på om det kan vara, för jag har sett nu i applikationen jag sitter i nu så har vi en massa varningar på att
det här är inte med i dependency arrayen, det borde vara med eller det borde inte vara där.
Och så vet jag att jag var inne och skulle stoppa i någon i någon ljuseffekt och sådär
"Det här blir nog en lilla loop!" men nu när jag plockar bort den igen.
Men nu när jag tänker på det så var det nog fem, sex stycken saker i dependency arrayen redan.
Så jag borde nog gå tillbaka in där och faktiskt splitta upp det istället.
Så kanske det löser sig.
Ja, men exakt. Det är väldigt lätt. Det skulle vi också säga att det skulle kunna vara en codesmell i sig, att man inte stoppar in alla dependencies.
För i 99% av fallen bör man kunna lösa det med alla dependencies i den.
Ja, det är någonting som händer i den här komponenten. Jag får nog in och kika på det.
Det finns ju ESLint-pluginet som React har, alltså React Rules of Hooks, heter det kanske.
Som gör de här klagomålen på att du har glömt att stoppa independences, eller du har villkorat en hook,
alltså du har en hook inuti en if eller något.
Och den är ju skitbra, och den ska man ju typ bara lyda rakt upp och ner.
Ibland blir det lite krångligare, för ibland blir det kanske att du måste
wrappa en funktion i useCallback eller något sånt
för att den inte ska trigga din useEffekt och sånt.
Så det kan ju bli... Jag vet att många klagar på det, att det blev ganska mycket så här
useCallback all the way up, liksom.
Alltså man måste... Den funktionen i sig beror på någonting,
så måste man stoppa in den i Defendency Array, så måste man kanske useCallback på någonting som man gör där,
eller useMemo, eller så här.
att det blir hela vägen upp i komponentträdet, man ska sprinkla med massa just callbacks eller just memos.
Men för mig så känns det vettigare att göra så ändå än att
liksom disable den här typ att
du får inte ha,
du får inte hoppa över grejer
i dependency-arrayen.
Nej, alltså
det är intressant för där är,
jag har läst också, de pratar mycket om att så här,
För från början var det mycket att om du bara vill att den ska ske på mount
så ska du stoppa in en tom dependency array.
Men egentligen om du inte klarar dig utan infinite loops och grejer utan den tomma arrayen
då är det också någonting som är fel.
Det är många sådana här saker som är tydliga.
Och vad är det de säger?
You should love React hooks unconditionally.
Ja.
Jag kanske missar halva av den här nu.
Men någonting som... Och det är ju tydliga regler och det är jättebra, men i stundens hetta när man väl sitter där och någonting inte funkar eller det är en bugg och du har en enormt komplex komponent som du bara vill ska funka, så är det så jävla lätt att bara frångå allting ändå.
Ja, och sen handlar det ju också om att lösa problem. Alltså jag har ju definitivt gjort det en massa gånger själv, att man bara "Jag orkar inte tänka ut någon lösning just nu" och så sätter man en liten kommentar "ESL-intensable" och så går man vidare i livet så länge.
Men förmodligen så kommer man tillbaka till den någon gång när man bara "Vad fan har jag gjort här?"
Och så är det något som är knas eller något som inte funkar eller så.
– Eller så byter man uppdrag innan dess.
– Fördelen med att vara konsult är att man kan dra när man har byggt massa skit.
– Lämnar dig 15 codesmäll så att man drar.
– Ja, det är bara dåliga exempel på hur man är konsult. Det är exakt hur man gör.
En annan som jag tycker är ganska intressant som kanske var mest diskussion kring var att jag tycker inte att man ska
returnera JSX från funktioner i en komponent.
Nej.
Och den verkar kanske mest kontroversiell av de här.
Många tycker att det kan vara bra att dela upp vad returmetoden innehåller så att den bara anropar lite andra funktioner så att det blir lättare att läsa.
Men jag tycker, i min erfarenhet i alla fall, så blir det bara jobbigare.
Alltså för det första så tycker jag att det är ett tecken på att det ska vara en enkomponent.
Istället för att ha en inline-funktion i din komponent som returnerar i J6.
Då ska det oftast brytas ut till en enkomponent.
Men sen tycker jag också att man tjänar inte så mycket på att ha en kort return i sin komponent.
Alltså det finns ingen benefit med att en return är fem rader jämfört med 50 rader
om det bara är ganska straightforward JSX.
För att det blir fortfarande contextswitchande
om du måste hoppa mellan massa olika ställen för att läsa vad returnen returnerar.
Ja, det är intressant för att jag läste det här och funderade lite på det
för jag tror att organiskt har jag nog slutat att returnera JSX i små funktioner i komponenten.
Det är ingenting jag egentligen har tänkt på.
För i början, way back, när jag började med React, då blev det ofta så att jag delade upp och returnerade JSX i funktioner.
Jag tror att det var för att då var det inte så mycket komponenttänk kanske som det var en funktion ska göra en sak.
Jag vet inte var det var som gjorde det, men det har blivit mycket mer för mig, som du säger, att man pratar om...
Ja, vad heter det? Det finns ju någonting när man sprider ut saker på för mycket ställen, så blir det...
Ja, exakt.
Ja, det finns ett ord och jag kommer inte att höra det.
Nej, inte jag heller.
Men som du säger, det blir context switch. Du måste hoppa mellan väldigt många olika delar för att få ihop helheten.
och det gör det mycket svårare att få en överblick.
Jag brukade tycka att det var jobbigt att ha mycket conditionals i ISXN direkt,
för jag tyckte att det blev mycket svårare att läsa,
speciellt när det är väldigt stora bitar,
men det är mer straightforward tycker jag nog nu.
Ja, men exakt. Jag tycker jag är helt på samma sida.
Jag har också varit där man skrev en massa funktioner som returnerade ISX.
och jag sutter i projekter, jag har väldigt mycket sådana grejer.
Men, jag tror att det kom ganska naturligt för mig,
från varje område, exakt som för dig också,
men sen att man har tänkt mer aktivt på det,
när jag stött på det nu, att "oj, det här känns inte bra".
Och att det är därför jag kanske skrev ner det i den här listan,
jag tänkte på nu.
Men ja, jag tycker det är svårt.
Men det är lite som du säger, att när jag skrev det här nu
och publicerade den, fick ganska mycket kommentarer som
ger en perspektiv på att det är så lätt att glömma på vad folk kan.
Jag kanske tar för givet att folk känner till att det finns en ljusreducer.
Eller jag tar för givet att folk vet att man kan skriva två ljuseffekt.
Och det är så jävla lätt att hamna där och bara tänka att "Vad fan, folk fattar ju det här".
Men det var skitmånga som sa "Aha, ljusreducer, aldrig hört talas om".
Den är ju skitnice.
Då behöver man kanske inte köra Redux bara för att man vill ha en reducer.
Och det perspektivet ger ju extremt mycket.
Ja, ibland tänker jag att man bara glömmer bort saker.
Till exempel om jag inte behövt använda det tidigare,
då när jag väl hamnade i en situation där jag sa
"Det här är klurigt, det här skulle jag säkert kunna lösa med någonting
som jag visste en gång i tiden fanns, men jag har lite glömt bort att det existerar,
som kanske en use reducer."
Men när jag satt här sist också och bara "Fan, use reducer, just det, den finns!"
Så försökte jag göra det, så försökte jag på något sätt returnera JSX i min Youproducer.
Och jag bara, "Det här, nu har det gått överstyr."
Så kände du dig jävligt smart.
Ja, brukade jag göra det. Jag bara, "Det är ett jävla state, jag vet inte vad jag håller på med."
Men klockan var typ sju på kvällen också, borde inte koda då.
Nej, men det var någon som kommenterade det också, att de gillade att skapa upp sin JSX och sen lägga den i state.
Alltså i typ en just state.
Och sen bara rendera den, lagt upp och ner.
Och då hade de liksom funktioner för att spara ner det där i statet.
Det funkar ju säkert, men det blir ju inte tydligt.
Alltså så här, okej, här hämtar du state. Vad är det här statet?
Och så bara, aha, okej, det var massa J6 som skapades upp på ett annat ställe.
Då tycker jag det är vettigare att man har statet och sen i sin render så mappar man det här till en komponent.
Till exempel om det är en lista eller en massa saker, eller vad det kan vara.
Ja, alltså för mig, den lösningen på det här blev att jag istället skapar ett state som innehåller en sträng
på vilken komponent jag vill rendera och sen så i min JSX så blev det en massa conditionals istället.
Sen om jag tycker det är det bästa jag gjort hittills, det återstår att se, men det var det minst komplexa, mest straightforward,
mest läsbara som jag kom fram till då.
Ja, exakt.
Jag tycker det är väldigt kul att skriva, även om jag väldigt sällan, som sagt, har varit uppe från maj och skrivit.
Så jag får en burst av produktivitet ibland, så skriver jag några stycken och sen går jag vidare i livet ett tag.
Det är väldigt kul att skriva, för man lär sig ju extremt mycket själv.
Jag har gått igenom, okej, men hur skulle jag kunna presentera det här som det bästa exemplet, till exempel.
Nu är jag inte helt nöjd med exemplen i det här, jag har något exempel på
composition, alltså att man istället får bara skicka in massa olika proppar,
så skickar du in barnkomponenter som renderas istället.
Och det tycker jag inte är helt straight forward, även om det kanske får,
man fattar poängen, men jag tycker inte det är det bästa exemplet jag gjort.
Men som sagt, bara för att lära sig saker är så jävla skönt att skriva saker.
Ja, och det kan man väl också koppla till lite som förra avsnittet när vi snackade om att hålla föreläsningar.
För att det blir så här, ibland så känner jag att jag har en inneboende idé kring hur saker funkar,
men så länge jag inte behöver verbalisera det eller faktiskt verkligen förklara det,
så är det fortfarande bara ett litet ludd.
Så att dels om man skriver ner saker som du har gjort eller skriver en föreläsning
eller kanske bara ska förklara någonting för en annan utvecklare,
så tycker jag på något sätt att det är då man verkligen lär sig någonting.
Ja, men så funkar det verkligen för jag internaliserar väldigt mycket
när jag faktiskt skriver ner eller använder det.
Exakt som du säger, jag vet att det funkar ungefär så här.
Men fram tills man faktiskt gräver ner sig i det, då vet man inte på riktigt egentligen.
Det är ganska många som håller presentationer som ibland kör så här,
Jag skulle vilja hålla en presentation om React, till exempel, för att jag vill lära mig om React.
Och de kanske inte kan någonting om React innan.
Och sen bara, "ja men okej, då sätter jag mig och tvingar mig själv att lära mig om React för att hålla den här presentationen".
Kanske inte en approach jag skulle ta.
Men jag förstår ändå att det funkar.
Ja, det gör jag också.
Men jag är ju inte så bra på att ta in information.
Jag förstår knappt att jag klarade skolan för att så fort jag öppnar en bok som innehåller fakta så tenderar jag att somna.
Jag har somnat i skolböcker.
Det är lite samma sak när jag ska lära mig.
Jag ser en enorm textmassa i någon blogginlägg eller dokumentation och då bara zonar jag ut, panikar lite och stänger ner det.
Det är ju perfekt då att du kan använda min bloggpost som kvällslektyr för att bli trött.
Ja, men det är ändå på en nivå där jag känner att jag har lite koll på vad som står i det.
Jag fattar det utan större ansträngning.
Det är inte så att jag ska lära mig fysiska lagar i en årlig grej.
Nej, fy fan.
Jag har en idé på ett tåg jag vill ha.
Jag har en ganska tydlig idé på hur jag vill lägga upp presentationen och allting sånt.
Men jag kan liksom inte riktigt vad jag ska prata om.
Sen har jag såklart inte skickat in det här någonstans.
Jag ska hålla taket, utan jag vill ju lära mig först.
Men det är ju liksom om typ "renders" i React.
Eller, ja, vet du vad en render är?
Typ...
- Ehh, nej...
- Okej, men så här. React DOM-paketet är en render.
Så att den renderar React till DOMen i browsern, liksom.
Och sen har vi React Native. Det är en renderer, så att du använder React fast du renderar native saker istället.
Och jag tycker det här konceptet är så jävla intressant, för det gör att React är plattformsagnostiskt.
I det att du skulle kunna skriva en renderare för React och använda det vart som helst.
Ja, för att core-paketet är det som är React.
Exakt, och jag tycker det är så jävla coolt att verkligen ha sålt mig mer och mer på React.
För även om jag tycker att andra ramverk är också jävligt nice, typ You Will Svelte eller vad man nu ska säga.
Så tycker jag att React har liksom, det finns liksom potentialen att det skulle kunna finnas överallt.
Och ett exempel som jag anledningsvis upptäckte det här var för att jag höll på med ett bibliotek som heter React 3 Fiber.
Som används för att skriva 3JS, som är 3D på webben.
Ja, det är väl WebGL-baserat.
Ja, precis. Det är väl JavaScript och WebGL typ.
Och är liksom standard för att göra det där på JavaScript skulle jag säga.
Har funnits i typ 15 år.
Och då är det en snubbe som heter Paul som har skrivit en renderare till React som ligger ovanpå det här.
Som då gör att du kan skriva liksom 3js i React.
Och det som händer är typ att du kan ta alla liksom,
Det som finns, säg att det finns en box till exempel, eller en box geometry finns det i 3js
Och då kan man bara skriva en J6 tagg som heter box geometry
Och då förvandlar den här renderaren det till 3js, så att den 3js förstår det
Medan React tar hand om allt annat
Så att då tar React hand om livscykeln för komponenter, du kan dela upp det i komponenter
Du kan använda alla hooks för att hantera state, du kan använda saker som att använda pointer events och hover-effekter och sånt som inte finns i 3js egentligen för att det är WebGL.
Men i och med att React hanterar sånt så funkar det bara.
Och jag tror att första implementationen som han gjorde var typ så här, jag tror att det var 160 radikal för att få det att funka.
Och jag tycker att det är så jävla coolt att det bara går att göra såna grejer och sen skriva React.
Folk som kan React kommer att fatta det där också, så länge man vet vad sakerna heter i 3JS.
Det är en intressant grej.
Jag tänker ändå att det måste finnas regler, speciellt om man vill ha en väldigt performant rendering,
för att det krävs ganska mycket att rendera 3D.
Ja, precis.
Jag tänker att 3JS har hand om sin rendering,
Och sen om jag nu har fattat det rätt, nu har jag som sagt inte grävt ner mig jättemycket,
men då...
React-biten lägger liksom inte på någon performance overhead.
För det enda den gör är liksom att reagera på events.
Så att event-loopen och allting sånt, och renderingsloopen, det sköter ju fortfarande all tree.
Mm-hmm.
Så att det enda den gör är att sköta typ lifecyclen och lägga på saker som state och sånt som man kan liksom använda för att rendera de här sakerna.
Och det gör det så möjligt att göra så mycket coola grejer.
Alltså jag har kollat lite grann på vilka det finns som andra renderare.
Och det finns till exempel något som heter React Inc, tror jag, som används för att skriva React som renderas i terminalen.
Det finns något som heter React Hardware, som är typ någon Arduino-grej, så du kan skriva React som kör på Arduino.
Alltså det är liksom hur mycket saker som helst, och det är så jävla coolt.
Så tekniskt sett skulle man kunna köra React ovanpå vad som helst.
Jag känner en nernördning att komma och erfara om det här.
Jag tänker att jag ska hålla en presentation om det här någon gång.
Jag tycker det är väldigt kul. Jag har lekt lite grann med React 3 Fiber och byggt lite små saker i.
Det är så jävla roligt. Jag har försökt med 3G-s förut, men tyckte att det går inte.
Det är för mycket att hålla koll på. Man ska anmounta och hålla koll på när komponenten lever.
Man ska attatcha saker till varann och det här bara händer av sig själv.
Och sen har det i det här biblioteket nu för tiden lite så här,
ger till lite grejer som att den sköter typ boilerplate kring responsivitet och sådana saker också.
Vilket också gör det mycket, mycket enklare att använda det liksom.
Ja, för att alltså vanligtvis när man pratar om 3D sådant,
det är ju som du säger, det är en jäkla massa att hålla koll på.
Var är ditt objekt? Vart är kameran? Vart är fysiken i det här?
Vart, hur vänder sig sådär?
Jag tycker bara det är en stor klump av förvirring.
Ja, exakt. Och just det här lilla communityt som har byggt upp sånt här har byggt massa grejer runt omkring det.
Typ det finns ett fysikbibliotek som heter Canon.
Och då har de gjort en hook som heter Use Canon.
Som man bara kan hooka in på det här med React 3 Fiber.
Och så får du fysik helt plötsligt.
Ja, det är häftigt.
Och så finns det lite andra grejer. Nu såg jag någon som hade byggt en flex-komponent,
så att du kan använda flex i dina 3G-grejer, alltså typ i WebGL,
som också anpassar sig efter hur responsiv, alltså om fönstret förminskas och sådana grejer.
Och det är också sjukt tufft.
Ja, jag blir alltid så fascinerad av människor som har sånt otroligt driv i de här grejerna.
Jag är verkligen inte en sån, jag är mer så här, ja, jag hamnade i React-världen
och sedan stannade jag där och så typ lärde jag mig att använda det och så går jag till jobbet
och så skriver jag saker i React och så försöker jag att hålla mig uppdaterad
och läsa problem på ett bra sätt.
Men det fascinerar mig verkligen det här drivet som finns hos vissa, att jag ska bygga på det här
Och jag har den här idén och kan förverkliga det här, kan jag som Dan Abramov bygga ett state-hanteringspaket med bättre dev-experience än vanliga flux-mönstret på 90-rader kod, eller vad det var man gjorde.
Alltså det är helt otroligt. Jag känner mig så långt borta från de här individerna.
Jag känner mig också, jag tänker att jag driver på ett annat sätt.
Jag tycker ju om att lära mig saker, men sen bygger jag ju, jag bygger ju liksom inget bibliotek eller ramverk.
Jag tycker om att det är roligt att bygga produkter, om man får använda produkter i en skan brett.
För ingenting jag bygger är ju liksom kommersiellt.
Men jag tycker om att bygga saker som att jag vill bygga en gameshow nu till exempel.
eller att jag har byggt någon sån här Gerard-app, eller det här rita-gissa-spelet som vi pratade om för något avsnitt sedan.
Alltså det är sånt jag tycker är kul att bygga, men inte bygga stenarna dit.
Nej, jag tror att hela den här grejen som vi pratade om, att jag tycker det är jobbigt att ta in saker och lära mig saker,
Jag tror det är det som lite hindrar mig från att verkligen förstå smeten nere i hur funkar faktiskt browsers?
Hur funkar det? Jag kan förstå de här mer översiktliga, du har JavaScript, du har web-APIs, du har en eventloop
som trycker upp saker när stacken inte är upptagen. Sådana saker, men verkligen ner i kärnan på hur saker funkar
som jag ändå tror är en förutsättning för att kunna bygga nya verktyg.
För du kan ju inte bygga någonting som många ska använda om du inte förstår vad som händer.
Ja, så är det.
Jag önskar verkligen att jag orkade lära mig det, tror jag.
Mer, tror jag, än att lära mig bygga produkter.
För jag känner mig inte innovativ, eller nytänkande, eller kreativ nog,
för att komma fram till roliga produkter.
som vi har pratat om förut i några avsnitt, jag är mer en tutorialsperson.
Så om något skulle driva mig så tror jag det skulle vara att grotta ner mig i teknik.
Men jag har fortfarande inte riktigt hittat något bra sätt att göra det.
För det är alltid som att det ligger på för enkel nivå eller för svår nivå.
Det här mellantinget tycker jag är svårt att hitta information kring.
Ja, exakt. Det känns ju som att när jag har känt att jag behöver,
Jag kanske vill grotta ner mig i någon teknisk detalj.
Så blir det ofta att jag vill hitta något jag kan använda det för.
Jag vill ha ett användningsområde. Jag vill liksom "Vad kan jag bygga med det här?"
Och den frågan har ju inte ett enkelt svar alltid.
Så för min del blir det alltid svårt att "Om jag ska lära mig mer om eventloopen i JavaScript, vad ska jag bygga för det här?"
Och jag är mer så här, jaha, det är så här det har funkat när jag har gjort de här bitarna.
Så att jag får mer av när jag lär mig sådana bitar så får jag mycket mer av en aha-upplevelse
för att jag kan koppla det till saker jag har gjort.
Inte vad jag skulle vilja göra.
Nej, men exakt.
Nej, jag tycker det är lite motivation.
Det är väldigt svårt.
Ja, jag tror att jag märker det så tydligt också att jag får väldigt så här fatig av att jobba.
Det är inte det att jag egentligen inte gillar teknik, men det är att jag gör det hela dagarna så blir jag trött.
För jag märker det tydligt om jag har haft semester eller jag kanske har suttit på bänken och haft lite tid att komma på sig själv.
Där brukar min kreativitet kicka igång.
Så jag känner ändå att jag gör saker och provar nya tekniker, men då gäller det att jag inte har gjort det åtta timmar per dag.
Ja, men exakt. Det är väl liksom helt naturligt.
Alltså jag tror att de flesta är väl så.
Att sitter man och knackar kod åtta timmar per dag,
man går inte hem och knackar kod igen.
Nej, men det finns ju ganska många som kodar mer.
Det finns i alla fall en bild av att många gör det.
Jag tänker att visst, det finns folk som gör det,
men jag tror också att det är en, jag kommer inte ihåg,
Och Scott Hanselman, som är Microsoft-superkänd bloggare, han har myntat ett uttryck som är "Black Hole Developers" eller "Black Mass Dark".
Något liknande uttryck som handlar om den här dolda gruppen med utvecklare som inte bloggar, som inte twittrar, som inte snackar code på kvällarna.
Och den är ju garanterat övervägande majoritet.
Alltså, liksom, jättestor del majoritet skulle jag våga säga säkert.
Och det är så lätt att man fokuserar på folk som jag, som sitter och skriver bloggposter,
nog för att det tog sedan ett halvår, men det är lätt att fokusera på de som syns väldigt mycket
och tänka att det är normen, när det i själva verket inte alls är det.
Nej, men det blir ju som, vad är vi igen på den här sociala medieffekten, det vi ser, är det som vi tror i verklighet.
Det är ju lite som de här vändiga grammen igen, vad jag kan, vad jag tror att alla andra kan, hur jag lever mitt programmerarliv och vad jag ser andra programmerare göra.
Ja, nämen exakt.
Nej, jag tycker det är fan viktigt att poängtera det på något sätt.
Att liksom så här, bara för att vi poddar så behöver inte folk podda.
Nej, Gud nej.
Bara för att någon bloggar så ska man inte behöva blogga liksom.
Tycker man att det är kul. Jag bloggar ju mycket för att, min egen skull.
Alltså jag vill skriva för att lära mig liksom.
Sen är det ju såklart, alltid en dopaminboost när man får någon like.
Men jag gör det ju mest för min egen skull.
Och det är också därför jag pratade om det här i något tidigare avsnitt, att jag kallar det här "digital garden".
Kan ha nämnt det. Det är i alla fall konceptet med att man ska sköta om sin hemsida och uppdatera saker mer än att bara producera nytt hela tiden.
Alltså det ska liksom inte vara en kronologisk lista över saker, utan det ska mer vara så här, "jaja, det här är lite saker jag håller koll på".
Så typ den här, alltså codesmelt-grejen till exempel, den kommer jag förmodligen lägga på saker på om jag hittar några mer saker.
- Lite agilt så. - Det var lite agilt.
Jag gillar verkligen det konceptet, för det sänker så mycket tröskeln för att skriva saker.
Så den här bloggposten har ju varit publicerad på min sajt, inte sedan i maj, men sedan i juni kanske.
Bara i kortare versioner, som jag har uppdaterat lite då och då.
Tills jag nu faktiskt länkade den på lite olika ställen.
Ja, jag är inte så mycket för att skriva sådana saker.
Och gör jag det så blir det alltid med den här lite mjukare twisten på det kanske.
Nu sitter jag här och poddar, men överlag är jag en av dem som är i den här black mass.
Jag gör inte så mycket utöver jobbet. Det har mer med att jag är trött.
Jag har fortfarande inte riktigt accepterat det, men jag har lagt väldigt mycket tid på att
acceptera att jag inte orkar koda på helgen och lära mig nya saker på helgen.
För de första åren i min karriär var det väldigt mycket så.
Jag försökte gå till jobbet och sen så satt jag och försökte lära mig saker på helgen.
Webpack-konfigurationer eller bara...
The good old days.
Ja, alltså när jag satt och så lärde jag mig webpack och sedan dagen efter jag hade spott upp det,
de bara "ny version!" och jag bara "åh, det var mycket ångest".
Så jag har räckt rätt mycket tid på att verkligen förlika mig med att jag behöver inte göra allt det här
för att vara bra på mitt jobb.
- Ja, exakt.
Det tycker jag är en väldigt bra,
positiv note
att avsluta det här på.
Tänker jag mig.
Vi finns som vanligt på Twitter. Vill man något så är det bara att höra av sig där.
Ge oss gärna en recension i iTunes.
Det är alltid härligt.
För då får vi en liten dopaminboost båda två, tror jag.
- I alla fall du.
- I alla fall jag. Du är lite mot WilliPod, eller?
- Ja, jag börjar förlika mig med det.
- Ja, det är bra.
Vi ses om två veckor igen.
Bye bye!
[Musik]
Hej då!
