Wanneer we naar code of naar websites kijken, kunnen we veel leren over de makers, hun prioriteiten, welke technieken er gebruikt zijn, en meer. Helaas kunnen we ook slordheden ontdekken. Daar hoef je geen ontwikkelaar voor te zijn, gezien reguliere gebruikers ook deze problemen ervaren. Test een aantal websites met Lighthouse, en we zien verschillende mankementen, vaak problemen met de laadsnelheid of toegankelijkheid. Waarom hebben zoveel websites dezelfde problemen?
Als vacatures indicatie zijn van hoe een gemiddeld web development team er uit ziet, lijkt het er op dat het gemiddelde team goed is in JavaScript, of met JavaScript frameworks, en verschillende tools die uit de JavaScript ecosysteem komen, zoals React, TypeScript, Zod, GraphQL/tRPC, Prisma/Drizzle, noem maar op. Deze developers zijn zo gericht op deze tools en vaardigheden, dat het hun afleid om kennis en ervaring op te doen met fundamentele technologieën en concepten, zoals HTML en CSS. Vacatures voor dit soort teams bevatten ook zelden toegankelijkheid, front-end performance, zoekmachineoptimalisatie, of security als vaardigheid. Dat zijn klaarblijkelijk allemaal bijzaken.
Als industrie lijken we homogene teams te prefereren, zowel op technisch als op andere vlakken, met overlappende vaardigheden, waardoor veel vaardigheden die essentiëel zijn voor goede software ontbreken. Het gevolg is dat veel producten hierdoor mankementen bevatten terwijl de JavaScript erg goed kan zijn. Helaas merkt de gebruiker weinig van dat laatste, maar zal wel een trage Time To Interactive, een ontbrekende skip link wanneer de toetsenbord gebruikt wordt om te navigeren, of de aankondiging van vele “klik hier” links wel opmerken wanneer gebruikers afhankelijk zijn van een screanreader.
Net als dat een nieuwe high-end computer met een hele oude processor langzaam is, zullen websites waar de essentials niet op orde zijn ook niet goed werken. Wil je goede software, moet de kwaliteit op (nagenoeg) alle vlakken goed zijn. Dat lukt niet wanneer er belangrijke vaardigheden ontbreken bij de ontwikkelaars. Een team dat goede software moet opleveren, maar niet de vereiste vaardigheden heeft, is incompleet.
Iedereen heeft eigen interesses, dus ik ga je nu niet overtuigen om ergens in te verdiepen, maar als team heb je wel de verantwoordelijkheid om ontbrekende vaardigheden in het team te identificeren en aan te kaarten. Als de eerder benoemde baanomschrijving bij jouw team past, wellicht is het tijd om vaardigheden in kaart te brengen of om competentie te meten met een workshop, quiz of oefeningen. Als iedereen in jouw team daadwerkelijk JavaScript-gericht is, is de kans groot dat er wat te verbeteren valt in front-of-the-front-end-gerelateerde onderwerpen.
Na het identificeren is het tijd om te mitigeren. We kunnen wat presentaties bekijken of een training volgen, maar er zijn mensen die zich hier in specialiseren — deze vaardigheden heb je niet met een dag of twee. Een andere en tijdelijke oplossing om de kwaliteit van projecten verbeteren, is door een consultant of freelancer er naar te laten kijken en eventueel mee te helpen in het oplossen. Hiermee ga je echter geen problemen in de toekomst voorkomen.
De enige permanente oplossing is om de kennis ten alle tijden in het team te hebben, dat het team elkaar aanvult. Dit is ook het moeilijkst om intern te verkopen, want zowel teamwissels als het aannemen van nieuw personeel heeft invloed op uitgaves en budgetten. Vaak kost het ook wat tijd, dus je kan bijvoorbeeld op korte termijn tijdelijke hulp inkopen, maar ook zorgen dat de eerstvolgende vacature past bij wat het team nodig heeft. Ongeacht hoe je het intern verkoopt, ontbrekende skills blijven als je ze niet identificeert of het niet aankaart.
Test eens een aantal websites met Lighthouse of een andere tool, en je zal zien dat perfect functionerende sites regelmatig toegankelijkheid, performance, en andere problemen hebben. Vaak zijn dit problemen die voorkomen had kunnen worden met de vaardigheden van een front-of-the-front-end developer.