Johan Larsson - känd från internet i allmänhet och En podd om teknik i synnerhet - snackar frilansjobb med Daniel Oskarsson och Erik Svedäng. Johan är nybliven frilansare, Erik har varvat egen spelutveckling med frilansjobb i sju år och Daniel har frilansat kring apputveckling i två år. Allt från bokföringsprogram och arbetsplatser till varför man blir frilansare och om man verkligen hinner med sina egna projekt avhandlas.

Ett stort tack till alla tre deltagare för en jätteintressant diskussion, och ett extra tack till Johan som inte bara föreslog ämnet utan dessutom glatt nappade när vi föreslog att han borde hålla i diskussionerna och ställa frågorna utan oss andra som mellanhänder.

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @iskrig och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes!

• 0: Intro och bakgrund
• 1:28: Hur och varför började ni frilansa?
• 4:56: Hur kommer man igång?
• 6:50: Första uppdrag, hitta kunder
• 13:55: Arbetsplatser
• 16:25: Samarbeten och arbetskonstellationer
• 21:24: Avgränsa sig, erbjudanden om att göra saker man inte kan
• 24:04: Miljonkronorsfrågan: hinner man med sina egna projekt när man frilansar?
• 30:05: Planer framåt? Vill man växa?
• 32:56: Konkreta tips, och hur svårt är det att börja? Hur ska man ha hand om redovisningen? Vilka program använder deltagarna?
• 43:03: Saknar ni något som frilansare?
• 46:33: Någonting annat?

Länkar

• Johan Larsson
• Daniel Oskarsson
• Erik Svedäng
• Erik berättade om sina spel och mycket annat i Kodsnack 146
• Dataspelsutvecklingsprogrammet i Skövde
• Blueberry garden
• Spelinkubatorn i Göteborg
• Gothia science park
• Speedledger - bokföringsprogrammet Daniel använder
• Iordning
• Frilansfinans
• Billogram

Titlar

• Jag har precis blivit frilansare
• Frilans lite mot min vilja
• Komma igång och göra så lite som möjligt
• En pendling som man aldrig riktigt kommer ifrån
• Långa perioder av R&D
• Hur nära ruinens brant vågar man gå
• Med lite tur så funkar det
• Skatteverket går att ringa
• Sitt inte på Facebook

Tobias och Fredrik snackar först om byggprocess och artefakthantering och sedan om motivation och arbetssituation.

Tobias berättar om Plex senaste omgång förändringar och förbättringar av bygg- och framförallt släpprocesser, och inom det allra mest specifikt hantering av artefakter.

Fredrik tar upp några tankar från den första dotcombubblan kring att vara fokuserad och motiverad på jobbet, och hur mycket eller lite stämningen och riktningen på allt runtomkring gör för att man ska känna driv att göra ett bra jobb. Vad är viktigast för dig om man drar saker till sin spets: dina arbetsuppgifter eller situationen runtomkring?

• 0: Intro och presentationstips för folk som har Kristofferabstinens
• 1:55: Byggsystem och artefakthantering
• 32:46: Att fokusera och motiveras
• 52:50: Poddtips från Tobias

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @iskrig och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes!

Länkar

• Programming is terrible - presentation av Thomas Figg
• Conan - numera Jfrog bintray - pakethanterare för C och C++
• Jenkins
• Groovy
• Artifactory
• Git LFS
• Xray
• Apache archiva
• Sonatype nexus
• Rsync
• Internet history podcast
• Netscape
• Napster
• “The Napster story with Jordan Ritter” - avsnittet som väckte Fredriks tankar
• Downloaded - dokumentären om Napster
• Cowboykåken
• Jamie Zawinski
• Long distance, del 1 och del 2 - Reply all-avsnitten om bluffcallcenters. Fredrik har också lyssnat och instämmer i rekommendationen!
• The destroyer of worlds - Hardcore history om atombomben - också stark rekommendation från både Tobias och Fredrik

Titlar

• Sin dos av “allt är skit”
• En sånhär sak med att växa upp
• Här är våran perfekta procedur
• Saker som måste få växa fram
• Efter mycket själasökande
• Utvecklare sitter och utvecklar
• Väldigt sällan samma binär som QA testar
• Ett riktigt artefakthanteringssystem
• Du går till alfakatalogen
• Våran Artifactory är din mirror
• Replikerad över Atlanten
• Det börjar med en rsync-kommandorad
• Sånt är bara godis för mig
• Utbytbara kuggar i maskineriet
• Det har alltid funnits en balans
• Nu gör vi det här, du har inget val
• Jag väljer en trevlig arbetsmiljö framför en intressant arbetsuppgift
• Vad är viktigast för mig?

Tobias och Fredrik snackar lite avslutande om Fredriks test av Surface book; hur långt han kom med sina försök att jobbutveckla och vad han tyckte. Det kom en del insikter om både jobbutvecklingen och Microsofts och Windows situation på köpet. Vi knyter an till Tobias test av Linux förra året, som ledde till att han idag utvecklar i huvudsak på Linux.

Sedan snackar vi, så kort vi kan, först om Transportstyrelsens IT-skandal med ett försök att fokusera på hur sådana problem uppstår och, kanske, kan undvikas.

Efter det avslutar vi med att prata, återigen så kort vi kan, om Google-PM:et kring jämstäldhet som bubblat upp.

IT är svårt.

• 0: Fredriks tankar kring Surface book
• 16:16: Tobias Linuxutveckling och val av distributioner
• 30:01: (Dubbelkolla) Transportstyrelsens IT-skandal
• 41:04: Google-PM:et

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @iskrig och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes!

Länkar

• Avsnitt 214 innehåller tidiga intryck av Surface book
• Surface book
• Grand central dispatch
• TimeEdit - där Fredrik jobbar
• Cmake
• Cmake server
• Clion
• Ninja
• Fredrik jämför sin egen handstil med penna på Ipad och Surface book
• Pixeltelefonerna
• Arch Linux
• Ubuntu
• Opensuse
• PPA - Personal package archive
• AUR - Arch Linux user repository
• EFI - Extensible firmware interface
• Sandy bridge
• Sandy bridge-bugg med multitrådning
• Hypertrådning
• Microcode
• Transportstyrelsens IT-skandal
• PM:et en Google-anställd skrev, som tar ställning mot diverse jämställdhetsåtgärder
• En av många uppföljningar eller reaktioner (för övrigt skriven innan det kom fram att författaren fått sparken från Google)
• The weeds-avsnittet

Titlar

• Semestern är den stressigaste tiden på året
• Tillbaka i podcaststolen
• Resten av miljön jag lever i är inte anpassad för det här
• Definitivt inte en Linuxdistribution för alla
• Jag vet inte om jag skulle köra det på en produktionsserver
• Det här är mitt fönster och här är min editor
• En mycket mer Maclik upplevelse
• När man är utanför ett pakethanteringssystem
• Jag kunde direkt uppdatera mikrokoden i CPU:n
• Han var ju så jobbig
• Det här är ju ett säkerhetsproblem
• Svart magi som magikerna borta i andra hörnet har hand om
• Kommunicera så att man kan utbilda varandra
• Ska jag rita hela internet åt dig?
• Vi behöver ha lite mer empati
• Jag förstår inte alls varför vi har den här diskussionen

Fredrik snackar med Jonas Nicklas om att bränna ut sig på öppen källkod, eller sidoprojekt i allmänhet. Det är lätt att se det som ett slutmål att släppa sin kod fri, ett sätt att bidra till kodgemenskapen och visa vad man gjort. Men vad händer om ens projekt blir populärt? Om man plötsligt har förväntningar - egna eller andras - på sig att underhålla något på sin fritid som man kanske trodde att man var klar med? Vad kan vi göra - både som individer och organisationer - för att få mer långvarig hållbarhet inom öppen källkod?

Det blir fler intressanta frågor än definitiva svar. Har ni som lyssnar tips och tankar på hur man lär sig hantera att driva och leda öppna källkodsprojekt? Finns det bra saker skrivna som vi missat? Hur borde vi hantera kod vi släpper och “risken” att de plötsligt blir populära?

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @iskrig och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes!

Länkar

• Jonas Nicklas
• Lightning talk
• Ship it!
• Moment.js
• Tim Wood - Moment.js skapare brände ut sig och hoppade av projektet
• Substack har många repon på Github
• Guido van Rossum
• Capybara
• Jonas på Twitter
• Jonas på Github
• Bonus: Kenneth Reitz tankar kring att bränna ut sig på kod

Titlar

• Open source-utbrändhet
• Imperier på andras gratisarbete
• Jobba vid sidan av jobbet
• Från en kul grej man gör på fritiden till ett obetalt jobb
• En udda dynamik
• I bästa fall är det ingen som ser koden
• (Det krävs) Tur och timing
• Ett socialt problem
• Ett samhällsproblem
• En otrolig obalans i kunskap

Fredrik snackar med Ivan Milles om snabba kontra hållbara lösningar. Huvudfrågan är om vi kan skapa en grammatik för att prata om tusenårslösningar kontra fulkod på ett bättre sätt?

Ivan funderar kring “bra” lösningar, att göra saker rätt och hitta en fin arkitektur och ställer det mot att göra något som är snabbt och kanske bygger teknisk skuld men som löser problemet här och nu. Hur bygger vi system i olika sammanhang, och hur kan vi skapa begrepp för att prata om det? Vad behöver vara en tusenårslösning, och vad som behöver vara ett tält som bara ska klara vintern? Även begrepp för att prata om risker - finns det en risk att detta innehåller ett dolt fel som leder till dataförlust kontra en risk att knappen får fel färg eller att något uppenbart går sönder som man märker omedelbart. Att fastna i arkitektur med sitt prototyp-projekt, är det rätt?

Är poängen med kodkvalité att kunna komma undan med mer fulkod framöver? Lockelsen, nyttan och riskerna med generalisering - det är galet effektivt och lättförstått att bara kopiera en mapp.

Vad tycker och tänker du som lyssnar? Vi vill höra fler tankar kring allt detta!

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @iskrigoch @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes!

Länkar

• Ivan Milles
• Netlight
• Kodsnack 211 - Bli IT-konsult på tolv veckor - med Johanna Björklund Tedenborg
• Academic work
• UML
• The people’s platform av Astra Taylor
• Begreppet pattern inom arkitektur
• Gang of four
• Tumregler - avsnitt 215
• Boken hette Urban code - 100 lessons for understanding the city
• Varningsskyltar för kärnavfallslagring
• The long now foundation
• Long nows poddar
• Teknisk skuld
• Visitor-mönstret
• Ungersk notation
• Rekursion
• Generator
• Heartbleed
• Cloudbleed - Cloudflare-läckan
• left-pad-historien
• Licenskollare för npm-paket
• Mejla gärna Ivan!

Titlar

• Jag tror att det står “spel” på mig
• En tonårsdröm på alla sätt
• Flax och bra rubriker (i CV:t)
• Begreppet “fulkod” till en helt ny nivå
• Spänningen mellan hållbarhet och snabba lösningar
• Fulslides, skulle man kunna säga
• Vad kan vi göra på tusenårsskalan?
• Superakademisk data-tönt
• Så bygger vi ett samhälle
• En vettig fulkodsända
• Svinfett för en gravkammare
• Tusenårstänk
• Hur skriver man en varningsskylt som håller i tiotusen år?
• Man lånar tid från framtiden
• Kan vi fulhacka det här?
• Att inte ha ord för att tänka på det
• Smäll på akademikerfingrarna
• Hur många procent behöver jag kommentera kod?
• Allting ser ut som en visitor
• Rekursion är rätt svar
• Det är ju kul att grotta ner sig
• Varför sitter jag här och skriver tester?
• Nytta av att vara på fulkods-sidan
• Här är det okej att det går fort
• (Den kommer att få) noll klick på tio år
• Det är väldigt låg kognitiv last på en mapp
• De demoner just jag brottas med
• Felet finns i den kod du redan skrivit
• Kod som inte finns kan inte vara fel
• (Den enda) kod som är o(n^0)
• Pyramidernas frontend-stenar blev bord någon hel annanstans
• Refaktoreringar av hus
• Dålig på internet