Een goede developer is een luie developer
Na een lange zoektocht vond ze een artikel op stackoverflow dat perfect haar probleem kon oplossen. Aarzelend vroeg ze aan de senior developer die haar coachte wat ze moest doen. Ha, goed gevonden, wist de senior te zeggen, zonder op te kijken, je kan dat stuk perfect overnemen en dan kijk je maar of je probleem opgelost is. “Een goede developer is een luie developer!” Declameerde de senior en hij ging verder met zijn eigen werk.
We hebben het allemaal wel eens horen zeggen, zeker in het scenario hierboven beschreven. Echter zit er in dit bovenstaand stukje aardig wat verkeerd naar onze mening, dus gaan we dit met veel plezier fileren. Laten we enkele stukken eruit plukken en hier verder op ingaan.
Een goede developer is een luie developer
Een goede developer is een luie developer, deels zijn we het eens met deze uitspraak, maar dit slaat vooral niet op het feit dat die luie developer maar lustig moet kopiëren en plakken uit andere programma’s.
Neen, het gaat hier eerder over “slim lui” zijn:
- Bepaalde zaken automatiseren, CI/CD pipelines opzetten ipv manuele acties uit te voeren, code geen 5 maal schrijven, maar generiek maken.
- Bepaalde zaken documenteren zodat je niet telkens moet uitzoeken hoe de vork weer in de steel zit.
- Nog een betekenis van lui is om geen over-geëngineerde code te schrijven en zaken niet te compliceren. Eenvoudige, cleane code is dé manier hier. Complexiteit introduceert namelijk risico en dat is net hetgeen je wil vermijden in robuste clean code.
- Eerst communiceren en dan pas produceren. Overleg met collega’s kan ervoor zorgen dat je bepaalde inzichten verwerft alvorens je begint te ontwikkelen.
- Leer je IDE kennen en gebruik zijn kracht! Laat deze voor je werken met code completion, compiler errors en om sonar issues zo snel mogelijk aan te geven.
Dit alles zorgt voor een efficiëntere inzet van je tijd. En dat is wat een luie developer voor ons is, iemand die liever geen tijd verspilt.
Artikels op stackoverflow
Stackoverflow is een zegen en een vloek tegelijkertijd, er is een berg aan informatie en er is een zeker vorm van moderatie. Het maakt voor veel ontwikkelaars een deel uit van het dagelijks professionele leven. Echter, blindelings code kopiëren vanop stackoverflow is om verschillende redenen en no-go.
Zo was er een onderzoek door researchers naar de veiligheid omtrent de code snippets wat betreft security vulnerabilities en het blijkt dat er toch aardig wat risky code geshared wordt op stackoverflow. Om nog maar te zwijgen dat de originele code niet per sé werkt in je eigen use case.
Verder mag niet vergeten worden dat code overnemen niet zomaar kan, auteurs- en copyright rechten zijn een serieuze zaak. Bij gebruik van de code moet je de originele auteur crediteren en je moet er zeker van zijn dat de auteur die dit op stackoverflow deelde, dit in de eerste plaats wel mocht delen.
De recentere code die je kan terugvinden op stackoverflow valt momenteel onder een licentie genaamd CC BY-SA 4.0 International. Wat erop neerkomt dat je code mag gebruiken en herverdelen, zelfs commercieel, MAAR je moet wel aangeven of er wijzigingen zijn gebeurd, en die wijzigingen ga je terug moeten verdelen met hetzelfde licentie model. En je moet die originele schrijver van de code crediteren via een redelijke manier, bijvoorbeeld via een copyright notice.
Dus even kopiëren en klaar is kees, dat is een beetje kort door de bocht.
Iets dat de senior developer die onze junior begeleidt in bovenstaand scenario eigenlijk dient te weten.
Onze vriend de senior
Dit brengt ons naadloos bij ons laatste puntje. De senior luistert maar met een half oor naar het probleem van de junior. Het is hier aan de senior om zijn werk even opzij te zetten (in het mate van mogelijke natuurlijk) en de junior te coachen. Een probleem kan een leer momentje zijn. In een eerder artikel hebben we de term rubber ducking al eens aangehaald. Wel, de eerste vraag van deze senior zou moeten zijn, om het probleem eens uit te leggen. Gerichte vragen stellen, meekijken of de basishypothese van junior wel de juiste is en bovenal raad geven en zo onze jonge developer op die manier naar de oplossing leiden.
En misschien dat hij ook mee kan kijken naar die “externe ingeschakelde helper op stackoverflow”, maar dan ook kan hij aanleren om hier kritisch mee omgaan, een due diligence te doen van het gebruikte code snippet en er zeker genoeg kwaliteitstesten op te doen.
Misschien is de senior daar een uurtje mee kwijt, maar dat uurtje investering zal zich later dubbel en dik terugbetalen. De senior is hier inderdaad lui en niet op de goede manier zoals we hierboven beschreven. Misschien was het eerder om zijn eigen luiheid in zijn coaching rol goed te praten?
Althans dat is onze ongezouten mening.
