- Introduction
- Une bonne répartition du temps
- Pas de coding-game
- Faire de la veille
- Faire autre chose, de temps en temps
- Écrire du code comme s'il allait être relu (et il le sera)
- Standardiser les process
- Respecter l'utilisateur final
- Aimer ce que tu fais
- Du dev à l'artisan, puis à l'artiste
- Conclusion
Introduction
Je ne vous donne pas les clés pour trouver à coup sûr un boulot. Ce n'est pas possible, et je n'en ai pas l'ambition.
Par contre, je vous explique comment être un bon dev, par opposition aux mauvais devs, parce que oui, selon moi, le métier du dev est manichéen. On est attirés soit par l'argent (mauvais devs), soit par l'amour du code (bons devs).
Cet article devrait vous permettre de vous conforter dans l'une ou l'autre de ces catégories.
Il y en aura forcément pour me dire qu'on peut être un bon dev appâté par l'argent et un mauvais dev qui aime pourtant coder, et toutes les variations possibles entre les deux. À ceux-là je réponds ceci : merde.
J'ai 40 ans, je code depuis que j'ai 5 ans. J'ai travaillé dans le public, dans le privé, en association, en agence, etc. Je code par amour du code et par amour du travail bien fait. Jamais je n'ai choisi le dev pour des prérogatives financières. Je m'estime être un excellent dev, expérimenté et spécialiste de son sujet (Laravel). Et je suis attristé d'en être où j'en suis aujourd'hui : sans aucune reconnaissance.
Donc je le répète : cet article n'est pas un guide pour trouver un boulot, c'est une liste d'éléments que j'estime être cruciaux pour quelqu'un qui veut être un bon développeur dans son état d'esprit. Quelqu'un qui a juste envie de pisser du code ne pourra pas apprécier cet article.
J'ai transmis à quelques devs ces principes au cours du temps. Il me plait de croire qu'ils les exploitent aujourd'hui et contribuent à donner au métier ses lettres de noblesse.
Une bonne répartition du temps
Un bon dev réparti son temps de la façon suivante :
- 80% de temps de réflexion en amont
- 20% de temps d'écriture de code en aval
C'est simple, ça se passe des appréciations des recruteurs. Tout rapport différent, ou en tout cas où le temps de réflexion est inférieur au temps d'écriture, indique une entreprise qui s'en tape de la qualité, et donc hostile aux utilisateurs (et accessoirement, hostile à ses propres devs).
Mais le plus important dans ce rapport est son impact psychologique et la pénibilité du travail du dev (dont personne ne parle jamais alors qu'on est tous en burn-out en ce moment).
Tu préfères coder 2 jours et passer 5 jours à debugguer ta merde, ou passer 5 jours à réflechir et 2 jours à écrire le meilleur code du monde ? Il y aura toujours des bugs, mais au moins, ils seront challengeants et intéressants à résoudre.
Tout le monde peut pisser du code. Personne ne peut pisser du code de qualité supérieure.
Pas de coding-game
Les coding-game, c'est pour les Jacky. Un bon dev code bien, pas vite. Les deux sont mutuellement exclusifs.
Si tu fais des coding-games pour le sport mais qu'à côté tu prends ton temps pour les projets importants, tant mieux. Mais savoir prendre son temps est tout aussi difficile que de résoudre des challenges en temps limité.
Résoudre des coding-games ne fait pas de toi un bon développeur. Ils font de toi un bon résolveur de problème. L'étape entre les deux s'appelle le refactoring, et on ne te laisse pas le temps de le faire dans un coding-game.
Surtout qu'en dehors des coding-games, si tu réfléchi bien ton code en amont, tu as moins de refactoring à faire plus tard. Et moins de refactoring = meilleur qualité de vie pour tous les devs.
Faire de la veille
En tant que dev, on nous demande de maîtriser des dizaines de technos. Pas seulement plusieurs langages avec des orientations différentes, mais aussi des outils pas directement liés au code (genre, docker).
C'est chiant de devoir maîtriser ces trucs parce que c'est le marché qui dicte ce qu'on doit maîtriser. Donc, il est encore plus important de faire de la veille précisément sur ces technos.
Idéalement, tu as un ou plusieurs side-projects, de tout type et de toute taille, et tu t'en sers comme laboratoire pour tester les dernières versions de tes outils et langages préférés. Le petit plus, c'est que ça remplit ton portfolio.
Si en plus tes side-projects sont partagés avec la communauté, c'est tout bénéf.
Faire autre chose, de temps en temps
Voir mon article Apologie de la procrastination.
Écrire du code comme s'il allait être relu (et il le sera)
Je ne suis pas certain que cette phrase n'ait pas déjà été prononcée, au moins sur Internet. C'est dire à quel point elle est cruciale.
Par "relire du code", on entend trois choses :
- la code-review qui est censée intervenir avant la mise en situation
- le code relu plusieurs semaines/mois/années après son intégration
- le code lu par un nouvel arrivant dans l'entreprise
Ce dernier point est probablement le plus négligé et pourtant il n'est pas moins crucial qu'un nouveau collaborateur soit capable de prendre en main la codebase le plus rapidement possible. Si le code part dans tous les sens, le nouveau dev aura du mal à prendre ses marques et prendra plus de temps à se mettre au travail.
Standardiser les process
Le titre bien chiant à lire avec sa sémantique start-up... Pourtant, utiliser des techniques de développement plus ou moins standardisées permet de rapidement s'approprier le code de quelqu'un d'autre.
Par exemple, pour PHP et Laravel spécifiquement (à ajuster en fonction des langages et frameworks que vous utilisez) :
- Lire les PSR, c'est les standards les plus importants du langage
- Lire la doc du framework avant d'essayer de dev une fonctionnalité, il contient peut-être déjà ce que vous essayez de faire
- Lire la doc du langage qui vous concerne...
"Standardiser les process", ça veut aussi - et surtout - dire de ne pas réinventer la roue. En entreprise, arrêtez de coder des "frameworks maison", personne ne peut les connaître, les maîtriser ou être compétent immédiatement.
Ça veut dire aussi d'utiliser des librairies tierces, et surtout, savoir les choisir (en fonction de leur activité et de la communauté qui est derrière, mais aussi en fonction de sa taille et la façon dont elle est écrite).
Il est crucial d'embrasser des méthodes de travail qui ont fait leurs preuves depuis des dizaines d'années dans le métier :
- DRY
- KISS
- SOLID
- et, dans un autre registre, Merise, probablement considérée comme obsolète par les startuppers qui ne la connaissent peut être même pas, alors qu'elle est dans les fondations de n'importe quel projet et de n'importe quel framework aujourd'hui
Enfin, et c'est le plus important, ça veut dire utiliser correctement les éléments de langage, en particulier les interfaces, en tout cas en PHP. Les interfaces sont probablement les outils les plus importants du langage pour structurer son code et permettre à vos composants d'être facilement interchangeables.
Respecter l'utilisateur final
Bon, là, il faut se faire pousser des couilles et savoir dire "non" quand on te demande de coder un truc que tu sais être hostile à l'utilisateur. Faire de la veille sur les dark-patterns est important, pas seulement pour refuser de le faire mais aussi pour éviter de tomber dedans sans faire exprès (c'est plus facile qu'on le pense, surtout côté frontend, et surtout quand on touche à la télémétrie).
Respecter l'utilisateur final, c'est faire en sorte que ton application fonctionne comme elle est prévue. Qu'elle informe l'utilisateur quand elle doit l'informer, et qu'elle ait un comportement logique et intuitif (c'est quoi ce truc de faire des messages d'erreur du genre "Une erreur est survenue, réssayez plus tard", sans même un code d'erreur à remonter ?).
Tu mets tout le monde d'accord quand tu respectes l'utilisateur final : ce dernier parce qu'il est content d'utiliser une application qui fonctionne bien, le service support de ta boîte qui ne se fera pas engueuler à longueur de temps pour rien, et toi parce que ton application sera plus facile à debugguer.
Aimer ce que tu fais
Si tu codes parce qu'on t'a dit que coder c'était bien payé, passes ton chemin. Déjà parce que ce n'est pas forcément vrai, mais surtout parce que pour être un bon dev, la motivation principale ne peut pas être l'argent.
Ces remarques sont valables peu importe le métier, plus ou moins.
S'il n'y a que l'argent qui t'attire dans le dev, tu deviendras un mauvais développeur, hostile à l'utilisateur. C'est une remarque parfaitement censée et éprouvée depuis que le web existe : plus tu es hostile à l'utilisateur, plus tu rapportes de l'argent à ton entreprise. Ça ne fait pas de toi un bon développeur, ça fait de toi un bon rabatteur.
Sauf qu'un bon développeur qui produit une application de qualité peut rapporter encore plus d'argent à son entreprise, en plus de ne pas entâcher sa renommée. Et s'il y a une chose qu'une entreprise apprécie encore moins que perdre de l'argent, c'est d'avoir mauvaise presse.
Donc, tu dois coder parce que tu aimes coder. Parce que tu apprécies la capacité créatrice de l'informatique, écrire des instructions de la meilleure façon possible pour transformer ces instructions en résultat tangible, et fiable.
Du dev à l'artisan, puis à l'artiste
Si tu aimes ce que tu fais, tu vas entrer dans une boucle vertueuse, où tu vas chercher à produire le code de la meilleure qualité possible. Tu vas passer (intellectuellement) du simple développeur à l'artisan quand tu commenceras à rejeter les mauvaises pratiques exercées en entreprise (sauf, évidemment, si tu as la chance de tomber rapidement sur une boîte qui valorise les bonnes pratiques).
Et un jour, longtemps après, tu finiras par être considéré comme un artiste du code par tes pairs. Pour rester sur le thème de PHP et de Laravel, tu atteindras peut-être le niveau d'un Taylor Otwell, d'un Nuno Maduro ou encore d'un Freek Van Der Herten.
Conclusion
Il y a mille choses encore à dire sur le sujet, et encore plus si je me focalisais sur ce que devrait être un bon développeur PHP, mais on a là l'essentiel.
Si tu te reconnais dans cet article, tu es sur la bonne voie. La voie du bien, celle du bon dev bien dans ses babouches. Tu ne connaîtras pas forcément le succès (je ne l'ai pas connu), alors à toi de voir ce qui compte le plus pour toi.