Lâchez les claviers

La tête dans le guidon

Et si on faisait une pause ?

Vous vous souvenez de cette période de votre vie, pendant laquelle vous abattiez des journées de boulot de plus de 10h pendant des semaines ? Si si, ces jours lointains (ou pas) où vous commenciez à 7h30 et terminiez après 20h ? Ne me mentez pas, ça vous est déjà arrivé. Et si ce n’est pas le cas, rassurez-vous, ça vous arrivera bien un jour. Ne soyez pas jaloux de ceux qui ont déjà eu cette expérience fabuleuse, il y en aura pour tout le monde.

Parfois, ces périodes phares sont des passages obligés dans des projets critiques, ou soumis à une date de livraison dont la définition est bien hors de votre portée. Ou parfois, il s’agit simplement d’acharnement à vouloir enfoncer un clou à main nu dans un béton armé de 20 cm d’épaisseur.

Les interruptions tuent votre productivité

Ou comment ne pas avancer dans votre tâche

Dave Lawper est arrivé à 9h sur son lieu de travail. Une dure journée de développement l’attend. Armé d’un café et de toute la bonne volonté du monde, il s’attelle à sa tâche avec ferveur.

A 9h10, son chef Herman Adgeur vient lui annoncer qu’un imprévu événementiel est tombé, et qu’il faut absolument mettre à jour la charte graphique d’une des pages de l’application web. Il faut que ça passe en prod au plus tard le soir-même.

Pourquoi séparer développeur et analyste ne marche pas

Ou le meilleur moyen de décoréler métier et application

Dave Lawper travaille au sein d’une DSI d’un grand groupe. Il est responsable de l’implémentation d’une application pour laquelle il a reçu des spécifications très détaillées, rédigées par Anne Alyste, une analyste qui lui a prémâché tout le travail. Anne a été en contact avec le métier durant des semaines, à décortiquer le moindre petit bout de métier qu’elle aura pu extraire des centaines d’heures de réunions passées avec les experts métier. Ses spécifications sont très détaillées, et il ne manque pas un seul aspect du métier concerné par le projet”.

Dans cinq ans, tu seras chef de projet

Le développeur est-il mal aimé ?

Dave Lawper est développeur dans une SSII (ou ESN pour les puristes) depuis quelques années. Il s’apprête à fêter son trentième anniversaire. Son job, il l’aime. Ecrire du code, faire de la veille, interagir avec ses équipiers et débattre qui de Postgre ou Mysql est le meilleur, voilà ce qu’il aime. Pourtant, depuis une année ou deux, son manager qui “gère” sa carrière le tanne avec un sujet, et n’a pas l’air décidé à lui lâcher la grappe.

Développeur ou codeur ?

Et si les développeurs revenaient au centre du logiciel ?

Je suis développeur depuis maintenant plus de 6 ans et je me pose des questions sur les véritables attributions d’un développeur en France. A mesure que je gagne en expérience et en nombre de postes occupés, je me rends compte que la compréhension du métier de développeur change d’une société à une autre. Laissez-moi vous raconter une histoire.

J'ai pas le temps !

Ne laissez pas votre temps libre vous échapper

J’ai pas le temps ! Dave Lawper a mis cette réplique en favori dans un coin de son crâne tellement il y a recours en permanence. Il ne se passe d’ailleurs pas une seule journée sans qu’il la prononce. Que ce soit à Herman Adger, Deb Lopez, Mundir Hecteur, Pat Ron ou encore à sa femme, il ne se prive pas pour pousser sans arrêt cette ritournelle hors de ses lèvres. Il en est convaincu. Il n’a pas le temps.

Limitez la durée de vos réunions

Et fixez toujours un ordre du jour

Vous avez très certainement, dans votre vie professionnelle, déjà passé votre journée en réunion. A la sortie, vous vous êtes fait la réflexion que vous aviez perdu votre journée. Et vous avez sûrement raison. Quoi de pire que de passer des heures, entassé avec une dizaine de vos semblables dans un aquarium, à échanger sans vraiment savoir où vous vouliez en venir ?

Scrum vs Kanban, le duel

Entre les méthodes à Gilles, mon coeur balance

Lorsqu’on parle des méthodes à Gilles agiles, Scrum est généralement le premier mot venant aux lèvres. Ce cadre est pour la plupart le point de départ lors de la première expérimentation de l’agilité. Parfois, Scrum est adapté, et répond plutôt bien au besoin. D’autres fois, ce cadre nécessite d’être tellement plié et tordu pour répondre à un besoin qu’il n’a plus rien à voir avec les préconisations d’usage. Le point de départ n’est donc pas forcément le bon. Kanban pourrait également répondre au besoin initial. Ou pas tout à fait. Mais alors, comment choisir ?

Un freelance, c'est vraiment cher ?

Et si vous regardiez plus loin que le tarif ?

Pourquoi ne pas faire appel à un freelance pour votre prochaine mission ? Oh, c’est bien trop cher, pourriez-vous me répondre. Trop cher, vraiment ? Oui, regardez son TJM, c’est deux fois plus élevé qu’un poste en CDI d’un jeune sortant de l’école. Ah. Donc vous choisiriez un vélo plutôt qu’une moto simplement parce que c’est moins cher ? Ou préféreriez un presse-citron manuel plutôt qu’un électrique pour la même raison ? Ou encore iriez laver votre linge à la rivière au lieu d’investir dans un lave-linge ? Alors dire qu’un freelance est plus cher, est-ce que ça a vraiment du sens ?

Comment nous avons géré nos branches SVN

Aussi valable pour git

La philosophie des branches mise en pratique dans un gestionnaire de version tel que Git ou SVN est trop souvent une question à laquelle on s’emploie à répondre lorsqu’il est déjà trop tard. Lorsqu’on commence à vivre le cauchemar des fusions de branches, on se demande si on n’aurait pas dû s’y prendre autrement. Un système de branches bien défini peut vous éviter de perdre des cheveux trop précocement et permettra à n’importe qui dans l’équipe de procéder aux fusions et autre gestion de branches sans avoir à se poser de question ni y semer la zizanie. Cet article a pour vocation de vous indiquer la façon dont nous avons procédé au sein de Perigee, où j’ai sévi pendant près de trois ans. Ceci est un témoignage d’un modèle qui a fonctionné pour nous, et non une recette de cuisine qui fonctionne dans toutes les situations.

C'est la faute à Raoul

Ou comment éviter la crémation sur la place publique

Personne n’aime être la cible d’une accusation, qu’elle soit justifiée ou non. C’est encore plus vrai au sein d’une équipe. Et c’est encore pire lorsque cette accusation est proférée publiquement, devant une assemblée d’yeux accusateurs et réprobateurs. L’accusation est encore plus mal perçue lorsqu’elle est formulée gratuitement, sans aucun autre but que de trouver un coupable à une faute, simplement pour trouver un responsable. Or, dans un certain nombre de cas, trouver le fautif n’apportera rien de plus que de l’animosité, du ressentiment et de la honte. Rien de bien constructif. C’est ce qui est arrivé à Dave Lawper récemment.

Interview avec Alexis

Freelance dans la conduite du changement dans la métropole lilloise

Durant les recherches que j’ai effectuées en vue de quitter le salariat et d’entamer la grande aventure du freelancing, j’ai fait la rencontre d’Alexis qui a accepté de répondre à mes questions.

Théorie de l'actionnable

Ou comment ne plus dire "Il faut que" et "Y a plus qu'à"

Dave Lawper est membre d’une équipe affectée au développement d’une application tout juste budgetée. Toute belle toute neuve sur le papier. Le premier sprint est lancé, l’équipe est motivée. La vie est rose. Au terme du sprint, chacun a bossé dur, l’équipe a bien tourné. Bilan : tous les éléments du backlog n’ont pas été livrés. Les écueils ont été nombreux, et l’équipe n’a pas réussi à atteindre l’objectif fixé. Au terme de ce premier sprint, l’équipe a pris le temps d’effectuer une rétrospective, comme toute bonne équipe agiliste. De nombreuses problématiques ont été soulevées à cette occasion :

Interview de Simo Alaoui, Développeur freelance

En région parisienne

Dave Lawper est salarié depuis longtemps, et il souhaiterait changer d’air. Il a l’impression d’être bridé par une hiérarchie trop pesante, et des contraintes qui limitent sa créativité et sa productivité. Il a cependant entendu parler d’une alternative à ce statut, à savoir celui de freelance (c’est-à-dire travailler à son compte). Dans sa quête d’informations, il a eu la chance de rencontrer Mohamed “Simo” Alaoui, un ex et futur freelance officiant en Ile-De-France, qui a pu répondre à un bon nombre de ses interrogations.

La revue de code - Final

Ou pourquoi l'adopter

il est temps de faire le bilan de tout ce que la revue de code peut vous apporter. Nous avons suivi les déboires de ce malheureux Dave Lawper. Vous me direz certainement que la plupart de ces situations sont caricaturales. Néanmoins, vous les avez rencontré (ou les rencontrerez un jour) toutes à un degré plus ou moins élevé.

La revue de code - Partie 5

Ou comment miser sur le futur

La semaine de Dave Lawper a été une des pires de sa carrière. Lorsqu’il repart le vendredi soir, il est dépité. Le projet sur lequel il travaille n’est déjà pas des plus folichons, et les obsctacles s’amoncellent devant lui sans qu’il n’ait jamais l’impression d’en voir le bout. Les cinq derniers jours risquent d’achever ce qui reste de sa détermination

La revue de code - Partie 4

Ou comment resserrer les liens

Alors qu’il baigne dans une équipe au niveau technique relativement haut, Dave Lawper se sent seul. Il a passé sa semaine à se casser les dents sur des difficultés, livré à lui-même. Les seules intéractions avec ses semblables se sont fait dans la tension, voire l’animosité. Sa bêtise du vendredi précédent est resté en travers de la gorge de la plupart de ses collègues, et il n’a pas amélioré sa situation en requérant de l’aide à plusieurs reprises. Sa méconnaissance du code front-end a fini de les exaspérer, augmentant d’autant plus la pression pesant sur ses épaules. Seul face à l’adversité, se battant avec des défis techniques hors de son monde d’origine très orienté back-end, les quelques jours ont été très mauvais pour son moral.

La revue de code - Partie 3

Ou comment partager ses compétences

Dans cet univers alternatif où Dave Lawper a effectué sa revue de code avec Deb Lopez, un phénomène s’est produit. Ils se sont rapprochés l’un de l’autre, ont échangé, et se sont embrassés mieux compris.

La revue de code - Partie 2

Ou comment chasser les mauvaises pratiques

Le correctif de Dave Lawper se situait au fin fond d’une librairie historique, écrite en C. Or, Dave Lawper a un background très orienté nouvelles technologies. Java, Groovy, Scala, il connait bien. Tout ce qui date d’avant les années 90, beaucoup moins. Les pointeurs du C, il en a entendu parler. Ca ressemble même plutôt aux références en Java, après tout. Mais les pointeurs de pointeurs, ça l’a toujours laissé perplexe. Et pas de chance, la librairie en question en était truffée.

La revue de code - Partie 1

Ou comment gagner en qualité de code

Dave Lawper a écrit son correctif en vitesse. C’était un vendredi soir, il était tard. Le fix était localisé dans une lib interne, que personne d’autre ne maitrisait. Tous ses petits camarades de jeu étaient déjà partis en week-end, pour un repos bien mérité après une semaine difficile, le laissant seul dans les locaux. Dave Lawper avait été laissé à l’abandon, sans aide extérieure. Il lui avait fallu agir, quelque soit le moyen.

La revue de code - Introduction

Ou comment débute le calvaire de Dave Lawper

Je vais vous raconter une petite histoire qui devrait vous sembler familière. Cette légende est célèbre, et connue de tous les développeurs. Certains même en tremblent à sa seule évocation, ou en cauchemardent lors des nuits les plus noires. Pour ceux qui dormaient au fond, Je vais vous rafraîchir la mémoire.

La naissance d'un blog

Ou comment la magie Devoxx opère

Dans mon précédent post, j’ai abordé la question du comment j’ai réalisé ce blog. Avant toute chose, n’est-il pas mieux de se demander pourquoi le faire ? Laissez-moi donc vous raconter une histoire.