Vous ne pouvez pas être développeur sans savoir coder, c'est certain, mais à mon humble avis : ce n'est pas ça qui fera de vous un·e bon·ne développeur·euse… Je vous explique comment devenir un·e bon·ne dev à mon avis !

Première étape : apprendre à coder

Évidemment : devenir développeur passe par l'apprentissage du code. C'est le premier truc à apprendre, on ne peut pas être développeur sans savoir coder !

Par contre ce n'est que la partie technique du métier : tout le monde peut l'apprendre ! Tout le monde n'a pas forcément l'envie et/ou le temps d'apprendre cette technique, mais ce n'est qu'une technique, on l'apprend en répétant le geste comme le calcul, le bricolage ou la cuisine. Vous remarquerez que je n'ai pas cité de métier, mais bien des techniques, en effet je fais partie des gens qui aiment cuisiner et qui cuisinent plutôt bien, mais par contre je n'en suis pas cuisinier pour autant, ça demande d'autres compétences que juste "je sais couper, assembler et cuir des aliments".

De plus, vous avez sûrement vu que le métier évolue assez vite techniquement parlant. Typiquement l'IA (en particulier l'IA générative) commence à montrer que le code devient de moins en moins LE point : si aujourd'hui il vaut mieux avoir de bonne connaissance pour décortiquer le code générer et s'assurer qu'on a bien ce qu'on veut, il faut être honnête, l'IA s'améliore de jour en jour, on passera sans doute à l'avenir de plus en plus de temps à relire du code généré par IA plutôt qu'à écrire du code (de la même façon qu'on passe aujourd'hui une grosse partie du temps à choisir dans les propositions d'autocomplétion qu'à coder stricto-sensu).

Seconde étape : apprendre des autres, tous les jours

C'est le cas de beaucoup de métier, il y a beaucoup de chose à savoir, comprendre, apprendre. C'est en partie grâce aux autres qu'on va le faire et monter d'un cran !

Je le dis souvent, mais soyez curieux ! Faites de la veille, intéressez-vous à ce que les autres font, n'y passez pas vos soirées et/ou vos week-ends, mais prenez du temps pour ça. J'ai toujours pour principe de dire qu'on apprend essentiellement des autres, et ce n'est pas qu'une question d'expérience, j’apprends aussi très souvent de gens plus jeunes que moi (aussi bien en âge qu'en expérience) !

Dans la même logique, il faut aussi apprendre à se tromper. On va forcément se tromper, louper quelque chose, etc. Il faut apprendre à laisser les autres nous corriger !  Je ne dis pas qu'il faut attendre que les autres nous corrigent (qu'on soit bien clair !), mais plutôt que c'est normal que les autres nous corrigent, le but c'est qu'on avance, éviter les erreurs, apprendre des choses, peu importe qu'on ce soit trompé, ce n'est pas ça le point important !

Troisième étape : changer de mindset

Le métier de dev, comme j'aime à le dire très souvent, c'est résoudre des problèmes. Que ce soit des gros problèmes métiers, que ce soit des petits éléments techniques ou même des trucs très bêtes. En tout cas il faut aimer ça. C'est quelque chose qui pour moi s'apprend.

C'est une démarche qu'il faut incruster dans notre manière de penser : voir un problème, émettre des hypothèses, faire des essais puis choisir/trouver la solution. En sachant qu'on peut boucler assez longtemps sur la partie hypothèses et essais, et que cette boucle peut mettre en lumière d'autres problèmes…

C'est très frustrant comme métier. Il faut apprendre à composer chaque jour avec la frustration des petits trucs idiots, de la phrase manquante dans la documentation, du cas particulier pas pris en compte, du collègue qui a fait un truc pas logique de notre point de vue, etc.

C'est sur ces aspects-là qu'on voit aussi que c'est un métier très humain ! On a souvent l'image qu'un·e dev interagit surtout avec la machine, mais ce n'est plus si vrai que ça, c'est beaucoup de problème humain qu'on retrouve !

Quatrième étape : partager ce qu'on sait

Partager c'est important ! Je ne serais pas là à écrire si je n'en étais pas convaincu ! 😉

Je peux parler d'expérience, clairement partager ça m'aide à prendre du recul. J'apprends beaucoup à travers les moments de partage, que ce soi en préparant un article ou en bossant un sujet de conférence. Ça m'aide à voir les choses sous un angle différent, changer du quotidien, voir juste autre chose !

J'apprends aussi d'autres gens. Y'a un côté veille (au sens : d'autres partage aussi, donc je peux lire/écouter ça aussi), mais y'a aussi un côté : je partage, les gens réagissent et me partage des choses.

Je précise quand même que quand je parle de partage, je ne parle pas forcément "en public", ça peut être dans votre équipe, ça peut être dans votre entreprise, ça peut être dans une communauté (Discord, meetup, etc.), en ligne sous pseudonyme, vous n'êtes pas obligé de passer par la case "conférence" pour que votre partage soit utile ou provoque des échanges !

Conclusion

J'ai catégorisé des points en quatre étapes mais ne vous dites pas que vous ne pouvez pas faire ce dont j'ai parlé dans le 3 si vous n'avez pas fait le 1 et 2 à 100%. C'est pour moi un chemin que vous pouvez arpenter dans l'ordre de votre choix ! L'important c'est d'avancer !

C'est pareil, pour vous c'est quoi être un·e bon dev ? Je vous laisse répondre à ça, mais pour moi ça va au-delà du code.

Dans la même lignée, je vous conseille forte de lire un de mes précédents article -- Vous ne voulez pas être développeur, croyez-moi ! -- qui pour s'inscrit dans la même continuité !

Crédit photo : https://pixabay.com/photos/king-chess-checkmate-board-game-1846807/