8 habitudes de développeur(euse)s qui font progresser

En dehors du titre, le générique masculin est utilisé sans aucune discrimination et uniquement dans le but d'alléger le texte.

8 habitudes de développeur(euse)s qui font progresser

Avec le temps, j’ai fini par comprendre que ce qui comptait le plus dans ce métier, c’était les habitudes. Toutes ces petites décisions, ces façons de faire et de voir les choses. Ça a l’air de rien au jour le jour, mais mis bout à bout, c’est une putain de locomotive pour ta progression. OK vas-y on en parle.



Aller vers l’inconnu

Soyons honnêtes, j’ai pas toujours fait ça. J’étais plutôt dans la team : prendre la tâche pile taillée pour moi. La bonne techno qui va bien, la partie de l’app que je connais par cœur. Peinard ! Je savais exactement comment faire avant même de regarder. Et choisir la facilité, quand ça devient une habitude, ça devient dangereux.

Du jour au lendemain, j’ai décidé que j’allais faire le contraire. Dès que l’occasion se présenterait de faire un truc totalement inconnu, je me jetterai dessus comme un crevard sur un MacDo. Et la première fois que je l’ai finalement fait, c’était la catastrophe !





Le temps pour faire la tâche, je l’ai explosé. Il me semble que c’était une tâche estimée à un jour ou deux. J’ai tapé la semaine et demie LARGE ! Ma boite était en PLS, j’étais au bout du rouleau et le client faisait la gueule aussi. Mais il s’était passé un truc plus important que tout ça. Quelque chose qui me semblait impossible et hors de portée m’était devenu banal. Et ça, ça change tout.

Si tu prends l’habitude de te foutre dans des situations inconfortables en permanence, plus rien ne sera inconfortable. À force de sortir de ta zone de confort, tu vas l’étirer. Et faire ça fréquemment va petit à petit te faire progresser en permanence. Tu gagnes vraiment quand l’inconfortable devient ta nouvelle norme. Et c’est beaucoup plus simple que ça en a l’air.

Ce que je te conseille de faire tout de suite c’est de regarder la liste de tâche à faire dans ta boite. Prends celle avec un titre que tu comprends même pas. Et jette-toi là-dedans en mode saut de l’ange. Pour limiter les dégâts à l’atterrissage, discutons de comment gérer l’inconnu.



Prendre le temps de la compréhension

Ça, c’est pareil. Pendant longtemps, je me suis jeté sur tous les problèmes qu’on me donnait comme un sauvage et je codais direct. Le but c’était d’aller vite. Et quoi de plus rapide que de coder la solution tout de suite au lieu d’y réfléchir ?

Et je te comprends si tu fais ça aussi. On est poussé par des délais serrés et on est jugé sur notre vitesse. Mais c’est la pire habitude possible. Ça va vraiment te péter à la gueule tôt au tard. Pour éviter ça, à chaque fois, il te faut un plan.



plan


L’habitude que je te conseille est très simple. Ne fais aucune ligne de code tant que t’as pas une solution complète du problème. Alors attention, ça veut pas dire qu’il faut que tu rentres dans les détails et que tu fasses un roman.

Ça veut juste dire que tu sais au minimum où tu vas. Tu comprends, définis et résous le problème en amont. Tu investis du temps de compréhension ! La partie code ne sera plus que l’application d’un problème déjà résolu.

Ce que tu peux faire toute de suite pour commencer cette habitude et de faire des schémas pour tout. Avant de coder, papier/stylo, ou encore mieux whiteboard, et tu dessines ta solution. J’ai déjà évoqué ça dans l’article sur les compétences clefs des développeurs et c’est terriblement efficace !



Faire toujours au plus simple

Ça me fait toujours autant péter un plomb de tomber sur du code hyper complexe pour un besoin basique. On a cette habitude à tout complexifier quand on code. Il faut abstraire, découpler et surtout montrer qu’on sait faire des choses complexes. Encore une fois, c’est une habitude de merde.

Ce que je te conseille ici est un changement de mindset. Il faut que tu prennes l’habitude de te demander comment faire au plus simple en permanence. Découper la complexité, faire des classes avec moins de responsabilités, plus de fonctions, plus courtes qui font une seule chose. Tout faire pour rendre ce que tu fais hyper simple, hyper lisible. Toute ton équipe devrait instantanément comprendre ce qui se passe dans ton code !



habitudes


Tu peux appliquer ça hyper simplement dès aujourd’hui en faisant un effort conscient de simplifier tout ce que tu codes. Les avantages principaux de faire ça sont la maintenabilité et la compréhension plus rapide de ton code. Ça va te faire gagner du temps à toi et à toute ton équipe.



Être prudent avec les délais

J’ai dédié un article entier à ce sujet tellement c’est une source d’angoisse dans ton métier. Ton estimation de temps est une blague. Une bonne estimation est presque impossible à sortir et je le pense toujours.

Le problème c’est qu’il faut que tu en chies des estimations. Plein, en permanence. Comme la plupart des développeurs, tu as tendance à sous-évaluer ces délais. Ça te fout dans une merde pas possible. Tu te retrouves à devoir justifier en permanence pourquoi ton estimation était pourrie.



délai


Pour pallier à ça, j’ai mis en place deux habitudes. La première habitude c’est que je demande toujours plus d’informations. Plus de détails, plus de précision, plus de contexte, plus d’historique, pour qui, pourquoi, possible de simplifier, possible de livrer par étapes ? Ouais, je suis un gros relou. Mais la moindre information est critique et pourrait me sauver la vie.

La seconde habitude c’est que je ne donne jamais une estimation fixe. Toujours une fourchette, un min/max. Si je pense que ça va prendre deux jours, je dis que ça va prendre entre deux et quatre jours. Et si j’ai pas le choix de donner quelque chose de fixe, alors je dis quatre jours. Rien à foutre si c’est trop long, c’est mon estimation.

La prochaine fois que t’as une estimation à faire, je te conseille d’appliquer ça juste pour tester. On parie combien que tu vas en faire une habitude ?



Apprendre par étape

La première fois qu’on m’a présenté Git, on m’a dit que c’était la base pour tout développeur qui se respectait. Pas connaître absolument tout Git équivaut à jouer avec son caca. Ça m’a foutu la pression. Du coup j’ai lu absolument toute la doc en essayant de tout ingurgiter en quelques heures. Évidemment, le lendemain, je fixais le vide comme un débile après git status.

Je vois beaucoup de gens essayer de faire la même chose. Apprendre le plus de choses le plus rapidement possible. Il faut comprendre que ton cerveau lui, il en a rien foutre que tu veux aller vite. Ça sortira aussi vite que c’est rentré. Les gens ne veulent pas y croire, mais c’est vrai. Tu te transformes en poisson rouge quand tu reçois trop d’information trop rapidement. Tu peux courir autant que tu veux, t’oublieras tout.



habitudes


Du coup, comment faire pour apprendre beaucoup de choses alors ? Il suffit d’étudier par bout raisonnable, laisser du temps à ton cerveau d’imprimer l’information, et revenir dessus le jour d’après. Pour faire ça, tu peux appliquer dès aujourd’hui une habitude que j’ai pris il y a des années et qui a fait des miracles.

À chaque fois que j’entends un terme ou un concept que je ne comprends pas, je le note dans un google doc. Quand j’ai un peu de temps devant moi, j’ouvre ce google doc, je prends le premier ou les deux premiers termes/concepts, et je me renseigne à foison. Et c’est tout, j’arrête là, on verra un autre jour pour la suite. Faire de ça une habitude, tu te rends pas compte à quel point c’est redoutable sur le long terme. Et c’est sur le long terme qu’il faut investir ton temps. Le développement est un marathon, pas un sprint.

Une autre habitude que j’ai prise c’est de faire la même chose, mais avec des bouts de codes et des commandes. J’ai des longs snippets sur GitLab remplis de commandes compliquées et autres syntaxes chiantes à retenir. J’utilise tous les jours ces snippets et ça permet de me libérer la tête pour autre chose tout en restant efficace.



Prendre du recul

En début de carrière, très fréquemment, j’insultais mon ordinateur de vive voix en travaillant. Oui alors, sans contexte, c’est bizarre. Comme tous développeurs j’avais des bugs de l’espace dans mes applications. À force d’être bloqué sur une longue période, ma frustration montait tellement que je finissais par péter un plomb. Et c’est là que je commençais à insulter mon PC de vive voix. OK, même avec le contexte c’est bizarre.

La ténacité, la persévérance et la résilience face à un problème sont indispensables pour tous développeurs. Je suis sûr que t’as déjà pété un plomb devant ton PC. On l’a tous fait.

Le secret c’est de prendre du recul pour garder une approche logique et méthodique. La plupart du temps, quand tu pètes un plomb sur quelque chose, c’est que t’es tellement dedans que tu vois plus rien. En t’énervant, tu perds le focus qui te permet de réfléchir normalement.

Il faut que tu sortes la tête de tout ce caca et que tu abordes les choses froidement et méthodiquement. Tu peux mettre en pratique une première habitude très simple pour commencer.

La prochaine fois que tu sens que ça monte, au lieu de t’acharner jusqu’à implosion : lève-toi et va faire complètement autre chose. À chaque fois que je fais ça, je vais me faire café et/ou je vais faire chier un collègue. Quand je reviens à ma place mon cerveau est reset, j’ai pris du recul sur ce qui se passe et c’est tout de suite plus clair.



recul


Ensuite, ma seconde habitude et de réduire les paramètres et le contexte du problème à un niveau extrême. De façon méthodique, j’enlève la complexité de mon problème pour arriver dans un contexte simple et qui fonctionne. Enfin, je remets les paramètres un a un jusqu’à que ça plante. Quand ça plante, j’ai trouvé le coupable, je fixe le bug et j’ai insulté personne.



Créer des tunnels de concentration

J’entends souvent que pour être un développeur efficace il faut savoir se concentrer NON-STOP sur un sujet pendant plusieurs heures. Je te le dis tout de suite : c’est impossible. Si t’arrives à tenir 25 minutes sur un seul sujet en particulier sans flancher, déjà c’est incroyable. À mon sens, c’est donc plus efficace de créer des tunnels de concentration (20 à 30 min) et de s’accorder des pauses entre chaque tunnel.

J’ai mis en place plusieurs habitudes avec le temps pour faire ça. La première habitude que j’ai mise en place est le Pomodoro. Concrètement je mets un timer de 25 minutes et je bosse sans pause et sans interruption durant ce temps. À la fin du timer, je prends 5 minutes de pause, peu importe où j’en suis. J’en ai déjà parlé plusieurs fois en détail sur ce blog tellement ça m’aide, notamment dans l’article sur les compétences clefs des développeurs. Tu deviens absolument imperturbable pendant les tunnels et ça change tout.



habitudes


Une autre habitude super simple que tu peux mettre en pratique tout de suite : la prochaine fois que tu veux te concentrer, retourne ton portable ou mets-le à un endroit où tu peux pas le voir. Tu te rends pas compte à quel point les notifications sur ton portable te parasite le cerveau. Sérieusement, essaye juste une journée pour voir, c’est incroyable.



Contrôler son ego

Enfin, je suis obligé de finir sur l’ego. L’incroyable ego des développeurs est bien réel. Si je t’en ai dédié un article entier, c’est qu’il y’avait matière à discuter.

Le principal problème d’un développeur qui déborde d’ego c’est qu’il n’a aucune marge de progression. Si tu contrôles pas ton ego, tu estimeras que tu n’as plus rien à apprendre. Si t’apprends plus rien, tu ne progresses plus. Si tu ne progresses plus, tu régresses. Et crois-moi, c’est pas ça que tu veux en tant que développeur.

Et puis, au-delà de ta progression, si t’es vraiment rempli d’ego t’es surtout un connard. Tu fais chier les autres et personne n’a envie de travailler avec toi. Ça aussi c’est pas top pour ta carrière. La bonne nouvelle c’est que cet ego surdimensionné, tu peux facilement le contrôler.

L’habitude hyper facile à pratiquer rejoint énormément ce que je te conseille dans le premier point. Sors de ta zone de confort et échoue. Rien de mieux qu’un bon cassage de gueule pour remettre les idées en place et repartir de plus belle sur ta progression personnelle.



Épilogue

Ça fait beaucoup d’habitude à prendre d’un coup, mais crois-moi ça vaut le coup. J’ai lu un bouquin qui donnait justement des solutions pour absorber des bonnes habitudes. Le secret c’est d’y aller doucement par étapes en appliquant une partie de l’habitude un peu chaque jour. Ça s’appelle Atomic Habit, ça m’a énormément aidé, je te le conseille fortement ! Je vais avoir d’autres habitudes pour toi dans un prochain article sur le même sujet dans le futur. En attendant, tu peux commencer doucement en appliquant certaines habitudes. Je te promets que ça paye sur le long terme.

Qui me parle ?

jesuisundev
Je suis un dev. En ce moment je suis Backend Développeur / DevOps à Montréal. Le dev est l'une de mes passions et j'écris comme je parle. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cet e-mail ou le faire directement dans les commentaires juste en dessous. Y'a même une newsletter !

31 commentaires sur “8 habitudes de développeur(euse)s qui font progresser”

  1. Super article et complètement d’accord avec toi.
    Je vais essayer d’appliquer certains de tes conseils que je n’applique pas actuellement :).

  2. Aller vers l’inconnu, c’est toujours terrifiant. J’y vais plus ou moins régulièrement.
    Mais au-delà de l’habitude, se rendre compte qu’on est capable de terminer des projets dont on ne semblait rien comprendre est extrêmement motivant et bon pour la confiance.

    Avant j’avais surtout peur de ralentir mes collègues quand on me collait sur une techno ou un projet que je ne maîtrisais pas. Maintenant, je sais qu’ils sont bienveillants et qu’ils n’hésitent pas à m’apporter leur savoir. Oui, je suis plus lent que les autres et sans doute que me mettre sur ces sujets en pleine urgence n’est pas une bonne idée mais je glane ici et là des compétences et j’avance à mon rythme.

    J’ai aussi la (mal ?)chance d’avoir une copine très (trop ?) bavarde par téléphone. Je perds un temps fou à lire mes notifications. Pour elle c’était impensable qu’on ne s’écrive pas, pour moi ça devenait impossible qu’on continue comme ça. Ma productivité en prenait un sacré coup. Alors on a mis en place des règles : je ne lis et ne réponds qu’à des moments précis de la journée. Elle ne l’a pas très bien pris au début mais finalement, en essayant nos échanges sont devenus plus intéressants (le temps que je lui accorde étant limité, elle occupe au mieux ce temps pour que ce soit pertinent) et même elle, elle est d’accord pour dire qu’aujourd’hui sa productivité à elle est meilleure et qu’elle arrive mieux à se concentrer.

  3. Très bon article qui arrive à point nommé, et qui me conforte dans mon choix.

    Actuellement je suis en reconversion professionnelle, et avec mon école on va devoir choisir une spécialisation entre React, WordPress et Synfony. J’adore Php, et à terme je voudrai me lancer en Freelance donc Synfo ou WP semblaient plus indiqués, mais j’ai du mal à maîtriser JS donc je penche depuis plusieurs mois pour prendre React.

    Choix que beaucoup de mes camarades de Promo ne comprennent pas, mais je préfère travailler sur mes faiblesses que sur mes forces.

    Cet article me conforte dans mon choix de maîtriser React avant de m’intéresser à Synfony, il arrive à point nommé.

    Merci beaucoup, et au plaisir de lire ton prochain article.

    1. C’est toujours dur ces décisions. Surtout quand on arrive à avancer sur une autre technologie. Mais sur le long terme ca paye 🙂

  4. “En dehors du titre, le générique masculin est utilisé sans aucune discrimination et uniquement dans le but d’alléger le texte. ” -> Bah ouais ça s’appelle parler français en fait…

  5. Petit point de vue d’un dev à son compte 🙂
    Sortir de sa zone de confort et s’attaquer à des projets complexes sur des technos qu’on ne maîtrise pas, c’est assez flippant en effet, surtout qu’on peut avoir la pression du regard de ses collègues qui entre en jeu en plus… Le fameux ego 🙂
    Mais sortir de sa zone de confort quand on est à son compte, avec tous les risques et les responsabilités que ça implique, là ça peut devenir totalement terrifiant ! Par contre, une fois le projet fini, non seulement on gagne en confiance et en expérience, mais en plus on s’ouvre de nouveaux marchés… Belle récompense !
    Être prudent avec les délais, c’est parfois très compliqué quand on est tout seul en frontal avec le client et qu’il met la pression, mais c’est un conseil encore plus important (je me plante sans arrêt là-dessus et c’est épuisant à la longue).
    Et pour les tunnels de concentration, difficile également quand on s’occupe du commercial, de la maintenance, de la gestion de projet et du dev… Un équilibre à trouver vraiment pas évident !
    Merci pour tes articles en tous cas, toujours sympa à lire !

    1. Je pense qu’en effet, ça dépend grandement des situations.
      Ça peut être compliqué d’appliquer 100% de ces conseils selon sa situation. Mais c’est toujours bon de les avoir en tête !

  6. Bon article et très pertinent comme à ton habitude !

    Mais tu as oublié une habitude importante selon moi : le café chez le développeur 😄. Faut pas l’oublier cette habitude là.

    D’ailleurs ma cafetière m’appelle, alors j’y vais !

  7. Perso, sur la partie “prendre le temps de la compréhension”, pour moi commencer à coder fait partie de cette étape. Un raisonnement dans le vide peut vite partir en n’importe quoi, parce qu’on n’avait pas vu quelque chose. Alors qu’un POC avec un bout de code aide franchement à concrétiser la réflexion. Après c’est aussi ma façon de fonctionner, certains vont préférer bien réfléchir en amont avant de faire quoi que ce soit.
    Par contre, faut pas confondre “coder dans le processus de réflexion” et “tout faire”. Je code un concept général, je vois que ça marche, et là en général je recode tout pour avoir quelque chose de propre.

    1. Alors on est un peu différent la dessus. Perso j’ai vraiment besoin de mettre ça sur papier rapidement avant. Des gros dessins pour être sur de ce que je fait.

      Et en effet, quand le temps le permet, y’a souvent un POC rapide après.

      Rien à voir mais merci Yoda pour tous tes commentaires 🙂

      1. C’est peut-être parce qu’au contraire de beaucoup de gens, je fonctionne beaucoup plus avec les mots qu’avec le visuel.

        Merci pour tous tes articles, commenter est tellement plus facile que se lancer devant un champ de saisie blanc.

  8. Hello Mehdi!
    Très sympa ton article, merci !

    À propos du tunnel de concentration, je t’invite à voir un super projet qui propose un pomodoro plutôt intelligent : https://tempus.keziahmoselle.fr/
    Il te permet facilement de configurer tes périodes de concentration, mais aussi, si tu approches d’une heure spécifique, de lancer un timer jusqu’à la prochaine heure. De quoi te lancer dans un ultime sprint avant la pause ! Très ingénieux !

  9. Salut !

    J’apprécie énormément ton blog, découvert grâce à Micode 😙

    Super article, tes conseils sont vraiment pertinents et c’est super cool en plus tu donnes des livres enfin bref, grand merci et force à toi !

  10. C’est vrai j’ai le droit de t’insulter dans les coms ? 🥺👉👈
    Tes propos sont si pertinents qu’une envie incontrôlable m’en vient !

T'en penses quoi ?

Your email address will not be published. Required fields are marked *