Moi, 30 ans, développeur — et je n'ai pas raté ma vie !

11 mai 2015 travail

J’ai débarqué dans le monde du travail par une belle matinée1 de janvier 2006 — lundi 30 — pour le premier jour de mon stage de fin de master.

Les étoiles plein les yeux, quand mes nouveaux collègues me demandaient ce que je voulais faire ensuite, je répondais, bien évidemment, « je veux devenir chef de projet ». Après tout, même si les nuits blanches passées à coder sur les années précédentes m’avaient laissé de très bons souvenirs2, nombreux étaient ceux qui sortaient de l’école3 en voulant évoluer — et ce rapidement !

À la fin de mon stage, j’ai été embauché. Étrangement, après avoir fréquenté un peu le monde du travail et vu ce à quoi mes collègues occupaient de leurs journées, cela faisait quelques mois que je n’avais plus dit que je voulais devenir chef de projet : même si je n’avais pas vraiment bossé avec les technos les plus cool4, construire quelque chose était tellement fun ! Bien plus que remplir des .doc ou des .xls ou négocier des quarts de journées avec le client5 !


Plusieurs années se sont écoulées, je suis tour à tour devenu « ingénieur concepteur et développeur », « expert technique », « architecte », « développeur senior »6. Et je suis maintenant « développeur ».

En parallèle, j’ai changé plusieurs fois d’employeur, partant d’une SSII de 2000+ employés pour arriver dans une startup où j’ai une quinzaine de collègues, en passant par un éditeur regroupant une cinquantaine de personnes — chaque entreprise accordant moins d’importance aux titres, et plus d’importance aux réalisations, que la précédente.

D’ailleurs, voila plusieurs années que, travaillant en méthodes agiles, le terme de « chef de projet » ne fait plus partie de mon quotidien : l’idée de chef a été remplacée par des rôles différents7 (scrum master, product owner, développeur, …), tous collègues au même niveau hiérarchique, constituant une équipe qui vise à mener ses projets à bien8 !


Mais si évoluer n’est pas nécessairement devenir chef de projet — ce qui, d’une certaine manière, revient à changer de métier — dans les trois ans qui suivent le début de sa vie professionnelle, comment est-ce que ça se passe ?

Peut-être que évoluer, c’est aussi savoir tirer profit de son expérience ? Pour être plus efficace dans son travail, pour avoir une vision à plus long terme de ses projets, pour mettre en place des architectures ou du code plus maintenable, pour être là pour ses collègues… Et pour, finalement, aider l’ensemble de son équipe à évoluer ?

Peut-être que, en fait, ce n’est pas non plus avoir un titre pompeux sur sa carte de visite ou son CV ?


Vous vous souvenez quand, au moment de « si à 50 ans on n’a pas une Rolex, c’est qu’on a raté sa vie », on disait « si à 30 ans tu es encore développeur, c’est que tu as raté ta vie » ? Déjà en 2009, ça faisait quelque peu sourire…

Aujourd’hui, je fais un métier qui me plait, je vais au travail tous les jours en sifflotant et sans traîner des pieds, je bosse dans une boîte sympa, j’ai des collègues que j’apprécie — et même si je ne suis pas chef comme j’aurais dû l’être si j’avais écouté les autres il y a dix ans… C’est ce qui compte, non ?

Je peux donc, aujourd’hui9, affirmer fièrement : j’ai 30 ans, je suis développeur, je n’ai pas raté ma vie !



  1. Je dis belle matinée, mais je ne saurais plus me rappeler du temps qu’il faisait ; je sais juste qu’il y avait de la neige en fin de semaine, je me souviens être resté coincé dans un train pendant deux heures à cause de ça le vendredi. Quoi qu’il en soit, j’attendais la fin de mes études avec une certaine impatience : je voulais faire quelque chose d’utile — donc, c’était une bonne journée ! 

  2. Les week-ends et autres nuits blanches passés à jouer à Starcraft en LAN avec les collègues (un des avantages d’habiter dans une résidence quasi-étudiante pas loin du campus) sont un autre excellent souvenir ;-) 

  3. Quand la normalité semble être « devenir chef de projet » et qu’on ne connait pas grand chose au monde du travail ou aux différents métiers et ce qu’ils représentent exactement, le plus facile et le plus prudent est de s’orienter sur ce discours normal… 

  4. J’ai passé les 2/3 de mon stage sur de l’ASP pas NET, avant de passer sur du .NET 1.x et un tout petit peu de .NET 2 — 2006, hein ;-) 

  5. Oui, je simplifie beaucoup le rôle du chef de projet ! Rappelez-vous que ça ne faisait que quelques mois que je bossais ; et pas vraiment sur des gros projets. Finalement, je ne connaissais rien du métier de « chef de projet », si ce n’est qu’il y avait « chef » dedans, je crois… 

  6. J’ai bien eu du mal à l’expliquer à la médecin du travail, le coup du développeur sénior. Je continue à me demander si elle a saisit de quoi il s’agissait, d’ailleurs : en récupérant le papier après, j’ai vu qu’elle avait écrit « développeur séniors ». Qu’a-t-elle cru que je faisais comme métier ? 

  7. Ca m’a fait tout drôle lorsque j’ai assisté à une réunion de plannification pour la première fois, de voir que ce n’était pas le chef de projet (inexistant, pour cette équipe ! Alors qu’il était souvent tout puissant dans l’équipe que j’avais quitté deux semaines plus tôt !) qui décidait combien de temps devait être alloué à une tâche, mais bel et bien les développeurs, responsables de son implémentation, à qui on faisait confiance pour estimer le temps nécessaire ! 

  8. Même si on l’oublie parfois, mener nos projets à bien est ce pour quoi nous sommes généralement employés ;-). Cela signifie produire des logiciels qui répondent aux besoins des clients, en un temps (qui peut être un des besoins) acceptable, avec des contraintes de coût et de rentabilité (idem), tout en arrivant à quelque chose de maintenable, idéalement en s’étant fait plaisir au passage — une équation parfois complexe ! 

  9. Bien sûr, libre à moi de changer complètement d’avis (ou de métier) demain. Ou l’année prochaine. Ou dans 10 ans ;-) 

La prod est tombée !!!

5 mai 2015 travail, histoire

Aujourd’hui, je vais raconter quatre histoires : quatre cas où la prod est tombée, avec à chaque fois un contexte et des réactions différentes.


Histoire n°1

Cette première histoire commence de manière assez classique1 : le client passe un coup de téléphone au chef pour lui signaler que la prod est tombée et qu’il faudrait investiguer au plus vite.

Le chef se tourne vers son développeur, lui signale le problème et demande « qu’est-ce que je peux faire pour toi ? ». Le développeur répond que son chef peut commencer par « gérer le client » et qu’au besoin, il lui fera signe, en fonction des résultats de ses recherches.

Le développeur a résolu le problème assez rapidement. Le chef a répondu au client qui est venu aux nouvelles une ou deux fois entre-temps.

Point fort : le développeur a pu faire son boulot en paix, efficacement, sans que personne ne le dérange. En cas de problème, il pouvait appeler à l’aide ou demander des renseignements complémentaires.


Histoire n°2

La seconde histoire correspond à la mise en production d’un site grand-public, qui s’est déroulée un week-end. Au moment de valider le système de paiement utilisé par l’application, l’équipe s’est rendue compte que celui-ci ne fonctionnait pas2 — et après prise de renseignements, impossible de l’activer avant le lundi (et bien sûr, impossible de décaler de deux jours la mise en production).

Après discussion entre le développeur expérimenté et le développeur qui avait initialement branché le système de paiement dans l’application, ainsi que le chef et le client, il a été décidé de mettre en place une solution de contournement3.

Il était presque midi, les pizzas sont arrivées à ce moment là et le gros de l’équipe est parti déjeuner en salle de pause, pendant que le développeur restait à son poste, mangeant sa pizza d’une main en gardant le clavier sous l’autre, occupé à dé-brancher un premier système de paiement et à en brancher un autre passant par la solution de contournement retenue.

Point fort : l’équipe (développeurs + chefs + clients) a fait confiance au développeur : il a pu faire son boulot dans de bonnes conditions4, tout en ayant eu du soutien lors de la phase de recherche de solution.


Histoire n°3

Cette troisième histoire commence par un site grand-public tombé, en raison d’un pic de consultations brutal.

Arrive un grand-chef5 qui ordonne aux développeurs de débrancher leurs PC fixes et d’aller dans le bureau des administrateurs système, à l’autre bout du bâtiment — notez qu’il s’agit de PC fixes (donc, il faut vraiment tout débrancher, y compris écran et clavier et souris, trouver un chariot, …). Une fois arrivés à l’autre bout du bâtiment, le grand-chef ordonne de re-brancher le tout (ce qui inclut trouver une ou deux multi-prises, des chaises, de faire de la place sur un bureau, de tout rebrancher et rallumer…).

Une fois les développeurs et administrateurs système laissés entre eux, finalement, chacun des deux développeurs ayant fait le voyage s’est mis en pair avec un administrateur — sans toucher aux PCs qui avaient été déplacés. Une dizaine de minutes après, une piste était trouvée. Quelques minutes supplémentaires et une bidouille temporaire était en place pour corriger le problème au plus vite.

Bien sûr, il a ensuite fallu faire le trajet inverse, en débranchant les PCs (et rendant les chaises et multi-prises à leurs propriétaires dans d’autres bureaux), les re-posant sur le chariot, re-traversant le bâtiment, puis en rebranchant les PCs à l’autre bout, …

Point fort : les développeurs et administrateurs système ont mis en commun leurs compétences respectives (et connaissance de l’application / de la plate-forme l’hébergeant) pour rapidement trouver l’origine du problème et apporter une solution6.

Questions bonus : combien de temps a été perdu avant de vraiment s’attaquer à la résolution du problème ? Et avant de recommencer à bosser ensuite ?


Histoire n°4

Cette quatrième et dernière histoire commence elle aussi de manière assez classique : la prod est tombée, sur un site grand-public, sans raison apparente (pas de pic de consultation majeur), et les développeurs recherchent ce qui pourrait expliquer cette chute.

Le N+37 a été appelé par des gens importants, la pression monte. N+2 décide donc qu’il faut faire une réunion, avec N+1 et le lead-dev du projet. Cette réunion dure un moment, pendant lequel les autres développeurs continuent à fouiller — mais ils ont moins d’expérience que le lead-dev sur ce type de situation, connaissent moins bien que lui les points sensibles de l’application et n’osent pas mettre en œuvre seuls les pistes qui avaient été évoquées avant la réunion. Pendant cette réunion, le lead-dev propose un truc (genre modifier un paramétrage) pour essayer de calmer le feu. Le N+2 est d’accord, mais indique qu’il ne faut pas en parler à N+3.

A l’issue de cette réunion, le lead-dev retourne à son équipe, la proposition technique est mise en place et le site web a l’air de re-fonctionner de manière correcte. Le lead-dev profite de l’accalmie pour aller chercher un café.

Dans la salle de pause, le lead-dev est rejoint par le N+3 qui lui dit « j’ai vu que les graphes munin redescendaient, viens dans mon bureau et dis-moi ce que tu as fait ». N’ayant pas réellement le choix, le lead-dev suit le N+3 et explique la modification apportée (en se disant qu’il ne devrait pas mais n’a pas trop le choix — N+2 avait dit qu’il ne fallait pas que N+3 sache, mais le développeur ne fait pas de politique. Et, en même temps, la proposition en question a rétabli le bon fonctionnement du site, hein).

Après cela, le lead-dev se prend un commentaire du N+2 en mode « je t’avais dit de ne pas en parler à N+3 », suivi de l’interrogation de N+1 « mais tu lui as dit ? »

L’objectif8, après avoir lu cette histoire, est double : déterminer combien de temps a été perdu avant de résoudre le problème… Et estimer l’humeur et le niveau de motivation du lead-dev après cet incident — ainsi que son envie de continuer à bosser là.

Question bonus à laquelle personne n’a su répondre : pourquoi le N+3 a-t-il accès aux graphes de monitoring des serveurs et essaye-t’il de les analyser ? Et surtout, pourquoi est-ce qu’il ne se fie pas à ses équipes, qui ne lui font donc pas non plus confiance en retour ?


Et maintenant ?

Après ces quelques histoires, quelle situation vous convient le mieux, quand la prod est tombée ?

Pour ma part :

  • Être à deux à se mettre sur le problème, en pair (sur la même machine ou non — mais proches l’un de l’autre, pour échanger des idées et savoir ce que l’autre a fouillé ou envisage), permet d’aller plus loin dans l’analyse et de recouper les idées.
  • Mélanger les compétences (« dev » et « ops ») est un gros plus.
  • Et enfin, à mes yeux : le rôle d’un chef dans ce type de situation est de faciliter les choses pour son équipe, en absorbant la pression et en lui permettant de travailler sans être interrompu par des éléments perturbateurs (clients, hiérarchie, chef lui-même) — tout en étant disponible au besoin et en se tenant au courant (par exemple, en étant connecté sur l’outil de messagerie instantanée utilisé par l’équipe, en écoutant ce qu’il se dit — et pas en allant interrompre les développeurs toutes les trois minutes façon « c’est urgent, vous en êtes où ? » !

Et vous, des souvenirs de jours où la prod est tombée ?



  1. Une variante de ce début d’histoire, sur un projet un peu mieux outillé, serait une alerte remontée par le système qui monitore le bon fonctionnement des serveurs et applications de production. Dans ce cas, ce serait le chef qui informerait le client qu’un problème a été identifié et que la recherche de solution est en cours. 

  2. Bien sûr, si le système de paiement avait été validé en mode production à l’avance, plutôt que de considérer que ça marcherait forcément en production puisque ça marchait en test… Voilà une erreur que plusieurs membres de l’équipe n’ont pas refait depuis ! 

  3. Le niveau d’ingéniosité (enfin, de bidouille ^^ mais qui marche !) qu’on peut atteindre dans ce type de situation est assez incroyable ;-) 

  4. Et plusieurs années après, même si sur le coup c’était bien galère, le développeur a gardé un super souvenir de cette journée et de cette pizza ! 

  5. Pour cette histoire n°3, “grand-chef” correspond globalement au N+4 des développeurs. Quelqu’un de haut dans la hiérarchie, donc — à qui le développeur, peut-être encore un peu jeune et manquant d’expérience, ne dit pas “non”. 

  6. Travailler en mettant en commun les compétences des développeurs et des administrateurs système est quelque chose qui semble évident aujourd’hui à beaucoup d’entre nous. Ça ne l’était pas tellement à l’époque — le terme devops était encore loin d’être à la mode. 

  7. Pour cette quatrième histoire, les « N+X » sont relatifs au lead-dev : le N+1 est le chef de projet, le N+2 le directeur de projets web, … Autant N+1 est quelqu’un que les développeurs connaissent bien, autant N+3 est quelqu’un de plus distant, à qui les développeurs n’osent pas dire « non ». 

  8. En relisant cette quatrième histoire, je n’ai pas le sentiment qu’on puisse parler de point fort… Mis à part, bien sûr, le fait qu’une solution ait été trouvée. 

PHP : un langage, des utilisateurs aux besoins très différents

21 avril 2015 php

Il m’arrive régulièrement de discuter de PHP1 et de son évolution avec d’autres développeurs, que ce soit au bureau, lors d’événements communautaires comme les Apéros PHP ou les ForumPHP/PHPTour, ou même plus simplement par mails ou messageries instantanées.

Assez fréquemment, ces développeurs veulent voir le langage (et son écosystème) continuer à mûrir, à se professionnaliser : ils souhaitent du typage statique, des espaces de noms, du type-hinting (ou type-enforcing) sur les paramètres de méthodes ou leur valeur de retour, des générateurs, des annotations intégrées au langage, … Bref, plein de fonctionnalités qui nous — moi y compris — simplifieraient grandement la vie et nous permettraient de tirer le meilleur parti du langage que nous manipulons.

Toutefois, nous oublions souvent que nous ne sommes pas les seuls utilisateurs du langage PHP. Pour moi, en généralisant un peu et simplifiant beaucoup, on pourrait aller jusqu’à distinguer quatre catégories d’utilisateurs de notre langage. Et chacun de ces types d’utilisateurs peut avoir des besoins différents des autres !


Les débutants en programmation (et en PHP)

Une des grandes forces de PHP depuis sa naissance, et sans aucun doute la principale raison de son succès, est que PHP et son écosystème ont pendant longtemps été extrêmement accessibles aux débutants en programmation voulant faire un peu de web.

Cela se traduit à travers plusieurs points, dont notamment :

  • La gratuité, que ce soit pour de nombreux outils de développement2 ou hébergements3.
  • La facilité d’installation, de configuration et d’exécution :
    • Au niveau du poste de travail — avec, par exemple, des outils comme EasyPHP ou WAMP qui permettent d’installer une stack PHP+MySQL en trois clics sur « suivant », sans même avoir à comprendre comment ça fonctionne4.
    • Au niveau du déploiement : il suffit d’un glisser-déposer dans un client FTP, sans avoir à redémarrer un serveur d’application ou quelqu’autre lourdeur du même type.
    • Et au niveau de l’exécution : il suffit d’appuyer sur F5 pour constater l’effet du code que l’on vient d’écrire ou de déployer !
  • L’existence de nombreux tutoriels5, ainsi que d’une documentation officielle claire et en très grande partie traduite en français.

Pour un débutant, PHP doit être un langage simple : plus le langage se complexifie (par l’ajout de fonctionnalités), plus il devient difficile à prendre en main.

Même si les nouveautés de chaque version ne sont pas obligatoires et qu’il est possible de développer sans les utiliser, elles constituent autant de points qui sont susceptibles de provoquer des moments de confusion et de frustration lors de lecture de tutoriels, d’exemples de code, ou même de documentations.

PHP a été le premier langage orienté web que j’ai appris — l’autre langage que je connaissais à ce moment là est le C, qui n’est pas de bien haut niveau et ne s’encombre pas de certaines lourdeurs modernes6. Si, à l’époque, pour entrer dans PHP, il avait fallu que je me débatte avec les closures, les espaces de noms, les générateurs, composer ou symfony… Je ne sais pas si je ne me serais pas plutôt mis aux CGI7 ^^


Les amateurs

Une partie des débutants se prend au jeu, sans pour autant devenir professionnels comme beaucoup d’entre-nous l’ont fait — et deviennent alors ce que j’appelle des développeurs amateurs. Cette appellation regroupe pour moi ceux dont le développement n’est pas le métier, mais qui en savent assez pour oser mettre en place des scripts ou de petites applications répondant à leurs besoins.

Comme exemple assez marquant, j’avais un collègue il y a quelques années qui était product owner : son métier n’était pas le développement, mais il avait suivi quelques cours de JAVA et PHP à l’école et travaillait dans une entreprise où il côtoyait quotidiennement nombre de développeurs. Il se débrouillait suffisamment bien en PHP pour développer des scripts lui permettant d’automatiser certaines tâches (détection de mise à jour et téléchargement de documentation, parsing de fichiers CSV pour en extraire les valeurs importantes, …) qu’il aurait autrement dû effectuer manuellement. Sans pour autant avoir un compilateur dans la tête, il était capable de comprendre la structure d’une portion de code et ce qu’elle faisait dans les grandes lignes — ce qui facilitait d’autant les échanges avec les développeurs de son équipe !

PHP est à mes yeux un bon langage pour ces amateurs : sa simplicité d’utilisation (cf ce que je disais plus haut pour les débutants), combinée à sa verbosité ainsi qu’à sa souplesse (au niveau du typage, notamment), en font un outil bien adapté aux besoins de personnes qui souhaitent automatiser des tâches, sans que le développement ne soit pour autant leur métier. En contrepartie, cette souplesse peut parfois être à double tranchant, puisqu’elle encourage trop souvent des pratiques de développement peu sûres, notamment au niveau de ce qui est sécurité.

Pour PHP lui-même, le juste-milieu est difficile à trouver pour les développeurs amateurs : ils ont des notions, parfois bonnes, en programmation et sont capables de comprendre des concepts assez avancés — à condition que ceux-ci arrivent graduellement et ne masquent pas la simplicité du langage en le rendant moins accessible.


Les utilisateurs et intégrateurs de logiciels

Ma troisième catégorie de développeurs est composée de ceux qui partent de logiciels existant (assez typiquement, des CMS comme Drupal ou Wordpress) qui répondent au gros de leurs besoins et tirent profit de l’extensibilité de ces outils pour développer des modules complémentaires répondant aux quelques pourcents de leurs besoins qui ne sont pas couverts de base.

En fonction de l’outil choisi, les développements peuvent être assez cadrés, rendant difficile (ou décourageant, ne serait-ce que par leur non-utilisation dans le cœur de l’outil) l’utilisation de certaines fonctionnalités récentes. De plus, des contraintes de compatibilité avec de vieilles versions de PHP peuvent être souhaitées pour les modules qui sont destinés à être diffusés auprès de la communauté.

En fonction de leur niveau d’expérience, des fonctionnalités qu’ils souhaitent développer (faut-il personnaliser beaucoup ou peu ?), ainsi que de leur volonté ou non de diffuser ceux-ci à un large public, les développeurs de modules pour ces logiciels vont avoir tendance à exploiter ou non les fonctionnalités avancées de PHP8.

Pour ce public cible, qui compte nombreux professionnels, un langage qui évolue peut faciliter le travail sur le long terme, même si ces évolutions requièrent parfois une passe de formation : celle-ci sera probablement amortie au bout d’un moment. Cela dit, le langage doit rester stable, et ne pas subir une révolution tous les ans !


Les développeurs (PHP) full-time

Le dernier groupe de développeurs que j’ai retenu pour cet article est composé de ceux dont le développement est le métier principal — considérant mon lectorat habituel, il y a de bonnes chances pour que vous soyez dans ce cas.

Pour beaucoup de développeurs à plein temps, chaque nouvelle fonctionnalité, chaque évolution, est susceptible de nous faire gagner du temps ou d’aider à améliorer la qualité de nos projets : manipulant PHP au quotidien, que ce soit dans un contexte pro ou en dehors, le temps investi à expérimenter avec les usages d’une évolution sera rapidement amorti ! C’est par exemple souvent ici que sont regroupés ceux qui voudraient plus de typage statique, plus de type-hinting, ou encore ceux qui regardent avec un certain intérêt les spécificités du langage Hack.

Le plus souvent, les développeurs PHP avec qui je discute d’évolution du langage font partie de ce dernier groupe — et oublient qu’ils ne représentent qu’une (petite) partie des développeurs qui manipulent PHP ! Même si c’est peut-être celle qui a le plus tendance à s’exprimer dans la communauté ?


Et PHP dans tout ça ?

Au milieu de ces quatre types d’utilisateurs, l’évolution de PHP est tiraillée entre des besoins très différents :

  • D’un côté, le langage doit évoluer et continuer à se professionnaliser, pour répondre aux besoins de ceux d’entre nous qui l’utilisent tous les jours, sur des applications importantes, où la maintenabilité et l’évolutivité sont primordiales. Et des très gros progrès ont été fait ces dernières années !
  • Mais, d’un autre côté, le langage doit rester fidèle à son image de facilité et d’accessibilité : sans débutant hier, PHP n’aurait jamais eu la place qu’il a aujourd’hui. Et sans débutant aujourd’hui, PHP ne conservera pas sa place actuelle.

Au-delà des dimensions politiques et de maintenabilité de PHP en lui-même, ces deux points de vue, souvent opposés, se retrouvent fréquemment lors des discussions autour de propositions de fonctionnalités au sein du langage — et sont parfois une explication au fait que certaines évolutions, qui pourraient sembler indispensables à un groupe ou inimaginables à l’autre, passent ou non.



  1. PHP au sens large : le langage et son évolution, l’écosystème applicatif, les frameworks et bibliothèques, les outils, la qualité, … 

  2. Pour développer en PHP, un éditeur de texte suffit — même si, avec le temps et l’expérience, on aura souvent tendance à se tourner vers des environnements plus complets. 

  3. Ça se fait peut-être moins maintenant qu’il y a quelques temps (ça fait un moment que je ne me suis pas posé la question), mais avant, on trouvait des hébergements PHP gratuits un peu partout. 

  4. Comprendre comment une pile serveur web + langage côté serveur + base de données fonctionne est important lorsque l’on souhaite progresser vers du développement plus poussé… Mais est-ce qu’un débutant a réellement besoin de comprendre ces notions dès qu’il se lance ? A mon avis, non : il y a plus intéressant (et plus fun !) à voir avant ! 

  5. J’admets : le problème avec de nombreux tutoriels est qu’ils sont vieux, pas forcément mis à jour avec les bonnes pratiques de développement, parfois bourrés d’erreurs et de références à des fonctions obsolètes ou à des pratiques dépassées (y compris dans des tutoriels récents) — donnant ainsi parfois de mauvaises habitudes aux développeurs débutant qui les suivent souvent aveuglément. 

  6. En fait, lorsque j’ai commencé à apprendre le PHP, ce langage pouvait presque être comparé à du C (en supprimant le gros de la gestion de la mémoire, ce qui simplifiait bien les choses). En particulier, il n’y avait pas, en PHP, d’orientation objet et de tout ce qui va avec ! 

  7. J’ai fait un peu de Perl dans ma jeunesse, et j’aimais beaucoup en écrire (en relire, par contre, c’est autre chose). Si me mettre à PHP avait semblé plus complexe que fouiller l’écriture de CGI en Perl, je ne me serais peut-être pas mis à PHP ! 

  8. J’ai il y a quelques années eu l’occasion de développer plusieurs modules un peu complexes pour Drupal 6 (qui n’était lui-même pas vraiment « orienté objet ») — et je n’ai pas hésité à tirer profit des fonctionnalités avancées du langage. 

Des réunions sans ordinateur ni téléphone ? C'est possible !

31 mars 2015 agile, réunion, travail

Qui n’a jamais eu l’occasion de voir un conférencier faisant face à une armée de laptops ouverts, en se demandant si l’audience lui prêtait réellement attention1 ?

Qui n’a jamais vécu la situation suivante, lors d’une réunion ?

— Tu peux répêter la question ?
(intérieurement) Forcément, tu avais plus l’air plus absorbé par ton téléphone que par ce qui se disait…
— Bien sûr, je demandais si …

Ou encore, qui n’a jamais pris le temps de lire un mail alors qu’une collègue présentait le résultat de plusieurs jours de travail ? Voire même d’y répondre2 ? Ratant au passage une partie du message ou du raisonnement suivi ?

J’ai été dans les trois situations : j’ai déjà arrêté de prêter attention pendant quelques secondes à une personne qui prenait le temps de me présenter un sujet, j’ai déjà été dans une salle pleine en ayant le sentiment que le conférencier parlait dans le vide, et j’ai déjà eu envie de faire remarquer qu’il n’était pas très correct de faire répêter alors qu’on n’écoutait pas quelques instants plus tôt.

Un de mes profs d’IUT considérait qu’à partir du moment où un étudiant était devant un PC, il n’écoutait plus aussi attentivement… En fait, il n’avait peut-être pas tord : je sais que moi-même, avec un écran devant moi, ai tendance à le regarder de temps en temps !


Par conséquent, pour éviter de faire aux autres ce que je n’aime pas qu’on me fasse, je tâche désormais de ne prendre mon PC portable pour aller en réunion qu’aussi peu souvent que possible : uniquement si j’ai quelque chose à projeter (et je le ferme quand j’ai terminé) ou lorsqu’il s’agit d’une réunion pendant laquelle je vais réllement en avoir besoin (pour coder, par exemple).

Dans la même logique, je ne garde mon téléphone avec moi que si j’attends un appel qu’il ne faut impérativement pas que je rate — et je ne regarde pas mes mails ni mes SMS / hangouts dessus3. La majorité du temps, il reste posé à côté de mon ordinateur, loin de la salle de réunion : comme pour les mails, il est rare qu’un appel ne puisse attendre une heure ou deux !


Au bureau, un collègue et moi essayons depuis peu de pousser cette pratique en avant — en commençant par les démos de fin de sprint, puisqu’il s’agit de la réunion organisée par l’équipe technique (dont nous faisons tous deux partie) à laquelle l’ensemble de nos collègues sont invités.

Nous sommes en effet convaincu que certaines réunions peuvent être plus efficaces et plus courtes si les participants prêtent toute leur attention au sujet du jour ; quitte à ne pas venir et à se consacrer pleinement à une autre tâche s’ils estiment ne pas y avoir leur place.

Lors de notre avant-dernière démo il y a quelques semaines4, nous avons annoncé à l’oral que nous souhaitions que chacun vienne sans portable5. En fin de semaine dernière, nous avons été un peu plus loin, en scotchant l’affiche suivante à l’entrée de la salle de réunion6 :

Une démo de fin de sprint ?

Bien sûr, en échange, nous avons également fait quelques efforts de notre côté, pour que le temps investi par chacun soit rentabilisé au mieux.

En particulier, nous avons ces derniers mois progressé sur la préparation et la forme de nos démos :

  • nous les faisons désormais systématiquement à deux, de manière à ce qu’un développeur parle, debout, en regardant son public, pendant que l’autre manipule pour lui le PC qui sert à démontrer le travail effectué (et nous échangeons les rôles en milieu de démo),
  • chacun des deux démonstrateurs passe deux à trois heures, la veille, à préparer son texte et ce qu’il souhaite montrer,
  • et ils effectuent une répétition orale le matin même, pour adapter les derniers détails (il n’est pas rare de se rendre compte, en parlant, que certains éléments ne sont pas aussi clairs qu’ils pourraient l’être) et s’assurer que tout est prêt (cas d’exemples, navigateurs déjà ouverts avec les bons onglets, …)

Le résultat est une démo de fin de sprint qui est plus rythmée, qui dure moins longtemps (une vingtaine de minutes, contre une grosse demi-heure il y a quelques mois) et suite à laquelle les questions sont mieux ciblées : tout le monde y gagne !


Pour faciliter un peu la transition, encourager tout le monde à jouer le jeu et aussi donner un aspect plus festif à la démo de fin de sprint, une approche sympa peut être celle-ci, qui complète l’affiche reproduite plus haut7 :

Quelques viennoiseries !

Nous avons pour la première fois demandé de venir à notre démo sans portable il y a trois semaines ; une majeure partie de l’équipe a joué le jeu. Et la semaine dernière, pour la seconde fois ? Aucun ordinateur8 ni téléphone dans la salle pendant les 20 minutes de démo !


  1. Et ce que la conférence soit intéressante ou non ! 

  2. Après tout, un mail, c’est forcément urgent et ça ne peut jamais attendre une heure ! #sarcasm 

  3. Pour éviter la distraction de la diode qui clignote, une approche est de poser le téléphone écran contre la table — ou de le garder dans la poche. En n’activant le vibreur que pour les appels téléphoniques et en le désactivant pour toutes les autres notifications ;-) 

  4. Notre équipe bosse en Scrum, avec des sprints de trois semaines. 

  5. Notez l’emploi du terme portable, volontairement ambigu, qui pouvait signifier aussi bien ordinateur portable que téléphone portable

  6. La formulation ne se veut volontairement pas trop sérieuse : le but n’est pas de repprocher quoi que ce soit à qui que ce soit ! 

  7. À pas loin de 25€ de viennoiseries toutes les trois semaines, cette approche n’est malheureusement pas tellement jouable sur le long terme ;-( 

  8. sauf celui du présentateur, bien sûr — qui attend de toute façon la fin de sa démonstration pour prendre une viennoiserie ; difficile de parler, sinon ^^ 

PHP 7 et processus d'évolution de PHP : slides de ma présentation à l'AperoPHP lyonnais du 25 février

3 mars 2015 slides, php, php-7, afup, aperophp, internals@

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP :

Les apéros PHP sont ouverts à tous, quelque soit le niveau, le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien, en fonction des envies de tout le monde.

Lors de l’Apéro du 25 février 2015, j’ai eu l’occasion de donner une présentation, où j’ai parlé des nouveautés apportées par PHP 7, la prochaine version majeure de notre langage de prédilection, ainsi que du processus d’évolution de PHP, notamment à travers la mailing-list internals@.

Les slides que j’ai utilisés comme support sont disponibles en ligne2 : PHP 7 et processus d’évolution de PHP : slides de ma présentation à l’AperoPHP lyonnais du 25 février.



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s