Deze horrorscenario’s achtervolgen alle developers in hun nachtmerries

Deze horrorscenario’s achtervolgen alle developers in hun nachtmerries

Tester, coderen, code ...

Hoeveel verschillende disciplines er ook zijn, er zijn lessen die alle developers moeten leren. Of je nu freelancer bent of in loondienst werkt, sommige horrorverhalen overkomen (bijna) alle developers.

Te veel vertrouwen in third parties

Als developers moeten we vertrouwen op third parties om ons werk te kunnen doen. Van simpele WordPress plugins tot libraries, het is allemaal door anderen gemaakt. Dit is natuurlijk onderdeel van het werk. Jij zorgt ervoor dat al deze puzzelstukjes samenkomen. Maar hoeveel voorwerk je ook doet, soms kies je een product dat je hele applicatie (tijdelijk) breekt.

“Dit onthoud ik wel”

Hoe vaak heb je code geschreven en vervolgens gedacht “dit onthoud ik wel!”. Zelfs als jij een fotografisch geheugen hebt en werkelijk waar nooit iets vergeet, is dit de nachtmerrie van iedere developer die na jou komt. Een project zonder changelog is als een machine zonder blauwdruk, je hebt geen idee hoe deze machine werkt en welke onderdelen erin zitten – maar veel succes met het onderhoud!

Dit geldt ook voor andere zaken zoals “even snel wat CSS veranderen” of aanpassingen maken aan een bestaand template. Ja het werkt nu, maar als je maanden later ineens de website breekt is het vrij lastig om erachter te komen wat ook alweer het origineel was.

Doe jezelf en je opvolgers dus een plezier en documenteer wat je doet. Ja het is nu wat extra werk, maar future you wordt hier heel blij van!

Denken dat je weet wat de opdrachtgever wil

Ervaring en trends zorgen ervoor dat je soms precies denkt te weten wat een opdrachtgever wil. Alle opdrachtgevers voor hem wilden immers hetzelfde. Dit is een bekende valkuil en zorgt ervoor dat je niet meer goed luistert naar wat er gevraagd wordt. Het eerste concept is daarmee vaak een flinke teleurstelling en het kost je veel tijd om terug te werken naar een versie waar ze wel op zitten te wachten. Vergeet daarom niet om, hoe standaard een opdracht ook lijkt, goed door te vragen naar de wensen.

“Nog één kleine aanpassing”

In het begin gaat alles eigenlijk prima met deze opdrachtgever. Jullie zijn het beiden eens over de nieuwe applicatie, welke functionaliteiten het moet hebben en ook over het eventuele design zitten jullie lekker op een lijn. Jij gaat dus aan de slag en levert een mooie applicatie op. En dat is waar het begint… Ineens wil de opdrachtgever toch iets heel anders. Er moet nog even een (in zijn ogen) kleine aanpassing worden gedaan die je uren werk kost. Of nog erger, die eigenlijk het hele design om zeep helpt. Zeker bij front-end webdevelopers is dit een héél bekend scenario. Zo bekend dat The Oatmeal er een strip over heeft gemaakt.

Yes! Bug opgelost, nu zit je alleen wel met één klein probleem

Het oplossen van bugs is het minst leuke aan je werk. Het is tijdrovend, voelt onproductief op en tot overmaat van ramp is het ook nog ontzettend frustrerend. Na uren staren en aanpassingen maken heb je eindelijk die vervelende bug opgelost. Om er dan vervolgens achter te komen dat deze oplossing voor tien extra bugs zorgt…

Legacy code

De ultieme nachtmerrie van een developer begint eigenlijk wanneer hij een project krijgt waar al meerdere developers aan hebben gewerkt. Iedereen heeft zo zijn eigen werkwijze, en dat is helemaal prima, maar sommige dingen zijn ik-trek-de-haren-uit-mijn-hoofd irritant:

  1. Random en weinig omschrijvende namen geven aan variabelen. Ja iedereen heeft misschien zijn eigen variant van logische naamgeving. Maar kunnen we alstublieft dingen wel zo omschrijven dat het voor de developer na jou ook nog te ontcijferen is? En als je het dan echt niet kan laten om vreemde namen te geven, stuur dan ook altijd even een documentje mee zodat de rest niet eerst uren bezig is met uitzoeken wat de variabelen precies zijn.
     
  2. Geen structuur, geen design en dat dan ook nog gecombineerd met bovenstaand punt? Dan wil je echt niets liever dan de code (en de vorige developer) in de fik zetten en gewoon opnieuw beginnen. Helaas vindt de opdrachtgever dit vaak geen goed idee. Ze hebben immers al best wat geld uitgegeven aan de eerste variant.
     
  3. Geen documentatie whatsoever. Combineer de welbekende “dit onthoud ik wel” met de bovenstaande punten en bedenk je dan dat je eigenlijk ook niet weet wat eigenlijk precies de functie van de code moet zijn. Dat is hoe legacy code zonder documentatie voelt. Ja het is vervelend om alles wat standaard al in je hoofd zit bij te houden. Maar het is wel héél fijn voor diegene die na jou komt. 

Niet op tijd je grenzen aangeven

Of je nu in loondienst of op freelancebasis werkt, je grenzen bewaken leer je door tegen momenten aan te lopen dat er over je grenzen heen wordt gegaan. Of het nu kennissen zijn die je vragen om iets gratis te doen (en vervolgens al je tijd opslokken), of collega’s die je buiten werktijd vragen om toch nog even bij te springen. Geef mensen een vinger en ze nemen je hele hand. Krijg jij op zondagmiddag een berichtje om iets op te lossen? Weet dan dat je, wanneer je besluit te reageren, mensen leert dat het prima is om je op dat moment te storen met werk gerelateerde zaken.

Of je dit prettig vindt of niet is aan jou. Weet in ieder geval dat ook jij grenzen hebt en dat je vaak pas de gevolgen merkt als mensen er al meer dan eens overheen zijn gegaan. Ook dit is een les die je waarschijnlijk zelf moet leren, maar een gewaarschuwd mens…