Contenu
L'empathie est définie comme la capacité de comprendre et de partager les sentiments d'autrui. Si je devais vous raconter une histoire et vous demander de faire preuve d’empathie avec moi, je pourrais dire quelque chose comme: «Imaginez-vous à ma place». Mais si vous deviez suivre ces instructions, vous ne feriez qu'une partie du chemin. L’empathie ne s’imagine pas dans ma situation. L’empathie consiste à imaginer ce que c’est pour moi d’être dans ma situation.
Notre difficulté à imaginer ce que c’est d’être une autre personne et à faire preuve d’empathie avec elle a beaucoup à voir avec le contexte que nous partageons. En tant que développeur frontend, il m’est beaucoup plus facile de faire preuve d’empathie avec une personne aux prises avec des modèles de courrier électronique que de faire preuve d’empathie avec une personne aux prises avec le multithreading. J'ai beaucoup plus de repères, un contexte qui recoupe plus avec la première personne qu'avec la seconde.
Cela ne rend certainement pas l'empathie envers la personne aux prises avec le multithreading moins importante, cela signifie simplement que je vais devoir travailler un peu plus pour imaginer ce que c'est que d'être eux dans leur situation. Il faudra plus d'empathie de ma part pour combler ces lacunes de compréhension.
Qui?
En tant que développeurs, nous devrions faire preuve d'empathie avec ceux qui créent des modèles d'e-mails et ceux du multithreading en Java, mais avec qui d'autre devrions-nous faire preuve d'empathie? Nous devons faire preuve d'empathie avec les personnes concernées par le code que nous produisons. Ces personnes peuvent être réparties en trois groupes: nos coéquipiers, nos consommateurs de code et nos utilisateurs finaux.
Nos coéquipiers sont généralement le plus petit groupe, mais le groupe de personnes le plus affecté par le code que nous écrivons. Lors de la résolution de problèmes, ce groupe aura généralement un contexte beaucoup plus proche du nôtre, ce qui nous permettra d'écrire plus facilement du code avec lequel ils pourront travailler facilement. Si nous ratons la cible ici, ce groupe aura l'occasion de nous poser des questions et de nous donner des commentaires constructifs.
Nos consommateurs de code sont les personnes qui s'appuient sur le code que nous construisons. Par exemple: nous travaillons peut-être sur un framework JavaScript et d'autres développeurs utilisent ce framework pour créer d'autres services et produits finaux. Il ne faut pas s’attendre à ce que ces consommateurs aient un contexte qui chevauche le nôtre. Au lieu de pouvoir nous poser facilement des questions ou nous faire part de vos commentaires immédiats, ce groupe peut ne disposer que de notre code et de sa documentation pour indiquer les problèmes que nous essayons de résoudre.
Le dernier groupe de personnes concernées par notre code est nos utilisateurs finaux. Ce sont les personnes qui utilisent les applications que nous (ou ceux qui utilisent notre code) avons construit. C'est généralement le plus grand groupe de personnes que nous allons affecter avec notre code, et ils partagent probablement le moins de contexte avec nous. Bien que ces utilisateurs ne verront probablement jamais le code que nous avons écrit, et sortent donc du cadre de cette discussion, nous devons examiner comment le code que nous écrivons peut aider à l'intégration des fonctionnalités, y compris - mais sans s'y limiter - une accessibilité totale et la performance perçue.
Tous ces groupes existeront, quelle que soit l’ampleur des projets sur lesquels nous travaillons - des hacks de week-end en solo aux projets impliquant des centaines d’autres développeurs et s'étalant sur plusieurs années. À tout moment, nous pouvons nous trouver affectés par notre propre code en tant que membre de l'un ou des trois de ces groupes.
Pourquoi?
Y a-t-il des raisons de sympathiser avec ceux qui sont affectés par notre code, en dehors de faire preuve de bonne volonté les uns envers les autres? L'empathie est-elle importante pour la pratique du génie logiciel - et si oui, pourquoi?
Je pense qu'à un moment donné, la civilisation se retournera et se moquera de la façon dont nous remplissons les bâtiments de gens qui s'assoient et parlent aux ordinateurs toute la journée, mais d'ici là, nous avons encore de gros problèmes à résoudre. Et nous avons besoin d'équipes de personnes ayant des expériences et des connaissances diverses, des équipes avec de petites quantités de contexte partagé, pour se rassembler et les résoudre.
L'un des plus grands défis que ces équipes devront surmonter est la dénomination. Phil Karlton aurait dit: "Il y a deux choses difficiles en informatique: l'invalidation du cache et la dénomination des choses." Notre difficulté à nommer les choses peut être imputée aux inadéquations que nous rencontrons entre le contexte et la connaissance. Dans les cas du monde réel, cela est rendu encore plus difficile car nous essayons rarement de décrire quelque chose qui correspond à un objet du monde réel, mais essayons de nommer des concepts abstraits qui existent simplement pour organiser le code.
Lorsque nous commençons à fournir un contexte aux utilisateurs de notre code en fournissant des commentaires plus descriptifs, ainsi que des noms de variables et de méthodes, notre code peut commencer à paraître verbeux. Certes, nous voulons utiliser une certaine discrétion ici (et nous sommes certes en train de nous approcher du style de codage), mais nous devons garder à l'esprit que dans de nombreux environnements de production, les commentaires sont supprimés et notre code lui-même est minifié ou abrégé. Le code qui entre en production est conçu pour être lu par les ordinateurs, et le code que nous écrivons à la main est destiné à nos collègues développeurs à utiliser, à réutiliser, à étendre et à maintenir.
L'utilisabilité, la réutilisabilité, l'extensibilité et la maintenabilité de notre code sont des points clés lors de l'établissement des meilleures pratiques logicielles, et ils dépendent tous de notre capacité à transmettre notre intention à travers le code. Bien qu'elles soient rarement présentées sous cet éclairage, les meilleures pratiques sont généralement enracinées dans l'empathie. Avant de réfléchir à ce sujet, les meilleures pratiques, pour moi, étaient simplement des moyens d'améliorer la vitesse de développement d'un projet.
Comment?
Nous avons de nombreuses façons de mesurer la vitesse de développement, mais nous n'avons pas de bonnes mesures de la qualité ou du niveau d'empathie du code que nous produisons - c'est subjectif et relatif au consommateur du code. Cependant, les meilleures pratiques peuvent améliorer la vitesse de développement car elles rendent le code empathique. Nos collègues développeurs seront en mesure de se plonger dans notre code, de découvrir rapidement son intention et de se sentir raisonnablement sûrs de son utilisation et de la manière de le réutiliser, de l'étendre et de le maintenir. Les fonctionnalités peuvent être ajoutées plus rapidement, les régressions peuvent être évitées et les bogues peuvent être éliminés plus rapidement.
Dans le monde réel, nos équipes n'auront jamais de membres qui n'ont aucun chevauchement de contexte ou de connaissances avec d'autres membres. De même, il n'y aura jamais deux personnes avec exactement les mêmes connaissances. Les chevauchements changeront à mesure que les coéquipiers grandiront ou que le problème lui-même évoluera. Tant que les humains sont ceux qui développent des logiciels, nous aurons besoin de développeurs avec de grandes différences de connaissances pour combler leurs lacunes en contexte avec empathie et développer des solutions à certains de nos plus gros problèmes.
En tant qu'industrie, nous avons défini des rôles intitulés pour ceux qui innovent et développent des interfaces et des expériences empathiques pour nos utilisateurs finaux. Cependant, jusqu'à ce que ces rôles soient définis pour le développement logiciel, il nous appartient de favoriser l'empathie les uns pour les autres dans le code que nous partageons sur nos écrans. Car, après tout, les interfaces utilisateur ne sont pas les seules interfaces qui devraient être fluides, et nos utilisateurs finaux ne sont pas les seules personnes concernées par notre code qui méritent notre empathie.
En tant que développeurs, les interfaces régissent tout, et nous sommes aussi des personnes.
Mots: Amanda Glosson
Amanda Glosson est une ingénieure frontend chez Salesforce qui passe une grande partie de son temps à imaginer de nouvelles façons de pousser les pixels autour des écrans. Cet article a été initialement publié dans le numéro 271 du magazine net.
Aimait ça? Lisez-les!
- Comment survivre à des sessions de codage toute la nuit
- Comment créer une application: essayez ces excellents didacticiels
- Logiciel de conception graphique gratuit à votre disposition dès maintenant!
