Code met een ziel

Soms zijn het niet de grote projecten, maar juist de kleine hobbyprojecten waar ik de meeste lol uit haal. Even terug naar de basis. In mijn geval: een eenvoudige app bouwen, puur om weer te spelen met vanilla JavaScript en nested CSS. Geen groot plan, geen roadmap, gewoon leren door te doen.

Om binnen Leukeleu te bepalen wie er corvée heeft (lunch halen, vaatwasser inruimen, etc) hebben we een web app gemaakt waar we dat eerlijk kunnen bepalen: De Determinator.

Het mooie van zo’n project? Je bepaalt zelf hoe het eruit moet zien, hoe de logica werkt en je kunt net zo lang blijven schaven tot het past bij je idee. Vaak gaat de meeste tijd dan ook niet zitten in het programmeren zelf, maar in het zoeken, klooien, aanpassen en weer verder sleutelen. Precies dat proces maakt dat zo’n project voelt alsof het echt van jou is.

De teleurstelling

Vorige week kreeg ik ineens een nieuwe pull request binnen. Iemand (ik noem geen namen ;) had functionaliteit toegevoegd. Op het eerste gezicht aardig bedoeld, maar al snel zag ik dat het een typische “vibe coded” toevoeging was. De toevoeging werkte wel als prototype, maar voegde niet meteen waarde toe aan de app zelf op deze manier. Om maar een metafoor te gebruiken; Ik voelde mij als een schilder die een (in mijn ogen) mooi schilderij had gemaakt, waar iemand een simpel poppetje bij had gekrabbeld.

Code en werk zonder ziel

Een goede developer geeft om zijn code. Niet alleen om of het “werkt” maar ook om of het duurzaam, leesbaar en bruikbaar is. Deze PR had dat allemaal niet. Het had geen ziel. En dat is precies waar het vaak misgaat bij “snelle oplossingen”. Iets dat oppervlakkig gezien functioneert, kan in werkelijkheid de kwaliteit en samenhang van een project ondermijnen. Je ziet het in hobbyprojecten, waar het niet zo erg is, maar ook in serieuze en bedrijfskritische applicaties.

Herkenbaar?

Veel organisaties lopen tegen precies ditzelfde probleem aan. Een applicatie die ooit met zorg is gebouwd, raakt na verloop van tijd overspoeld door snelle fixes, halfbakken uitbreidingen of integraties die niet echt passen. Het resultaat: software die fragiel, inconsistent en frustrerend is om mee te werken.

Die teleurstelling is geen luxeprobleem. Het vertraagt innovatie, vergroot de kans op fouten en tast het vertrouwen van gebruikers aan. Net zoals ik even geen zin meer had om naar mijn hobbyproject te kijken na die PR, zo haken teams en gebruikers af bij software die geen samenhang of kwaliteit meer uitstraalt.

Code met ziel

Wat maakt dan het verschil? Code met ziel. Daarmee bedoel ik code die met aandacht is geschreven. Waar keuzes onderbouwd zijn, de interface logisch voelt en de architectuur ruimte biedt om door te ontwikkelen. Dat vraagt om meer dan alleen technische vaardigheden. Het gaat om respect voor het werk dat er al ligt, om begrip van de context en om het besef dat software altijd onderdeel is van een groter geheel.

De teleurstelling over die ene PR werd voor mij een herinnering aan iets groters: goede software schrijven gaat niet alleen over snel resultaat, maar ook over duurzame waarde. Het is beter om één goed doordachte toevoeging te maken, dan tien halfbakken features. En misschien nog belangrijker: een developer die om zijn code geeft, zorgt voor vertrouwen. In zijn team, bij zijn gebruikers, en uiteindelijk in de hele organisatie.

Tot slot

Mijn hobbyproject is er niet slechter van geworden. Sterker nog, het gaf me een aanleiding om weer scherp te kijken naar wat kwaliteit voor mij betekent. Maar voor organisaties die afhankelijk zijn van hun software is dit een serieuze les: software zonder ziel is software zonder toekomst. Wil je weten hoe wij bij Leukeleu omgaan met zulke uitdagingen? Lees meer over hoe we omgaan met technical debt of plan een gesprek met ons team.