Programmeren gaat niet over het toetsenbord indrukken en zo snel mogelijk typen. Het gaat niet om het religieus uit het hoofd leren van sneltoetsen en het uiteindelijk overbodig maken van de muis. Het gaat niet over het leren van elke programmeertaal die er is, als dat überhaupt al mogelijk is. Een goede programmeur wordt niet bepaald door het merk, de prijs, de prestaties en het besturingssysteem van zijn computer, noch door zijn voorkeur voor code-editors en IDE’s-VS Code, Atom, IntelliJ IDEA, Vim, Notepad++, of iets anders. In tegenstelling tot wat vaak wordt gedacht dankzij de vele Hollywoodfilms, staat programmeren zeker niet gelijk aan hacken.
Daarnaast gaat het verder dan het uit het hoofd leren van de syntaxis en ingebouwde functionaliteiten van een programmeertaal. Logica, voorwaarden, if verklaringen, en algoritmen – vooral die van het sorteren – geven geen volledig beeld van wat programmeren werkelijk is. Wiskunde, recursie, informatica, en design patterns doen er ook geen recht aan. Hoewel ze een groot deel uitmaken van wat programmeren is, zijn ze slechts één stukje van de puzzel.
Ontwerpen en plannen
Voordat er ook maar één regel code wordt geschreven, worden het ontwerp en de architectuur van een project grondig gepland om de kans op een soepele ontwikkelingscyclus te garanderen of op zijn minst te vergroten. Dit is waar softwareontwerp in het spel komt. Toolchains, pijplijnen, abstractielagen voor publieke en interne API’s, modularisatie, objectrelaties en databasestructurering worden allemaal gepland tijdens deze ontwikkelingsfase.
We zijn levende, ademende debuggers
De kunst van het programmeren vereist dat we buiten de gebaande paden denken en problemen oplossen met de meest pragmatische, effectieve en haalbare oplossingen. Dit is waarschijnlijk de reden waarom wij de “I.T. man” of “customer support” van het huishouden zijn. Het is praktisch onze taak te repareren wat kapot is. Het is alsof “programmeren” een veredelde manier is om te zeggen “problemen oplossen”.
Met andere woorden, we zijn levende, ademende debuggers op en naast onze computers, en daarom is het belangrijk dat we weten hoe we documentatie moeten lezen en schrijven. Goede documentatie – in de vorm van pagina’s met gedetailleerde documentatie, of zo eenvoudig als het toevoegen van waardevolle commentaren aan de code – is een van de belangrijkste levensaders van een programmeur. Zonder dit, zijn we verloren in het donker, niet in staat om onze plichten als debuggers te vervullen. Er kan weinig tot geen vooruitgang worden geboekt omdat het grootste deel van onze tijd zou worden besteed aan experimenteren en onderzoeken hoe een framework of legacy code base werkt. Over het geheel genomen zou het resulteren in een vreselijk slechte ontwikkelaarservaring.
Bedenk alle mogelijke scenario’s
Debuggen is al moeilijk genoeg zoals het is. Om het nog erger te maken, de uitvoering van code is meestal niet lineair. Grote projecten hebben meerdere “vertakkingen” van mogelijke uitvoeringstrajecten als gevolg van programmalogica met het if statement. We moeten rekening houden met elk mogelijk scenario en elke mogelijke fout, vooral als het gaat om invoer door de gebruiker. De cognitieve belasting die het bijhouden van elk mogelijk uitvoeringstraject met zich meebrengt, maakt programmeren des te moeilijker.
Gebruikerservaring
Stappen we buiten de wereld van ontwikkeling, dan kruipen we in de huid van een gemiddelde gebruiker. Naast het bieden van functionaliteit, het toevoegen van nieuwe functies, het oplossen van bugs, en het documenteren van onze code base, richten we ons ook op hoe een gemiddelde gebruiker interageert met onze app of software. We houden rekening met meerdere factoren die leiden tot een geweldige gebruikerservaring, zoals (maar niet beperkt tot) toegankelijkheid, bruikbaarheid, gebruiksvriendelijkheid en -ontdekbaarheid, UI-ontwerp, kleurenthema’s, functionele animaties, en prestaties.
Prestaties en optimalisatie
Over prestatie gesproken, prestaties zijn een enorm facet van programmeren op zich. Wij, vooral degenen met een achtergrond in de informatica, streven ernaar de meest tijd- en ruimte-efficiënte algoritmen te gebruiken en te schrijven. We obsederen over de ondoorgrondelijke tijdschaal van microseconden om het meeste uit ons beschikbare geheugen, CPU’s en GPU’s te persen.
In de context van webontwikkeling is netwerkoptimalisatie een belangrijk concept om te begrijpen. We springen door hoepels te minify en onze HTML, CSS, en JavaScript comprimeren alleen maar om de payload van een antwoord van de server te minimaliseren. Afbeeldingen en andere diverse bronnen worden ook gecomprimeerd en lazy-loaded om de hoeveelheid data te minimaliseren die de gebruiker moet downloaden voordat een pagina zinvol en bruikbaar wordt.
Echter, er zijn momenten dat we te geobsedeerd raken door prestaties. Voortijdige optimalisatie wordt een probleem wanneer we ons onnodig bezighouden met het optimaliseren van bepaalde delen van een code base in plaats van ons te concentreren op wat er moet worden gedaan voor de werkelijke vooruitgang en productiviteit. In dat geval moeten we de wijsheid hebben om te beoordelen welke delen van de code base echt optimalisatie nodig hebben.
Security
Naast de UI en de logica van onze software, zijn we als programmeurs verantwoordelijk voor de veiligheid van onze gebruikers. In deze tijd waarin gegevens zeer begeerd zijn en veel geld verdienen, is het belangrijker dan ooit om ervoor te zorgen dat de persoonlijke gegevens van onze gebruikers veilig zijn. Wij nemen extra maatregelen om privégegevens te beschermen omdat onze gebruikers onze software vertrouwen. Als we die verantwoordelijkheid niet nemen, zijn we zeker geen echte programmeurs, zelfs niet bij lange na niet.
We kunnen nooit te veilig zijn bij het benaderen van beveiliging. Als algemene vuistregel geldt: “vertrouw nooit de invoer van de gebruiker”. Het kan zelfs worden beschouwd als een “best practice” om veel moeite te doen om gegevens en gebruikersinvoer te zuiveren. Niet alleen brengen we onze software en infrastructuur in groot gevaar als we er niet voorzichtig mee zijn, we lopen ook het risico gevoelige gebruikersgegevens te compromitteren – dezelfde gegevens die we als programmeurs beloven te beschermen.
Veiligheid is echter niet exclusief voor gebruikersgegevens en -input. Virussen, wormen, Trojaanse paarden, adware, key loggers, ransomware, en andere vormen van computer malware blijven zich verspreiden en teisteren miljoenen en miljoenen computers en apparaten over de hele wereld. Zelfs na tientallen jaren van technologische verbeteringen in hardware en software, bestaat er niet zoiets als een onkwetsbaar systeem. Beveiliging is gewoon een ambacht dat voortdurend wordt aangescherpt, maar nooit zal worden geperfectioneerd omdat er altijd een paar nieuwsgierigen zullen zijn die onderzoeken en zoeken naar elke mogelijke manier om een systeem te “hacken”.
Om die reden, ongeacht het gebruik en de gebruikersbasis, ontwerpen wij onze software met beveiliging in gedachten als een van de topprioriteiten, zo niet de topprioriteit. We doen dit om onze gebruikers te beschermen tegen de eerder genoemde bedreigingen die ongemakken kunnen veroorzaken, zoals verlies van gegevens, bestandscorruptie en systeemcrashes om er een paar te noemen.
Teamwork makes the dream work
Ook al heeft het niet per se betrekking op programmeren, teamwork speelt een zeer integrale rol in softwareontwikkeling. Met alle complexiteit en bewegende delen van een groot project, is het onmogelijk voor slechts één persoon om kwaliteitssoftware te ontwikkelen in het snelle tempo van regelmatige iteratie of onder de strikte deadlines en tijdsdruk van een klant of een toezichthoudende entiteit.
Daarom hebben we verschillende teams van mensen die gespecialiseerd zijn in één van de vele facetten van programmeren. Eén persoon zal nooit alle vaardigheden en kennis hebben die nodig zijn om elk facet effectief en samenhangend aan elkaar te lijmen. Het ene team kan verantwoordelijk zijn voor UI design en toegankelijkheid, terwijl een ander team werkt aan de functionaliteit van de software zelf. Als alle competenties van de verschillende gespecialiseerde teams worden gecombineerd, zal de resulterende software de beste functionaliteit, gebruikerservaring, prestaties, en veiligheid hebben die het mogelijk kan hebben binnen financiële en praktische beperkingen.
Voor tijdbeheer en het halen van deadlines, workflow organisatie en automatisering zijn van het grootste belang. We nemen de tijd om onze build tools en pipelines goed te configureren, omdat dit ons in de toekomst veel tijd zal besparen. Over het algemeen neemt de return on investment toe naarmate de tijd verstrijkt.
Goed samenwerken met anderen
Om het idee van teamwork en samenwerking verder uit te werken, bouwen we gezonde relaties op met onze collega’s omdat het succes van een project uiteindelijk sterk afhangt van het succes van het team dat erachter zit. We doen er alles aan om een ondersteunende werkomgeving te creëren, waar ervaren seniors nieuwkomers op een zorgvuldige manier begeleiden.
Omdat we software ontwikkelen als een team, moeten we rekening houden met anderen die onze code lezen. Om de ontwikkelcyclus op lange termijn duurzaam te houden, worden leesbaarheid en onderhoudbaarheid net zo belangrijk gevonden als de logica en functionaliteit van een project. We schrijven consequent goede, leesbare code en zorgen voor informatieve commit-berichten en documentatie, omdat deze ons en anderen zeker zullen helpen onze code beter te begrijpen.
Over anderen die onze code lezen gesproken, een code review is een geweldige kans om meer te leren over best practices in programmeren. Het is ook een andere manier om ons vertrouwd te maken met een codebasis en het onderliggende ontwerp en de architectuur. Hoewel constructieve kritiek onaangenaam is en moeilijk te hanteren aan de ontvangende kant, is het belangrijk om het op te vatten als gedegen advies zodat we ons kunnen verbeteren als programmeurs.
Programmeren is moeilijk
Programmeren omvat veel aspecten naast functionaliteit, zoals gebruikerservaring, prestaties, beveiliging en teamwork. Het is niet genoeg om je alleen op één aspect te richten en de andere weg te laten. Voor projecten van aanzienlijke omvang en betekenis, is het niet zo eenvoudig als het typen van een paar regels code. Er is veel zorgvuldige planning, ontwerp, overweging en teamsamenwerking nodig om succesvol te zijn. In feite wordt bij programmeren meer tijd besteed aan denken dan aan typen, vooral tijdens lange sessies van debuggen.
In the end, programmeren gaat echt over continu, non-stop leren. Aanpassingsvermogen en voortdurend leren zijn de sleutels tot het overleven van deze industrie. We kunnen niet verwachten dat we relevant blijven als we niet ons deel doen om te blijven leren. In zo’n vluchtige industrie van exponentiële technologische verbetering, moeten we het hoge tempo bijhouden, anders eindigen we in het stof.
Ik wil dit artikel afsluiten door het harde werk van alle ontwikkelaars over de hele wereld te erkennen. Om dit artikel te schrijven, moest ik nadenken over de dagelijkse workflow van een team van ontwikkelaars. Ik moest kijken naar de vele aspecten van programmeren en software ontwikkeling die meestal onopgemerkt blijven. Sindsdien heb ik een grotere waardering gekregen voor alle software die op mijn computer is geïnstalleerd. Daarom moedig ik iedereen aan om vandaag een programmeur te bedanken, ongeacht zijn of haar ervaring. Waar zouden we zijn zonder hen?
Never take their hard work for granted.