Spiria logo

Comment ne plus être un développeur “junior”

« Junior », c’est le premier échelon de notre carrière professionnelle… et c’est celui qu’on veut bien vite quitter. La distinction précise entre junior, intermédiaire et senior, est parfois variable, mais il y a quand même quelques points qui font l’unanimité.

Un junior, c’est quelqu’un qui doit encore faire ses preuves quant à la constance dans la qualité de son travail, que ce soit devant un chargé de projet pendant les rencontres avec un client, devant l’équipe technique d’un client lors d’une mise en production, ou encore avec un développeur plus expérimenté pendant une revue de code. Voyons donc quelques conseils pour un junior visant à diminuer les risques d’envoyer des bogues en production et de s’assurer qu’aucun d’eux ne soit irréparable. Les suivre augmentera votre confiance, votre autonomie et vous aidera à démontrer à vos supérieurs que vous méritez le titre de développeur intermédiaire.

Trucs pour juniors

Apprendre à revenir en arrière…

Avec votre code : devenez à l’aise avec un outil de gestion de version de code (Git, SVN ou autre). Connaissez les concepts de base, ayez un système de branches clair, sachez faire les manipulations les plus communes, laissez des commentaires pertinents, etc.

Avec un SGBD (système de gestion de base de donnée) : les premières choses à apprendre avant de toucher à des données en production sont...

  • Comment exporter les données pour créer une copie.
  • Comment faire un rollback (annuler ses changements).

Si on ne peut pas effectuer ces opérations aisément, on ne devrait jamais manipuler des bases de données. Perdre des données peut causer d’importantes pertes de temps et d’argent (voire bien pire).

Apprenez à déboguer votre code

Dans tous les langages récents, il y a moyen de suivre le code pendant son exécution, d’ajouter des breakpoints et des sorties à une console, etc. Ça vous permet de vous plonger rapidement dans un projet déjà existant et d’en apprendre la structure, et c’est indispensable pour déboguer votre propre code. Plusieurs techniques ou outils sont disponibles selon le langage utilisé.

Bien programmer

Tout comme savoir écrire ne fait pas de nous un écrivain, on doit aussi apprendre à bien programmer. Votre code est fait pour être lu soit par une machine, soit par un humain. Lorsqu’un humain le lit, c’est généralement pour le modifier ou le corriger. Rien de garanti que vous serez encore là pour l’expliquer, donc, règle d’or : votre code devrait être autosuffisant pour se faire comprendre.

Lisez sur le sujet et apprenez les bonnes et mauvaises pratiques (noms de variables et de méthodes, nomenclature, indentation, documentation, etc.)

Testez votre code avant de l’envoyer

L’équipe d’assurance qualité (QA) est là pour attraper les balles échappées, pas pour aller les cueillir dans le fond d’un lac. En tant que développeurs, nous sommes les plus proches du code et pouvons estimer l’impact de nos changements. Valider en combien d’endroits la méthode qu’on vient de modifier est appelée, ça prend une minute avec un bon IDE, et ça évite de causer des bogues qui seront décelés seulement plus tard par l’équipe de QA, le client ou les utilisateurs.

Lorsqu’on dit que notre code est prêt, il faut avoir confiance qu’il l’est vraiment.

Qualités à démontrer

Sens du détail

Je fais tout en mon pouvoir pour que ma tâche soit exécutée comme indiqué, et je demande des détails lorsque nécessaire. Si quelqu’un s’est donné la peine de rédiger des spécifications, c’est qu’il y a une raison derrière elles. Je m’assure que rien ne manque à l’appel.

Rigueur

Je m’assure que ma solution est réfléchie et n’est pas simplement la première qui me soit passée par la tête. Je veux que ma tâche soit bel et bien terminée et que je sois fier du résultat avant de l’envoyer pour une révision avec vos collègues, au client ou autre. Ça évite de faire perdre du temps à ceux-ci. Ils comptent sur moi pour bien faire mon travail.

Humilité

La première étape pour régler un problème, c’est de reconnaître qu’il existe. J’apprends de mes erreurs et de celles de votre équipe. Tout le monde en fait et les occasions d’apprendre sont partout. Vaux mieux un bogue avoué et corrigé qu’un bogue qui n’est simplement pas encore répertorié.

Savoir laisser de côté son orgueil

Je ne suis pas impliqué dans toutes les décisions prises pour le projet et c’est normal. Quand je ne sais pas, je l’indique. Ce n’est pas toujours ma solution qui sera choisie, et il faudra vivre avec : je travaille avec des gens plus expérimentés. Parfois, ma solution me semble meilleure, mais ne convient pas au client pour une question de budget, d’échéance, restriction légale ou autre, et donc n’est pas retenue. Inutile d’être orgueilleux, ce n’est rien de personnel.

Collaboration

Je participe aux discussions, mais c’est en écoutant que j’apprends le plus. Comme tout projet implique au moins deux personnes, je dois donc apprendre à travailler à plusieurs de manière professionnelle. Je pose des questions afin d’éviter les zones grises et avancer plus rapidement. Lorsque j’apprends quelque chose de nouveau qui mériterait d’être connu de tous, je le documente et le partage.

S’attaquer à un problème à plusieurs est parfois la meilleure solution : deux cerveaux valent mieux qu’un. C’est le principe même du Pair programming. Parfois, même un simple canard de plastique peut être un bon compagnon (voir la méthode du canard en plastique).

Autodidaxie

Mon apprentissage est essentiel et ne peut pas reposer seulement sur les autres développeurs plus expérimentés. Il est possible que je sois seul sur un projet, je dois donc pouvoir apprendre par moi-même, savoir où trouver de l’information et juger de sa qualité, etc.

Adaptabilité

Les clients changent d’idée. C’est frustrant après plusieurs semaines de travail, mais c’est la vie. Chaque changement de direction peut impliquer des coûts additionnels, le client en est bien conscient. Le mieux est encore de demander pourquoi le changement était nécessaire afin prévenir un scénario semblable dans le futur en conseillant le client.

Vision « Big Picture »

Je garde une vision d’ensemble du projet, pour l’analyse des besoins, pour agir en tant qu’expert-conseil auprès du client, et ne pas s’attacher émotionnellement aux tâches que je réalise. Je ne me limite pas à regarder seulement ce que je suis en train d’accomplir. Peut-être que ça fait plusieurs jours que je suis sur une tâche, mais que je devrais m’attaquer à une autre, plus importante à court terme pour le projet. Il est important de regarder les nouvelles tâches qui s’ajoutent et de valider leur priorité par rapport à celle que je suis en train d’accomplir.

Curiosité

La dernière, mais non la moindre des qualités. La technologie évolue plus rapidement que jamais, surtout avec les librairies open source. Il est essentiel d’être prêt à accepter et à chercher le changement. Sans désir d’apprendre, on est rapidement dépassé. C’est valable à tous les échelons, et tout employeur ne peut qu’apprécier quelqu’un qui cherche à se tenir à jour et à s’améliorer.

Cette entrée a été publiée dans Méthodes et bonnes pratiques
par Olivier Mageau-Pétrin.
Partager l'article