Titeln har blivit lite av ett modeord, men det den beskriver är reell och ofta underskattad.
En fullstack-utvecklare rör sig genom hela systemet — från det användaren ser och klickar på, till den logik som körs på servern, till hur data lagras och hämtas. Det handlar inte om att vara bäst på allt, utan om att förstå tillräckligt av varje lager för att se hur de påverkar varandra. Den förmågan är mer sällsynt än den låter.
I praktiken innebär det att kunna följa ett problem hela vägen. När något inte fungerar som det ska behöver du inte gissa vilket lager felet befinner sig i — du kan följa kedjan. Det är den egentliga poängen med rollen, inte att du kan lista fem ramverk.
Jag har arbetat som systemutvecklare i över tjugo år, mot finansiella system och e-handel, i roller som spänner från arkitektur och backendutveckling till gränssnitt och integration. Det som framträder tydligast i efterhand är inte vilket språk eller ramverk som användes vid vilken tidpunkt — det förändras ändå. Det som håller är förmågan att läsa ett system: förstå vad det försöker göra, var det är sårbart och vad en förändring i ett lager faktiskt kostar i ett annat.
Den förmågan är också det som gör fullstack-perspektivet användbart utanför ren utveckling. I innovationsprojekt, i tekniska upphandlingar, i diskussioner om systemarkitektur och säkerhet — det hjälper att ha sett hur systemen faktiskt byggs, inte bara hur de beskrivs i en kravspecifikation.
Rollen kräver ett visst mått av komfort med att befinna sig i gränszoner. Mellan frontend och backend. Mellan teknik och krav. Mellan det som är möjligt och det som är rimligt. Det är ofta där de intressanta problemen finns.