Tech op het web - uitgelegd - Waarom eigenlijk?

#1・
Tech voor op het web uitgelegd
30

subscribers

14

issues

Subscribe to our newsletter

By subscribing, you agree with Revue’s Terms of Service and Privacy Policy and understand that Tech voor op het web uitgelegd will receive your email address.

Jos van Essen
Jos van Essen
Je hebt je ingeschreven voor de Revue nieuwsbrief waarin ik wekelijks een technische term begrijpelijk ga proberen te maken voor mensen die misschien van huis-uit niet zo technisch aangelegd zijn. In deze eerste editie wil ik stilstaan bij het ‘waarom’. Welke situaties kom je tegen als je wat minder technisch onderlegd bent? En waarom is dit een probleem?

Tevreden keek de developer door de kamer
De techneut keek om zich heen. Hij had ons zojuist in een kwartier bijgepraat over het project. Althans, dat was de bedoeling. Het bleek namelijk dat het project een webservice, REST API en Ruby on Rails als framework had. En dat er dynamische feeds naar de beacons werd verstuurd met productinfo. Ik zag mensen in de ruimte met hun ogen knipperen. Hij had net zo goed in het Arabisch iets kunnen voorlezen.
Ik zat ook in bovenstaande meeting. En hoewel ik eigenlijk wel begreep wat er gezegd werd voelde ik mee met de 4 mensen die er ook bij zaten die werkelijk geen idee hadden waar ze naar hadden geluisterd.
De afgelopen jaren is de afdeling ‘techniek’ opgegaan in de organisatie. Er zijn nieuwe processen gekomen (zoals Agile en Scrum) die hebben gezorgd dat techniek dichter bij is. Vaak ook letterlijk: de meeste marketing-vrienden die ik heb werken in teams waar ook developers zijn.
Toch is er nog steeds vrij veel jargon. En dat jargon maakt het voor deze teams soms lastig te communiceren. Je kunt dit oplossen door alle ontwikkelaars in de meetings te vragen om bijvoorbeeld analogieen te vragen, maar dit levert uiteindelijk nogal clowneske toestanden op.
Bijna ieder beroep kent z'n eigen jargon en z'n specifieke eigenaardigheden in hoe begrippen en taal zich ontwikkelen. Zie ook de video hier beneden.
Ik weet uit ervaring dat een deel van mijn (niet technische) vrienden zich ook onzeker voelt. Soms krijg ik wel eens appjes met daarin screenshots van gesprekken of opmerkingen met het bijschrift: ,,klopt dit?“.
Het is niet fijn om je onzeker te voelen in een baan die je leuk vind. En daarom heb ik besloten om een deel van dit jargon te de-mystificeren.
Jargon is in zekere zin wel altijd nodig om een discussie inhoudelijk, on point en nuttig te houden.
Toch zit er in het geval van technologie ook een duistere kant aan jargon. Deze wordt misbruikt door slimme accountmanagers van webbureaus in offertes. Door matige ontwikkelaars die zichzelf interessanter willen doen lijken. Of door slimme projectmanagers die de complexiteit misbruiken om deadlines naar achteren te schuiven.
Je wapenen tegen bullshit in een offerte kan flink wat geld schelen. Dit is een voorbeeld van een stijlpost die ik dit jaar zag in een offerte-traject voor een klant:
4 dagen voor het inrichten van een deployment-straat a €120,- per uur €3840,-
Ik geloof er best in dat zo'n deploymentstraat (de manier hoe de code van de ontwikkelaar naar de server gaat, hierover dus later meer) belangrijk is. Maar 4 dagen? Met tools als Github Actions of bijvoorbeeld Buddy is zo'n situatie in een paar uurtjes te configureren.
Een andere allergie die ik soms voel bij technologie is de wens van veel ontwikkelaars om zich toe te leggen op nieuwe technologie en nieuwe platformen. Omdat ik zelf ook best technisch ben snap ik de aantrekkelijkheid daarvan (iets nieuws doen!) maar veel ontwikkelaars onderschatten hoeveel tijd en moeite het kost om een nieuw framework ook écht in productie te krijgen. Ik bouwde ooit een MVP in Meteor wat ik destijds fantastisch vond maar waar ik in de loop van de tijd zo enorm in vastliep was de tijd die het koste om een server dusdanig te configureren dat deze mijn code ook kon draaien. Gelukkig was dit geen klant-project want anders hadden we meteen een flinke vertraging te pakken.
En dan de projectmanagers, of product owners. Ooit moest ik voor een grote verzekeraar een training geven voor twee groepen van 30. Deze mensen klaagden steen- en been dat ze geen enkel inzicht hadden in hoe de ontwikkelaars werkten. En dat er veels te weinig waren. En dat er veel afhankelijkheden waren. Dat ze tussen-producten kregen die ze niet konden testen. Kortom: dat er nogal een kloof was tussen verwachtingen.
Ik denk dat de beste project-managers uiteindelijk goed ingecheckt zijn (gewapend met de juiste inhoudelijke kennis!) in hun ontwikkelteam, en complexiteit niet als smoes hoeven te gebruiken. Dat ze echt kunnen meedoen in hun team in de discussies. En deze niet als ‘te inhoudelijk’ markeren (echt gebeurd!).
Kortom: als je beter weet waar je over praat kun je effectiever vergaderen en je werk doen, ruik je bullshit op kilometers afstand en kun je geld besparen in je offerte-traject.
Hopelijk zijn dat genoeg redenen om deze nieuwsbrief te blijven lezen ;-)
Tot volgende week!
Heb je vragen, opmerkingen of suggesties, klik dan op ‘reply’ op deze e-mail. Dan komt ie vanzelf bij mij binnen. Ken je mensen voor wie deze nieuwsbrief ook interessant is? Deel deze dan met hen. Dank daarvoor!
Jargon. - Sluipschutters
Jargon. - Sluipschutters
Did you enjoy this issue? Yes No
Jos van Essen
Jos van Essen

JSON, API's, webtokens, CI deployments, JavaScript, Tag Manager: we horen allemaal regelmatig termen voorbij komen waarvan we niet 100% zeker weten of we het ook daadwerkelijk begrijpt. Deze nieuwsbrief laat een licht schijnen op deze materie: tech voor op het web uitgelegd

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.