Meetings & coaching

Meetings met de opdrachtgever & coach

Bij de gesprekken met de opdrachtgever hebben mijn teamgenoten veelal genotuleerd, de notulen zijn hier te vinden.

Ik probeerde de feedback vooral direct te vertalen naar technische oplossingen en direct met de coach of opdrachtgever te sparren over mogelijkheden.

In de gesprekken met de opdrachtgever en coach probeerde ik het voortouw te nemen maar merkte ik wel dat ik soms wat moeite had met het vertalen van technische dingen naar 'begrijpbare' taal voor niet-techneuten. Hier heb ik dan ook een code review-sessie aan gewijd (zie hieronder) omdat dit ook een persoonlijk leerdoel was geworden. Dit is dan ook iets waar ik me in m'n stage verder in wil ontwikkelen.

In de standups met mijn teamgenoten heb ik ook geprobeerd zo veel mogelijk to the point te blijven ipv vage conceptuele taal te gebruiken, maar daarbij wel de dingen die niet geheel duidelijk waren, geduldig uit te leggen met behulp van metaforen en concrete voorbeelden.

Als iets nog steeds niet helemaal lukte/duidelijk was, ben ik er even specifiek samen aan bezig geweest om m'n teamgenoten op weg te helpen. Ik heb ook gemerkt dat ik het best wel leuk vond om hen hierbij te helpen en aantoonbaar vooruit te zien gaan op die gebieden. Zo heb ik zelfs een moment gehad met Deanna waarbij ik iets zei in de trant van: "Ik ben oprecht trots op je code kwaliteit".

Design reviews

(Vasilis) Hoe kan je op een mooie manier focus styles toevoegen? Vaak komt het bijvoorbeeld ook naar voren als je op een button klikt terwijl je dat wellicht niet wil.

Laat ik voorop stellen dat ik een fan ben van toegankelijkheid op het web. Echter, op sommige momenten komen focus styles nou niet bepaald mooi uit. Een naar iets vind ik bijvoorbeeld dat het ook naar voren komt als je op een button klikt. Daarom vroeg ik aan Vasilis hoe je dit mooi kan oplossen.

Uitkomst:

Vasilis legde me uit dat je de CSS pseudo-class `focus-visible` hiervoor kunt gebruiken. Zo wordt de style enkel en alleen toegepast wanneer iemand ook echt op een element focust (dus met tab). Voor 'normale' gebruikers kan je dan weer andere styles toepassen.

(Koop) Workflow; Is de huidige 'logic first' aanpak die ik vaker toe pas op projecten een handige workflow of kan je soms beter eerst kijken naar de vormgeving van een project omdat je nu natuurlijk werkt met een opdrachtgever die dingen wilt zien?

Omdat we nu eigenlijk vanaf het begin een soort 'logic first' aanpak hebben gehad (eerst zorgen dat technisch alles werkt en dan pas focussen op de specifieke vormgeving) leek het me goed om hier even samen met Koop op te reflecteren of dit een goede aanpak is of dat het ook anders kan.

Uitkomst:

Koop vertelde mij dat het zeker geen slechte aanpak is. Echter, het kan wel maken dat je je weer teveel gaat storten op de technische dingen terwijl je aan een opdrachtgever vaak dingen eenvoudiger duidelijk kan maken door het te laten zien in een toffe vormgeving. Een opdrachtgever kan dan snel zoiets hebben van 'is dit het?'. Dit blijft wel iets wat je door ervaring leert aan te voelen.

Code reviews

Hoe kan ik progressively enhanced gebruik maken van serverless functions?

Serverless functions zijn natuurlijk niet qua uitgangspunt 'van de HTML/basic'-basis opgebouwd. Natuurlijk is het wel een best practice om dit uitgangspunt zo veel mogelijk na te streven. Ik vond dit een goede kwestie om te bespreken met de code review met Janno.

Uitkomst:

Na wat sparren met Janno drong het tot me door dat een serverless function ook maar een stukje server-side logica is. Dus als we JSON over de lijn kunnen sturen, waarom zouden we dan niet ook HTML over de lijn terug kunnen sturen?

Zo kunnen we een formulier een action geven naar de serverless function en die serverless function een HTML bestand terug laten sturen. There you got your progressive enhancement.

Als je dan wel JavaScript hebt kan je gewoon een call doen naar die serverless function en de gebruiker direct feedback geven.

Tips voor het uitleggen van technisch complexe zaken aan opdrachtgevers?

Met gesprekken met een opdrachtgever die niet zo technisch of misschien wel helemaal niet technisch is ingesteld, vind ik het soms wat lastig om de specifiek technische zaken uit te leggen. Een middenweg tussen een volledige uitleg en 'jip en janneke taal' is soms wat lastig te vinden, zeker aangezien ik zelf zo diep in de materie zit. Ik vroeg aan Laurens hoe ik dit het beste kan oppakken.

Uitkomst:

Laurens legde mij uit dat het al veel helpt als je metaforen gebruikt (bijvoorbeeld het verhaal van koffie halen of het doen van een bestelling bij de mac voor het uitleggen van async en promises).

Ook moet je weten wanneer je dingen vooral niet moet willen uitleggen en misschien wat meer op de oppervlakte blijven. Daarnaast kan het handig zijn om schetsen te maken bij je uitleg zodat je verhaal duidelijker wordt.

Ik heb geprobeerd om de bovenstaande punten nog mee te nemen voor zolang het project duurde. Dit hielp vooral bij de gesprekken die ik had met Mattijs.

Hoe kan ik de knowlegde gap met m'n teamgenoten managen en me begripvol opstellen tegenover m'n teamgenoten?

Bij de laatste code review met Joost stelde ik niet zozeer een code-gerelateerde vraag maar meer één die met project-management te maken had. Ik merkte namelijk dat ik mij begon te 'irriteren' aan het verschil in kennis over het werken in zulke projecten.

Waar ik persoonlijk zoiets heb van 'blijf bij je ticket' hadden m'n teamgenoten nog wel eens de neiging om uit te wijken en ook andere dingen die liggen op te pakken. Dit is an sich geen slechte instelling, zeker niet, echter, het maakt dat het itereren op bepaalde oplossingen trager verloopt naar mijn mening omdat een ticket dan minder snel afgerond kan worden.

Ik vroeg aan Joost hoe ik hier mee om zou moeten kunnen gaan en hoe ik dit (subtiel) kan communiceren met m'n teamgenoten.

Uitkomst:

Joost vertelde mij dat het niet zozeer iets is waar je wat aan kan doen. Het hebben van een gat in kennis etc. is inherent aan het samenwerken in een (dev)team. De simpele conclusie hiervan is dus 'deal with it', echter, hij vertelde me ook dat je soms niet te bot wilt zijn tegenover je teamgenoten hierin.

Dit is dus iets wat je aan moet voelen of je er wat over kan zeggen tegen je teamgenoten. Als je er iets van kan zeggen kan je serieus een gesprek aan gaan. Als je dat gevoel niet hebt moet je het ook zeker niet doen, behalve als het de spuigaten uitloopt.