Note de lecture : The Passionate Programmer, par Chad Fowler

Note : 6 ; Juste une nouvelle édition actualisée et améliorée dans les idées développées dans le précédant ouvrage

J’ai une habitude, probablement détestable : je pénalise d’un point les secondes éditions qui sont justes aussi bonnes que les premières éditions ! Cette seconde édition de « My Job Went to India », car c’est bien de cela qu’il s’agit même si le titre a changé, subit cette règle de plein fouet. Comme nous allons le voir, si l’évolution du texte va au-delà du cosmétique, c’est surtout le changement de titre qui reflète mieux l’intention première du propos.

A format équivalent, cette nouvelle version, avec près de 200 pages en accuse 20 de plus que l’opus précédent. 5 nouveaux items sont apparus et 4 ont disparus (ceux du dernier chapitre), un bilan qui passe donc de 52 à 53 items. On retrouve les mêmes chapitres que précédemment, à l’exception du dernier qui a disparu. Donc, c’est 5 chapitres au lieu de 6. La première partie « choose your market » comporte 10 items au lieu de 9 précédemment, mais avec quelques changements. Mon item « à emporter » est le n° 4 : Be the worst ! Comme le disait Miles Davis, pour progresser, il faut choisir le groupe où l’on sera le moins bon joueur !

Lire la suite

Note de lecture : Réussir votre parcours professionnel en temps de crise, par Willet Weeks

Note : 4 ; Une vision assez vintage des changements d’orientation des « C levels ».

Il faut replacer ce texte dans son époque, à savoir la crise de la première guerre du golfe et la récession des 3 années qui suivirent. Le monde a bien changé depuis et c’est sans doute ce décalage qui rend la lecture savoureuse, car le texte était clairement pertinent à l’époque. En fait, il l’est toujours à maints égards.

C’est un texte assez court, il compte moins de 150 pages. Il est découpé en 2 parties pour un total de 7 chapitres. La première partie « êtes-vous prêt à affronter le changement ? » regroupe 3 d’entre eux pour un total d’environ 60 pages. Il commence par un chapitre pour nous aider à déterminer si nous sommes d’un naturel casanier ou aventurier. Le propos est clair et peut aider à des prises de consciences. Toutefois je trouve les traits un peu violemment marqués. L’auteur nous propose 2 questionnaires pour nous aider. Très bonne idée.

C’est également sur un questionnaire que débute le second chapitre « le poids des habitudes ». J’y retrouve certains éléments de l’excellent livre de Charles Duhigg, à savoir que les habitudes nous aident à dédier notre attention à des choses plus importantes. Mais on peut très rapidement devenir prisonniers de nos habitudes ! Le message est clair : il est indispensable de se débarrasser de nos fixations passées. Cette première partie se conclut sur un chapitre pour nous aider à identifier nos besoins et nos atouts. J’y retrouve les éléments de la motivation intrinsèque chers à Daniel Pink. Et surtout l’auteur nous exhorte à ne pas confondre souhaits et besoins. Les atouts sont plus légèrement traités. Mais surtout l’auteur nous propose un processus à base de matrices pour étudier l’adéquation d’un poste avec nos besoins/atouts. Un peu lourd mais intéressant.

La seconde partie « Le changement » regroupe les 4 chapitres restants, soit environ 70 pages. Il s’ouvre sur un chapitre 4 pour nous aider à capter les signaux d’alarme. L’auteur s’appuie sur sa longue expérience pour analyser des situations vécues qu’il nous raconte. Instructif et captivant. Le chapitre 5 est plus court et évoque les situations de licenciement. L’auteur nous invite à ne pas rater notre sortie, bien structurer son temps une fois dehors et surtout à ne pas nous sous-évaluer suite à cet évènement traumatique.

Lire la suite

Hiring the Best Knowledge Workers Techies and Nerds, par Johanna Rothman

Note : 6 ; De la définition de poste jusqu’à l’embauche

Le recrutement est probablement le facteur le plus important de la constitution d’une équipe. Avec le temps, on finit par développer une certaine expérience sur le sujet, et aussi une approche de ce qui est important, déterminant et ne l’est pas. Et à un moment donné, on souhaite confronter ces idées instinctives aux personnes expertes du sujet. C’est à ce moment que l’on s’aperçoit que ces experts ne sont pas si nombreux, la plupart se bornant à de classiques conseils RH sans valeur dans notre domaine. S’il est un auteur auquel j’attache quelque importance dans ce domaine, c’est bien Johanna Rothman.

Sur ce sujet, notre experte du management agile nous gratifie tout de même d’un ouvrage comptant 280 pages sans les annexes (comptez une cinquantaine pour ces dernières). Johanna Rothman a délibérément choisi de couvrir tout le cycle de vie du recrutement, donc en ne se limitant pas à l’interview. Par ailleurs, ce livre ne s’adresse pas spécialement à de l’embauche en contexte agile et certains éléments du cycle de recrutement sont assez spécifiques du contexte américain. Toutefois, aucun de ces deux points n’est un obstacle, l’approche de l’auteur est en effet très convergente avec ce que l’on essaie de faire (en tout cas moi) lors d’un recrutement en contexte agile.

Passons maintenant en revue le texte. L’ouvrage compte 5 parties distinctes totalisant 15 chapitres. La première partie couvre globalement les questions de définitions de poste. Elle est longue de 65 pages et comprend 3 chapitres. Le premier couvre une vingtaine de pages et traite de la stratégie d’embauche. Il culmine avec un « hiring strategy template » permettant de s’orienter entre embauche externe, contractant, embauche interne, etc. en fonction du type de besoin et du contexte de la recherche. Malgré sa qualité, ce n’est pas ce qui m’a intéressé le plus. Le propos du chapitre suivant est « d’analyser le job », il occupe 30 pages et nous conduit à déterminer les compétences techniques et humaines nécessaires en fonction du type de travail. Une analyse très fine et pertinente qui va jusqu’à évoquer les questions de fit culturel avec l’entreprise et les facteurs d’élimination. Cette partie se conclut avec le chapitre 3 qui traite sur une dizaine de pages l’écriture de la fiche de poste. Il s’agit du chapitre qui m’a le moins intéressé : l’auteur nous propose une fiche de poste des plus classiques (bien que complète) mais qui ne sera pas à même de faire briller les yeux…

Lire la suite

Des Ressources Humaines au Capital Humain avec l’agilité

Tel que nous les vivons aujourd’hui, la gestion des ressources humaines et l’état d’esprit agile ne semblent pas fait pour se marier ensemble. Mais c’est bien de cela que nous a parlé Jas Chong lors de ce Meetup organisé par Agilebee. J’avais rencontré Jas Chong il y a peu, lors de l’open-space du Scrum Day.

Aujourd’hui c’est le retour d’expérience d’une transition qu’elle évoque avec nous.

image

Jas a passé pas mal de temps à nous camper le contexte. Pour ma part, je vais faire beaucoup plus court : il s’agit d’une transformation digitale dans le domaine du voyage. Une transformation qui passe par l’agilité et la rationalisation de l’organisation des développements à l’échelle internationnale ! C’est là que Jas intervient.

Lire la suite

Carnet de route : Le ScrumDay 2014 (3/4)

Nouvelle journée, nouvelle énergie. Après la journée conférence que je vous ai comté ici et ici, voici la journée consacrée à l’open-space, à l’image de ce qui se fait à Grenoble depuis quelques années déjà.

L’organisation met à notre disposition tout ce qu’il faut pour se remettre dans le rythme : thé, café, jus de fruits, viennoiseries…

image

Mais on est vite intrigué par le grand cercle matérialisé à même le sol autour duquel nous sommes invités à nous rassembler pour débuter cet open-space.

image

Ce sont Laurent Bossavit et Raphael Pierquin qui se chargent d’expliquer les règles de fonctionnement de l’Open-space … ou du moins tentent de le faire ! Apparemment, la sonorisation pose quelques problèmes…

image

Le principes sont en fait assez simples. Une fois établis, il est temps d’utiliser le matériel mis à notre disposition au centre du cercle pour proposer nos sujets.

image

Ces sujets sont ensuite eux-mêmes affichés sur les différents créneaux horaires en mode auto-organisé. C’est la « place de marché ».

image

J’ai posté mon propre sujet. Il est temps de faire le tour de ceux qui peuplent le premier créneau horaire. Et je reste un peu perplexe devant le sujet traitant de l’utilisation des points de fonction dans les projets agiles. Quand je vois ce genre de sujet, mon reflexe est de me demander en quoi ces techniques peuvent nous apprendre quelque chose, si la technicité développée ici peut nous aider. Laurent Bossavit semble plus circonspect quand aux motivations. Du coup, nous décidons tous deux de nous joindre à ce débat.

Agilité et point de fonction

La première chose qui me trouble est une certaine confusion entre l’outil et l’usage. Dans l’esprit de beaucoup, il y a une relation directe entre projet au forfait et point de fonction.

image

En fait, il semble même que nous ayons un pattern d’usage : on se sert des points de fonction comme outil « commercial » pour chiffrer une réponse à appel d’offre. Ensuite, lors de la réalisation, on se servira des story points. Voilà un constat assez troublant pour moi, bien qu’instructif sur la vision que l’on peut avoir des différents outils :

  • Les points de fonction sont vus comme un outil donnant un chiffre absolu, alors qu’il donne un chiffre relatif (les points) qui se transforment en charge via des facteurs d’ajustements. Comme les story points, en fait, bien que de façon plus complexe.
  • Quel est l’intérêt de faire un « chiffrage agile » si en amont le projet est de toute manière verrouillé par un chiffrage contractuel ? Je dirais même : quel est l’intérêt de faire le projet en agile, mais c’est sûrement une autre question…

La discussion s’est beaucoup focalisée sur l’usage de l’une ou l’autre approche, alors que je pense que la question n’est pas là : on peut parfaitement utiliser les FP ou les story points dans les mêmes contextes.
Par contre les points de fonctions traitent des « blocs » plus gros, qui sont ensuite décomposés sous l’angle technique (requêtes, entités, I/O, etc…), alors que les story points s’adressent à des blocs plus fins que l’on évalue globalement, en différent les questions sur les choix de conception. Par son approche les points de fonction « vérouillent » les choix techniques dès le chiffrage.

image

J’ai été assez déçu par le débat qui ne s’est finalement pas dirigé vers la question de la nature de ces différents types d’estimation (ce que j’évoque plus haut). Dommage…

Ressources Humaines et agilité

Ce sont à la fois l’originalité du sujet et son importance qui m’ont attiré vers ce groupe. Une groupe à coloration un peu « grandes gueules » avec Pablo Pernot et Pierre Neis, par exemple !

image

Tout d’abord, quels sont les problèmes ?

  • La gestion du parcours professionnel.
  • La gestion des évaluations.
  • La dissonance cognitive entre rôle et fiche de poste.

Le constat partagé par tous est qu’aujourd’hui les RH ne sont pas une aide au sein des projets agiles. Dans le meilleur des cas. Dans le pire des cas, elles sont un frein, voir un obstacle. Bref, il n’y a pas grand monde dans le cercle à aimer les RH. On entend même que les RH n’ont pas de raison d’être !

image

Mais il nous faut aussi admettre que l’on doit mieux comprendre le problème des RH : celui de devoir composer avec la loi, le management, les syndicats, le C.E., etc… En fait, il nous semble que leur effort porte plus sur la composition de ces contraintes que sur une véritable fonction support au sein de l’entreprise (ce serait plutôt un fonction contrainte !). Le mécanisme des entretiens annuels est bien entendu montré du doigt.

Alors, quelle solution pour la RH dans un environnement agile ?

C’est que cette RH devienne elle-même agile, en portant les valeurs agiles au niveau de l’entreprise. Entre autre choses.

image

Pause déjeuner

Pas de pause déjeuner bien calée dans le temps pour cette journée open-space ! Les session occupent les créneaux horaires sans discontinuer. Aux participants de faire une pause quand ils le désirent !

image

On est un peu plus en mode picnic que la veille, d’ailleurs les tables ont disparu au profit de quelques « mange debout », mais on s’assoit aussi par terre.

image

Cela ne veut pas dire que la qualité n’est pas au rendez-vous. Au contraire ! Je n’ai aucune raison de renier mes éloges d’hier. Jugez-en !

image

De mon côté, j’ai passé cette pause déjeuner avec Pierre Hervouet, Joumana et Pierre Neis. Pierre Neis nous parle (et nous montre des photos) de #play14, un rassemblement autour des agiles games qu’il co-organisait au Luxembourg. Prochaine étape : en faire une sorte d’Agile Tour des agile games !

Le bureau du SUG en mode Happy

Christopher Mann était le photographe de ce ScrumDay (il avait fait un excellent boulot lors d’Agile France, une bonne raison pour moi de le recommander pour cet évènement). J’ai suivi le mouvement, quand lui-même et le bureau se sont dirigé vers l’extérieur pour ce qui semblait une photo de groupe. Le résultat est visible sur le reportage du ScrumDay, mais j’ai aussi pris mes propres clichés…

image

Backlog, cher boulet…

J’avais aussi soumi mon propre sujet. En quelque sorte une reprise d’un de mes thèmes préférés sur le backlog produit, à la fois vision de ce qu’il y a à faire et frein du changement.

image

Au final, on trouve deux grand types de situation :

  • Les projets agiles « classiques » où la vision d’un périmètre complet est plutôt une chose souhaitée. Le backlog Scrum rempli bien son office car il donne une vue partagée à tous les acteurs du « reste à faire ».
  • Les projets innovants pour lesquels on essaie de limiter le stock par diverses approches (parfois combinées) : approche type « kanban » où l’on limite volontairement et activement le nombre d’items dans le backlog, où backog à granularité différentielle, à deux ou trois niveaux.

Dans le cas d’une approche « kanban » nous nous sommes posé la question d’évacuer, c’est à dire supprimer les items de plus basse priorité dépassant le WIP. Nous en sommes arrivés à la conclusion qu’il n’y a aucun dommage à le faire : si l’item est important, il reviendra !

J’ai aussi évoqué les sujets qui m’interpellent en ce moment : combiner un backlog (limité) avec une approche type impact mapping et/ou Lean Canvas. Mais nos réflexions n’ont pour l’instant pas abouti…

image

Clôture des ScrumDays

Ce grand open-space s’est terminé par une retrospective type « tour de parole ». Un tour de parole à près de 200 personnes, il faut dire !

image

Il me manque le courage (ou la motivation) pour en être. Je préfère passer un peu de temps avec Samira Batahouche d’IBM qui représentait Big Blue au bureau l’an dernier et avait accueilli le ScrumDay à Bois Colombe l’an dernier.

Le stand de Cloudbees est juste à côté, j’en profite pour fixer pour la postérité Nicolas De Loof en hôtesse d’accueil…

image

Scrum.org était aussi partenaire du ScrumDay cette année. Je me suis vu interdire de prendre le stand en photo, une première pour moi. J’ai moi-même étendu cette interdiction à la keynote de clôture faite par son représentant (je ne me souviens même plus de son nom, pourtant il s’est cité lui-même durant sa présentation).

J’avais aussi décidé de ne prendre aucune note de l’intervention pour faire bonne mesure. Grand bien m’en a pris : elle manquait complètement d’intérêt, j’ai failli quitter la salle. Finalement je suis resté et j’ai consulté mon fil Tweeter pendant le reste de la présentation.

Si j’étais parti, je n’aurais pu prendre en photo l’équipe du French SUG, et cela aurait vraiment été dommage. Grand merci à toute l’équipe pour ce bel évènement ! De droite à gauche : Anne, Christopher, David, Arnaud, Valérie, Karine, Laurence et Xavier.

image

Voilà, il est temps de replier tous le matériel, et de tout remettre dans les cartons … jusqu’à l’an prochain.

image

Note à moi-même

Pour ce qui est du format tout d’abord : le ScrumDay (ScrumDays, donc comme je l’ai écrit par ailleurs), ça marche ! Les open-spaces dans des « coins de salle » ne sont toutefois pas une configuration idéale. il faudra trouver mieux et surtout moins bruyant !

Cette année, le thème était la « culture produit ». En fait cela ne me paraissait pas si évident au vu du programme. Maintenant, est-il nécessaire d’avoir des thèmes annuels ? Des tracks thématiques feraient assez bien l’affaire.

Concernant le lieu, eh bien il a clairement la taille voulu pour accueillir l’évènement. Le hall central (qui hélas n’était pas central) permettait une bonne circulation. Les stands des sponsors étaient disposés sur le pourtour.

Question sponsors, leur nombre était réellement à l’inflation, et cela fait un peu ressembler le ScrumDay à une expo (sans compter un traitement pas différentiant des platinums) … La raison est bien entendu le coût d’organisation, car le lieu est apparemment très cher, malgré son éloignement de Paris.

J’avais crains que cet éloignement, justement,  soit une cause de désaffection, d’autant que la venue en voiture n’est pas vraiment facilitée (pour ne pas dire franchement découragée), mais il semble au final que ce facteur n’ait eu aucune influence.

Bref, un bel évènement, avec deux fois plus de plaisir pour deux fois plus de durée !

Une dernière chose : nous n’en avons pas fini avec ce ScrumDay : je vous ai promis un 4ème volet : ce sera un « bonus track », je n’en dis pas plus. Je ferais aussi un petit post sur mon atelier sur l’acceptance testing.

Agile Playground #8 (en images) !

Pour changer un peu, l’Agile Playground de ce mois ne déroulait pas chez Valtech, mais dans les locaux de CLT Services. Un espace un peu plus réduit, donc une contrainte de places plus importante. Elle avait été fixée à une trentaine de personnes. Je m’étais dépêché de m’inscrire. Youpi, tant pis pour les autres …

3 jeux étaient en lice. J’avais fixé mon choix sur celui de Yannick Ameur

Atelier RH Team

Comment recruter agile ? Peut-on recruter agile ?

Yannick était ce soir-là le maitre de cérémonie pour ce défi !

apg8-yannick

Votre mission, si vous l’acceptez consiste à créer la fiche poste de votre job que l’on va afficher et trier.

apg8-rh2

S’en suivent les entretiens avec les candidats. Tout d’abord en mode “old school”. Avec vôtre serviteur pour être honnête… Puis en mode “agile” en faisant participer toute l’équipe.

apg8-rh4

Après, c’est le débriefing et les leçons tirées de l’exercice.

apg8-rh3

Yannick nous fait le plaisir de mettre à notre disposition le support servant de trame à l’atelier. Le voici donc.

Cocktail

On termine comme à l’acoutumée autour d’un verre et de longues discussions qui nous font toujours rentrer bien tard dans nos penates !

apg8-cocktail1

Nos discussions ont pas mal tourné autour du coaching : qu’est-ce qu’un coach agile ? Est-ce un coach sportif, un coach miroir “posture basse”, un expert, un mentor, etc… ou un mixte de ces différents rôles ? Le question est trop large pour que je m’étende dessus aujourd’hui. Un autre jour peut-être dans ces colonnes …

Evaluation des compétences et suivi de carrière

Comment évaluer et donner un sens au suivi et à l’évolution de carrière en informatique ? La traditionelle approche de l’escalade de l’échelle hiérarchique n’a pas réellement de sens et n’intéresse généralement pas les informaticiens. De plus il n’y a pas de place pour tout le monde sur cette foutue échelle.

Cette présentation date d’il y a 8 ans (déjà…) et propose une approche inspirée du SWEBOK et du “Professionnal Software Development” de Steve McConnell au sujet duquel j’avis déjà posté une note de lecture.

Note de lecture : New Programmer’s Survival Manual par Josh Carter

Note : 4 ; Manque de ciblage clair

Sur le papier, le public cible de ce livre est claire : donner au jeune développeur arrivant dans la vie professionnelle une boite à outil pour lui permettre d’acquérir plus rapidement les bonnes habitudes et les bons comportements. C’est pourquoi les 225 pages de cet ouvrage au format inhabituel, plus proche du roman que du livre informatique dont nous avons l’habitude, sont découpés en 33 « tips ». Jusqu’ici tout va bien. En fait, cela ressemble au format emprunté par son ainé, le « pragmatic programmer ». Bonne également, l’idée de découper l’ouvrage en 4 parties :

  • Professionnal programming : 14 tips sur 2 chapitres, couvrant près de 100 pages, donc pas loin de la moitié du livre.
  • People skills : 9 tips sur presque 50 pages et toujours 2 chapitres.
  • Corporate world : Les deux chapitres composant cette partie regroupent 6 « tips » sur presque 50 pages aussi.
  • Looking forward : clos le texte avec 3 tips sur un seul chapitre.

Les conseils toutefois, quand on rentre dedans semblent un peu disparates. C’est sans doute pour cela que l’auteur à attribué 3 niveaux de maturité aux conseils qu’il prodigue : ceinture blanche, ceinture marron et ceinture noire. De mon point de vue c’est l’erreur fondamentale du livre. Au lieu de cibler le débutant l’auteur tente d’adresser différents publics et finalement ne satisfait correctement aucun d’entre-eux. C’est dommage car l’auteur écrit fort correctement et son savoir-faire et la pertinence de ses idées est réelle.

Le livre a voulu cibler trop large en parlant à différents publics, mais aussi en élargissant son débat depuis le craftmanship jusqu’aux aspects sociaux dans l’entreprise. On se trouve ainsi avec du code (Ruby) en début d’ouvrage et des questions sur les cycles de développement produit vers la fin. Ce n’est pas une diversité qui me choque en soi, mais j’ai du mal à y trouver une cohérence dans le propos.

En lisant ce livre, je n’ai pu m’empêcher de le comparer à « SQL antipatterns ». Ce dernier réussit là où celui-ci échoue. En effet ce premier à choisit délibérément de s’adresser au développeur souvent peu expert (et peu intéressé) par les questions ayant trait aux bases de données et à la modélisation de celles-ci. Je pense que ce « new programmer’s survival manual » aurait dû atteindre la qualité du « SQL antipatterns » en ciblant son public et surtout en maintenant sa cible dans son contenu et aurait peu et dû atteindre le même niveau de satisfaction.

C’est donc une déception.

new-prog-survival-manual-pragprog

Référence complète : New Programmer’s Survival Manual, Navigate your workplace, cube farm or startup – Josh Carter – Pragmatic Bookshelf 2011 – ISBN : 978-1-93435-681-4

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

http://www.goodreads.com/book/add_to_books_widget_frame/1934356816?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job par Chad Fowler

Note: 7; Une ligne de conduite pour sauvegarder son employabilité: utile bien au-delà du contexte cite dans le titre, et à reconsulter régulièrement.

Derrière un titre amusant (et une couverture qui ne l’est pas moins), Chad Fowler nous livre un propos tout à fait sérieux et profond: comment rester employable et éviter l’obsolescence. L’approche de l’auteur est à la fois simple et originale: il faut considérer sa carrière comme un produit. Cela conduit à une approche en 5 parties, plus une “supplémentaire”.

Choisir son marché: c’est orienter sa carrière selon ses capacités mais aussi par rapport aux opportunités de marché. C’est aussi garder le contrôle de la direction que l’on souhaite emprunter et éviter de se laisser embarquer dans des voies sans issues.

Investir dans votre produit: c’est définir et mettre en œuvre le plan d’action pour prendre la direction que l’on souhaite.

Exécuter : Ou comment se comporter et agir au jour le jour dans son poste. C’est aussi se remettre en cause continuellement et avoir une idée claire de sa valeur et de la valeur (ou du manque de valeur) de son travail. 

Marketing : comme son nom l’indique, c’est se vendre en mettant en valeur son travail sans penser que l’on sera automatiquement connu et reconnu par la simple production de livrables de qualité. C’est donc aussi savoir être un bon communiquant.

Maintenir son avantage : C’est éviter l’obsolescence en restant en mouvement, en ayant une gestion « agile » de sa carrière.

Si vous ne pouvez les battre… : Ce dernier chapitre adresse la position que l’on peut prendre par rapport à l’offshore, non en essayant de l’éviter, mais en prenant une position forte dans ce processus.

L’auteur est tout à fait aguerri sur son sujet : il a été manager sur la mise en place d’une entité offshore dans son entreprise. Chaque item est traité sur 2 à quatre pages environ, ce qui évite l’ennui, dans un style plutôt agréable et illustré d’exemples, mais dans un anglais parfois un peu sophistiqué qui en complique un peu la lecture. Chaque item se termine par des points de « mise en mouvements », certains sont bons et d’autres un peu forcés. Au final ils sont un peu nombreux, mais on peut utilement piocher dedans.

Un ouvrage qui invite à la réflexion, donc.

job-went-to-india

Référence complète : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job – Chad Fowler – Pragmatic Bookshelf 2005 – ISBN: 0-9766940-1-8 (une seconde édition sous un autre titre existe qui fera l’objet d’une note de lecture ultérieure)

My Job Went to India: And All I Got Was This Lousy Book (Pragmatic Programmers)


http://www.goodreads.com/book/add_to_books_widget_frame/0976694018?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on