46. Stack-Ove & Kjell Kod
lyssna! 
Dokumentationsbonanza! Egen dokumentation i form av kommentarer och readmes samt ramverks dokumentation och guider. Är frågor på “Stack-Ove” dokumentation? Är det en superkraft att vara duktig på att läsa dokumentation? Den eviga känslan att det är jobbigt att uppdatera dokumentation samt mycket mycket annat.
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:
Vad sa utvecklaren som blev medbjuden på padel?
Tack, men jag föredrar att squasha!
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Vad sa utvecklaren som blev medbjuden på paddel?
Jag har ingen aning.
Tack, men jag föredrar att squasha.
Det var kul. Är det ett eget skämt eller något du har hittat?
Nej men det är ett eget, men faktiskt var det min PM/PO, vad det nu är för roll, som sa någonting om paddel när jag sa skorsa i förbifarten.
Så då tänkte jag att här finns det något.
Ja det förstår jag, det var ändå roligt tycker jag.
Det var bra kvalitet på det.
Ja men det känns lite nutida också.
Ja verkligen, det är inte så aktivt när folk lyssnar på det här om tio år och tänker vad fan är paddel för något.
Du hoppas det eller?
Ja, gud ja. Någon kommer inte ihåg Puddle Crasen 2021.
Eller när fan det var när det exploderade som mest.
Är inte det typ någon OS-gren eller något nu?
Jo, kanske. Det kanske är.
Jag vet inte om det är optimistiskt eller pessimistiskt att tänka att det är bortglömt om tio år.
Nej, jag vet inte. Jag har aldrig provat. Jag ska inte uttala mig.
Och där pratar jag om sport. Det ska jag inte heller göra.
Det är säkert så finkul, jag brukar spela badminton så det är säkert minst lika roligt.
Men välkomna till ett nytt avsnitt av ASDF.
Jag har vaccinerat mig för ganska precis sex timmar sedan typ.
Så jag tänker att någon gång under det här timmet så kommer bieffekterna slå till.
Så får vi se om det blir en halvtimme eller inte.
Än så länge lite stel i kroppen och lite ont i armen men annars ganska lönt.
Jag fick full blown influensa va?
Ja det var det. Jag har hört att den här booster dosen är inte så snäll mot de flesta.
Så vi får se om det blir ett helt avsnitt eller inte. Men än så länge känns det bra.
Så jag tänker att om jag pratar snabbt så kan jag bara sänka hastigheten på avsnittet sen.
Och så blir det en halvtimme.
Okej.
Jo, jag funderade på lite grann, vi kanske har berört det här i något gammalt avsnitt eller liksom glidit in på det i något sidospår
för det brukar ju bli några stycken sådana.
Men jag tänkte vi skulle snacka lite dokumentation och kanske lite ur lite olika perspektiv.
Men jag tänker vi kan börja med liksom dokumentation för att det känns som att dokumentation är något som alla utvecklare hatar
Alltså att göra, det vill säga.
I att skriva dokumentation.
Och det kommer då ofta ur perspektivet att man ska göra det för sin egen app eller sin egen tjänst eller vad man nu utvecklar.
Men hur mycket dokumentation har du skrivit i dina dagar i relation till kodet till exempel?
Ouff.
Ja, det är ju mer kod.
Det är en övervikt mot kod skulle jag säga.
– Du då? – Ja, men verkligen.
Nej, jag känner exakt likadant.
Och jag har också varit, i början av min karriär särskilt, då var jag så här
"Ja, fy fan, vad tråkigt att skriva dokumentation på hur saker fungerar."
Men sen har det kanske skiftat lite grann, så nu känner man ändå så här
"Ja, jag förstår varför dokumentation behövs i vissa fall."
Och då kanske det är lite lättare att ta det steg där man faktiskt skriver dokumentationen
än om man bara skriver den för att någon har sagt åt den att skriva den.
- Jo, alltså, jag menar dokumentation har ju verkligen en plats egentligen.
Det är ju bara mer att jag får någon slags...
lite... det är lite ångestfyllt att skriva dokumentation, för att helt plötsligt så måste du
formulera vad det är du håller på med.
Alltså en sak som är jättebra, det är ju att dokumentera beslut som har tagits.
Men hur fan formulerar jag det? Jag får lite så här "rapport i skolan ångest" liksom.
Ja, exakt. Jag håller verkligen med dig. Det måste vara rätt typ av dokumentation för att det ska bli värt det.
Alltså till exempel som du säger, att man skriver dokumentation som förklarar beslut,
eller varför någonting har gjorts snarare än att man skriver dokumentation som förklarar koden.
För dem är ofta ganska värtlös.
Ja, ibland kan jag komma in i system och verkligen känna att nu går dokumentationen bra. Skriver ner allt jag vet och gör det.
Men det värsta jag vet, förutom att skriva dokumentation, det är att uppdatera dokumentation.
Så jag tror det är det som håller mig tillbaka. Skriver dokumentation, sen ska jag uppdatera rätt delar av det.
missar alltid någonting och sedan helt plötsligt så har den dött.
Det är svårt för det.
Ja, jag förstår det.
Nej, jag är verkligen på samma sida också.
Det är ju lite så här
någonting med dokumentation som gör att man bara tar emot litegrann.
Jag vet inte, för mig tror jag att det kanske beror på också, eller i alla fall
berodde mer på i början, att det är en stor skillnad på att skriva kod som man
tänker att "ja, men det har jag liksom lärt mig hur man gör".
Och sen att jag plötsligt skriver dokumentation, för det är inte så lätt att skriva bra dokumentation.
Alltså det är liksom en helt annan färdighet än att skriva kod till exempel.
Ja, verkligen.
Men det ska vara tydligt och...
Alltså jag brukar ofta fastna också i det visuella, att jag vill att det ska vara konsekvent.
Om jag har möjlighet att formatera vissa saker.
"Okej, men jag använder en sådan här heading för den här överskriften."
"Borde inte det vara en subheading till den här?"
Alltså jag fastnar liksom i saker runtomkring.
Ja, jag är också så här. Jag har verkligen märkt det att man måste träna upp dokumentationsskrivandet.
Jag tror att det är samma sak som att skriva tekniska artiklar eller vad det nu kan vara med så mycket teknisk innehåll.
Eller manualer förr i tiden, för nu finns det inte så många manualer.
Det är samma färdighet att dokumentation måste man träna på.
Skriva ganska dålig dokumentation innan man kan skriva bra dokumentation.
Ja, men det tror jag, det är nog verkligen en grej. Jag gick ett år kognitionsvetenskap, till exempel.
Och därifrån har jag för detta klasskompisar, som jobbar eller har jobbat med att enbart skriva säkerhetsmanualer.
För att det är den här människa-maskin-interaktionen och vad som händer i den mänskliga hjärnan när man får stresspåslag,
har en så stor effekt på hur man uppfattar saker.
Så det är ju verkligen en liten vetenskap att skriva dokumentation.
Ja, eller hur?
Och sen så är det också så här, man måste anpassa sig, för det finns ju så jävla många typer av dokumentationer som man tittar på.
Kodkommentarer, som kanske ska vara fem rader långa, typ, max.
Då måste man verkligen vara konsekvent och tydlig med vad kommentaren tillför för värde, och varför man ska läsa den.
Annars skippar folk också att läsa kommentarerna.
Och då hjälper det ingenting.
Nej. Jag tycker det är en fine line också med att jag tenderar att lägga till en massa extra ord.
Så jag brukar få jobba ganska mycket med att plocka bort ord.
Men när det är jättekompakt, då är det ju en extrem torma som uppstår också.
Och där tänker jag att man inte heller vill hamna. Alltid.
Samtidigt känns det som att man hellre hamnar där, att det är väldigt kort och konsekvent än att det är utdraget och tråkigt för att det är långt.
Jag är på samma ställe som dig. När jag skriver i artiklar till exempel, då jobbar jag väldigt hårt på att läsa in den här meningen. Hur många ord kan jag ta bort utan att det blir alltför torrt eller att den byter innebörd?
Ja, absolut. Men jag är ju också extremt dålig på att läsa dokumentation.
Det är fruktansvärt.
Det borde jag kanske vara bra på när jag jobbar med det här.
När det kommer en enorm textmassa före över, då är det som att jag bara stänger ner.
Den är dessutom torr. Jag kan läsa samma mening typ tio gånger och ändå inte förstår den.
- Ja, där tror jag att jag är jävligt bra på att läsa.
Jag tror att det är generellt för text överlag, för jag har läst extremt mycket böcker, särskilt när jag var liten.
Både på engelska och svenska.
Jag är väldigt duktig på att skumma texter, till exempel bara för att hitta information.
Eller om man vill hitta innebörden i en text så är jag ganska bra på att skumläsa den och hoppa över vissa ord som jag vet inte behövs.
Jag har inte tänkt på det förut, men nu när du svarar så tänker jag att det kanske hjälper ganska mycket just i dokumentationsfallet också.
Då kan jag väldigt snabbt skumma en dokumentation utan att bli uttråkad på vägen och faktiskt hitta det jag är ute efter.
Gud ja, det tror jag. Alltså jag fastnar ju.
Om jag läser, om jag säger till en bloggpost,
så är det ett inledande stycke, så läser jag det ord för ord
och så fastnar jag på typ så här två ord som jag inte förstår.
Då fastnar jag på dem. Sitter fast där. Antingen upprörd,
eller så måste jag kolla upp vad det är, så måste jag försöka sätta in dem i sitt sammanhang.
Men jag fastnar där. Och så kan jag vara så här,
"Vad betyder det här, vad betyder det här?" Så skickar jag länken till någon.
Och de bara, "Jo men svaret kommer i stycket under om du bara fortsätter läsa."
Men det gör inte jag. Jag sitter fast där och är arg.
Ja, det är ju ändå spännande.
För det är inte något jag har tänkt på förut.
Jag har ju uppfattat att folk inte läser så mycket dokumentation.
Eller att man bara "jag hittar ingenting i dokumentationen".
Och så går jag själv och tittar och bara "men det står ju där".
Men jag vet inte. Det kanske också är en anledning till att nu för tiden läser jag
extremt mycket dokumentation på saker jag använder.
Det är sällan jag gått stackoverflow nu för tiden, om det inte är något specifikt problem mellan kopplingen mellan fyra olika bibliotek som man ska hitta någon lösning på.
Då kan stackoverflow vara bra. Men annars är det någonting med ett javanskript bibliotek till exempel, då är dokumentationen dit jag går först.
Det här är någon slags superior skillnad. Jag går till dokumentation, läser, förstår inte, blir arg, googlar, hamnar av stackove, skummar, fattar inte, blir arg och googlar upp något nytt.
Jag har ju ett väldigt dåligt sätt att arbeta.
Men det är lite intressant att du kan hoppa över viktiga saker och grejer. Det måste vara så himla skönt.
Jag har ju helt andra hållet. Jag har ju verkligen problem med det här.
Och då har jag ändå läst ganska mycket tidigare.
Jag kan läsa, alltså dålig däckare kan jag läsa fort. Det går undan.
Men det var också kul då, för vi hade user testing för ett system.
Och då är det så här, UX-aren bara "ja men var med, skriv ner saker som du finner intressanta"
Och mina kollegor, de är bra på det. Jag skriver ganska lite. Jag skriver bara upp saker som är intressanta.
Jag är så här, jag typ transkriberar allting som sägs.
För att jag bara, jag vet inte vad som är viktigt. Jag har med allt.
Jag kan inte sålla. Det går för fort liksom. Det funkar inte.
Jag sållar ju extremt mycket.
Alltså, verkligen att jag kan skriva en mening på en presentation på 20 minuter.
Det här var det. Take awayen.
Det är det som kommer åka. Sen visst att det är backfire ibland att "oj, missade den här grejen"
Men fan, hellre det än att sitta och transkribera 20 minuter.
[Skratt]
- Ja, jag önskar verkligen att jag hade den dokumentationsläsaren-skillen.
Jag har fått träna något enormt. Och också träna mig på det som kommer naturligt för många.
Jag har ju för många, även dig tror jag, att dokumentationen inte ger mig det jag vill.
Så jag går in och läser lite källkod.
Det sitter också ganska långt inne för mig att göra det.
- Ja, för det kan jag också göra. Jag kan gå in i källkoden för något bibliotek och kolla.
Hur funkar det egentligen? Varför funkar det inte som jag har tänkt?
Vad gör den i bakgrunden?
Och så, innan jag glömmer bort det här.
Stack Ove. Älskar uttrycket, aldrig hört det förut tror jag.
[Skratt]
- Ja, okej. Det var nog någon gammal universitetsgrej. - Ja, Stackover.
- Ja, att vi skulle välja namn som var teknikerrelaterade, men på svenska. Så var det någon som valde Stackover.
- Jag tycker det är... - Det var någon som hette Källkod också.
- Ja, den är också rolig. Väldigt kul. Vet du vad det finns? Det finns stickerspotential här.
Om jag bara kunde designa, då hade det varit stickers.
Jo, sidospår deluxe. Men, vart var vi?
Dokumentation. Jag tänker också så här, Stack Overflow är ju egentligen dokumentation.
Även om det ska vara en wiki eller en Q&A-sida.
Men det blir ju i förlängningen dokumentation på hur man gör saker.
Kanske inte som jag sa tidigare, hur det här biblioteket fungerar.
Men snarare, hur integrerar jag den här saken x med y när jag bygger det på z?
Men det är ganska intressant att den dokumentationen finns och man kan tycka ganska mycket om stack OV.
Men jag kan förstå deras ambition när de har så hårda regler.
Att det här ska vara dokumentation, det ska vara på samma nivå som om du går in på biblioteks dokumentation och läser.
Ja, men det är också intressant för att i Kärplastik så känns det som att man har öppnat upp lite begreppet för dokumentation.
För mig när jag tänker dokumentation i den här världen, då är det ju liksom, där är ett lib, här är typ referenserna, APIerna och så är det mycket text liksom.
Och så ska man förklara varenda funktion som finns.
Men som du säger, jag menar allting som vi skriver ner gällande sakerna vi håller på med är ju någon typ av dokumentation liksom.
Ja, nämen exakt.
Likväl tickets som vi jobbar med, det är också dokumentation.
Ja, absolut. Där vet jag att jag är jävligt kass egentligen.
Vi diskuterade det senaste i dag faktiskt på jobbet.
Att vi borde skriva ner mer saker i tickets.
Till exempel vilka beslut som är tagna i den här ticketen.
Om man har gjort någon avsteg från vad som var kravet från början till exempel.
Sådana saker måste vi bli bättre på att faktiskt skriva ner.
För det är ju dokumentation som lever tills vi lever vidare liksom och är skitbra att ha om en månad eller två när vi tittar tillbaka på det här.
"Varför gjorde vi inte så här?"
- Ja, så är det verkligen. Jag är ju verkligen en person som hade en period där jag bara gjorde one-liners.
Eller vad jag menar, i allhetens namn. Jag är fortfarande en person som kan göra one-line-tickets liksom.
Och sen gå tillbaka och bara "Vad fan var det här?"
Så där har jag också verkligen tränat på att bara skriva ner saker.
Och det är inte heller så att det alltid måste vara rätt.
Jag använder kommentarsfält i Tickets, om det nu finns, ganska mycket för att få ner saker utan att det finns någon press på att det måste formuleras helt korrekt.
Eller formateras helt korrekt.
Men snarare att, okej, men här finns saker som ledde upp till det här.
Eller saker vi ska komma ihåg.
Får bara ner det någonstans så kan vi förbättra det sen i sådana fall.
Ja, men precis.
Ja, jag tycker också att det är intressant det där, vad som gör bra dokumentation.
Alltså både oavsett om det är i en ticket, eller om man skriver i en readme-fil, eller om det är på hemsidan för ett bibliotek.
Alltså det är liksom, jag har svårt att spesa exakt vad som gör att jag tycker att det här är bra dokumentation.
Alltså jag har liksom ingen checklista som jag skulle kunna fylla i.
Nej, inte jag heller. Men det beror ju extremt mycket på. Jag menar en readme.
Så att du ska starta upp ett projekt som inte har några konstiga grejer eller behöver sätta en...
Alltså det är ju toppen om du behöver ha den här enven och då hämtar du via det här systemet genom att sätta den här.
Annars är det typ "yarn start".
Ja.
Och då behöver man inte skriva jättemycket mer som ingen orkar läsa om ingen läser det.
Och det är ju för egna projekt, småprojekt.
Jag menar, jag tycker det är ju...
Allt ska ju stå i en readme om det är något lib jag vill använda.
Jag vill ha mer information i det, liksom. Jag vill ha allt.
Ja, jag har precis. För du var ju till exempel inne på lite tidigare det här med typ att en API-referens bara.
Det skulle jag tycka att om det är det enda som finns, då är det ganska dålig dokumentation.
Alltså om du har ett bibliotek och så bara "Ja, men du kan se vilka API vi har och vi har dokumenterat dem"
och det står typ så här.
"Den tar emot de här parametrarna, spottar ut sig i det här."
Klart.
Den skulle jag förmodligen tycka är ganska dålig. Det beror lite på vad det är.
Jag kan tänka mig typ, om vi tar Lodash eller Underscore eller vad alla nu heter.
Där funkar det lite bättre för att det är typ utility-funktioner.
Men tittar man på Reacts dokumentation eller Vues dokumentation, då vill jag gärna ha-
-mer saker som förklarar idéerna bakom och hur man ska tänka och sådana saker också.
Ja, men jag skulle ändå vilja ha en tydlig sida där de bara spesar allting.
För om jag är bekant med ett bibliotek och använder det, då vill jag kunna ha kortkommandon.
Jag hänger mycket i dokumentation bara för att jag inte kommer ihåg.
Ja, exakt. Det kanske är lite olika syften med de sidorna.
API-specifikationen kanske mer är referens eller API-referens.
Alltså att du går in dit och bara refererar till saker du vet vad finns, men du behöver bara dubbelkolla hur det funkar.
Medan annan typ av dokumentation som hur man ska tänka i React till exempel.
Den är ju mer om man kanske är ny inom det paradigmet eller språket eller vad det nu kan vara man dokumenterar.
Ja, jag gillar ju verkligen när det finns ofta en "get started" eller någonting som har lite grundläggande tyngd och information.
De tycker ofta att kanske... Ett problem jag tycker med dokumentation ibland som jag känner igen mig väldigt mycket från när jag började koda överhuvudtaget
Jag tycker att det är två nivåer. Du har saker som är dokumenterat eller förklarat på en extremt låg nivå.
Det här är kod, det här är en for loop.
Alltså, du förstår min grej. Den är extremt, liksom, här är bara grunderna.
Och sen så tycker jag att hoppet till att bara göra antagandet, att du förstår allting som ska vara däremellan, kommer väldigt tidigt.
Jag har alltid känt att det är väldigt svårt att hitta köttet i mitten.
Och på det tycker jag är lite samma sak ibland med sådana här "get started".
Okej, här får du de första exemplen och här är hela API-referensen.
Men så fort jag går på lite mer komplexa delar, vart står det? Hur hittar jag det?
Absolut, det är väldigt sant att det är ofta basics eller avancerat.
Det är inte så mycket "intermediate" säger man på engelska. Jag kommer inte på något svenskt ord.
Ja, extremt mycket kortare sätt att beskriva det på än vad jag gjorde.
Nej, jag samfattade bara vad du sa.
Eftersom jag inte kan dra ut gisten i saker, då får du göra det åt mig.
Jag får öva på det nu.
Nej men precis, jag håller med om det.
Ofta hittar man det här mellan-steget.
Och det är väl lite steget som tutorials eller guider fyller.
Att någon håller dig i handen medan du försöker använda det du kan från basics för att komma till det som är avancerat.
Så det kanske är lite så, men det är också sällan jag ser själva biblioteken eller upphovspersonerna bakom har de här guiderna.
Oftast är det ju att communityt steppar upp och försöker skriva de här guiderna eller tutorials eller vad det nu kan vara.
Och liksom fyller den luckan kanske.
Visst, det funkar ju, men det känns samtidigt som att det kanske behövs lite mer som faktiskt
officiell dokumentation för vissa saker som bara fyller den mittendelen också.
Ja, jag antar att det också är den som är svårast att få ner på något sätt.
Här börjar du och här upplever du referenserna, men det här svåra i mitten är väl...
För jag antar att de som skriver de här posterna, de har nog inte bara "Jag bara gjorde det, allt var lugnt, allt var fin".
Det har nog svettats en del för att komma fram till de här grejerna.
– Ja, verkligen.
Nej, jag tror att det är svårt.
Jag har ändå några "drafts" på min sajt.
Det är typ så här "Hur du bygger en rit-app med React".
Typ, eller något.
Och sen har jag spesat ner vad som behöver innehållas här och så bara "Oj, vad mycket det blev!"
"Det här orkar inte jag skriva."
"Det kommer vara svårt att få det på en bra nivå och konsekvent språk."
"Att det inte blir tråkigt, att det inte blir utdraget och så vidare."
Så jag förstår verkligen att det kan tänkas vara svårt.
- Ja.
Men ja, dokumentation blir ju också...
Det blir ju mycket lättare att få till om man har bra verktyg för att göra det.
Jag kommer ihåg att jag byggde en tjänstagång.
Som jag sen då skulle, alltså det var bara en pock.
Och sen så skulle jag lämna projektet liksom.
Och så skulle jag dokumentera det.
I ett dokumentationssystem som var så otroligt bra.
Och jag menar det var ju ett fullt team som satt och jobbade med det.
Så det var inte så att det bara fanns.
Men det var liksom något sådär Python, Markdown baserat liksom.
Det var helt magiskt att skriva saker i och kunna lägga in bilder och bygga grafer.
Det gick ju undan, men det är också ett väldigt litet isolerat system där jag bara skulle försöka få ner allt och lämna vidare det.
- Men det var något internt system på just det där bolaget som de hade byggt för att dokumentera saker?
- Ja, precis.
Det finns ju ändå lite försök att göra det här.
Du har ju till exempel Storybook, är väl kanske en del av det här, lite mer upp i referens fast för komponenter.
Som försöker vi prata om i en tidigare avsnitt också.
Men sen finns det också Docosaurus, är väl något open source bibliotek, eller ramverk kanske.
Som man kan skriva dokumentation i. Jag tror att det är Facebook som ligger bakom det också, eller om de har köpt upp det eller något.
Det är också tänkt för att man ska kunna dokumentera saker.
En sak jag tänker på nu är att älska den nya vågen, eller nya...
Inte så nya idéer, men att folk har börjat integrera mer interaktiva element i dokumentation.
Alltså att du faktiskt kan klicka runt och känna hur nånting känns, eller att du kan skriva koden
Och sen se resultat direkt i dokumentationen eller att du kan typ redigera kodexempel och de liksom uppdaterar faktiskt vad som resultatet blir också.
Det känns jävligt bra tycker jag.
Ja, men det är ju väldigt Mozilla. De var ju tidiga.
MDN.
Ja, men precis.
Och jag vet till exempel.
Nu ska vi se vad det heter för något. Code Sandbox har ju släppt något verktyg som är gjort just för att kunna köra liksom.
Eller för att kunna, vad ska man säga, kompilera kod i browserna eller transpilera eller vad man nu vill kalla det.
Som heter, heter det Snowpack? Eller bland ihop med något annat?
- Var inte Snowpack det här när du skulle kunna dra in typ Endances i runtime?
- Jo, det kan vara. Det heter antingen Snowpack, det heter kanske Sandpack?
Får jag för mig?
Ja, det heter Sandpack.
Jag gissar på att det egentligen är en blandning av att det andra heter Snowpack och det här blir Sand.
Och att det kommer från kod Sandbox, gissar jag.
Bra förklaring.
Ja, precis. Så det är liksom något bibliotek som du kan köra kod i webbläsaren som du skriver i webbläsaren.
Sånt gör ju dokumentationen så mycket roligare att läsa att man kan experimentera lite grann med den.
För min del blir det så mycket enklare att lära sig saker när jag faktiskt kan testa lite och förstöra det och se vad som händer när man ändrar på saker.
Fan det är också intressant för jag är sådärn.
Nej men det där, det där ska jag inte pilla med.
Du vill gärna bara ha, okej säg åt mig vad som är rätt och sen rör inte jag det.
Jag tror inte det, det är ju fan ingenting. Jag är så otroligt hämmad av min egen ängslighet.
Jag vet inte vad jag håller på med.
Nej, det känns ändå som att du skulle kunna ändra på och lära dig lite lättare.
Jag vet inte, det är ju personligt också hur man lär sig.
Det är samma sak som folk som föredrar att lära sig via video, text eller att göra själv.
Det är dumt, vi är en extremt visuell människa egentligen.
Och fattar inte när jag inte får se saker. Så det måste jag börja använda.
Jag tycker det verkar väldigt nice. Jag tror, minns inte om ni gör React-docs-sajten.
Använder ju Sandpack, eller om det kom senare, jag vet faktiskt inte.
Men de har ju också ganska mycket interaktiva exempel på, där man kan se hur saker bedir.
När man faktiskt har en komponent och allting sånt.
Jag tror att den trenden är väldigt positivt framåt för alla.
Ja, men det är intressant. Vilken dokumentation tror du att du använder dig mest av in life?
Jag vet inte, det är så jävla svårt.
Views-dokumentation har ju varit extremt bra väldigt länge.
Och det känns som att många andra har spelat catch-up med views-dokumentationen för att komma ikapp den nivån.
Jag vet att när jag lärde mig Views från början så satt jag nästan bara i dokumentationen.
För att den var så extremt bra. De hade mycket exempel.
De hade en cookbook kanske, där de hade tagit fram ganska komplexa exempel på hur man kan göra saker och rekommenderade lösningar på det.
Så den satt jag och läste extremt mycket när jag lärde mig Vue.
Men sedan har jag hållit på med React så pass länge nu att jag kanske har läst Reacts dokumentation mer.
Men sen är det också svårt, det kan ju vara att man är in på MDN och läser om JavaScript.
Det händer ju också väldigt ofta.
Så jag tror det är svårt att säga, men MDN ligger nog där uppe i topp i alla fall.
Blandat med något ramverksdokumentation.
Har du någon som du känner "ja, den har jag varit in på så jävla mycket"?
Nej, du är ju helt baserad på vad jag jobbar med.
På senaste, av någon anledning så har jag blivit helt okej på MongoDB aggregation pipeline.
Det är ganska nischat.
Ja, det är ganska nischat.
Där hänger ju en del för att hitta saker.
Men det är också kul för att någonting som jag alltid återkommer till det är gästs dokumentation.
Och det är ju också, det har ju gått till en nivå där jag blir lite arg för att jag har hängt i, alltså det är alltid problem med att mocka saker.
Ja det gäller det.
Och då hänger jag i en mockdokumentation och så är det alltid det här jäkla happy exemplet med en sound player.
Jag är alltid lite arg när jag läser det här.
Det är som att jag blir lite tryggad av att jag igen måste titta på Soundplay-exemplet.
För att jag igen har problem med att mocka.
Så det väcker känslor.
Ja, det förstår jag. Det var ganska länge sedan jag var inne i S-dokumentation nu tror jag.
Men jag har en känsla för att jag inte tyckte det var så bra.
Men det kanske är bara för att det fanns så många olika saker som lät typ likadant.
Som jag inte riktigt vet vad skillnaden är på.
Och så hittade man ingenting och slutade med att man hamnade på stack over.
Och så ser man vad det blir av det.
Jo men absolut, absolut. Så tycker jag också att det är.
Men sen har ju stack-ovarna liksom bara så här
"Ah, men det här exemplet med en sound player, och då?"
[Skratt]
Ja, det är inte lätt alla gånger att hitta rätt.
Nej, men alltså sen så om jag ska säga vilka som hänger med.
MDN hänger ju en del in på.
Och sen så hamnar alltid V3 Schools uppe bland mina sökningar.
Och sen var det väl någon gång då någon sa "där ska man inte vara inne".
Så jag gör mitt allra yttersta för att hitta en annan träff.
Men ibland så är jag bara för trött för att jag bara vet att jag ska kolla någon syntax.
Så jag hänger där en del också.
- Ja, men de var väl liksom the go-to back in the days.
Jag vet att ni har byggt en klanhemsida när jag var 15 år sedan.
Då var det ju V3 Schools som var dit man gick, det var där man lärde sig saker.
Men sen hade de väl ganska mycket felaktig information framför mig.
Alltså dåliga råd på deras sida och grejer, så det var extremt dålig kvalitet på deras dokumentation ett tag.
Nu tror jag faktiskt att den är bättre.
Jag har inte varit i någon dubbelkolla där själv, men jag har hört folk säga att de har ryckt upp sig så nu är den bättre än förut.
Men de har ju en jävligt bra SEO-sida så att de hamnar ju ofta högst upp i resultatet när man söker på saker.
Ja, den måste vara så himla bra.
Men det är ju ofta när man ska kolla så här.
Jag borde inte trycka här, men jag orkar inte. Det är bara en syntaxgrej. Jag går in här.
Det är också lite nostalgiskt att gå in där. Den har väl sett likadan ut i 15 år?
Ja, säkert.
Det är kanske där vi lämnar våra lyssnare med idag. Gå in på V3 Schools. Få en liten nostalgi-trip om du ser likadant hur länge som helst.
Så att det kanske är helt nytt utseende.
Jag var nog inne förra veckan. Jag tror det är ganska likt.
Med det sagt så tackar vi för oss den här gången och vi hörs igen om två veckor.
Det gör vi. Ha det bra. Bye bye.
[Outromusik]
