J'ai regardé l'autre jour une performance de Kate Gregory à la conférence Pacific ++ 2018.
Kate est une bonne programmeuse et une excellente conférencière. Le rapport lui-même soulève beaucoup de choses intéressantes sur la programmation C ++ et la programmation en général (ça vaut le coup d'oeil). Mais surtout, j'ai été accroché par une (littéralement en passant) pensée qu'elle a exprimée. Kate a pu très brièvement et dans le cas présent identifier la motivation des programmeurs. Elle ressemblait à ceci: "Le programmeur, tout en travaillant, cherche à maximiser son bonheur." Cela semble ringard, mais ça l'est vraiment.
Nous pouvons dire que nous soutenons le projet, le client, l'entreprise, l'humanité et la paix dans le monde (et cela peut même être vrai). Mais soyons honnêtes. Nous sommes des gens et, comme tout le monde, nous nous efforçons en premier lieu de maximiser notre bonheur - globalement tout au long de notre vie, stratégiquement dans nos carrières, tactiquement dans le projet actuel, et mesquins ici et maintenant, lors de l'écriture de cette fonction, cette ligne de code. Oui, nous le faisons et il serait bon de comprendre ce qui nous rend plus heureux et ce qui nous rend moins. Cela nous permettra de mieux comprendre nos collègues, nos subordonnés et nous-mêmes.
Je veux immédiatement mettre entre parenthèses les questions de rémunération, conditions de travail, supérieurs, personnel et autres. Si vous travaillez là où vous travaillez, alors tout cela vous conviendra à peu près. Concentrons-nous sur ce qui nous rend heureux et malheureux lorsque nous travaillons directement sur le code.
Les tests
Tous les projets avec tests sont également satisfaits, chaque projet sans test est mécontent à sa manière. Je peux dire avec confiance que les programmeurs dans les projets avec une bonne couverture de test sont en moyenne plus heureux que dans les projets sans tests en général. J'ai même vu comment les programmeurs, avec qui leurs supérieurs n'étaient pas d'accord pour écrire des tests à part entière, les écrivaient secrètement (parfois même après les heures). Pourquoi est-ce arrivé? Le test écrit rend le programmeur plus heureux. Son existence même est déjà un signe qu'au moins quelque chose dans votre projet se fait selon les meilleures pratiques de l'industrie (même si le reste ne l'est pas). Un test terminé avec succès montre une belle coche verte, fait l'éloge du programmeur (et après tout, peut-être que personne ne le félicitera). La réussite de 100% des tests fournit une sorte de terrain stable sous vos pieds, quand vous pouvez déjà croire en quelque chose - cela ajoute à notre confiance en aujourd'hui et demain, nous rend plus heureux. Et même un test échoué fait son travail - nous informe que nous l'avons écrit pour une bonne raison, nous félicitant pour notre prévoyance. Si vous voulez rendre un programmeur plus heureux, laissez-le (ou même le forcer à forcer) écrire des tests (bien sûr, tout est bon avec modération).
Correction de bugs et développement de nouvelles fonctionnalités
«Je ne vous le dirai pas pour l’ensemble d’Odessa», mais la plupart des programmeurs que j’ai rencontrés dans ma vie aimaient davantage écrire de nouvelles fonctionnalités que corriger du code legac. Pourquoi? Mais parce que toucher un bug, c'est toucher le malheur de quelqu'un d'autre. Quelque chose s'est mal passé pour quelqu'un et il était si important qu'il n'était pas trop paresseux pour porter son deuil jusqu'au développeur. Faut aller dans sa position, essayer de se reproduire. Et puis après tout, il réussira à se reproduire - et il y aura un coup à l'estime de soi en raison d'un bug admis, ou cela ne fonctionnera pas et il sera nécessaire (oh mon Dieu, non!) De contacter une personne vivante qui a découvert le problème et d'essayer d'obtenir plus d'informations. Tout cela ne peut pas être qualifié d'agréable.
En même temps, écrire une nouvelle fonctionnalité est une touche potentielle de bonheur. Nous n'avons encore rien cassé, ce n'est pas de notre faute. Nous écrivons un nouveau code pour résoudre de nouveaux problèmes. Peut-être que cela réussira. Peut-être que nous recevrons des éloges bien mérités (bonus, promotion). C'est déjà plus proche des niveaux supérieurs de la pyramide des besoins humains
selon Maslow .
Quelle conclusion? Le travail du programmeur doit être équilibré, il ne doit pas y avoir de correction de bogue. Chaque programmeur doit confier de temps en temps le développement de nouvelles fonctionnalités. Oui, il n'y a pas d'échappatoire à la correction de bogues, mais au moins nous pouvons essayer d'atteindre un équilibre «à peu près zéro» de bonheur et de malheur dans cette affaire.
Refactoring
Travailler avec un bon code est bien. Malheureusement, un bon code ne tombe pas du ciel. Il est même impossible de le prendre et de l'écrire la première fois. Nous devons faire du bon code à partir du mauvais, car il n'y a plus rien à faire. Ici, les programmeurs font un choix: chaque jour, quand ils viennent au travail, ils continuent de souffrir et de travailler avec du mauvais code, ou encore d'essayer d'en faire du bon code. Dans le second cas, vous devez souvent vous battre avec un leadership qui ne comprend pas sur quoi ces N heures pourraient être consacrées si de nouvelles fonctionnalités n'étaient pas ajoutées au produit et que les anciens bugs n'étaient pas corrigés. Oui, vous devez vous battre. Heureusement, dans cette guerre, nous avons des arguments: un code concis et beau est moins sujet aux erreurs, son support prend moins de temps (et coûte moins d'argent), il se prête mieux aux changements lorsque de nouvelles exigences métier apparaissent, etc. De plus, cette guerre, en règle générale, n'est pas longue: elle se termine par une sorte de compromis comme "non, je ne donnerai pas un mois pour le refactoring, mais allouons-le 2 heures par semaine le vendredi". D'accord, c'est bien. Nous venons de nous procurer un morceau de bonheur. Oui, il devra toujours être construit de vos propres mains, mais cela est déjà devenu possible.
Utilisation de bibliothèques et d'outils modernes
Beaucoup connaissent probablement la douleur d'avoir à travailler dans un projet qui est bloqué pour une raison quelconque sur un compilateur (framework, bibliothèque) il y a de nombreuses années. Ils nous expliquent que pour telle ou telle raison, il est impossible de passer à la nouvelle version ici et maintenant, mais un jour, probablement, si cela fonctionne ... Que pouvez-vous faire? Eh bien, premièrement, nous devons admettre que les circonstances ne sont pas en notre faveur et que la situation nous rend plus malheureux que nous ne pourrions l'être. Deuxièmement, la même idée peut être exprimée par les autorités (ou le client). Il est peu probable que quiconque conteste cela. Et en ce moment, vous pouvez essayer de négocier pour vous-même: par exemple, le temps pour les tests mêmes, les nouvelles fonctionnalités et la refactorisation. (Vous pouvez augmenter le salaire, mais au début de l'article, j'ai promis de ne pas le mentionner.)
Soit dit en passant, le temps consacré à ces tâches utiles peut non seulement vous rendre un peu plus heureux ici et maintenant, mais également éliminer les raisons très «effrayantes» pour lesquelles il était impossible de passer à l'utilisation d'outils plus récents. La vraie situation de ma vie:
- Nous ne sommes pas sûrs que la transition vers une nouvelle bibliothèque ne nous posera pas de nouveaux problèmes ...
- Et ici, j'ai écrit 200 tests pour le code en utilisant cette bibliothèque, essayons de passer et nous les lancerons.
- Hmm, allez.
Après 2 semaines - une nouvelle bibliothèque en production.
Vous pouvez probablement continuer à explorer d'autres aspects. Mais l'idée générale est la même: certaines tâches et circonstances rendent le programmeur plus heureux, d'autres - plus mécontents. S'il y en aura plus que les premiers - l'humeur et la productivité du programmateur chuteront, tôt ou tard, cela entraînera des problèmes dans le projet ou son départ de l'équipe. Par conséquent, le programmeur et son manager devraient non seulement penser au «bien global» du projet, de l'entreprise ou de l'utilisateur, mais aussi comment rester relativement satisfait du développeur. Sinon, à quoi ça sert?