Être un bon développeur n'est pas qu'une question de code...

Bonjour bonjour 😁,
Cette semaine vous l'aurez compris on va parler de ce qu'est un bon développeur, mais, pas de la manière dont vous l'imaginiez.

L'idée de cet article me vient des échanges que je peux avoir avec mes clients et de pourquoi ils apprécient travailler avec moi.

Cet article vient également du fait que, le week-end dernier, je regardais un peu l'état de l'infrastructure sur laquelle est hébergé ce site (et des clients), et qu’en deux ans il s'en est passé des choses 🤣.

Vous êtes prêts ? Alors, c'est parti.

Ce que cet article n'est pas

Afin d'éviter de faire perdre du temps à ceux qui ne sont pas intéressés, sur cet article il n'y aura pas de débat de "Quel est le meilleur tech ?" ou "Quel est le meilleur langage ?"
L'idée ici, c'est d'aller plus loin dans le métier de développeur, et, encore plus de développeur freelance.

Qu'est-ce que fait un développeur, réellement ?

Beaucoup voient le dev comme quelqu'un qui passe son temps à écrire du code, ce n'est pas tout à fait vrai.

La question est, pourquoi écrit-on ce code ?
Pour résoudre des problèmes, et pour répondre à des besoins.

Le code seul n'a absolument aucune utilité, le code est un outil qui permet d'atteindre des objectifs.

Certes, dans ma vie de développeur indépendant, je passe du temps à écrire du code, mais le moment où je me trouve le plus productif, c'est quand je suis perdu dans mes pensées à réfléchir à une situation à laquelle je suis confronté.

Cela m'est encore arrivé plusieurs fois, la semaine dernière, dans un projet sur lequel je travaille actuellement, l'expérience utilisateur n'était pas suffisamment satisfaisante à mon gout, j'ai mis le problème de côté et j'ai continué à avancer sur le projet... et puis j'ai été prendre l'air.

Plus tard en marchant comme j'ai souvent l'habitude de le faire, j'étais perdu dans mes pensées dans un parc bien connu de Nancy, au bou d'une dizaine de minutes de marche, la solution a mon problème d'interface m'est apparu comme ça... en réfléchissant.

En rentrant, j'ai donc éprouvé mon idée et écrit les quelques lignes de code pour la mettre en œuvre, ça se résumait à une 20aines de ligne de code (dans un contrôleur stimulus pour les connaisseurs).

Voilà, 30 lignes... mais ce n'est pas ces lignes qui ont de la valeur, c'est l'idée sous jasaient m'ayant permis de trouver la solution au problème qui a de la valeur.

(je vous reparle du projet en question dans un futur article, ça avance bien)

Comprendre son client et ses besoins

Pensez que son boulot est uniquement de "venir, coder un truc et repartir", est une erreur.
En fait dans le processus il y a tout un travail à comprendre son client, son univers et ses besoins, et il est même possible de découvrir des besoins qu'il ignore avoir.

Je m'explique, dans ma clientèle, il y a des petites et moyennes entreprises, des grands groupes ou encore des entrepreneurs qui se lancent dans une nouvelle aventure.

Ce paragraphe est un clin d'œil à ces derniers.

J'ai eu il y a quelque temps un projet, ou il était question de lancer un "nouveau média" (pareil, on en reparle plus tard) lors de nos échanges, je comprends bien de quoi il est question, mais je vois déjà plus loin.

À la base, le média était disponible en français et en anglais, sauf qu’en écrivant le CMS (basé sur Ludo Dev CMS) pour ce projet, il paraissait bon d'anticipé certaines choses comme le fait que ce comme toute entreprise, ce média évoluera avec le temps (une entreprise : soit elle croit, soit elle meure, il n'y a pas d'entre deux).

Du coup, le module linguistique a été pensé pour l'avenir, certes il supporte le français et l'anglais, mais il est déjà compatible avec toutes les langues, en fait il n'y a pas de limite technique, juste de fichiers de traduction à ajouter.

Enfin, sur ce même projet, malgré que le client voulait au départ 4 catégories bien définies. Il fallait aller à contre-pied et permettre autant de catégories que nécessaire, qu'il puisse ajouter autant de choses qui le souhaitait avec le temps.

Au début, c'était compliqué, car le client n'étant pas dans la tech, lui il voyait que les catégories sur le site de test étaient des "test 1", "test 2" ... etc.

Puis quand il a compris ce qui avait été fait, il a juste dit "Merci".

L'idée ici, c'est de comprendre les besoins de son client, mais aussi de lui proposer des choses et pour cela, il faut entrer dans son univers et ne pas se contenter de faire de "l'exécution".

L'utilisateur final n'est pas forcément qui vous pensez

En fait le client, c'est une chose, il croit avoir des besoins et croit savoir comment y répondre, mais, ce n'est pas toujours vrai.

Prenons par exemple l'e-commerce, beaucoup pensent qu'il suffit de mettre une boutique en ligne pour vendre et que leurs plus gros problèmes, c'est la technique.

Bon, si votre développeur n’est pas mauvais, la technique on s'en fiche un peu... 😛

Par contre pour vendre en ligne ce n'est pas si simple, il y a énormément de concurrence, il faut donc savoir se démarquer...

Et c'est encore une fois ici que le développeur peut avoir un rôle important, en effet, il faut imaginer les utilisateurs de la plateforme e-commerce que l'on est en train de créer, qui sont-ils ? Comment appréhendent-ils le web ?

L'idée pour un dev, ce n’est pas de se dire "oulah, pour ça je vais utiliser React", mais plutôt de se dire "Comment je peux leurs simplifier la vie le plus possible ?"

Faire des applications c'est bien... des applications utilisées par beaucoup de monde c'est mieux. Et si en plus les utilisateurs aiment utiliser l'application sur laquelle vous avez travaillé alors c'est le top. 😍

Le monde des développeurs et la vraie vie

Ce paragraphe me vient d'un tweet que j'ai vu passer :

"Les devs qui font pas de tests sont des débiles"
Cette phrase aurait été prononcée dans un espace de coworking.

En fait, dans le petit monde du dev, il y a une déconnexion avec la réalité.
L'idée est simple, une entreprise, sa vie et évolue, parfois ça a de grosses contraintes et parfois des urgences.

En arrivant sur un projet, on le retrouve "en l'état", mais on ne sait pas pourquoi certaines décisions ont été prises et pourquoi.

Prenons par exemple le cas d'une entreprise qui a très vite grandi, au début, il avait peu de moyens et donc il faisait avec les moyens du bord, avec le temps ils se sont développés, mais leurs bases techniques elle reste la même, hors, il faut répondre aux nouveaux besoins des clients.

Et réflectoriser l'ensemble du code, ça prend du temps, temps que l'entreprise n'a surement pas eu.

Pour les tests, c'est pareil, les "bonnes pratiques" de développement disent qu'il faut faire des tests.
Certes, sauf que ça, c'est souvent déconnecté du marché réel, un marché ça bouge et ça évolue en permanence.

Si on prend ce qui s'est passé en 2020, tout a été chamboulé en moins d'un mois... il a fallu s'adapter. Il n’est donc pas étonnant que les tests unitaires et fonctionnels n'ai pas été une priorité.

L'idée à comprendre ici est que : le dev, c'est une chose, vouloir faire les choses bien, c'est bien, mais parfois il faut prendre des raccourcis, car la situation l’exige.

Je ne compte plus le nombre de fois ou j'ai fais une modification "dans la view", sur une page produit plutôt que de coder proprement un système d'édition... bah oui, mais il fallait répondre au besoin dans l'instant. C'était très important pour le client.

Créer des solutions qui s'adaptent aux besoins et non l'inverse 

Ce paragraphe est simplement la suite des derniers mots du paragraphe précédent.
Parfois on peut penser qu’en tant que développeur que le monde doit s'adapter à nous, mais la réalité elle n'est pas là.

L'informatique, la création d'outils, c'est là pour répondre à des besoins du monde qui nous entoure, le code seul, ça ne sert à rien.

De ce fait, les outils que nous créons doivent être pensés avec en tête ce qu'il doit résoudre.

Personnellement, je fonctionne beaucoup comme ça, sur le projet sur lequel je travaille en ce moment avant même d'écrire la première ligne de code, j'avais une image claire de ce qu'il faut accomplir, en cours de progression, des opportunités sont apparues pour faire encore mieux, opportunité qui ont été saisies dans l'idée de rendre le produit final encore plus simple d'utilisation et donc utilisé et apprécié par ses utilisateurs.

Dans le même genre, il y a le cas de Twitter Bootstrap, qui se fait parfois critiquer par les développeurs de front, oui, mais il répond à un besoin, s’il ne servait à rien il ne serait pas aussi populaire 🙂.

Conclusion

Cet article va clairement à contre-courant de tous les articles sur "le meilleur stack", "le meilleur langage". L'idée ici, c'est de comprendre que ce soit en freelance avec des clients ou en salariat. Un client ou un employeur travaillera avec un développeur, car celui-ci apporte de de réelles réponses a ses besoins.
Le fait de simplement venir et écrire du code, cela fonctionne uniquement dans les très grosses boites.

Mais même dans ces grosses boites, si un développeur souhaite avoir un plan de carrière interne, alors il devra savoir s'adapter.

Passez une très bonne semaine 😁