Mathieu Agopian : Plan de carrière d'un développeur

Le plan de carrière, j'en avais très souvent entendu parler, depuis tout jeune, depuis avant même de savoir que je voulais devenir développeur.

Puis quand j'ai découvert l'informatique, je m'y suis jeté à corps perdu, et j'ai rangé cette notion dans un petit tiroir de mon cerveau étiqueté « inutile pour un développeur ».

C'était bien évidemment une erreur. Ne pas comprendre un concept n'en fait pas un concept inutile.

Je m'adresse ici aux développeurs salariés, et n'aborderai pas la création d'entreprise, n'y connaissant rien.

Le plan de carrière, qu'est-ce que c'est ?

Un plan de carrière, c'est un but à atteindre dans sa vie professionnelle. Ce but peut être multiple, et j'en vois trois principaux :

Chacun de ces buts permet d'atteindre un idéal qui sera différent pour chacun. Pour l'un ce sera un plus gros salaire, pour l'autre plus de temps libre, plus d'importance (l'entreprise ne pourrait pas tourner sans moi), plus de poids social (je suis le chef de x personnes), plus de sécurité de l'emploi.

Pour atteindre ces buts, il faudra alors utiliser une ou plusieurs échelles, pour reprendre l'image assez répandue de « gravir les échelons ».

Pour un développeur, je perçois deux échelles fondamentalement différentes, que je vais tenter de vous décrire.

L'entreprise

L'échelle la plus visible, évidente, la voie royale. Et pour la gravir, il existe une multitude d'équipements d'escalade appropriés : le chantage, le harcèlement moral, le léchage de bottes, le carriérisme, la prédation, le piston...

Je dresse un tableau caricatural, mais dans chaque caricature, il y a une base de vérité il paraît.

Il existe bien évidemment, et heureusement, des moyens plus nobles et droits d'évoluer au sein d'une entreprise. Le travail acharné, l'implication, la loyauté, donner le meilleur de soi-même, être fiable, ne pas compter ses heures, être agréable et aimable, facile à vivre, bon équipier.

Pour faire part de mon expérience, ayant gravi plusieurs échelons, très rapidement, j'ai aussi fait de mon mieux pour être un moteur, être force de proposition (et de réalisation !).

Et quand on dit qu'un développeur travaille beaucoup en dehors de ses horaires de travail, même en étant loin du clavier (sous la douche, sur la route, dans son sommeil), c'est d'autant plus vrai quand on est investi à 100% dans sa tâche.

Mais après tout, n'est-ce pas normal ? Tout donner à l'entreprise qui nous paie, nous fait vivre, nous permet de nous payer un toit, de quoi manger, se payer du luxe, des vacances...

Dans un sens, oui, ça paraît logique. D'un autre côté, quelqu'un a dit : « je veux travailler pour vivre, et non vivre pour travailler. »

Par contre, il vaut mieux bien choisir son entreprise, et j'en parlerai dans un prochain billet. S'investir, être fidèle, loyal, fiable, et tout donner pour une entreprise, qui en retour, vous aspire sans vergogne, et vous vide petit à petit de votre substance, c'est un danger réel à éviter à tout prix !

La visibilité

C'est l'autre extrême du spectre, l'autre chemin qui passe par le gain de visibilité au sein d'une communauté, ou pour les plus chanceux et doués, au regard de ses pairs d'une manière générale.

Qui parmi vous ne connaît pas Jeff Atwood, Joel Spolsky ou Ward Cunningham, pour ne citer qu'eux ? Ces développeurs de renom se sont fait connaître bien au delà de la communauté de développeurs utilisant le même langage qu'eux.

Sans prendre des exemples aussi extrêmes, la plupart des développeurs Python connaissent les noms d'au moins une dizaine de personnes clé, des contributeurs reconnus, des blogueurs influents, des créateurs de logiciels ou services qu'on utilise au quotidien.

Ces gens là sont visibles. La visibilité peut se faire à plusieurs niveaux, du plus simple au plus difficile :

  1. local : au sein d'une entreprise, d'une équipe, d'un « user group »
  2. communauté : au sein de la communauté des utilisateurs de son langage de programmation, ou du framework, CMS, CRM ou plus généralement outil utilisé au quotidien
  3. global : nationalement, voire même internationalement, être connu et reconnu comme une référence en matière de développement

La visibilité s'acquiert par plusieurs moyens, pouvant être combinés :

Conclusion

Les deux échelles permettent d'atteindre un ou plusieurs des buts listés en début de ce billet, par des chemins différents. Nous verrons dans un prochain billet que choisir l'une ou l'autre des échelles permet d'accéder à différents types d'entreprises.

Attention à toi, jeune développeur, ne fais pas comme moi, ne te réveille pas « trop tard » en te rendant compte que tu as gravi la mauvaise échelle. Il n'est jamais trop tard pour recommencer à gravir « la bonne », mais ça implique de repartir d'en bas !

Certains me diront qu'il est tout à fait possible de gravir les deux en même temps. Je le crois, en effet, mais je doute que ce soit à la portée de tout le monde. Et de la même manière qu'on sait qu'il est impossible pour un cerveau de faire du multi-tâche, je pense qu'essayer de gravir les deux échelles sera non seulement épuisant et difficilement faisable sur le long terme, mais surtout, une échelle sera toujours privilégiée par rapport à l'autre.

D'autres me diront que gravir une échelle fait « gravir des échelons » automatiquement sur l'autre. C'est aussi vrai, mais dans une moindre mesure. Encore une fois, utiliser une échelle se fera généralement au détriment de l'autre.

Le but de ce billet est surtout de faire partager ma prise de conscience tardive. Tant qu'on est jeune, fougueux et plein d'énergie, il vaut mieux se concentrer sur une seule échelle, et le faire consciemment, au lieu de se lancer tête baissée et de potentiellement le regretter plus tard !

Edit : 19h29

Suite à la réponse de David Larlet, j'ai repensé à ce billet, et ma première réaction a été « mais il m'énerve ce David à avoir raison, et l'écrire si bien ! ».

Si vous n'êtes pas encore abonnés à son flux RSS, je ne peut que vous le conseiller, ses billets sont source d'inspiration, très bien écrits, synthétiques et concis à souhait.

Revenons à nos moutons : oui, je pense que le conseil de David de partager est le meilleur qu'on puisse suivre, mais je pense aussi que c'est orthogonal à la pensée initiale de ce billet. Je pense effectivement que la meilleure chose à faire, quelle que soit l'échelle qu'on choisi, c'est de partager, et ce pour toutes les raisons énoncées par David.

Ainsi, sur l'échelle de l'entreprise, on partagera par le biais de formations internes, de discussions à bâtons rompus à la pause café, de conseils donnés ou reçu lors de demande d'aide ou de conseil, de la revue de code.

Sur l'échelle de la visibilité, on partagera en conférences, par des contributions open source, etc.

Par contre, je reste convaincu qu'il existe vraiment deux échelles, chacune menant à une position différente, plus ou moins avantageuse selon le type d'entreprise qu'on vise. Et c'est ce que j'espère montrer et expliquer plus clairement avec le prochain billet sur la taxonomie des entreprises.