De geek à directeur technique

Le blog d'un geek devenu directeur technique

Aller au contenu | Aller au menu | Aller à la recherche

mardi 27 juillet 2010

Ma méthode «musicale»

Je n'en ai jamais parlé sur ce blog, mais j'ai quelques activités en dehors de l'informatique et de l'entrepreneuriat. L'une d'elles est la musique. Je joue de la basse depuis l'âge de 16 ans, de la basse 6 cordes depuis 10 ans, et de la basse fretless depuis 2 ans. J'ai joué dans plusieurs groupes ; mon groupe actuel − Perpetual (e)motion − existe depuis 2002 et a sorti son premier album il y a peu de temps. C'est du métal progressif : l'énergie du métal avec une vraie recherche musicale.

Si, si, je vous jure, c'est vrai. La preuve en image : Concert

Il existe grosso modo deux manières d'aborder la musique : soit on rejoue la musique des autres, soit on invente la notre. Ce n'est pas antinomique ; la plupart des groupes, amateurs ou stars mondiales, jouent des reprises au milieu de leurs propres compositions.
J'ajouterais un cas supplémentaire auquel on ne pense pas forcément, celui de la composition en groupe. On se retrouve forcément à devoir jouer certaines parties qui ont été composées par un autre membre du groupe, et d'autres parties qui sont de notre propre fait.

Tout l'intérêt de la création de groupe, c'est justement l'équilibre et la mise en danger que l'on ressent quand on essaye de créer une œuvre qui transcende les individualités, tout en exprimant la créativité de chacun.

Les principes

Pour ma part, j'ai toujours abordé la musique en appliquant la même méthode. Elle tient en 3 principes simples :

  1. Simplifier. Quand il s'agit de musique, je suis un peu fainéant. Travailler une partition à la note près, je l'ai fait assez souvent pour savoir que j'en suis capable. Mais c'est fatiguant et castrateur. Alors la première chose que je fais − qu'il s'agisse d'une reprise ou d'une composition du groupe − est de simplifier les lignes de basse qui ont été écrites. J'en extraite la substance fondamentale, qui peut être la mélodie principale ou le groove de base de la chanson.
  2. Écouter. La simplification permet d'ajouter de l'espace, qui m'offre des options pour m'exprimer, composer mes propres variations sans dénaturer le morceau. Mais le seul moyen d'apporter ma pierre à l'édifice musical, c'est de trouver la bonne mélodie, de placer la note juste au bon moment. Et pour y arriver, je prend le temps d'écouter l'ensemble du morceau, j'essaye de sentir ce qui lui manque. En abordant une chanson avec une oreille neuve, en écoutant tous les instruments en même temps, on peut apprécier ce qu'on peut lui apporter.
  3. Improviser. Je n'ai malheureusement pas le temps de travailler longuement nos morceaux. Quand j'étais plus jeune, je travaillais mes lignes de basse tous les soirs, mais maintenant c'est bien plus difficile. Je répète toutes les semaines avec mon groupe. Je mets ce temps à profit pour expérimenter, pour essayer de nouvelles choses. Je me laisse aller à l'improvisation, mais ce n'est possible que parce que j'ai d'abord épuré les lignes de basse, puis pris le temps d'écouter. Quand une mélodie intéressante se dessine, je la ciselle en l'améliorant à chaque répétition.

Cette méthode est celle que je pratique depuis plusieurs années. Forcément, c'est plus facile quand on joue avec les mêmes personnes depuis 8, voire 10 ans. J'oscille entre le rôle ingrat habituellement réservé aux bassistes de rock (soutenir le rythme) et mes velléités mélodiques (en mettre plein partout). J'aime la basse car c'est un instrument à la fois harmonique et rythmique − c'est pour ça que la basse 6 cordes me convient si bien.

Bref, je me suis souvent demandé s'il y avait des enseignements à tirer de tout cela, applicables à mes activités professionnelles. Et je me suis rendu compte qu'au final c'est exactement la même chose avec les méthodes de travail.

La partition professionnelle

J'ai déjà dit sur ce blog que les méthodes de travail ne sont que des modèles théoriques, et qu'il faut savoir les adapter à nos besoins. Je me suis aperçu que, pour y arriver, j'utilisais le même cheminement que pour la musique.

  1. Simplifier. Appliquer telle quelle une méthode de travail à une entreprise ou un groupe de projet est quasi-impossible. Le plus important est de comprendre en quoi cette méthode est différente des autres, quels en sont les points spécifiques qui vous ont conduit à vouloir l'utiliser. Retirez le superflu et concentrez-vous sur l'essentiel.
  2. Observer. Mettre en place une organisation de travail, cela ressemble beaucoup à faire une greffe. Un rejet peut survenir à tout moment. Il faut donc observer attentivement, pour voir les points qui ne sont pas suivis, et comprendre pourquoi. Certaines fois, il faudra insister sur ces points-là, d'autres fois vous pourrez finalement les laisser de côté si leur adoption n'est pas générale.
  3. Adapter. Si vous avez pris le soin de bien observer votre entreprise, vos collaborateurs et vos projets, vous devriez sentir les problèmes qui vont apparaître. C'est simple : si vous avez l'impression qu'il manque une procédure ou que quelque chose est mal défini, c'est que la méthode est incomplète dans votre cas spécifique d'utilisation. Ajoutez donc ce qui manque, en vous inspirant de tout ce que vous pourrez trouver (y compris grâce à votre propre imagination). Vous voulez saupoudrer du Scrum sur un cycle en cascade ? Rien de vous en empêche. Vous souhaitez intégrer quelques principes de l'extrem programming sur un process basé sur un cycle en V ? Essayez !

L'improvisation et l'adaptation sont des qualités qui permettent aussi bien de composer une œuvre musicale que d'améliorer l'organisation d'une entreprise. Rien n'est monolithique, contrairement à ce qu'essayent de nous faire croire la plupart des livres qui traitent des méthodes de travail. Chaque situation est différente. En entreprise, l'arrivée d'un nouveau collaborateur ou la signature d'un nouveau client peuvent vous amener à revoir en profondeur vos manières de travailler. Oui, c'est un équilibre aussi précaire que ça.
Mais justement, c'est ça qui est fun. Quand vous avez des responsabilités, vous êtes toujours en train de vous assurer que l'équilibre est respecté, tentant d'anticiper les futures pertes d'équilibre.

Tout cela est évidemment très empirique. C'est ainsi que je fais les choses naturellement, mais c'est intéressant d'étudier la question, non ?

À propos de la théorie et de la pratique

Il y a un autre parallèle à faire entre mon parcours musical et le monde de l'entreprise, celui de la formation.

Quand j'ai commencé la basse, j'ai pris des cours avec un très bon professeur pendant près de 2 ans. Cela m'a permis de prendre de bonne habitudes, de m'améliorer rapidement, d'acquérir un socle solide de connaissances sur la théorie musicale.
À côté de ça, j'ai toujours joué dans des groupes. Le premier groupe dans lequel j'ai joué, cela faisait à peine 2 mois que je pratiquais la basse. Grâce à ça, j'ai pu aborder la musique sous un angle moins intellectuel. C'est ce qui m'a appris la souplesse de la musique : on peut jouer avec les règles, l'important c'est que ça sonne.

Je connais des musiciens qui ont appris uniquement par eux-même. Certains ont développé de mauvaises habitudes : des guitaristes qui ne savent pas faire autre chose qu'un accord en quinte, des batteurs qui ne savent pas accorder leur batterie (oui, les batteries s'accordent) ni battre une mesure en 16/8. D'autres ont atteint une très bon niveau, mais cela leur prend plus de temps que s'ils avaient suivi une formation factuelle.
Je connais aussi des musiciens qui ont fait un parcours très complet en conservatoire, sans jamais sortir des «sentiers battus». Certains sont incapables de composer, ou même de participer à une composition. Beaucoup n'en ont même pas envie, ayant été formatés par des années à jouer une musique dite parfaite dont les œuvres ont plus de 200 ans (vision sclérosante des choses, non ?).

Les meilleurs musiciens avec qui j'ai joué ont suivi des cours, parfois en conservatoire, parfois pendant plus de 10 ans, mais toujours associés à des activités de composition seul et en groupe.
J'ai tendance à voir les choses un peu de la même manière concernant la formation des informaticiens. Faire des études longues, c'est bien ; y associer des stages, c'est mieux.

L'informatique est encore une sorte d'El Dorado ; chacun peut s'y lancer, développer ses propres compétences et en faire une activité commerciale. Ce n'est pas réglementé comme certaines professions (médicales, notamment).
J'ai rencontré pas mal d'autodidactes complets qui avaient un niveau technique incroyable. Mais il leur manquait souvent la capacité à analyser un problème jamais rencontré jusque là. Lorsqu'il fallait raisonner au niveau algorithmique, trouver par eux-même des solutions innovantes, ce n'était pas toujours évident.
J'ai connu aussi de jeunes informaticiens particulièrement brillants, des cerveaux qui avaient fait de longues études théoriques. Il leur manquait souvent la vision réaliste des choses qui leur permettrait de faire les bons choix. Par exemple, j'ai connu un gars très intelligent, qui voulait développer un code basé sur un algorithme génétique ; mais ce qu'on lui demandait, c'était juste un parseur (un peu compliqué comme parseur, certes ; mais il lui a fallu moins de temps pour tester et comparer les 3 ou 4 algorithmes possiblement utilisables que pour de mettre en place son algo génétique).

Il y a toujours des gars qui font des études purement théoriques et qui deviennent de vraies machines à apprendre. En sortant d'école ils ne savent rien faire, mais donnez-leur un peu de temps et d'expérience et ils atteignent des sommets. Ça existe, mais ce n'est pas courant.
De la même manière, rien n'empêche un autodidacte d'atteindre un niveau exceptionnel en prenant en main sa propre formation. Là aussi, c'est rare mais ça arrive.

Pour se donner les meilleures chance, il faut donc associer les aspects théoriques et pratiques. Mais j'espère que c'était déjà évident pour tout le monde.

dimanche 18 juillet 2010

Livre : De la simplicité

J'ai lu récemment le livre De la simplicité, écrit par John Maeda.

Ce livre n'est pas seulement une ôde à la simplicité, mais il décortique consciencieusement les principes qui conduisent aux choses simples, et comment ils procurent un avantage. D'amblée, l'auteur applique à ce livre les préceptes qu'il met en avant. Ainsi, c'est un livre relativement court (185 pages), découpé en chapitres d'une dizaine ou une quinzaine de pages, particulièrement facile à lire car illustré − au propre ou au figuré − d'exemples bien trouvés.

L'auteur n'est pas un inconnu. Professeur au MIT et web-designer de renom, il a une approche des choses très intéressante, qui combine l'esthétique, la technique et l'ergonomie.

Les principes de la simplicité

John Maeda décrit la simplicité suivant 10 lois et 3 clés.

Les lois sont (telles que listés dans le livre) :

  1. Réduction. Pour atteindre la simplicité, le mieux est la réduction méthodique.
  2. Organisation. Avec de l'organisation, un ensemble composé de nombreux éléments semble plus réduit.
  3. Temps. En économisant son temps, on a le sentiment que tout est plus simple.
  4. Apprentissage. La connaissance simplifie tout.
  5. Différences. La simplicité et la complexité ont besoin l'une de l'autre.
  6. Contexte. Ce qui se trouve à la périphérie de la simplicité n'est absolument pas périphérique.
  7. Émotion. Mieux vaut plus d'émotions que moins.
  8. Confiance. Dans la simplicité nous avons confiance.
  9. Échec. Certaines choses ne peuvent jamais être simplifiées.
  10. Loi cardinale. La simplicité consiste à soustraire ce qui est évident et à ajouter ce qui du sens.

Les clés :

  1. Au loin. Plus semble moins si l'on s'en tient éloigné, très éloigné.
  2. Ouverture. L'ouverture simplifie la complexité.
  3. Puissance. Se servir de moins, en tirer plus.

Au milieu de tout cela, il utilise une méthode qu'il nomme AMI, pour «Atténuer, Masquer, Insuffler». L'idée est qu'il est souvent possible de réduire la complexité perçue de quelque chose en diminuant son impact psychologique. Cela peut être atteint en réduisant sa taille ou la “surface” (au sens métaphorique du terme) de son interface avec nous ; ou encore cachant les éléments ou les fonctionnalités les plus complexes afin de mettre en avant un sous-ensemble plus simple à appréhender avant d'avoir besoin de plus ; enfin en transmettant à l'objet en question des qualités qui dépassent sa définition au sens littéral − si la qualité réelle et la qualité perçue se rejoignent, on simplifie et justifie les complexités sous-jacentes.

Utilité et application

Chaque loi est détaillée dans un chapitre qui lui est dédié. Je ne vais pas vous en faire une explication de texte détaillée, les descriptions de l'auteur, que j'ai repris ci-dessus sont suffisantes pour comprendre leur teneur (et devraient titiller votre intellect).

Le plus intéressant, c'est que ce livre reste général sans pour autant se perdre en généralités. Les principes élémentaires qu'il exprime peuvent être appliqués à des cas aussi différents que l'ergonomie d'un appareil électronique, le design d'un site web, la définition d'un business, la mise en place d'une méthode d'organisation personnelle, le déploiement d'une procédure professionnelle, ou l'amélioration d'une formation supérieure.
Même quand le propos de l'auteur semble partir dans des directions incongrues, il retombe sur ses pieds et délivre un message qui nous apporte quelque chose.

Le livre se termine par une bibliographie qui vous permettra d'approfondir certains aspects si vous le souhaitez.

Mon avis

À mon sens, ce livre devrait faire partie des ouvrages de référence que tout le monde devrait connaître. Que vous soyez informaticien ou non, que vous ayez à réfléchir à de nouveaux produits, que vous développiez un logiciel ou une entreprise, ou simplement si vous souhaitez réfléchir aux moyens de progresser personnellement, il vous apportera des réponses et vous fera méditer certaines choses dont vous n'aviez pas forcément conscience auparavant.

Même si vous n'en étiez pas convaincu avant de le lire, vous saurez après pourquoi il faut aller vers la recherche de la simplicité, et comment ce but peut être atteint.

Sachez enfin que John Maeda a créé un site pour accompagner le livre, du nom de LawsOfSimplicity.com. Si vous lisez l'anglais, allez y faire un tour. Même si aucune mise-à-jour n'y a été faite depuis un an et demi, il reste très enrichissant.

mercredi 7 juillet 2010

Recrutement : Administrateur système

Le poste d'administrateur système n'est plus à pourvoir. Merci à tous ceux qui m'ont envoyé un CV.
Par contre, nous sommes toujours à la recherche d'un développeur PHP, n'hésitez pas à postuler.

Pour faire suite à mon billet précédent, je suis aussi à la recherche d'un administrateur système / responsable d'exploitation.

Présentation de l'entreprise

Nous éditons des sites web communautaires, comme CommentFaitOn ou DcoPhoto, et des sites "de niche" comme Le guide de la cuisine, ou les sites ComprendreChoisir (sur la fenêtre, la défiscalisation, le home cinema, les standards téléphoniques, ...).

Nous sommes localisés dans le 17è arrondissement de Paris (métro Villiers).

Définition du poste

Le poste d'administrateur couvre un champ d'action assez large.

Au quotidien, cela implique :

  • Maintenance du réseau interne de l'entreprise, qui comprend 28 postes de travail, 4 serveurs et un NAS. Nous avons un second réseau dédié à la téléphonie (voix sur IP).
  • Administration des serveurs de production, soit 5 machines hébergées en datacenter.
  • Exploitation : Mise en pré-production et en production de nos projets, déroulement des cahiers de tests. Amélioration de nos procédures de suivi et de documentation.
  • Monitoring de nos serveurs et applications.

Je cherche quelqu'un qui puisse aussi participer aux évolutions que nous avons commencé à mettre en place sur notre architecture :

  • Expertise en base de données (configuration MySQL, optimisation de requêtes, réplication de bases).
  • Amélioration de la montée en charge de nos serveurs Web (load-balancing).
  • Étude de solutions de virtualisation (OpenVZ) et de cloud computing.

Environnement technique

  • Linux : Tous nos serveurs tournent sous Ubuntu, ainsi que la plupart de nos postes de travail.
  • Web : Nos applications sont écrites en PHP, exécutées par Apache, et utilisent des bases de données MySQL.
  • Serveurs : Nos serveurs de productions vont du Core2Duo/4 GO au bi-Xeon QuadCore/16 GO, avec des disques allant de 300 GO à 750 GO. Les serveurs internes tournent sur du matériel classique, certains sont virtualisés.
  • Scripting : Quelques scripts d'administration sont écrits en shell, mais la plupart de nos outils sont écrits en PHP (cela facilite les choses quand il faut se connecter à l'applicatif).

Si vous êtes intéressés, envoyez-moi votre CV à l'adresse amaury.bouchard@finemedia.fr.

lundi 21 juin 2010

Recrutement : Développeur principal PHP 5

Un billet inhabituel aujourd'hui : Fine Media, l'entreprise que j'ai co-créé et dont je suis le directeur technique, est à la recherche d'un développeur web. Pas n'importe quel poste de développement ; nous cherchons notre développeur principal.

C'est quoi un développeur principal ? Simplement la personne qui pourra prendre mon relais. Un “responsable des développements”, si vous préférez.

Présentation de l'entreprise

Nous éditons des sites web communautaires, comme CommentFaitOn ou DcoPhoto, et des sites "de niche" comme Le guide de la cuisine, ou les sites ComprendreChoisir (sur la fenêtre, la défiscalisation, le home cinema, les standards téléphoniques, ...).

Nous sommes localisés dans le 17è arrondissement de Paris (métro Villiers).

L'environnement technique

  • Linux. On utilise de l'Ubuntu Server sur les serveurs, et de l'Ubuntu Workstation sur les postes de développement. À vrai dire, même les rédacteurs et les commerciaux sont sous Linux, chez nous.
  • PHP 5. Tout est développé en PHP, en objet, en utilisant des design patterns, avec des cycles de développement itératifs et des validations test/pré-production/production.
  • MySQL. On fait des requêtes assez compliquées. Il vaudrait mieux que vous sachiez la différence entre une sous-requête et une jointure.
  • Subversion. Si vous n'avez jamais utilisé le moindre système de gestion de sources, ce n'est pas grave, vous vous y ferez très vite. Et après vous ne pourrez plus vous en passer.

Ce que vous aurez à faire

  • Améliorer notre framework MVC interne, ainsi que notre CMS. Ils sont petits et légers, des vrais jouets faciles à faire évoluer dans les directions qui nous intéressent.
  • Travailler sur FineFS, notre outil de clustering réseau, placé sous licence libre. Si vous cherchez un projet hyper-technique en PHP, vous allez être servis ! ;-)
  • Génie logiciel : modélisation des objets métier, évolution du modèle de base de données, développement orienté objet.
  • Gestion de projet : écriture des spécifications techniques, suivi du planning, supervision des tests.

Évidemment, c'est un poste avec certaines responsabilités. Donc je cherche quelqu'un ayant déjà fait ses preuves en développement Web, et qui aime ça. Un passionné avec des idées à faire valoir, ayant envie de les partager et de les appliquer. Mais aussi quelqu'un qui souhaite faire de la gestion de projets et faire de l'encadrement.

Sans oublier que je prends le temps de former les membres de mon équipe. Car il s'agit vraiment d'une équipe : je cherche quelqu'un qui pourra nous apporter autant que nous pourrons lui apporter.

Alors si vous êtes ambitieux, si vous avez des idées techniques intéressantes, si vous aimez le Web et avez envie de bosser sur des trucs pointus et originaux, envoyez-moi votre CV à l'adresse amaury.bouchard@finemedia.fr.

dimanche 13 juin 2010

Attention aux mercenaires

Vendredi dernier, j'ai fait passer un entretien d'embauche. J'en fait passer régulièrement, c'est une activité chronophage mais malheureusement nécessaire.

Là, je recevais un jeune homme qui avait un profil autodidacte, chose qui ne me dérange pas outre mesure tant que les connaissances, les capacités et la motivation sont là. Malheureusement pour lui, il a lamentablement échoué à un petit test technique de rien du tout, qui me sert habituellement de «filtre passe-bas». Comme je cherche un développeur expérimenté, c'était évidemment rédhibitoire.

Quand je fais passer un entretien − à plus forte raison quand je m'apprête à l'écourter − je prends le temps de donner un feed-back au candidat. Je peux lui donner quelques trucs dont je parle sur ce blog, concernant le CV ou l'entretien lui-même, ou lui donner quelques pistes dans sa recherche. On ne se refait pas.

Là, le jeune homme avait sur son CV un parcours particulier : une première expérience d'un an en contrat pro, puis une autre expérience d'un an, puis enfin son poste actuel qu'il occupait depuis moins de 2 ans. Quand je vois ce genre de chose, je demande toujours au candidat de m'expliquer. Jusqu'ici, j'avais toujours eu des réponses satisfaisantes ; on m'expliquait que le poste était moins intéressant que prévu, ou que que l'entreprise n'offrait aucune perspective d'évolution, ou encore que les attentes de l'entreprise étaient trop élevées et que le candidat s'était mis à la recherche d'un poste lui permettant de développer son expérience.
Bref, dans tous les cas, les personnes en face de moi ont toujours tenté de m'expliquer qu'il s'agissait d'erreurs de parcours ponctuelles.

Bizarrement, ce candidat a réagi tout autrement. Il m'a dit que le turn-over est un fait en informatique, que les développeurs restent entre 6 mois et 1 an et demi dans leurs entreprises, qu'il est normal de vouloir changer d'air régulièrement. Quand je lui ai dit que les entreprises cherchent des employés pour les garder longtemps, il m'a dit qu'il n'était pas d'accord (sic) et qu'aucun autre recruteur ne lui avait jamais posé ces questions ni fait ces remarques.
(Je lui ai demandé si les autres recruteurs qu'il avait rencontré l'avaient rappelé, il m'a dit que non. Étonnant, hein ?)

Où est le problème ?

En fait, il faut se rendre compte que lorsqu'une entreprise embauche une personne, c'est dans l'idée d'investir dessus. Investir en prenant le temps de la former, ce qui génère des coûts par son salaire alors qu'elle n'est pas productive, mais aussi par le manque à gagner sur le salaire des personnes qui la forment et qui ne sont donc pas productives non plus durant cette période. Investir en comptant qu'il lui faudra une certaine période d'adaptation au métier de l'entreprise, à ses outils, à ses procédures.

Le retour sur investissement prend plusieurs formes. La première, c'est le travail effectif que cette personne va fournir par la suite. Plus elle sera autonome, plus le retour sur investissement sera important.
Ensuite, par son implication et sa créativité, cette personne peut amener des idées fondamentales qui peuvent avoir des impacts déterminants sur l'organisation (tant fonctionnelle que technique) de l'entreprise.
Il y a aussi la propre expérience que possède cette personne, et qu'elle partagera avec ses collègues. Si cette personne conduit une veille technologique efficace, cet aspect peut devenir relativement important.

Dans tous les cas, le retour sur investissement se fait dans la durée. On n'embauche pas un informaticien en se disant qu'il sera parti ailleurs dans un an et demi. Il faut être totalement hermétique aux réalités du monde de l'entreprise pour croire cela.
Au contraire, la plupart des entreprises cherchent à recruter des personnes qui pourront s'épanouir sur le long terme, qui donneront le meilleur d'elles-mêmes, qui pourront «grimper les échelons» au fur et à mesure que l'entreprise se développe.

Lorsque les entreprises cherchent des mercenaires, elles se tournent vers des sociétés de service ou des développeurs free-lance. Dans ces cas-là, elles payent des compétences pointues dont elles ont besoin pendant une durée convenue. Mais c'est alors une situation particulière, gérée comme telle, qui comporte ses avantages et ses inconvénients. Il y a une grande différence entre se payer les services d'un mercenaire professionnel compétent, et former un informaticien qui mettra sa formation en œuvre dans d'autres entreprises.

Pour les recruteurs

Habituellement, les candidats sont assez intelligents pour ne pas réagir comme le candidat dont je vous parle. Même ceux qui aiment bien faire «grimper les enchères» trouvent toujours une manière positive d'expliquer leur parcours. Ils sentent bien qu'il serait néfaste pour eux de se présenter comme des danseuses sur qui on ne peut pas compter plus de quelques mois.

Mais il faut être vigilant. Essayez de lire entre les lignes pour comprendre les réelles motivations du candidat. S'il semble être intéressé par le salaire de manière exagérée par rapport aux autres aspects (intérêt du poste, ambiance de travail, formation continue, proximité géographique, ...), cela doit vous mettre la puce à l'oreille.

Pour les candidats

La première chose à intégrer est que le turn-over des employés n'est pas plus normal en informatique que dans d'autres secteurs. C'est même plutôt l'inverse : les salaires sont assez élevés (par rapport à d'autres branches qui réclament autant d'années d'études) et on ne peut pas vraiment parler de pénibilité du travail.

Essayez de comprendre qu'il est dans votre intérêt et celui de votre carrière de trouver un poste dans lequel vous allez pouvoir apprendre des choses, où vous allez pouvoir faire fructifier cet apprentissage, mais aussi un poste où vous allez pouvoir vous exprimer, faire la différence, gagner des responsabilités.

J'ai déjà croisé des jeunes disant qu'ils pensaient passer deux ou trois ans dans telle ou telle entreprise, pour «avoir un nom à mettre sur le CV» ou parce que le salaire y était vraiment intéressant. Mais sans jamais regarder l'intérêt intellectuel du travail en question, ni les perspectives d'évolution. Et à chaque fois, ils se sont retrouvés au bout de 6 mois à chercher un autre boulot, plus humain, plus intéressant ou mieux encadré ; ou bien ils passaient 2 ans à déprimer.
Ce n'est pas une situation enviable.

- page 1 de 22