Salutation, mon cher ami.
J’étais pas mal occupé ces derniers temps, notamment dans la réalisation d’un projet (on en reparlera peut-être) puis, suite aux difficultés que j’ai rencontrées dans celui-ci, par la lecture d’un livre. Il s’agit de “97 things every programmer should know”. Il fait 304 pages en ebook, et le lire à l’arrache n’apporte pas grand-chose.

J’ai donc décidé de créer cette série de trois articles ayant pour unique objectif de trier ces 97 conseils, et de les résumer. Ainsi, la prochaine fois que je me lancerai dans un travail de ce type, j’aurai un « pense-bête » pour me remémorer les bonnes choses.

Vu que ces avis ne proviennent pas de moi, j’ai laissé de côté ma très grande expérience dans le domaine (ironie) pour retranscrire de façon la plus objective possible ce que les auteurs disent. Évidemment, n’hésitez pas à vous aussi, partager les petits trucs qui peuvent nous être utile en tant que développeur. 😉

~~~~
La mentalité du développeur.
Coder de façon satisfaisante.
Moi, et les autres. (Sera disponible un jour)
~~~~

Sommaire :

• Introduction
• Être altruiste
• Le plaisir d’apprendre
• Se mettre au travail
• Apprendre correctement
• Conclusion

 

Introduction

Pour commencer, il est important de bien avoir conscience de la nature même de notre travail. En effet, un dévoloppeur est souvent perçu comme un technicien. Comme quelqu’un qui construit une voiture, ou une maison. La réalité, c’est qu’il devrait plus être vu comme un artiste. Vu comme quelqu’un dont les ressources sont illimitées, mais dont le résultat est incertain.

Par exemple, la difficulté de prédiction du temps et du matériel nécessaire pour clôturer un parc est assez faible : nous savons de combien de piquets on aura besoin et ce que chacun d’eux demande. En revanche, les moyens dont devra disposer un designer pour élaborer un nouveau concept de lampe seront bien plus instables. Pourquoi ? Parce que la création n’est pas physique, mais une œuvre de l’esprit. On peut faire autant de prototypes que l’on veut, les coûts de tests sont nuls, bref, à l’instar des techniciens, c’est leurs imaginations qui les brident, pas des contraintes du monde réel bien connu et pouvant être très précisément calculés.

À votre avis, à quoi ressemble le plus le métier de développeur ? Évidemment, à celui de designer ! Pourtant, on continu à être mal considéré. Le pire, c’est qu’on le pense souvent nous-mêmes. Croyez-vous vraiment qu’on divise la durée d’un projet par le nombre de personnes qui travaillent dessus ? Que le temps de création peut être défini de façon nette ?

Un développeur est un artiste. Son rôle n’est pas de faire appel à ses mains pour construire une copie de quelque chose qu’il a appris et qu’il maîtrise donc pleinement, mais de faire usage de son imagination et son expérience pour concevoir quelque chose d’abstrait répondant à une problématique dont la confusion est tout aussi élevée.

Être altruiste

Une des choses les plus importantes pour être altruiste doit probablement se trouver dans la pensée positive. En effet, nous avons souvent tendance à intérieurement directement rejeter les demandes des autres en les qualifiant de stupides, inutiles ou nuisant à l’ensemble du programme. Le problème de cette optique est que l’on se retrouve à travailler contre le client, voir ses collègues plutôt qu’avec eux, ce qui nivelle vers le bas la qualité du projet qui en résultera. Une meilleure attitude à une requête nous paraissant non productive est de s’interroger sur la raison qui nous pousse à réagir de la sorte. Trouvons-nous objectivement que la demande est vraiment impropre, ou ne s’agit-il que de mauvaise foi ? Parler avec l’émetteur d’une idée est très bien pour comprendre son point de vue et distinguer plus clairement où il veut en venir.

Eh oui, après tout, il ne faut pas oublier que si l’on code, c’est principalement pour les autres ! Nous pouvons carrément pousser l’image jusqu’à dire que nous sommes des développeurs qu’à travers les confrères avec qui l’on interagit. On est bon, si notre programme est jugé correct par les usagers ou si nos collègues peuvent réemployer ce que nous avons construit. À aucun moment, nous ne travaillons que pour nous même. Il faut avoir conscience que chaque caractère que nous tapons l’est dans le but de servir nos semblables. L’utilité est soit directe (maintiens du logiciel), soit indirecte (client final), mais dans les deux cas, c’est leurs expériences avec notre création qui nous définira, et non l’ouvrage en lui-même.

En fait, ce qui joue beaucoup entre un bon programmeur et un mauvais n’est pas vraiment l’intelligence, mais l’attitude. Certaines personnes sont en effet capables de produire des algorithmes de folie, mais écrivent un code dégueulasse dont on ne peut rien faire. Rappelez-vous qu’être le plus doué ne sert au final à rien si l’on ne concevoir quelque chose d’exploitable. L’aptitude à faire des choses très poussées n’est profitable que pour des concours et pas pour la réalisation concrète de projets, car le travail est futile si la compréhension de celui-ci ne touche personne.

Nous devons donc rester humbles, et pas nous prendre pour un super-gourou ! Souvent, on a tendance à croire que la faute vient des autres. On cherche à prouver que le compilateur se plante, ou que le collègue a fait de la merde. On devrait utiliser notre énergie dans l’étude de notre propre code, et vérifier si ce n’est pas lui-même qui contient quelque chose qui ne va pas. Encore une fois, nous ne sommes pas seuls, au lieu de considérer vos partenaires comme des boulets, voyez-les plus comme des amis pouvant vous aider. Demandez-leur d’implémenter eux aussi la chose qui chez nous bloque, pour tester si l’erreur surviendra, ou si quelqu’un arrive à passer outre.

Le plaisir d’apprendre

Comme tout artiste, ce n’est pas à l’école qu’on évolue forcément de la meilleure des façons. En tant que développeur, on ne peut donc pas prétendre devenir doué rien qu’en suivant tranquillement les cours. La programmation nous passionne, et notre curiosité envers ce qui nous fascine nous pousse à chercher à en connaitre toujours plus dans le domaine. On se tient informé de ce qui se passe via nos flux RSS, on suit des experts sur Twitter, on va à des conférences, dans des groupes d’utilisateurs des technologies qu’on aime, s’abonne à des listes de diffusion, etc. Se trouver des mentors est également bénéfique pour progresser : avoir des personnes plus expérimentées que nous capables de nous expliquer les choses qu’on ne comprend pas, et qu’on puisse prendre comme modèle. Cependant, l’inverse est aussi intéressant : ne pas hésiter à aider, à parler des sujets qu’on maîtrise, voir donner des cours, car les questions que les autres vous poseront seront un bon stimulant pour continuer à se renseigner sur quelque chose.

Il est conseillé d’apprendre en moyenne un nouveau langage par an. Pourquoi ça ? Premièrement, pour rester à jour. En effet, la technologie évolue très rapidement en ce moment ce qui rend également les choses très vite obsolètes. Le second avantage à ça est de nous permettre d’avoir plusieurs points de vue sur la résolution d’un problème. C’est surtout le cas à partir du moment qu’on maitrise différents paradigmes. Vous verrez tôt à quel point il est bon de pouvoir choisir entre différents chemins, différents points de vue, dans la façon d’atteindre les objectifs.
Mais ce n’est pas tout, on oublie vite que nous n’avons pas qu’à communiquer avec des machines ! Appréhender les humains (notamment les collègues et les clients) est également nécessaire. Pour cette raison, comme pour les langages de programmation, il est conseillé de se tenir à jour : assimiler le vocabulaire des marketeux qui bossent avec nous, et du domaine dans lequel sera utilisée notre application. Apprendre des langues étrangères ouvre pareillement notre capacité à mieux saisir les gens. Les bons développeurs ne sont souvent pas uniquement habiles avec du code, ils le sont de même avec les mots : ils peuvent être clairs dans leurs phrases, comprendre et se faire comprendre.

Bref, il est primordial de maîtriser son environnement : nous-mêmes et les autres, mais pas que. Avoir conscience des mécanismes engendrés pour transformer nos sources en véritables programmes n’est pas moins capital. Avoir recours aux commandes Unix par exemple, à la place de son IDE, n’est pas seulement plus performant d’un point de vue de la consommation de ressources, c’est aussi beaucoup plus « puissant ». Vous perdez la dépendance que vous avez envers cet IDE qui souvent peut s’avérer problématique comme ils ne couvrent qu’un nombre très restreint de langages. L’autre très gros avantage se trouve dans le concept même : ils seront sur mesure, super efficace pour votre utilisation, et vous connaîtrez leurs limites !
C’est pareil pour la compilation. C’est une erreur de se contenter de cliquer sur un bouton de votre IDE. Vous devez au moins maitriser la compilation manuelle et savoir créer votre propre makefile. Il en est de même pour l’étape de linkage, couramment incomprise alors qu’il ne s’agit que d’un bête programme qui ne fait que concaténer tous les fichiers objets ensemble et connecter les symboles. Supprimer la magie aide à trouver les solutions aux problèmes « mystiques » et à avoir pleinement conscience de ce qu’on manipule. C’est l’unique façon de juger de la qualité et d’expliquer la cause de certains types d’erreurs.

Si vous continuez à travailler avec un IDE (des fois, c’est efficace quand même), ne tombez pas dans le piège de la simplicité ! Souvent, la courbe d’apprentissage est très douce, ce qui a pour conséquence de donner rapidement l’illusion à l’utilisateur de le maîtriser parce qu’il arrive à « survivre » avec. Aujourd’hui, rares sont les personnes qui lisent le manuel de leurs interfaces de développement, car instinctivement nous pouvons trouver comment la régler à peu près correctement et de quelle façon compiler. Malheureusement, c’est à coup sûr que de cette façon, nous passons à côté de toutes les fonctionnalités qui font pourtant leurs forces.

Se mettre au travail

Bien, j’espère vous avoir motivé à devenir bon. Donc par où commencer ? Par bosser dans l’optique de nous parfaire, et non pas de produire quelque chose. En effet, nous ne devons pas seulement travailler pour créer des contenus, pour faire du concret, mais aussi pour nous éduquer, et ce, durant toute notre vie. Malheureusement, nous sommes souvent plus payés à fabriquer des logiciels, donc on aura plus tendance à privilégier ce qu’on sait déjà faire (pour être plus efficace). On sera donc réduit professionnellement à apprendre bien moins… Vous l’aurez compris : il faut se mettre à la pratique délibérée. Bosser sur un projet pour le fun, dans l’unique optique de nous améliorer. Prendre une techno qui nous intéresse et qu’on ne maîtrise pas, et travailler dessus en ayant pour seul but de progresser, passer les paliers, un à un, pendant quelques années, jusqu’à devenir un expert.
Faire un bon programme nécessite aussi de faire, des fois, le courageux choix de tout casser, et recommencer quelque chose quand les fondements eux-mêmes sont mauvais. Trop de personnes essayent de faire avec un code de base médiocre. Ça peut venir d’une erreur de conception dès le début du projet, ou parce qu’un même code est rafistolé depuis des années. Souvent, les développeurs tentent de faire avec et du coup, passent énormément de temps à corriger les bogues que ça engendre. N’hésitez donc pas à casser des œufs si vous avez à faire une omelette. Surtout si ça concerne quelque chose « pour le fun », sans retombée financière.

Enfin, probablement la meilleure façon de progresser est de contribuer à des programmes open source. Vous trouverez forcément un projet qui vous intéresse. Commencer à lire son code source est un très bon début. Vous verrez de cette façon comment quelqu’un d’autre a implémenté une solution à un problème, et vous pourrez comparer avec ce que vous auriez fait à sa place. Vous pourrez également regarder les paterns utilisés et les règles d’écriture. On peut analyser directement la qualité du contenu : pourquoi est-il difficile à lire ? Ou au contraire, simple ? Le pouvoir didactique de l’étude du code d’autrui, surtout des développeurs talentueux est souvent sous-estimé.
Enfin, pourquoi ne pas devenir acteur ? Soumettre des patchs et un très bon moyen pour avoir des avis de codeur expérimentés sur votre travail. Créer des programmes de test efficace est aussi quelque chose de très instructif. De plus, vous vous ferez des connaissances, voir même des amis, qui pourront toujours vous aider dans votre apprentissage.

Apprendre correctement

Les différences entre les langages de programmation ne se limitent pas que dans la syntaxe. Malheureusement, beaucoup de personnes se focalisent à mémoriser ces variances de formes : quelle est la bonne orthographe d’un foreach en PHP, une condition en Python, etc. Pourtant, il ne s’agit que d’une infime partie des choses à savoir. Le plus important se situe surtout au niveau de son contexte : pourquoi a-t-il été créé ? Dans quelle optique ? Comment les concepteurs ont prévu qu’il soit utilisé ? Souvent, en assimiler un correctement signifie également prendre conscience de nouveaux procédés dans la résolution d’un problème. Ironiquement, l’enseignement ne concernera pas que cet unique langage, mais notre façon générale de penser, quitte à modifier nos attitudes de codeur.

Les langages que nous apprenons doivent aussi être de plusieurs paradigmes, comme du procédural, de l’orienté objet, du fonctionnel, de la programmation logique, ou encore en flot de données. Attention, derrière « apprendre », je veux dire réellement maîtriser, pratiqué régulièrement pendant plusieurs mois, pas juste avoir quelques bases. Pourquoi cela ? Parce que ça nous permet d’intégrer pleinement la résolution d’un problème de différents moyens : un algorithme en C++ n’aura rien à voir avec un autre en Ada, même si les deux répondent à la même tâche. Ne pas être coincé avec une unique façon de faire et crucial pour pouvoir correctement juger si notre implémentation est acceptable ou non.

Une bonne chose à faire aussi pour bien apprendre est de réinventer la roue. Savez-vous comment créer des listes doublements chaînées ? Des tableaux dynamiques ? Des bibliothèques d’affichage graphique ? N’oubliez pas que pour intégralement assimiler les difficultés et puissances de quelque chose, nous avons à maitriser le fonctionnement. C’est le cas, même si en production nous nous contenterons finalement des algorithmes reconnus et utilisés par des millions d’autres plutôt que les nôtres. Il y a des fois où les connaissances théoriques ne suffisent pas pour optimiser ou même déboguer. C’est encore plus vrai quand ça concerne les bases sur les-quelles se reposent quasiment tous les programmes, mais que nous voyons comme des boites noires.

Attention quand même. Les précédents conseils peuvent laisser croire qu’il est bon de passer sa vie à coder, ce qui est faux. En effet, pour travailler correctement, nous ne devons pas être en saturation. Or, c’est souvent ce qui arrive si l’on est à l’œuvre plus de 30 h par semaine. Quand nous sommes bloqués sur un problème, lâcher le clavier quelques minutes, le temps de faire une promenade, boire un café, ou écouter de la musique est également une façon très utile d’avoir l’idée qui arrange tout qui « surgit » dans notre tête. Ne l’oubliez pas : être développeur, c’est avant tout être un artiste. Nous ne créons pas une belle peinture en nous acharnant dessus. Pensez aussi au fait que nous devons nous tenir à jour des nouveautés, aller à des conférences, et converser avec d’autres pour rester bons. Comment serait-ce possible de faire ça si nous passons nos soirées et week-ends à continuer de travailler sur nos projets ?

Conclusion

Pour finir avec cette partie sur la mentalité du bon développeur, il semble important de préciser que les gourous n’existent pas. Il n’y a rien de magique là dedans. Quelqu’un qui est doué, c’est parce qu’il a investi énormément de temps dans l’apprentissage de son domaine. Bien sûr, certaines personnes éprouvent plus de difficultés que d’autres pour inculquer de nouvelles choses, mais personne ne devient un génie par accident. Il faut en moyenne consacrer 10 000 heures à un secteur pour pouvoir commencer à être qualifié d’« expert ». Autant vous dire que ça ne se fait pas du jour au lendemain.
Certains individus alimentent le mythe du gourou par souci d’égo, ou bien par choix stratégique pour avoir l’air plus intelligent face aux clients ou au patron. Ironiquement, c’est souvent loin d’être le cas. Pourquoi ? Parce qu’ils sont comme tout le monde, et que s’ils ne partagent pas de connaissances avec d’autres, ils finissent également par en gagner moins, voir en perdre !

N’oubliez pas que pour être professionnel, il faut être responsable. C’est à vous-même de vous prendre en main. Ce n’est pas votre employeur qui a la charge de vous maintenir à jour, ni d’étendre votre domaine intellectuel. Vous êtes par ailleurs l’unique responsable de votre code. Ce n’est pas parce qu’un projet comporte souvent des dizaines de développeurs et des testeurs qu’on peut se permettre de commité des algorithmes hasardeux dont on n’est pas vraiment sûr du résultat, en se disant que « si quelque chose cloche, quelqu’un d’autre finira bien par le voir ». Enfin, il s’agit d’un jeu d’équipe : vous n’êtes jamais seul. Ça implique de faire les efforts nécessaires à l’écriture de contenu propre, mais aussi dans la compréhension de celui des autres. Vous travaillez avec eux : « Si l’un tombe, je tombe. ».

Oui, être un développeur, c’est vraiment vivre dans un monde de fou ! Les péripéties et les défis sont partout. À nous de faire notre chemin dans cette palpitante aventure, mais n’oublions jamais l’essentiel : si on fait tout ça, c’est parce que c’est fun ! Nous avons la chance d’évoluer dans un univers qui semble infini et rempli de gens intéressants, à nous de mettre toutes les opportunités de notre côté et de devenir celui qu’on veut être. 🙂 À bientôt pour la suite de cet article, mais en attendant, amusez-vous bien ! 😉

---

Crédit images :

• Le développeur qui dors sur son clavier (image à la une) by ~Veritude
• Les raisins et l’arbre by *veprikov
• Les chiens et l’os by *VardelosHund
• Le bonhomme content d’apprendre by *chocolath
• Le poney qui devient puissant by =Tridgeon
• La fille rêvant d’atteindre les sommets by ~violet-rainstorm
• L’homme qui s’élance dans le vide by ~until-it-bleeds