Article original : Don’t be the software developer you can’t stand working with
Par Bruce Flow
J'ai plus de 10 ans d'expérience dans l'industrie en tant que développeur logiciel. Je travaille dans l'une des plus grandes entreprises technologiques. J'ai également travaillé comme Scrum Master dans plusieurs projets.
Je ne suis pas le développeur le plus expérimenté qui soit, loin de là. Pourtant, j'ai travaillé avec suffisamment de développeurs logiciels pour reconnaître que j'apprécie travailler avec certains développeurs bien plus qu'avec d'autres.
Les développeurs avec lesquels j'aime travailler sont ceux qui collaborent bien avec moi. Ils sont professionnels mais agréables. Leur compétition amicale me pousse à devenir un meilleur développeur chaque jour.
Et il y a des développeurs qui m'énervent au plus haut point.
J'ai fait une analyse des caractéristiques de ces développeurs difficiles. Ce n'est pas une liste de plaintes. J'ai fait cette liste pour en tirer des leçons pour mon propre développement personnel. Je l'utilise également pour me vérifier de temps en temps comme moyen d'auto-réflexion professionnelle.
Ce qui suit est une liste de choses agaçantes que font les développeurs logiciels. Pour chaque caractéristique, je fournis également des suggestions sur ce que nous pouvons faire à la place.
Avoir un travail bâclé
Vous connaissez ce développeur. Celui qui nomme mal les variables, fait des fautes de frappe dans les noms de fonctions et laisse des vestiges de vieux commentaires dans le code. Celui qui ne peut pas se donner la peine d'exécuter le formateur de code malgré avoir été rappelé 5 fois. Le développeur qui ignore les problèmes de lint même lorsque l'IDE lui crie dessus.
Avoir un travail bâclé énerve les autres développeurs. Cela ralentit également le processus de développement. Lors des revues de code, les autres développeurs doivent perdre du temps à commenter des problèmes flagrants qui auraient dû être corrigés pendant le codage. Dans d'autres cas, les autres développeurs doivent corriger ces problèmes eux-mêmes.
Encore pire, l'attitude négligente augmente les chances d'avoir des bugs dans le logiciel. Les bugs coûtent de l'argent et du temps à corriger par la suite.
Je suis frustré par le travail bâclé parce que c'est une question d'attitude. Cela ne peut changer que si ce développeur négligent décide de prendre fierté dans son travail.
En tant que développeurs logiciels, nous avons beaucoup de liberté pour choisir comment nous faisons les choses.
Utiliser cette liberté pour perfectionner nos compétences est un travail difficile. Il est plus facile de simplement se laisser porter. Néanmoins, il y a des récompenses majeures à long terme.
« Sans artisanat, l'inspiration n'est qu'un roseau agité par le vent »
— Johannes Brahms, pianiste et compositeur allemand
Prendre fierté dans notre artisanat nous rend de plus en plus meilleurs dans ce que nous faisons. Cela nous aide également à tirer plus de satisfaction de notre travail. Devenir meilleur dans ce que nous faisons ouvre plus d'opportunités à l'avenir.
Manquer de respect pour le temps des autres
Il y a ce développeur qui arrive en retard aux réunions de manière constante. Tout le monde est en retard de temps en temps. Pourtant, arriver en retard tout le temps est un choix.
Selon l'importance de ce développeur dans cette réunion, deux choses peuvent se produire. L'équipe devra soit attendre le développeur, soit devoir passer du temps à le mettre à jour sur ce qu'il a manqué.
Arriver habituellement en retard aux réunions est un manque de respect flagrant pour les autres. Cela peut ne pas sembler un gros problème si vous arrivez quelques minutes en retard, mais voici ma formule approximative pour calculer le temps gaspillé :
Temps total gaspillé = n x (t1 + t2)
n = nombre de personnes
t1 = temps de retard à la réunion
t2 = temps perdu à mettre le développeur à jour
Scénario d'exemple :
Une équipe compte six développeurs. Un développeur arrive 10 minutes en retard. L'équipe prend cinq minutes pour le mettre à jour. La perte de temps totale serait de 6x(10+5) minutes. Cela représenterait un total de 90 minutes gaspillées.
Arriver en retard aux réunions perturbe le déroulement de la réunion. D'autres collègues peuvent avoir une discussion productive lorsque le développeur en retard les interrompt.
La ponctualité est une attitude.
Avoir l'attitude de la ponctualité économise le temps et les nerfs de tout le monde. De plus, cela donne une impression positive de fiabilité. Être à l'heure à chaque réunion signifie que nous nous soucions. Cela signifie que les chances sont plus grandes que nous nous soucions également de livrer notre travail à temps.
Ignorer les aspects non-code du travail
Il arrive que j'entende un développeur dire « L'UI que j'ai construite est moche parce que je ne suis pas designer ». Cela me donne envie de passer en mode Hulk et de renverser mon bureau debout.
Le codage n'est qu'une des responsabilités du développeur.
Être bon en développement logiciel signifie que nous adoptons une approche holistique de notre travail. Nous devons également considérer des aspects comme l'expérience utilisateur, l'architecture et la stratégie commerciale.
Penser que le développement logiciel se résume au codage, c'est comme dire que vous pouvez conduire parce que vous savez appuyer sur la pédale d'accélérateur.
Ignorer le tableau d'ensemble rendra le logiciel difficile à utiliser, coûteux à maintenir et incohérent avec les autres composants.
C'est notre responsabilité en tant que développeurs logiciels de nous éduquer dans tous les aspects. Certes, nous ne pouvons pas être experts dans tous les domaines. L'important est d'avoir une conscience adéquate. Nous pouvons toujours demander l'aide d'experts lorsque nécessaire.
Avoir une vision holistique des choses nous permettra également de mieux comprendre les autres rôles.
Lorsque je participe à des discussions avec des designers, j'ai pour habitude d'apprendre comment les décisions de design sont prises. Je le fais en posant des questions. Cela améliore ma compréhension de base des principes de design.
Apprendre à voir le tableau d'ensemble est un processus continu. Un processus guidé par la curiosité et l'engagement à produire un bon travail.
Parler d'excuses au lieu de solutions
Tout le monde traverse une mauvaise passe à un moment donné. Parfois, il faut plus de temps pour produire les résultats que nous voulons. Cela est tout à fait normal. Ce qui ne l'est pas, c'est lorsqu'un développeur produit constamment des excuses au lieu de résultats.
Les excuses typiques incluent les contraintes de temps, les connaissances inadéquates ou la difficulté de la tâche.
Produire des excuses de manière constante n'a aucun effet positif sur l'équipe. Au mieux, cela gaspille du temps. Dans le pire des cas, cela abaisse le niveau d'excellence dans l'équipe.
Au lieu d'excuses, je préfère entendre les étapes spécifiques que le développeur a déjà prises.
Cela présente de nombreux avantages :
- Donne à l'équipe une meilleure chance d'offrir de l'aide ou des solutions
- Permet à l'équipe d'apprendre du problème
- Fournit une meilleure image de l'avancement de la tâche
Parler de solutions est ce que nous faisons. Après tout, nous sommes des ingénieurs. Les ingénieurs résolvent des problèmes.
Philosophier sur l'inconnu au lieu de comprendre le problème
À de nombreuses occasions, des collègues discutent de sujets techniques sur la base de leurs opinions. Des opinions qui ne sont étayées par aucun fait.
De telles discussions interminables peuvent être terminées en découvrant les faits au lieu d'en discuter.
« La vérité se trouve toujours dans la simplicité, et non dans la multiplicité et la confusion des choses. »
— Isaac Newton, un type intelligent
Dans le développement logiciel, nous traitons à la fois des problèmes techniques et non techniques.
Avec les problèmes techniques, nous avons le luxe que les choses sont généralement en noir et blanc. Tout litige peut être résolu en essayant du code dans un bac à sable ou en exécutant un logiciel pour vérifier ce qu'il fait.
Les problèmes non techniques sont résolus en lisant la documentation, en demandant à des experts du sujet ou en cherchant sur Google.
Se plaindre et avoir une aura de négativité
La plupart des développeurs avec lesquels j'ai travaillé sont des personnes positives et enthousiastes. Peut-être est-ce pour cela que travailler avec des développeurs négatifs m'irrite tant.
La négativité est contagieuse. Si quelqu'un se plaint, cela attire l'attention sur le côté négatif des choses. Les autres seront enclins à adopter la même attitude.
« La négativité est l'ennemie de la créativité. »
— David Lynch, réalisateur
Bien sûr, tout n'est pas rose dans le développement logiciel. Il y a des moments difficiles. Nous devons parfois travailler avec du code hérité des âges sombres ou avec des outils qui ont la performance d'un paresseux.
Il est préférable de se demander ce que nous pouvons contrôler au lieu de répéter ce que nous ne pouvons pas changer.
Nous pouvons allouer des ressources pour le refactoring de code ou écrire de la documentation. Nous pouvons découvrir si nous pouvons ajuster les paramètres de mémoire des outils lents pour les accélérer.
S'étendre longuement lors des réunions
Lors des réunions, je vois les yeux se retourner lorsque « ce développeur » s'étend longuement.
Comme dans toute autre profession, la communication verbale est l'une des principales compétences douces que nous devons apprendre.
Lors de la communication, aller droit au but fait des merveilles. Les collègues nous comprendront mieux, ainsi que la situation.
Un de mes petits agacements en matière de communication est lorsqu'un développeur parle à des non-codeurs en utilisant du jargon. Les designers font parfois semblant d'acquiescer lorsque un développeur s'étend sur les intrications de JavaScript. Tout pour les faire arrêter de parler.
Savoir à qui vous parlez et parler dans leur langage est du bon sens. Parfois, le bon sens n'est pas si commun.
S'attribuer le mérite pour soi-même
De temps en temps, je vois un développeur s'attribuer le mérite du travail produit par un effort d'équipe. Il pourrait écrire un email à la direction pour vanter la fonctionnalité ou parler d'une tâche comme s'il l'avait faite seul.
Le plus souvent, cela est communiqué de manière sournoise et non directe. Les déclarations d'attribution de mérite sont habilement impliquées.
De telles stratégies peuvent produire une visibilité à court terme pour cet individu.
À long terme, de tels développeurs seront mis à l'écart. Cela se fait soit par choix, soit de manière subconsciente. Les autres membres de l'équipe feront évoluer leur communication pour mieux mettre en avant leurs contributions.
Il serait beaucoup plus sensé de donner le mérite aux autres lorsqu'il est dû. Pas besoin d'en faire trop. Mais je dis qu'il faut donner le mérite dû.
Il existe de nombreuses façons de donner le mérite. Nous pouvons mentionner les contributions du collègue lors du Daily Scrum. Nous pouvons remercier le collègue par email et copier son manager.
Il y a de nombreux avantages à donner le mérite dû :
- Vous vous sentez bien parce que vous êtes honnête.
- Le collègue contributeur se sent reconnu.
- Permet au manager d'avoir une impression plus précise du collègue.
- L'équipe a une meilleure image des compétences des individus.
Ainsi, soyons conscients de quand donner ou prendre le mérite.
Conclusion
Le chemin pour devenir un meilleur développeur est un processus sans fin. Parfois, il est judicieux de faire une pause sur ce chemin pour réfléchir à la manière dont nous faisons les choses. L'art de l'auto-réflexion professionnelle nous aide à corriger notre trajectoire. Devenir meilleur dans notre métier augmente notre niveau de contentement avec ce que nous produisons.
Soyons le développeur logiciel avec lequel nous aimons travailler.