Hoe dialoog je code transformeert

Stel je voor: een schemerige kamer, slecht verlicht door het koude blauwe schijnsel van een computerscherm. Een eenzaam figuur, gehuld in een hoodie, zit gekromd over het toetsenbord. De enige geluiden zijn het getik van toetsen en het zachte zoemen van een computer. Dat was het beeld dat ik voor ogen had toen ik aan mijn opleiding informatica begon in 2015. Een wereld waar woorden overbodig zijn en code de enige taal is die telt.

Maar de realiteit? Die kon niet meer verschillen van dit clichébeeld. Toen ik met mijn rolstoel de deuren van mijn eerste programmeerklas open ramde, kwam ik in een levendige wereld terecht. Een wereld waar discussies over algoritmen net zo natuurlijk waren als vragen over het weekend. Al snel leerde ik dat je in de wereld van softwareontwikkeling niet zonder communicatie kunt.

De eerste stap in applicatieontwikkeling? Het domein begrijpen. Welke uitdagingen zien gebruikers? Wat verwacht de klant? Voordat het hele team op dezelfde lijn zit, ben je wel even bezig. Dit is een gebied waar ik als ontwikkelaar nog veel kan leren. Voor meer tips van een pro? Check onze blog over goede briefingvragen.

Dan komt de fase van procesdefinitie. Wat gebeurt er als je op die knop drukt? Wat als er iets fout gaat? Communiceren over deze zaken is een kunst. We gebruiken schema’s, flowcharts en user stories om dit helder te krijgen. Dit is cruciaal, want een applicatie moet doen wat het belooft.

Als je nu denkt dat we klaar zijn met communiceren, dan heb je het mis. Programmeren gaat juist over samenwerken. Over problemen praten met collega’s is dagelijkse kost. Dat vereist wel dat je je probleem duidelijk kunt maken. Elk teamlid heeft z’n eigen sterktes. Leren inschatten of je collega je volgt is een must.

Eindelijk, tijd om code te schrijven. Maar wacht, hier komt de twist: zelfs nu blijven we communiceren. Code moet leesbaar zijn, niet alleen voor machines maar ook voor mensen. Bestandsnamen, variabele en functienamen; allemaal manieren om duidelijk te zijn.

Wat in dat artikel ook genoemd wordt zijn code reviews. Het bekijken van andermans code. Dit is een belangrijke stap om ervoor te zorgen dat code leesbaar is voor je collega’s. Net als bij het schrijven van een blog, kan je op een gegeven moment vast zitten in een bepaalde manier van denken. Dan is een extern perspectief een waardevolle manier om daaruit te komen.

Ook hier speelt communicatie weer een cruciale rol. Samen in discussie gaan over wat werkt en wat niet levert uiteindelijk betere code en daarmee een beter product op.

De vraag ‘heb je ooit gehoord van Rubber Duck Debugging?’ hoef je aan geen enkele developer te vragen. Het is een grappige naam voor een serieuze techniek, wanneer we spreken over het onderwerp communicatie. Stel, je loopt vast met een probleem in je code. Dan pak je een rubberen eendje en leg je stap voor stap uit wat je code doet. Ja, echt waar. Je communiceert met jezelf.

Door hardop te denken en het probleem uit te leggen, zie je vaak ineens wat er mis is. En het mooie is: je hebt niemand gestoord met je vraag. Dus de volgende keer dat je vastloopt, probeer je verhaal eens te doen aan een rubberen eendje, een teddybeer of wat je ook maar in de buurt hebt. Je zult verbaasd zijn hoe vaak je zelf tot de oplossing komt.

Communicatie an sich is ook een proces. En laat dat nou net hetgeen zijn waar ik als developer van ga kwispelen: het optimaliseren van processen. Kortom, goed kunnen praten met je team en de klant is super belangrijk als je software maakt. Vergeet het idee van de eenzame programmeur die alleen maar code tikt. Je bent constant in gesprek: met collega’s, met klanten en zelfs met je code.

Zoals we bij Linku gekscherend meer dan eens zeggen, het werk is nooit echt af en dat geldt ook voor communiceren.