Inhoud
Empathie wordt gedefinieerd als het vermogen om de gevoelens van een ander te begrijpen en te delen. Als ik je een verhaal zou vertellen en je zou vragen om je in me in te leven, zou ik iets kunnen zeggen als: ‘Stel je voor dat je in mijn schoenen staat’. Maar als u deze instructies zou volgen, zou u slechts een deel van de weg ernaartoe zijn. Empathie is niet jezelf voorstellen in mijn situatie. Empathie is me voorstellen hoe het voor mij is om in mijn situatie te zijn.
Onze moeilijkheid om ons voor te stellen hoe het is om een andere persoon te zijn en om ons in te leven, heeft veel te maken met de hoeveelheid context die we delen. Als frontend-ontwikkelaar is het veel gemakkelijker voor mij om me in te leven in iemand die worstelt met e-mailsjablonen dan me in te leven in iemand die worstelt met multithreading. Ik heb veel meer referentiepunten, een context die meer overlapt met de eerste persoon dan met de tweede.
Dit maakt het inleven in de persoon die worstelt met multithreading zeker niet minder belangrijk, het betekent alleen dat ik wat meer werk moet verzetten om me voor te stellen hoe het is om hem in zijn of haar situatie te zijn. Het zal van mijn kant meer empathie vereisen om die hiaten in begrip te overbruggen.
WHO?
Als ontwikkelaars zouden we ons moeten inleven in degenen die e-mailsjablonen bouwen en die multithreading in Java, maar met wie moeten we ons nog meer inleven? We moeten ons inleven in degenen die worden beïnvloed door de code die we produceren. Deze mensen kunnen worden onderverdeeld in drie groepen: onze teamgenoten, onze codegebruikers en onze eindgebruikers.
Onze teamgenoten zijn doorgaans de kleinste groep, maar de groep mensen die het meest worden beïnvloed door de code die we schrijven. Bij het oplossen van problemen zal deze groep meestal een context hebben die veel dichter bij de onze ligt, waardoor het voor ons eenvoudiger wordt om code te schrijven waarmee ze gemakkelijk kunnen werken. Als we hier niet slagen, krijgt deze groep de gelegenheid om ons vragen te stellen en constructieve feedback te geven.
Onze codeconsumenten zijn de mensen die bovenop de code bouwen die we bouwen. Bijvoorbeeld: misschien werken we aan een JavaScript-framework en gebruiken andere ontwikkelaars dit framework om andere diensten en eindproducten te bouwen. Je mag hier niet verwachten dat deze consumenten een context hebben die de onze overlapt. In plaats van ons gemakkelijk vragen te kunnen stellen of ons onmiddellijke feedback te kunnen geven, beschikt deze groep mogelijk alleen over onze code en de bijbehorende documentatie om de problemen aan te geven die we proberen op te lossen.
De laatste groep mensen die door onze code wordt beïnvloed, zijn onze eindgebruikers. Dit zijn de mensen die applicaties gebruiken die wij (of degenen die onze code gebruiken) hebben gebouwd. Dit is doorgaans de grootste groep mensen die we zullen beïnvloeden met onze code, en ze delen waarschijnlijk de minste hoeveelheid context met ons. Hoewel deze gebruikers de code die we hebben geschreven waarschijnlijk nooit zullen zien, en dus buiten het bestek van deze discussie vallen, moeten we overwegen hoe de code die we schrijven kan helpen bij de integratie van functies, inclusief - maar niet beperkt tot - volledige toegankelijkheid en waargenomen prestaties.
Al deze groepen zullen bestaan, ongeacht de omvang van de projecten waaraan we werken - van solo-weekendhacks tot projecten waarbij honderden andere ontwikkelaars betrokken zijn en die meerdere jaren beslaan. Op elk moment in de tijd kunnen we worden beïnvloed door onze eigen code als lid van een of alle drie deze groepen.
Waarom?
Zijn er redenen om je in te leven in degenen die door onze code worden beïnvloed, buiten het algemeen blijk geven van goede wil jegens elkaar? Is empathie belangrijk voor de praktijk van software engineering - en zo ja, waarom?
Ik denk dat de beschaving op een gegeven moment zal terugkijken en lachen om hoe we gebouwen vullen met mensen die de hele dag zitten en praten met computers, maar tot die tijd hebben we nog een aantal grote problemen die moeten worden opgelost. En we hebben teams nodig van mensen met verschillende achtergronden en kennis, teams met kleine hoeveelheden gedeelde context, om samen te komen en ze op te lossen.
Een van de grootste uitdagingen die deze teams zullen moeten overwinnen, is naamgeving. Phil Karlton wordt gecrediteerd met te zeggen: "Er zijn twee moeilijke dingen in de informatica: cache-ongeldigverklaring en het benoemen van dingen." Onze moeite met het benoemen van dingen kan worden toegeschreven aan de discrepanties die we tegenkomen tussen context en kennis. In praktijkgevallen wordt dit zelfs nog moeilijker gemaakt omdat we zelden proberen iets te beschrijven dat is gekoppeld aan een echt object, maar proberen abstracte concepten te noemen die gewoon bestaan om code te ordenen.
Wanneer we context gaan bieden aan de gebruikers van onze code door meer beschrijvende commentaren te geven, evenals namen van variabelen en methoden, kan onze code uitgebreid lijken. We willen hier zeker wat discretie gebruiken (en we gaan weliswaar op het gebied van codeerstijlen), maar we moeten in gedachten houden dat in veel productieomgevingen opmerkingen worden verwijderd en onze code zelf wordt verkleind of anderszins afgekort. Code die in productie gaat, is gemaakt voor computers om te lezen, en de code die we met de hand schrijven, is voor onze mede-ontwikkelaars om te gebruiken, hergebruiken, uitbreiden en onderhouden.
De bruikbaarheid, herbruikbaarheid, uitbreidbaarheid en onderhoudbaarheid van onze code zijn sleutelpunten bij het vaststellen van best practices voor software, en ze hangen allemaal af van ons vermogen om onze intentie over te brengen via code. Hoewel ze zelden in dit licht worden gepresenteerd, zijn best practices over het algemeen geworteld in empathie. Voordat ik over dit onderwerp nadacht, waren best practices voor mij gewoon manieren om de ontwikkelingssnelheid van een project te verhogen.
Hoe?
We hebben veel manieren om de ontwikkelingssnelheid te meten, maar we hebben geen goede metingen voor de kwaliteit of het niveau van empathie van de code die we produceren - deze is subjectief en relatief ten opzichte van de gebruiker van de code. Best practices kunnen echter de ontwikkelingssnelheid verhogen, omdat ze de code empathisch maken. Onze mede-ontwikkelaars zullen in onze code kunnen duiken, snel de bedoeling ervan kunnen ontdekken en redelijk zeker kunnen zijn van waar deze voor wordt gebruikt, en hoe ze deze kunnen hergebruiken, uitbreiden en onderhouden. Functies kunnen sneller worden toegevoegd, regressies kunnen worden vermeden en bugs kunnen sneller worden geplet.
In de echte wereld zullen onze teams nooit leden hebben die geen overlappingen hebben in context of kennis met andere leden. Evenzo zullen er nooit twee mensen zijn met precies dezelfde kennis. Overlappingen zullen veranderen naarmate teamgenoten groeien, of het probleem zelf evolueert. Zolang het mensen zijn die software ontwikkelen, hebben we ontwikkelaars nodig met grote verschillen in kennis om hun hiaten in de context met empathie te overbruggen en oplossingen te ontwikkelen voor enkele van onze grootste problemen.
Als branche hebben we rollen met titels gedefinieerd voor degenen die innoveren en interfaces en empathische ervaringen voor onze eindgebruikers ontwikkelen. Maar totdat die rollen zijn gedefinieerd voor softwareontwikkeling, is het aan ons om empathie voor elkaar te kweken in de code die we op onze schermen delen. Gebruikersinterfaces zijn tenslotte niet de enige interfaces die wrijvingsloos zouden moeten zijn, en onze eindgebruikers zijn niet de enige mensen die door onze code worden beïnvloed en die onze empathie verdienen.
Als ontwikkelaars beheersen interfaces alles, en wij zijn ook mensen.
Woorden: Amanda Glosson
Amanda Glosson is frontend-engineer bij Salesforce en besteedt veel van haar tijd aan het bedenken van nieuwe manieren om pixels rond schermen te duwen. Dit artikel is oorspronkelijk gepubliceerd in nummer 271 van net magazine.
Vond dit leuk? Lees deze!
- Hoe u coderingssessies van de hele nacht kunt overleven
- Een app bouwen: probeer deze geweldige tutorials
- Nu gratis grafische ontwerpsoftware voor u beschikbaar!
