Kit de survie en entreprise

AmauryOrganisation personnelleUn commentaire sur Kit de survie en entreprise

Contrairement à ce que le titre de cet article pourrait le laisser penser, je ne vais vous parler des situations conflictuelles que l’on peut rencontrer en entreprise. Je vais plutôt vous parler de quelques trucs qui sont facilement applicables, et qui peuvent faciliter les choses dans certaines situations. Ça vaut ce que ça vaut, mais ça peut vous sauver la vie (enfin, presque).

Diviser par deux

C’est une situation que nous avons tous connus : On discute avec une ou plusieurs personnes, chacun argumente dans le sens qui l’intéresse, et au moment où on veut exprimer nos propres idées, elles arrivent toutes en même temps. Au lieu de lister les points importants de manière intelligible, on délivre un amas de non-sens sans queue ni tête. Plus on s’en rend compte, plus on s’embrouille. Au final, quelqu’un d’autre captera la discussion pendant que l’on reprend notre souffle entre deux phrases, et tout le monde oubliera notre pathétique contribution.

Comment faire pour éviter ça ? La technique la plus simple est de systématiquement chercher à diviser nos idées en deux.
Si vous avez une idée en tête, mais que vous ne savez pas par quel bout l’aborder, essayer d’en distinguer deux facettes. Forcez-vous à y trouver deux aspects différents. Cela peut être les avantages et les inconvénients. Ou quelques enseignements liés à votre expérience sur le sujet, comme un “contre-exemple” qui apporterait un éclairage particulier. Prenez le temps de préparer mentalement votre «thèse / antithèse». Le but de la réunion sera de faire la «synthèse» à plusieurs.

Cela paraît débile, mais c’est une vraie méthode d’organisation de la pensée. Je connais une personne qui commence la moitié de ses phrases par « En fait, il y a deux choses dans ce que tu dis » ; c’est crispant à la longue, mais ça a le mérite d’éclaircir les idées de tout le monde quant au propos échangé.

Reconnaître les hypocrites

Tout le monde le sait : en entreprise, il y a des gens sympas et il y a des cons. On est prévenu et préparé à cela. Le problème, c’est quand on a affaire à des cons qui sont assez fourbes pour paraître sympas. Il y a plusieurs profils de ce genre :

Les connaissances informatiques de base

AmauryVotre carrière23 commentaires sur Les connaissances informatiques de base

Au fil du temps, j’ai pu observer des lacunes techniques chez beaucoup d’informaticiens. On ne peut évidemment pas tout savoir ; l’informatique est un domaine très large, qui couvre des choses très variées. Mais il y a un certain nombre de connaissances basiques que vous devez absolument maîtriser si vous êtes informaticien.

Valeurs binaires standard

Il me semble absolument nécessaire de connaître de tête les plus importantes valeurs binaires.

Un octet, c’est stocké sur combien de bits ? Et un entier standard ?
Combien peut-on stocker de valeurs différentes en 8 bits ? Et en 16, 24, ou 32 ?

Réponses :

  • Un octet est stocké sur 8 bits. Un entier standard est stocké sur 32 bits. Un «short» est classiquement stocké sur 16 bits, un «long» sur 64 bits.
  • En 8 bits (sur un octet, donc), on a 256 valeurs différentes. En non-signé, cela va donc de zéro jusqu’à 255. En signé, cela va de -128 à +127.
  • En 16 bits (sur 2 octets), on a 65 536 valeurs. De zéro à 65 535 en non-signé ; de -32 768 à +32 767 en signé.
  • En 24 bits (3 octets), on a 16 777 216 valeurs possibles.
  • En 32 bits (4 octets), on a 4 294 967 296 valeurs possibles.
  • En 64 bits (8 octets), on a 18 446 744 073 709 551 616 valeurs.

C’est pas bien compliqué à mémoriser. Gardez juste à l’esprit les ordres de grandeur :

  • 1 octet => 256
  • 2 octets => 65 milles
  • 3 octets => 16 millions
  • 4 octets => 4 milliards
  • 8 octets => beaucoup (je considère que 18 trillions, ça fait trop grand pour être compté).

Mais pourquoi est-ce si important à savoir ? Après tout, on peut recalculer facilement tout ça. Oui, mais pour un informaticien, recalculer ça reviendrait au même qu’un géomètre qui se demande tous les jours combien il y a de centimètres dans un mètre…

Concrètement, ces valeurs ne servent pas forcément tous les jours, mais il faut être capable de les utiliser à bon escient. Si vous faites du développement embarqué, vous aurez sûrement besoin de calculer au plus juste l’utilisation de la mémoire ; et en codant en C, vous devrez choisir le type de vos variables en connaissance de cause. Mais ce n’est pas le seul cas où c’est utile.

Si vous êtes un développeur Web ou un DBA vous aurez à créer des tables dans votre base de données. Pour cela, vous devez connaître les types de données que vous pouvez utiliser. Si on prend l’exemple de MySQL, les nombres entiers peuvent être stockés dans des champs de type TINYINT, SMALLINT, MEDIUMINT, INT et BIGINT. Chacun pouvant être signé (par défaut) ou non-signé (en ajoutant UNSIGNED au type).
Alors pour stocker la taille d’un être humain, en centimètres, un TINYINT UNSIGNED sera sûrement suffisant. Hum… sauf si vous devez gérer les 4 hommes les plus grands du monde qui dépassaient les 255 centimètres. Certains choisissent alors la facilité et stockent tous leurs entiers en utilisant des INT. Mais pourquoi prendre 4 octets, là où la moitié suffirait ?

De la même manière, quel est le type le plus adapté à une clé primaire ? Sur 16 bits, ce serait un peu court ; c’est assez fréquent d’avoir des tables qui contiennent bien plus de 65 milles lignes.
Un petit truc pour y arriver, c’est de réfléchir en terme de rapidité de remplissage de la table : Si vous avez en moyenne une nouvelle ligne par seconde, une clé primaire stockée sur 3 octets (un MEDIUMINT UNSIGNED) se remplira en à peine plus de 6 mois. Si par contre vous passez sur 4 octets (INT UNSIGNED), vous pouvez tenir ce rythme pendant 136 ans. Est-ce vraiment utile de passer sur un BIGINT ?

Langage de script

Quel que soit votre domaine, quelle que soit votre plate-forme, quelles que soient les technologies que vous utilisez, vous ne pouvez pas faire votre travail efficacement si vous ne connaissez aucun langage de script. Évidemment, on peut toujours s’en tirer en mettant au point des «méthodes de contournement». Mais quelle perte de temps ! Cela revient à passer le baccalauréat scientifique avec une calculatrice « 4 opérations » ; c’est possible, mais c’est se mettre soi-même des bâtons dans les roues.

Recrutement : Développeur principal PHP 5

AmauryVotre carrièreLaissez un commentaire sur Recrutement : Développeur principal PHP 5

Le poste de développeur n’est plus à pourvoir. Merci à tous ceux qui m’ont envoyé un CV. Par contre, nous sommes à la recherche d’un administrateur système, n’hésitez pas à postuler. Un billet inhabituel aujourd’hui : Fine Media, l’entreprise que j’ai co-créé et dont je suis le directeur technique, est à…

Lire la suite

Attention aux mercenaires

AmauryVotre carrière14 commentaires sur 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.

Améliorer les flux d’information

AmauryOrganisation d'équipeLaissez un commentaire sur Améliorer les flux d’information

J’ai entendu récemment un échange qui m’a amusé, entre un oncle et une tante.
Elle de dire :

Mais tu ne m’écoutes pas ?

Et lui de répondre :

Je ne peux pas, tu parles tout le temps !

Derrière cette blague potache, on peut toutefois discerner une vérité universelle. Dans un flot incessant de communication, il devient difficile de faire le tri entre les informations pertinentes et celles qui ne le sont pas.

Dans le monde de l’entreprise, cela est d’autant plus vrai que le nombre d’interlocuteurs est souvent bien plus grand que dans le cadre plus restreint de la sphère familiale proche. Chaque nouvel intervenant sur un projet communique à son tour en direction de toutes les autres personnes concernées, ce qui démultiplie les échanges.

C’est toujours pareil

J’imagine que cela a dû vous arriver, d’effacer plusieurs dizaines d’emails que vous aviez reçu dans la même journée, et qui ne véhiculaient aucune information réellement utile pour vous. Et si vous réfléchissez bien, vous vous souviendrez que vous en avez vous-même envoyé un certain nombre dans la même journée.

Pourquoi envoie-t-on ce genre d’email ? Les raisons habituelles sont, en vrac :

  • Pour transmettre l’information à tous ceux qui pourraient en avoir besoin.
  • Pour élargir une discussion, s’assurer que notre désaccord avec Untel sera connu de tous.
  • Pour faire passer ses choix en douce («Comment ça tu n’es pas au courant ? Je l’ai proposé dans un email il y a 3 semaines et tu ne m’as pas dit non !»).
  • Pour se couvrir, en rejetant la faute sur les autres («Ça fait 2 mois que je vous préviens qu’on n’y arrivera pas, à raison de 15 emails par jour !»).

Et quand ce n’est pas par email, ça peut prendre la forme de blogs ou de forums d’entreprise dont le rapport signal/bruit décroit au fur et à mesure que la quantité d’information échangée augmente.