Compétences clefs pour développeurs

Les compétences clefs pour tous développeurs ne sont pas une liste sans fin de langages et de technologies. Je vois partout ces espèces de check lists interminables à la con. On t’explique que tu es censé tout maîtriser sinon t’es la pire des merdes. C’est faux. Aujourd’hui je vais te parler de ce dont tu as vraiment besoin.

Résolution de problème

Je t’en parle tout de suite car c’est central dans ton métier. Résoudre des problèmes c’est ton activité principale et donc ta principale compétence clef. Si tu deviens bon là-dedans tu vas commencer à léviter dans l’open space et rien ne pourra t’arrêter. Et pour commencer à léviter de façon permanente il te faut juste y aller par étape.

Quand on te jette un problème au visage, il faut que tu commences par le comprendre parfaitement. Le premier truc que tu peux faire tout de suite c’est de le formuler. Si t’arrives pas à faire une phrase qui fait du sens et sans hésitation, déjà on est mal. Tu peux pas trouver une solution si tu ne comprends pas parfaitement ton problème. Hé non, c’est pas si évident pour tout le monde. Le nombre de devs que j’ai vu copier/coller solution après solution depuis stackoverflow en faisant des prières pour qu’il y en ait une qui finisse par passer est hallucinant. Au lieu de miser sur la chance, prends le temps de la compréhension. Une fois que tu as compris ton problème, il est temps de le boxer dans les côtes.

Il te faut un plan. Si tu te lances la tête la première dans le code sans aucune réflexion c’est débile et à part perdre du temps et t’arracher les cheveux tu vas rien faire. Ce que tu peux faire facilement c’est prendre une feuille, un stylo et faire un schéma rapide de la solution que tu imagines. Je fais ça tout le temps et pour tout. Je fais un dessin et je vois tout de suite si c’est débile ou pas. C’est surprenant le temps que tu peux gagner en faisant quelque chose d’aussi simple que de mettre tes pensées sur un papier. Car les failles dans ta réflexion deviennent évidentes. Des fois je montre mes dessins à mes collègues aussi. Ils me répondent par un pouce ou un doigt d’honneur et je suis fixé sur la viabilité de ma solution.

Maintenant que tu es prêt à coder, il faut que tu découpes la complexité de ta solution en petits morceaux. La meilleure façon de résoudre un problème compliqué et de le découper en problèmes simples. Je t’en avais déjà parlé dans l’article pour les juniors tellement c’est essentiel. Ce que tu peux faire tout de suite c’est prendre la première étape de ton problème et en faire une fonction séparée. Résous cette première étape sans sortir du scope de la fonction. C’est facile ? C’est normal c’était juste un petit problème. Recommence sur toutes les étapes et BOOM t’as gagné.

Avec ces trois étapes, je viens à bout de tous les problèmes qu’on m’envoie à la gueule. Sûr et certain que tu peux faire pareil. Ça te semble trop simple pour être vrai ? T’as raison. En fait pour que ces trois étapes soient efficaces il te manque des choses. Il te manque de la méthodologie, du savoir et le bon état d’esprit. Hey mais ça tombe bien on va parler de tout ça, c’est bien foutu cet article c’est incroyable.

Insiste sur ta méthodologie

La première technique que tu peux appliquer quand t’essayes de résoudre un problème est très simple. Ça vient de la programmation par intention et c’est d’une efficacité redoutable. Concrètement, imagine-toi que tu es dans un monde parfait où à chaque fois que t’écris le nom d’une fonction elle est automatiquement créée quelque part. Ce petit shift dans la tête permet de faire du code non pas par contrainte, mais par intention. Tu codes un algorithme parfait et tu feras les fonctions qui n’existent pas encore plus tard. Ça rend le code simple, lisible et surtout ça te permet de te concentrer sur la manière optimale de résoudre un problème complexe avec un algorithme simple. Évidemment pour faire ça proprement il faut que tu gardes toujours en tête des principes de programmation basique.

KISS, DRY, YAGNI sont les plus connues et les plus efficaces. Si tu les découvres, applique les immédiatement sinon tu vas te faire découper en code review. Si tu les connais déjà, je tiens à te rappeler l’idée principale derrière tous ces principes que beaucoup de développeurs ont l’air d’oublier. Personne ne te respecte parce que ton code est compliqué. En fait tout le monde te déteste quand ton code est compliqué. Faire du code simple est une compétence clef à tous développeurs. Le plus compliqué est de faire du code simple. Ton code est simple quand on peut le comprendre vite et donc le modifier simplement. La meilleur ressource sur ce sujet reste cette bible indémodable que je te conseille fortement ! En respectant toujours les bonnes pratiques ton code ne devient pas une usine à gaz et personne te maudit.

Design pattern

Autre chose côté méthodologie il te faut à tout prix comprendre et savoir utiliser les design patterns les plus fréquents. Les design patterns (ou patron de conception) sont des solutions reconnues comme bonnes pratiques pour des problèmes logiciels récurrents. Maîtriser les design patterns est une compétence clef à tous développeurs. Si tu les connais pas, sache qu’il est fort possible que tu les utilises déjà sans le savoir.

Exemple : imaginons que tu veux qu’une seule instance de ton cache ou de ta base de données soit faite et utilisée dans toute ton application. Tu peux soit essayer de te prendre la tête avec un algorithme compliqué qui va marcher à moitié ou bien tu peux tout simplement appliquer le design pattern singleton. Des design patterns qui résolvent énormément de problèmes il y en a beaucoup. Pour les apprendre correctement j’avais lu ce bouquin à l’époque. Ceux que j’utilise le plus fréquemment sont adapter, factory et decorator. Je te conseille de commencer par ceux-là. Évidemment au besoin hein ? Ne commence pas à mettre des design patterns parce que c’est cool de mettre des design patterns.

Teste ton code

Enfin tu dois obligatoirement intégrer les tests dans ta méthodologie. Savoir tester soi-même son code est une compétence clef à tous développeurs. Ça te donne confiance en ton code et donc en tes capacité à produire de la qualité. Et si j’entends encore quelqu’un dire que tester ça fait perde du temps je lui fais avaler son clavier.

Tester c’est obligatoire pour assurer un minimum de qualité, mais surtout ça va te faire gagner un temps de fou de développement. Pendant et après le développement de ton app tu vas y injecter constamment des changements et des nouvelles features. Si t’as pas un moyen de valider automatiquement en une commande que tout ce que tu as fait avant marche toujours tu vas perdre un temps fou en test manuel. Tu vas laisser passer des régressions à chaque mise à jour. Ton application ne va pas être stable et la confiance que les gens vont accorder à ton travail va régresser aussi. Teste ton code, partout, tout le temps. Aucune excuse.

Continue à apprendre

Je vais pas revenir sur le faite qu’être en apprentissage constant soit une question de vie ou de mort. Oui l’autoformation est une compétence clef à tous développeurs, j’ai l’impression de le répéter dans tous les articles c’est effrayant. Par contre aujourd’hui je vais te dire comment s’autoformer efficacement.

C’est simple pour savoir plus de choses il faut y accorder plus de temps. Mais pas tout ton temps. Pour pas y passer ta vie, il faut faire ce qu’on appelle de la veille. Comment faire de la veille tu vas me dire ? Très simple : tout est expliqué dans ce fabuleux article. Tu auras les principaux curateurs de news francophones et anglophones sans oublier les blogs de développeurs Français. Avec tout ça tu as tout ce qu’il te faut pour tout savoir.

Le but n’est pas de tout apprendre et de tout maîtriser. Déjà tu n’y arriveras pas, car il y a trop de choses. Personne ne sait tout, à part les menteurs et les gens qui pètent plus haut que leur cul. La nuance c’est qu’il faut tout comprendre au lieu de tout apprendre. C’est pour ça que plein de mes articles commencent par le mot comprendre. Car ce qui est important dans ton métier c’est d’avoir une expertise sur ta stack et une vision globale sur les autres.

Ne fait pas l’impasse Regex

Je crois que les regex sont autant détestés qu’aimés. Je vois beaucoup de développeurs leur vouer carrément un culte pendant que les autres les vomissent comme pas possible. Que tu les aimes ou pas, peu importe. Les regex sont une compétence clef pour tous développeurs. On les sous-estime ÉNORMÉMENT ! Personnellement je les utilise pour simplifier mon code. Investir dans une REGEX qui valide parfaitement tes paramètres d’API ou l’input d’une fonction va te sauver énormément de complexité dans ton code.

Mais voilà, la regex c’est pas sexy. C’est le bordel à appréhender et peu de monde à envie de les apprendre par cœur. Je vais te donner une tactique simple pour produire n’importe quel REGEX facilement. C’est ce que je fais à chaque fois que je dois en faire une et à chaque fois j’ai l’impression d’être intelligent. Étape 1 : je commence par trouver une bonne cheatsheet de regex, car je les connais pas par cœur. Ça me tente toujours pas de tout apprendre par cœur. Étape 2 : je vais sur regex101 et je rentre des exemples de string que je veux valider. Ensuite j’itère hyper rapidement en m’aidant de la cheatsheet et en testant en temps réel avec Regex101. Copier/coller essai/erreur avec en plus l’aide de regex101 sur le côté droit, c’est ultra efficace et super rapide. Aucune regex ne te fera plus jamais peur avec cette technique.

Travaille ta concentration

J’en parlais dans l’article des inconvénients du métier, ton travail demande un niveau absurde de concentration. Maintenir une bonne concentration est une compétence clef à tous développeurs. Et ça pour une raison simple. Tu produis des algorithmes qui eux même discutent avec d’autres algorithmes eux-mêmes alimentés par des bases de données etc etc puissance infinie. Pour arriver à tout faire fonctionner, sans que ça te pète à la gueule, il faut que tu penses à toutes ces choses en même temps. Et pour faire ça, une bonne concentration est obligatoire. Il faut donc que tu trouves des moyens d’entraîner cette concentration.

Au boulot la technique principale que j’utilise tous les jours est la technique pomodoro. Le principe est simple : tu lances un compteur de 25 minutes en utilisant ce genre de site ou en prenant un vrai minuteur. Pendant ces 25 minutes tu focus sur une seule tache et AUCUNE distraction n’est possible. À la fin des 25 minutes, que tu aies fini ou pas, tu dois arrêter de bosser et faire autre chose pendant 5 à 10 minutes. Pas lié au boulot, c’est ton moment de détente, genre tirer au nerf sur un collègue. Et puis tu recommences.

C’est beaucoup plus compliqué que ça en a l’air. C’est super dur de focus sur une seule tache et rien faire d’autre pendant 25 minutes. Vraiment. Je te conseille de commencer par faire un ou deux pomodoros dans la journée. C’est déjà beaucoup au début. Si t’arrives à faire ça tu vas halluciner à quel point c’est efficace. C’est fou ce qu’on peut produire juste en se concentrant vraiment sur quelque chose. Encore une fois c’est extrêmement sous-estimé. Je te conseille également de retourner ton portable pour ne pas voir ton écran et ces milliards de notifications. Enfin je te conseille de mettre ton casque et d’écouter de la musique que tu aimes, si possible sans paroles pour maximiser la concentration.

En dehors du travail c’est encore plus dur de se concentrer, car les tentations sont plus fortes. Ma technique dans ce cas-là c’est justement d’aller faire joujou avec ce que je veux faire avant de dev ou d’écrire un article. Je vais te donner un exemple concret. Quand j’ai commencé à écrire cet article, Borderlands 3 est sorti. Je suis fan. J’ai tout arrêté et je suis allé poncer le jeu. Maintenant que je l’ai poncé, plus rien ne m’empêche d’écrire. C’est bon je suis content j’ai eu mon fun. Je suis pas entrain de penser à mon loot mais à comment t’aider du maximum que je peux. Et ça permet de maintenir ma concentration pour faire les choses du mieux possible.

Savoir gérer les gens

Je sais que ça semble évidemment, mais ça ne l’est pas pour tout le monde. Les devs ont énormément cette réputation d’asociale. Je viens de te conseiller de mettre ton casque et te parler à personne donc ça doit venir de là j’imagine. Mais quand tu n’es pas en mode concentration, il faut que tu parles à des gens. Savoir communiquer, notamment avec d’autres développeurs, est une compétence clef à tous développeurs. Car l’application que tu fais, tu la fais pas tout seul. Si t’es pas capable d’expliquer ce que tu as fait ou de demander ce qu’on fait les autres, ça va être le chaos ton truc.

Très important aussi : adapte ton langage par rapport à la personne devant toi. Combien de dev j’ai vu parler POO avancée pour expliquer un choix à un chef de projet. Le chef de projet en PLS qui comprend rien à ce qui se passe et qui regarde autour de lui pour trouver de l’aide. Si tu fais ça, tu vas être rangé dans la case « personne incompréhensible ». Et crois-moi tu veux pas ça. Personne ne veut parler à un extraterrestre. Et les développeurs qui ne savent pas bien communiquer sont extrêmement pénalisés dans leur évolution en entreprise.

Moins drôle maintenant. Beaucoup de développeurs sont exposés au burnout. Le burnout arrive quand un projet se passe mal pour x raisons et que le développeur en question est surinvesti sur ce projet. Ce sujet mérite un article à part entière. Je le ferai dans le futur. En attendant ce que je te conseille, c’est de prendre de la distance humainement par rapport à un projet catastrophique. Dans une telle situation, tu dois te concentrer sur la solution technique et éviter tous conflits humains. Savoir se concentrer sur son travail même dans une situation de stress est une compétence clef à tous développeurs. Car sinon tu vas rentrer dans le triangle de l’enfer victime, agresseur, sauveur. Tu veux pas ça.

Cocadmin explique ça beaucoup mieux que moi et je te laisse checker sa vidéo. Ça peut vraiment t’aider à gérer tous tes futurs drames humains au boulot.

Soit fainéant

Les meilleurs développeurs sont les développeurs les plus fainéants. Un développeur fainéant va utiliser des librairies toutes faites et robustes au lieu de réinventer la roue et refaire des choses déjà faites. Quand une tâche devient quotidienne, le développeur fainéant refuse de la refaire manuellement tous les jours. Il va l’automatiser dans un script pour gagner du temps. Il va filer le script à tous ces collègues pour faire gagner du temps à tout le monde. Un développeur fainéant va faire enlever les features inutiles pour bosser seulement sur celles qui apportent de la valeur. Et par la même occasion, simplifier l’application et faire gagner du temps à tout le monde.

Un développeur fainéant va écrire le moins de code possible pour faire son application. Il va faire du code plus optimisé et plus concis pour en avoir moins à taper. Tu ne verras jamais un développeur fainéant faire des copier-coller de données d’un fichier à un autre. Il va faire un petit script en bash/node ou python pour le faire. Ce qui sera plus rapide et évitera les nombreuses erreurs humaines. Tu ne verras jamais un développeur fainéant tester son app à la main, car c’est une tâche répétitive. Bref tu vois ce que je veux dire. Adopte un mindset de fainéant et tu deviendras plus productif. Et non, cette phrase n’est pas contradictoire.

Épilogue

Si tu appliques tout ce que tu viens de lire avec rigueur, tu vas être inarrêtable. Et oui, je te parle de rigueur, car sans ça tout le reste est inutile. Évidemment il manque plein de choses. Mais au lieu de te faire un article de trois kilomètres (c’est déjà le cas) je vais plutôt t’en faire plusieurs. Compte sur moi pour te sortir ça assez vite. En attendant, tu peux me laisser tes compétences clefs en commentaires. Sûrement que je te les volerai pour la suite des articles.