Quel langage apprendre en 2023 ?
10 janvier 2023 —« Quel langage me conseilles-tu d’apprendre ? »
Cette question revient à maintes reprises en début d’année et je lis souvent : « PHP », « Java », « Rust », « Haskell »…
Et je suis déçu.
Oui, ces langages de programmation ont une certaine importance…
Mais ce ne sont plus mon premier conseil.
Mon conseil ? Apprenez le français ! Ou, plutôt, apprenez à mieux utiliser la langue avec laquelle vous communiquez, la langue avec laquelle vous travaillez1 – l’anglais, peut-être.
En effet, nos métiers exigent que nous communiquions.
Nous discutons sur Slack2, nous écrivons et lisons de la documentation, nous rédigeons des RFCs et des ADRs, nous découvrons ou redécouvrons ces documents des mois ou des années après… Une compréhension difficile ou erronée aura un impact négatif sur notre activité.
Souvent, bien trop souvent, j’essaye de lire un texte3 et j’ai du mal à le comprendre. Je ne parviens donc pas à suivre ni à appliquer — ou, du moins, pas sans douleur, sans erreurs, ni sans perdre de temps !
Parfois, le document auquel je fais face est blindé de fautes. Ça arrive beaucoup sur des textes dont l’auteur n’écrivait pas dans sa langue natale. C’est souvent le cas quand une entreprise impose une langue de travail sans former suffisamment ses employés.
D’autres fois, c’est parce que la structure même du texte est un bordel incroyable :-/. Et c’est presque plus grave, puisque la compréhension peut en souffrir encore plus.
Quand on écrit un programme, on l’exécute et on voit s’il fonctionne. Peut-être même, pour une classe ou une méthode, on écrit des tests automatisés. Cette pratique est entrée dans les mœurs de beaucoup de développeurs et développeuses, et c’est une bonne chose. Par contre, un écrit textuel, savoir s’il « fonctionne », s’il est compréhensible par quelqu’un d’autre, c’est plus difficile…
Oh, et j’allais oublier : alors que beaucoup souhaitent télétravailler plusieurs jours par semaine, nous communiquons de plus en plus par écrit. Et lorsque cette communication est asynchrone4, chaque « je ne comprends pas ce que tu as écrit » coute jusqu’à plusieurs heures de délai !
Alors, oui, bien sûr, c’est du travail 💪
Si vous passez 25 h par semaine à coder5, ça fait plus de 1000 heures par an. Réussir à en passer ne serait-ce que 10 % sur de l’écriture semble beaucoup. Et pourtant, 100 h de pratique par an, ce n’est pas énorme6 !
Cela dit, apprendre quelques éléments théoriques et faire un petit effort à chaque texte, ça finit par payer ;-)
Par exemple ? Commencer par définir son public, puis le garder à l’esprit, ainsi que ce qu’il connait ou non, tout au long du processus de création et d’écriture. Fixer son message avant de commencer à écrire et vérifier régulièrement que notre texte est fidèle à cet objectif. Passer un coup de correcteur d’orthographe et de grammaire avant de publier.
Ce ne sont pas des principes révolutionnaires, mais ils amélioreront grandement la qualité et l’utilité de vos écrits !
Ce conseil, apprendre le français ou l’anglais, s’applique-t-il à tout le monde ?
En partie, oui, je n’en doute pas.
J’admets que pour certains rôles, je devrais être moins affirmatif. En particulier, pour des personnes qui commenceraient leur vie professionnelle ou débuteraient en programmation, bien connaitre un langage et son écosystème est peut-être plus important ?
Cela dit, plus on gagne en séniorité, plus savoir communiquer est nécessaire. Quelqu’un qui a du mal à communiquer après cinq ou dix ans d’expérience va souvent voir sa progression ralentir ! Et, même junior, vous aurez du mal à évoluer dans votre équipe et dans votre entreprise sans communiquer !
Pour finir, comme je sais que certains et certaines d’entre vous ont tout de même envie de me demander quel langage de programmation je conseillerais…
Ces jours-ci, je pointerais vers Go ou Rust (back / infra / outils), Python (data), Javascript ou Typescript (front / back) — et le principe d’Infrastructure as Code (pour tout le monde). Bien sûr, mon job, son contexte et ma vision ont leur influence et ces recommandations ne sont peut-être pas adaptées à votre situation !
Illustration par Drew Beamer sur Unsplash
-
Votre langue officielle de travail ? Dans nos métiers, souvent l’anglais, d’après quelques expériences passées. Et beaucoup d’entreprises (et de développeurs) considèrent que « tout le monde parle / écrit anglais », oubliant que non, en fait. Ou pas si bien qu’on voudrait le croire. ↩︎
-
Nous discutons même probablement trop sur Slack, mais c’est un autre débat, pour un autre jour et un autre article… ↩︎
-
Comme vous, j’ai de nombreux types de textes à lire pour exercer mon métier : documentations, articles de blogs, mails, ou même User-Stories… ↩︎
-
Notez que la communication peut être asynchrone aussi dans des entreprises où le télétravail n’est pas la norme : il suffit d’échanger avec des clients, souvent externes, ou une personne localisée sur un autre étage ou dans un autre bâtiment… Ou, tout simplement, de ne pas avoir l’habitude, souvent nuisible, d’interrompre ses collègues dès qu’on a une question. ↩︎
-
25 h par semaine, c’est plus de 2/3 de votre temps si vous êtes aux 35 heures. Si vous retirez les moments de réunions, de pauses, de discussions (utiles ou non, directement liées au travail ou non), d’architecture, de revues… Je doute que vous codiez plus de 25 h par semaine. Faites le calcul, vous êtes sans doute même en dessous ! ↩︎
-
100 h de pratique par an, c’est très peu. Encore plus si on fait confiance à celles et ceux qui considèrent qu’il faut 10 000 heures de pratique avant d’être expert ou experte dans un domaine ! ↩︎
