Det finns en uppfattning om att fullstack inte är något bra och att duktiga utvecklare specialiserar sig och arbetar inom ett enda område för att bli experter.
När allt kommer omkring är kanske mästerskap det yttersta målet för varje framstående utvecklare, och en framgångsrik karriär innebär att man behärskar Android, iOS eller Scala för att bli specialist.
Man kan inte vara bra på allt, och det krävs djup koncentration för att uppnå ”zen” inom utveckling. Vissa säger att det tar tio år att verkligen bemästra C# och CLR.
Full-Stack anses vara farligt
Det må vara sant att en dålig fullstackutvecklare är farlig och inte bidrar med någon djupgående kunskap, men det vore en lögn att påstå att alla fullstackutvecklare är likadana.
Jag har själv arbetat med både usla och fantastiska fullstack-utvecklare.
En dålig fullstack-utvecklare är inte expert på någonting och har inte tillräckligt djupgående kunskaper inom något område av mjukvaruutveckling. Han har grundläggande kunskaper om allt men saknar avancerade kunskaper. Han klarar inte av att lösa svåra problem när de uppstår.
Vem ska lösa de svåraste problemen? Ingen, eftersom ni har helt hopplösa utvecklare i ert team.
Var inte en helt värdelös utvecklare
En ”Full-Sucks”-utvecklare är ett stort problem i ett team, men jag tror att det handlar om rekrytering och utbildning, eftersom det finns många duktiga fullstack-utvecklare där ute som kan lösa de svåraste problemen.
Det är ett problem som rör rekrytering och företagskultur, eftersom en ”Full-Sucks”-utvecklare är någon som har fel inställning och mentalitet.
En ”Full-Sucks”-utvecklare är en person som inte har lagt ner tid på att bli riktigt skicklig. Den här typen av utvecklare bygger bara programvara som fungerar, även om det innebär att man lappar ihop NPM-moduler till en Node.js-app och kopierar kod från Stack Overflow utan att bry sig om kvaliteten. Att få det att fungera är viktigare än att göra det perfekt.
Att ge allt handlar inte om fokus eller specialisering,utan om inställning.
Är alla fullstack-utvecklare likadana? Nej.
En gång i tiden arbetade jag med en kille som var duktig på WPF, backend, molntjänster och DevOps. Hans specialområde var dock WPF, och han var en av de bästa i världen – vilket bevisades av att han drev den mest populära WPF-bloggen på jorden – men han visste också mycket väl hur man konfigurerar en bra CI/CD-pipeline.
Faktum är att han kunde lösa vilket problem som helst som han ställdes inför.
Hur är det ens möjligt? Han var smart och flitig. Han grävde sig djupt in i varje problem, oavsett vilken teknik det handlade om. Om han fick tid på sig kunde han lösa även de svåraste C++-problemen.
Han var en programmerare som behärskade flera språk, brydde sig om produkterna och kunderna och tog ansvar för hela kodbasen.
Om din backend-kod är usel och din frontend-kod är fantastisk, är din produkt som helhet ändå usel. Är det din uppgift att leverera helhetslösningar eller att sköta och försvara ditt ansvarsområde?
En dålig specialist ger samma resultat som en dålig fullstack-utvecklare, och teknisk skuld beror inte på kunskap, fokus och specialisering, utan på hur teamet är organiserat och på hur kvaliteten säkerställs genom väl utformade mekanismer för noggrann programvarudesign och kvalitetskontroll.
Teknisk skuld demoniseras också utan anledning, eftersom vi glömmer bort att entropi är ett faktum inom mjukvaruutveckling och att varje system tenderar att glida in i kaos. Kaos, och inte ordning, är det naturliga tillståndet.
Teknisk skuld går att hantera, men inte att eliminera eller förhindra. Varför demonisera något som alltid finns där och som bara behöver hanteras på rätt sätt?
Det finns till och med skäl för att faktiskt behålla en viss teknisk skuld inom företag, eftersom ett alltför stort fokus på kvalitet bromsar leveransen, men det blir ett ämne för en annan artikel.
Kvalitet är en process och beror inte på en enskild person, såvida man inte är en oberoende utvecklare.
Att ha en specialist kommer inte att hindra din kod från att glida in i kaos, och det är bara önsketänkande. En dålig Android-utvecklare skriver dålig Java-kod.
En duktig utvecklare bryr sig om all kod i kodbasen och inser att det handlar om lagarbete och att ta hand om koden.
Det finns en särskild typ av fullstack-utvecklare som specialiserar sig på ett område men som inte bortser från de övriga.
En T-formad fullstack-utvecklare har mycket djupa och ingående kunskaper inom ett specifikt område.
Han kan vara expert på React, Vue eller Node.js, men han har även kunskaper inom många andra områden, vilket gör att han kan bidra till hela kodbasen. Han är en anpassningsbar och mångsidig person.
En duktig utvecklare vet vad han ska fokusera på – det kan vara backend, men han kan också bidra till infrastrukturen eller till och med till frontend om det behövs.
Överkapacitet är bra i svåra tider, och svåra tider kommer att komma.
Ett högpresterande team består av T-formade individer som fyller alla luckor i en organisation.
Varför är detta användbart? Låt oss ta en titt på typiska hierarkiska team och silos – en armé av specialister.
Även om den skiktade organisationen känns väldigt trygg och låter bra till en början,är den ett kvarlevande inslag från den fruktade vattenfallsmodellen.
Varje team har tydligt definierade ansvarsområden och kan behärska ett annat område. Men är det verkligen detta som ett företag behöver? Uppdelning av roller och ansvarsområden är vanligt inom traditionell ledning, men det medför också konsekvenser. Ingenting är perfekt.
En frontend-utvecklare kan vara till nytta när det faktiskt finns arbete att göra på frontend-sidan, men vad händer när det inte finns något arbete på frontend-sidan?
Tänk om en DevOps-ingenjör är på semester. Vem ska då sköta driftsättningen?
Om en backend-utvecklare är inriktad på serversidan, vad händer då när det finns mer arbete på frontend-sidan än på backend-sidan på grund av verksamhetens behov?
Ska vi anställa fler personer eftersom frontend-resurserna inte utnyttjas fullt ut? Och hur är det med backend-utvecklaren som bara arbetar till 20 % av sin kapacitet med API:et? Han sysslar inte med frontend, så han kanske får göra några slumpmässiga uppgifter eller bara titta på YouTube-videor hela dagen.
En hierarkisk organisation som saknar fullstack-utvecklare genererar med tiden enorma mängder slöseri.
I själva verket är lagrade team i praktiken silor som verkar i sina egna mikromiljöer. De är helt fokuserade på att lyckas inom sin egen nivå och bortser från resten. Många av nivåerna bryr sig inte om front-enden, men i verkligheten ärdetjustfront-enden som utgör applikationen för kunden. Detsammagäller front-enden – en vacker front-end med en undermålig backend kommer inte att skapa något värde.
Ett system består av sina delar – och ännu mer än så. Hur kan man utforma en del av systemet och förstå alla konsekvenser för systemet som helhet om man inte förstår hur de andra delarna är uppbyggda? Räcker det med att prata lite med frontend-teamet? Eller bör man veta mer för att kunna hitta möjligheter till optimering och förbättring?
Silo-team är ett anti-mönster inom DevOps och borde inte förekomma i någon modern mjukvaruorganisation. Varje team behöver minst en fullstack-utvecklare.
Enligt teorin om begränsningar är isolerade team den perfekta platsen för att skapa flaskhalsar och hindra ett optimalt arbetsflöde i hela organisationen.
Är fullstack verkligen så dåligt?
Ju lägre man befinner sig go i vattenfallshierarkin bland frontend-, backend- och DevOps-ingenjörer, desto mindre kontakt har man med kunderna, kundernas feedback och analysdata.
Att tappa kontakten med verkligheten och kunderna bidrar till ännu mer slöseri, eftersom backend- och DevOps-ingenjörer kan hamna i en situation där de arbetar med optimeringar och uppgifter vars avkastning på investeringen (ROI) är mycket tveksam för det företag eller projekt de bidrar till.
Refaktorisering är en uppgift som ofta hamnar på dagordningen, även om den inte är nödvändig.
”Det finns inget att göra i den här sprinten, så låt oss omstrukturera koden och göra den mer skalbar” — En slösaktig utvecklare
Världens bästa företag, däribland Amazon och Google, strävar efter att alla team ska ha så mycket kontakt med kunderna som möjligt. Varför då? Jo, därför att kunderna och analyserna är ledstjärnan för varje produkt.
Det är bra att en backend-utvecklare granskar supportärenden, analysdata och kundfeedback, eftersom han då får en förståelse för hur hans arbete faktiskt påverkar verksamheten, men också för kundernas verkliga behov.
Varför optimerar ni DevOps-pipeline om verksamheten redan har en mycket tillfredsställande driftsättningsfrekvens samt låg MTTR och låg andel misslyckade förändringar?
Du slösar bara bort tid och pengar.
Du kanske tror att din uppgift är att se till att systemet har god drifttid och få buggar, men det är inte det verkliga värdet – det är bara att upprätthålla status quo, och din lön är fortfarande en kostnad och en risk för företaget.
Sanningen är att det i varje bra företag finns mer arbete än vad teamet klarar av, ochattarbetet inte är jämnt fördelat mellan rollerna i organisationen – och det kan det inte heller vara. Man kan inte alltid göra det man vill, men man bör göra det som behövs.
Arbetet är dynamiskt och fördelas ojämnt mellan olika funktioner inom en organisation beroende på verksamhetens prioriteringar.
Det vore kanske bättre om du bidrog på frontend-sidan där du kan tillföra verkligt värde, men problemet är att du inte är en fullstack-utvecklare och därför inte kan göra det. Du klagar över bristen på arbete på backend-sidan, tittar på PluralSight och ägnar dig åt onödig refaktorisering som inte tillför något verkligt värde.
Är det inte slöseri?
Efter att ha arbetat som WPF-utvecklare i tre år fram till 2015 kände jag att jag inte lärde mig särskilt mycket.
Efter en tid insåg jag att mina kunskapsvinster började avta och jag kände att jag hade tappat kontakten med utvecklingen inom branschen.
Det som oftast händer är att en utvecklare i min situation skulle tro att det är en bra lösning att byta produkt för att utmana sig själv, men på lång sikt leder det till stor tröghet och brist på utveckling.
Ibland byter utvecklare som har tröttnat på sitt arbete specialiseringsområde.
En iOS-utvecklare kan byta till Android och en Vue-utvecklare kan byta till React.
Problemet är att även om specialisering är utmanande, så är den det bara upp till en viss gräns – därefter avtar inlärningen och utmaningen helt och hållet, och då infinner sig tristessen.
Det är väldigt otillfredsställande att go sitta hela dagen och upprepa samma rörelser för att koda på autopilot. Det är raka motsatsen till vad neurovetenskapen rekommenderar oss att göra för att öka vår mentala kapacitet.
Vi måste försöka göra saker som känns obekväma för att utveckla vår hjärnkapacitet.
Är inte själva essensen i utveckling att ständigt lära sig nya saker och ställas inför utmaningar? T-formad fullstack-utveckling är den ultimata utmaningen, och möjligheterna till lärande är oändliga.
Att fördjupa sig i ett enda område är vettigt inom den akademiska världen, men inte inom produktionen.
I produktionen kan det hända vad som helst inom alla områden, och det är väldigt oförutsägbart.
Det finns också en underliggande psykologisk utmaning i att vara fullstack-utvecklare, nämligen insikten om att man måste lära sig en jävla massa saker för att kunna prestera på jobbet.
Vår kropp och vårt sinne är programmerade att undvika smärta och spara energi, och det är mycket smärtsamt att bryta sig ur sina egna förutfattade meningar och sin komfortzon för att lära sig nya saker när man vet att det är mycket smärtsamt och tidskrävande.
Men din motvilja mot att lära dig och bristen på tid betyder inte att det inte går att hantera.
Att studera inom olika ämnesområden innebär en utmaning när det gäller att planera och prioritera ditt studieprogram samt att se till att du fokuserar på rätt saker vid rätt tidpunkt.
Du kan lära dig React och DevOps samtidigt. Det handlar bara om fokus och uthållighet.
Du kan bli en flerspråkig programmerare. Du kan bli en programvaruversion av Leonardo da Vinci.
I vissa situationer behövs specialister, och det kan vara lämpligt att ha en dedikerad DevOps-ingenjör eller en QA-ingenjör som fokuserar på mycket specifika uppgifter, särskilt i större team och mycket komplexa system.
Varje företag bör dock alltid ifrågasätta det värde som levereras och kostnads-nyttoförhållandet.
Hur ser fördelningen ut mellan avancerade problem och vanliga problem som ska lösas under en 12-månadersperiod? Hur ofta behöver ni specialister i er verksamhet för att lösa problem som en vanlig utvecklare inte kan hantera? Skulle det vara enklare att anlita en konsult X timmar per år för att lösa dessa problem?
Specialister kan trivas i en akademisk miljö och inom open source-projekt, eftersom de kan välja vad de vill arbeta med och inte utsätts för press från en dynamisk affärsmiljö.
Det krävdes specialister för att utveckla protokoll, operativsystem och drivrutiner, men är det något du sysslar med till vardags? Eller utvecklar du affärsapplikationer och letar efter en ursäkt för att slippa jobba med frontend?
Att ha en specialist i teamet kan vara användbart, men vad händer när en specialist blir föråldrad? Tekniken förändras hela tiden och man måste se till att uppdatera sina kunskaper i tid, annars riskerar man att bli en COBOL-dinosaurie i teamet.
Full-stack är en självklarhet för alla framgångsrika företag. Tvärfunktionella team, funktionsbaserade team och liknande är den bästa vägen till framgång. Dessa team behöver full-stack-utvecklare.
Regelbunden kontakt med kunden och tillgång till analysdata är ett sätt att fatta välgrundade beslut.
Effektivitet och utnyttjande är bra. Tråkighet och onödig refaktorisering är det inte.
Varför tycker du att en T-formad fullstack-utvecklare är något negativt? Det tycker inte jag.
Startup-team kanske aldrig kommer att ha en tydlig organisationsstruktur med olika nivåer och specialister, eftersom jag vill att alla ska arbeta mycket nära kunderna och ha kontakt med verkligheten – vilket ofta innebär att man arbetar nära front-end, analysverktyg och kundfeedback – men också att man är mångsidig och effektiv för att utnyttja företagets budget på bästa sätt.
Kanske tillhör du den 1 % av specialisterna som verkligen behövs i ett team, men se till att fundera över om det verkligen är bra för din produkt eller ditt projekt på lång sikt.
