Tag communicatie
Aansluiting (z)onder emoties
Onlangs mocht ik getuige zijn van een mooi moment. In een video-opname van een coachingsgesprek, zei de coachee van één van mijn medecursisten, met een verwonderde trilling in haar stem: “Goh, zo had ik het nou nog nooit bekeken.” Haar coach stelde toen de vraag die, denk ik soms, wordt gezien als de heilige graal onder de coaches(-in-opleiding?): “Wat voel je daarbij?”
Luisteren, sammenvatten en doorvragen
LSD staat voor lysergic acid diethylamide en heeft een hallucinerende werking. Het verhaal wil dat dat de inspiratie vormde voor Lucy in the Sky with Diamonds, en da’s een liedje van The Beatles. Maar LSD staat ook voor luisteren, samenvatten en doorvragen en da’s een bekende gesprekstechniek - weinig hallucinant, maar minstens even belangrijk in het leven van een softwareontwikkelaar.
Communiceren naast coderen
Veel programmeurs denken dat hun werk begint en eindigt bij het schrijven van code. Helemaal onterecht is dat niet, want het is precies die vaardigheid die hen hun baan heeft opgeleverd. Maar er komt veel meer kijken bij het ontwikkelen van software. Denk bijvoorbeeld aan: bedenken wat je gaat bouwen en hoe je dat gaat doen, het beoordelen van de code van je collega’s, en presenteren wat je hebt opgeleverd aan stakeholders. Zulke taken hebben een gemene deler: communicatie.
Een GIF zegt meer dan duizend woorden
De mogelijkheid om eenvoudig met GIF-jes te kunnen communiceren is één van de meest gewaardeerde features die Microsoft Teams heeft, als je het mij vraagt. Maar waarom? Want strikt genomen kan het doel van die applicatie - asynchrone communicatie bewerkstelligen voor gedistribueerde teams - ook worden bereikt zonder deze feature. Sterker nog, misschien zou onze communicatie wel vlotter verlopen als ik niet elk gesprek ontspoor met bewegend beeld!
De noodzaak van refactoren
Ons team heeft een stakeholder wiens gezicht vertrekt, elke keer als we tijdens een Sprint Review aangeven tijd te hebben gestoken in het refactoren van onze applicatie. In zijn beleving is refactoren een verspilling van je tijd. Als we meer tijd hadden genomen om de wensen van onze gebruikers grondig te analyseren, redeneert hij, dan had zo’n dure, inefficiënte refactorslag kunnen worden voorkomen. Als ik iemand zo hoor redeneren, dan vertrekt míjn gezicht.
De rol van user stories
Wie The Art of Agile Development van James Shore doorbladert, doet heel nieuwe opzichten op. Zijn hoofdstuk over stories (ook wel bekend als user stories) deed me wel opveren, in elk geval. Shores stelling - mening? inzicht? - is provocatief: een story moet op een index card passen. de volledige story zou dus uit niet meer dan een zin of een kreet hoeven bestaan.
Een reflectie op communicatiestijlen
Elk mens is uniek, maar laten we niet overdrijven. Het menselijk vermogen te generaliseren wint het met gemak van de uniciteit van het individu - dat is waar stereotypen vandaan komen. En stereotypen hebben hun functie. Ze geven ons handvaten in de omgang met individuen, in het bijzonder wanneer hun stereotype anders is dan het onze.
Hoe lang hoort een Sprint Review te duren?
Soms sluit ik wel eens aan bij de Sprint Reviews van collega-teams. Wat me daarbij opvalt, is dat er een behoorlijke diversiteit in tijdsduur is tussen de Reviews van de verschillende teams. De onze zijn getimeboxt op een uur en ‘n kwartier, al duren ze in de praktijk meestal ongeveer een uur. Maar ik woon ook Reviews bij van een halfuurtje. Wat is er aan de hand?
Code reviews als leermiddel
Toen ik begon als softwareontwikkelaar, was ik eerlijk gezegd een beetje bang voor code reviews. Inmiddels zijn de rollen omgedraaid, en zijn mijn collega’s banger voor mijn code reviews dan ik voor die van hen. Feit is dat ik een stuk scheutiger ben met mijn opmerkingen dan mijn collega’s. Toch denk ik dat er in mijn commentaar maar weinig is om bang voor te zijn. Ik zie code reviews namelijk niet als middel en moment om kritiek te geven op andermans code. Of liever: niet alleen als middel en moment om kritiek te geven.
Goede code documenteert zichzelf (niet)
Uit de code valt niet af te leiden wat de specificaties zouden moeten zijn. Om met David Hume (1711-1776) te spreken: een ought valt niet af te leiden uit een is. Wie zegt dat goede code zichzelf documenteert, maakt zich schuldig aan de naturalistische dwaling. En toch zit er een kern van waarheid in het idee dat goede code zichzelf documenteert.