Achter de schermen bij Stimmt met Paul, Lead Backend Developer

Backend development: vooruitdenken is beter dan oplossen

Wat gebeurt er eigenlijk achter de schermen nadat een website live is? Voor veel bezoekers lijkt alles vanzelf te werken, maar achter iedere stabiele website schuilt een developer die continu monitort, verbetert en vooruitdenkt.

In deze editie van Achter de schermen bij Stimmt spreken we met Paul Steenkist, Lead Backend Developer. Over zijn route van ondernemer naar Stimmt, waarom hij liever problemen voorkomt dan geneest en waarom een verkeerde aanname soms meer tijd kost dan een ingewikkelde bug.

Van Sony naar een eigen bedrijf en uiteindelijk Stimmt

Paul rolde niet met een uitgestippeld carrièreplan de softwareontwikkeling in. Hij begon zijn loopbaan bij Sony, waar hij interne applicaties ontwikkelde. Toen zijn leidinggevende hem de kans bood om voor zichzelf te beginnen, greep hij die met beide handen aan. Op zijn 24e startte hij een eigen softwarebedrijf, dat hij vijftien jaar lang met veel plezier runde.

Later deed zich de kans voor om een nieuwe stap te zetten: inmiddels werkt hij alweer zo’n vijf jaar bij Stimmt, waar hij als Lead Backend Developer verantwoordelijk is voor de technische basis achter uiteenlopende digitale projecten. 

Wat klanten meestal niet zien

Wanneer een project is opgeleverd, lijkt het voor klanten vaak alsof het werk erop zit. In werkelijkheid begint dan juist een belangrijk deel van Pauls werk. “Ik houd klantomgevingen actief in de gaten, controleer schijfruimte, logbestanden en de werking van applicaties,” vertelt Paul, “ik probeer problemen voor te zijn voordat gebruikers er last van krijgen.” 

Daarnaast onderhoudt Paul ook persoonlijk contact met klanten. Soms doet hij dat zelfs onderweg naar huis. “Een telefoongesprek werkt vaak net wat sneller of prettiger dan een lange e-mail,” zegt hij, “een project stopt niet zodra iets live staat, juist daarna wil je zeker weten dat alles blijft doen wat het moet doen.”

Verkeerde aannames zijn een grote valkuil

Paul vertelt over een situatie die hem altijd is bijgebleven: “We zochten voor een klant urenlang naar een ingewikkelde technische oorzaak van een probleem.” Na ongeveer acht uur debuggen bleek dat er helemaal niets mis was met de code. “De oorzaak zat in een verkeerde instelling binnen de beheeromgeving.” 

Die ervaring heeft zijn manier van werken blijvend veranderd. Eerst de aannames controleren, daarna pas de ingewikkelde scenario’s onderzoeken. Sindsdien begint hij vrijwel ieder onderzoek met dezelfde vraag: hebben we de basis eigenlijk wel gecontroleerd? “Je kunt jezelf helemaal verliezen in complexe technische analyses, terwijl het probleem soms verrassend eenvoudig blijkt. Het bespaart tijd én voorkomt tunnelvisie,” aldus Paul.

Wanneer een technische oplossing écht goed is

Voor Paul draait goede software niet om perfecte code. “Natuurlijk wil iedere developer nette, onderhoudbare software schrijven. Maar uiteindelijk is de belangrijkste vraag: helpt deze oplossing de klant echt verder?”

Dat betekent soms dat hij eerst een snelle oplossing implementeert om een storing op te lossen, om daarna tijd te nemen voor een structurele verbetering. Bij nieuwe projecten kiest Paul liever direct voor een toekomstbestendige architectuur. “Die afweging maak ik niet alleen op technische gronden, maar vooral vanuit de businesscase van de klant. Welke risico’s zijn acceptabel? Wat levert de meeste waarde op? En wat is op dit moment de slimste keuze?”

AI maakt developers sneller, maar zeker niet overbodig

“Tuurlijk, ook backend development verandert snel door AI en ik gebruik de mogelijkheden graag,” zegt Paul. “Tegelijkertijd zie ik ook duidelijke grenzen. AI helpt developers sneller te werken, maar neemt het denkwerk niet over. Juist het beoordelen van oplossingen, het begrijpen van de context van een organisatie en het inschatten van risico’s blijven mensenwerk.” 

Daarmee ziet hij ook een misvatting ontstaan. “AI maakt softwareontwikkeling niet automatisch goedkoper of beter. AI maakt het werk sneller, maar de kwaliteit hangt nog altijd af van de mensen die de juiste vragen stellen en de uitkomsten kritisch beoordelen. Essentieel onderdeel van ons vak, is dat we AI-output blijven toetsen, bijsturen en valideren.”

Drie tips voor een succesvolle start van een digitaal project

Volgens Paul hoeven succesvolle digitale projecten niet ingewikkeld te beginnen. Zijn belangrijkste adviezen lees je hieronder.

1. Houd niet vast aan hoe het altijd ging. Bekijk processen kritisch en durf bestaande werkwijzen opnieuw tegen het licht te houden. Los tijdelijke workarounds niet eindeloos op met nieuwe workarounds, maar pak de oorzaak aan.

2. Maak grote projecten klein. Werk in overzichtelijke stappen. Kleine, testbare opleveringen zorgen voor sneller resultaat, meer controle en minder risico dan één grote eindoplevering.

3. Betrek de juiste mensen. Laat specialisten meedenken over hun eigen vakgebied. De beste oplossingen ontstaan wanneer de juiste expertise op het juiste moment aan tafel zit. 

Even kiezen: vijf dilemma’s

• Complexe bug oplossen óf een elegante oplossing bedenken? 
  Eerst de bug oplossen, zodat de klant verder kan, om daarna een structurele oplossing te bouwen, zodat hetzelfde probleem in de toekomst wordt voorkomen. 
• Flexibiliteit voor de toekomst óf de snelste oplossing? 
  Volgens Paul hangt dat af van de situatie. Bij een live-probleem gaat continuïteit altijd voor. Soms is een tijdelijke quick fix nodig om de business draaiende te houden, maar daarna wordt gewerkt aan een structurele oplossing. Zo blijft de webshop niet alleen vandaag beschikbaar, maar ook op de langere termijn stabiel en betrouwbaar.
• Vertrouwen op ervaring óf alles onderbouwen met data?
  “Mijn ervaring geeft de juiste richting, maar ik toets die altijd aan data,” is het stellige antwoord. En dat zegt eigenlijk al genoeg.
• Perfecte code óf maximale klantwaarde? 
  Maximale klantwaarde. Want uiteindelijk bouwen we software om organisaties verder te helpen.
• Vrijdagmiddag: een mysterieuze bug óf een nieuwe integratie bouwen? 
  Hier moest Paul even over nadenken. Uiteindelijk koos hij voor het bouwen van een nieuwe integratie.

Voor Paul staan snelheid en kwaliteit, flexibiliteit en stabiliteit of ervaring en data niet tegenover elkaar. “Juist de combinatie maakt een technische oplossing sterk,” besluit hij.