Mes prochaines lectures 2010

IMG_2447Avec les vacances, je prévois avoir davantage de temps libre pour faire de la lecture. On verra bien si cela va se réaliser ou non.

Histoire d’être mieux organiser, j’ai décidé d’aligner mes prochaines lectures afin de mieux suivre mes objectifs 2010. Je vais tenter d’en lire un ou deux pendant mes vacances et le reste, idéalement d’ici la fin de l’année.

Je vais aussi vous faire un résumé ici de ces prochaines lectures.

J’ai aussi terminés la lecture de plusieurs livres (Linchpin, Brain Rules, The art of Unit Testing) qui seront résumé aussi lorsque le temps me le permettra.

Bon, voici donc cette liste de mes prochaines lectures:

  • Made to Stick par Chip Heath & Dan Heath : Livre abordant la créativité et le pourquoi certaines idées “collent” davantage que d’autres. C’est une des suggestions de Mark Levison lors de son passage à Québec en mai dernier.
  • The Back of the Napkin et Unfolding the Napkin by Dan Roam: Pour en apprendre davantage avec le “Visual Thinking”. Dan Roam a écrit deux livres sur le sujet de comment illustrer ses idées de manière simple. Le premier de ces livres, The back of the Napkin, parle surtout de la théorie, et son deuxième, unfolding the napkin, est plutôt un guide de comment apprendre la technique par des exercices. Je me demande par lequel je vais commencer… La théorie ou la pratique ?
  • Simplicity par Edward de Bono: Ce livre vient d’être rééditer; il était auparavant difficile à trouver. J’ai déjà lu sur la simplicité avec le livre “Laws of Simplicity” et j’avais bien aimé. Daniel Lafrenière m’a recommandé celui de Edward de Bono pour approfondir davantage le concept de la simplicité qui peut s’utiliser un peu partout.
  • Presentation Zen par Garr Reynolds: Beau livre en couleur avec plein d’exemples de comment faire de bonnes présentations. Cela devrait bien accompagner le concept de Beyond Bullets points que je connais déjà bien.
  • Agile Coaching par Rachel Davies et Liz Sedley: J’ai ce livre depuis près d’un an et je ne l’ai pas encore lu. Il est grand temps que je m’y mettre donc. On y retrouve plusieurs bons conseils sur le coaching et comment introduire des nouvelles notions, comme l’agilité, au sein d’un équipe.
  • Programming F# par Chris Smith: Je voulais apprendre au moins un nouveau langage de programmation cette année. Ainsi avec le F#, je vais toucher le concept de la programmation fonctionnelle et aussi voir les nouveautés avec Visual Studio 2010.

Aussi, j’ai pris l’habitude de mettre les références à la fin de mes billets plutôt que répartis un peu partout dans le texte. Je trouve que cela rend le tout plus lisible. Qu’en pensez-vous ?

Références :

Publicités

Critique du livre Pragmatic Thinking & Learning

J’ai lu le livre « Pragmatic Thinking and Learning: Refactor your Wetware » l’été passé (et oui, je suis un peu en retard dans mes critiques de livres, mais bon) et j’ai vraiment aimé ce petit livre. Son auteur, Andy Hunt, est aussi le co-auteur du fameux The Pragmatic Programmer . Le livre est bien présenté avec plusieurs chapitres, plusieurs images sont présentes pour illustrer certains concepts et on retrouve des capsules conseils un peu partout dans le livre.

Ce livre ne parle ni de programmation ni d’agilité (et oui !). On y discute principalement comment notre cerveau fonctionne et comment l’optimiser dans ce monde qui ne cesse d’évoluer et où nous sommes en apprentissage continue. Ce livre vise donc en particulier les personnes œuvrant dans le domaine informatique, mais pourrait aussi bien être très utile en générale pour quiconque.

Le livre commence en introduction en nous rappelant de toujours considéré le contexte car tout, d’une certaine manière, est inter relié. J’aime beaucoup aussi quand on décrit brièvement tous les chapitres du livre dans l’introduction. Cela nous permet d’avoir un bon aperçu du livre et voir ce qui va s’en venir. Autres sujets couverts dans les chapitres suivants : le modèle d’acquisition de connaissance Dreyfus, le fonctionnement de notre cerveau, comment apprendre délibérément, comment déboguer notre cerveau, acquérir de l’expérience et garder le focus.

J’ai particulièrement apprécié le chapitre 3 qui décrit comment fonctionne notre cerveau avec quelques analogies informatique. On y parle aussi de nos deux cotés du cerveau qui y sont rebaptisé mode linéaire (gauche) et mode riche (droit). L’idée n’est pas de connaître son côté dominant et de l’exploiter au maximum. Au contraire, nous avons besoins de deux côtés et il faut parfois se servir de l’un et l’autre pour arriver à nos fins. Par exemple, on peut partir quelque chose en mode riche (coté droit) pour générer des idées ou être créatif et par la suite retomber en mode linéaire (côté gauche) pour analyser le tout et faire des regroupements. Par contre, embarquer en mode riche n’est pas toujours évident, mais le livre mentionne plusieurs trucs et façons de faire pour y parvenir.

Un petit passage que j’ai bien aimé : Savez-vous que travaillez dans un cubicule détruit nos neurones ? La création de nouveaux neurones est davantage stimulée dans un environnement riche ou l’on peut observer, apprendre et interagir. Comme un animal dans une cage, un programmeur pris dans un cubicule ne fera pas la création de nouveaux neurones. Voilà pourquoi c’est important d’avoir un espace de travail ouvert et qui stimule nos sens. Voici quelques articles en référence à ce sujet :

Bref, j’ai beaucoup aimé ce livre et je le recommande à tous. Seul petit point négatif, certain sujets sont abordés très légèrement et aurait mérité qu’on y aille en profondeur. Pour ce, il faut donc me falloir d’autres lectures…

Mes points clefs : Darts

  • Nous avons besoin toujours besoin de nos deux modes de fonctionnement de notre cerveau : mode linéaire et mode riche.
  • Prendre en note chaque idée que nous avons. De cette manière on pourra en générer davantage
  • Lire et relire pour ne pas oublier. Utiliser des « mind maps » pour résumé le contenu.
  • Et ne jamais oublier le contexte, car tout est inter relié

Critique de livre : The Five Dysfunctions of a Team

FiveDysfunctionsCover Ce livre n’est ni technique et ne parle pas d’agilité. Pourquoi donc j’en ai fait la lecture ? Et bien tout a commencé cet été lors de mon passage à la conférence Agile 2009 qui a eu lieu à Chicago, lorsque j’ai assisté à la présentation suivante :

Scaling Up by Scaling Down: A (re)Focus on Individual Skills

Dans cette présentation sur le comment faire progresser une équipe pour la rendre hyper-performante, on mentionnait le livre en référence. Intrigué, je me suis procuré le livre en question sur les 5 dysfonctions d’une équipe. En passant, la présentation a été filmée et vous pouvez donc l’entendre au complet sur le site d’infoQ:

http://www.infoq.com/presentations/scaling-up-by-scaling-down

Je vous la recommande fortement si vous voulez en savoir davantage sur le leadership d’équipe et le lien avec l’agilité. Le conférencier, Ashley Johnson,  parle avec un anglais qui est en général très facile à comprendre.

Pour revenir au livre, c’est un bon livre et j’ai l’est vraiment aimé. Il est d’ailleurs utile pour tout ceux qui sont intéressé par le travail d’équipe, peu importe leur rôle. C’est une lecture assez facile, cela m’a pris environ 1-2 semaine pour le terminer. De plus, son contenu est présenté ainsi, de manière peu conventionnelle:

  • Les 184 premières pages du livre racontent une "fable" sur le leadership.
  • C’est dans les 40 dernières pages que le modèle des 5 dysfonctions nous est décrit.

J’ai trouvé très instructif ce format. On nous fait découvrir graduellement la théorie des 5 dysfonctions d’une équipe à travers une histoire fictive, mais très réaliste. On devient rapidement accroché à l’histoire et on a hâte de voir la suite et comment l’équipe va réussir à corriger ces 5 dysfonctions. Ce format nous permet de comprendre la théorie à travers une histoire au lieu d’y aller directement avec la théorie sans trop de concret. Ah si les écoles fonctionneraient de cette manière…

Pour les 5 dysfonctions d’une équipe je les résume ainsi avec une traduction libre :

  • Manque de confiance envers les autres (Absence of trust)
  • Peur des conflits (Fear of conflicts)
  • Manque d’engagement (Lack of commitment)
  • Éviter la responsabilisation (Avoidance of accountability)
  • Inattention aux résultats (Inattention to results)

On doit commencer idéalement par résoudre la première dysfonction, ici le manque de confiance, et résoudre les autres en ordre par la suite pour finir avec le dernier, soit l’inattention aux résultats.

Vous trouverez le détail de ces dysfonctions dans les documents suivants disponibles:

Autre bon résumé si vous avez moins de 5 min, écouter l’auteur du livre, Patrick Lencioni, nous décrire brièvement les 5 dysfonctions:

 

Pour poursuivre mon habitude des points clefs, voici ce que je retiens de cette lecture :Darts 

  • Si on se retient de dire des choses de peur de confronter les autres, cela nuit grandement à rendre une équipe fonctionnel
  • Viser le consensus de toute l’équipe n’est pas toujours la bonne chose à faire. L’important c’est que tous les membres de l’équipe aient eu l’occasion de s’exprimer. Après, la décision passe beaucoup mieux au sein de l’équipe.
  • Je vois bien intégrer ce genre de modèle aux pratiques de rétrospective et d’amélioration continue d’une équipe Agile. À essayer donc lors d’un prochain projet.

Critique du livre: « Laws of Simplicity »

image Bon, voici le premier d’une série d’article sur mes critiques de livres lus. D’autres suivront sous peu, j’ai un peu de retard avec mes critiques par rapport à mes livres lus.

C’est suite à une recommandation de James Newkirk, lors de son passage au Patterns and Practices summit l’an passé, que je me suis procuré ce petit livre à propos de la simplicité.

Je voulais approfondir le sujet afin de comprendre en détails qu’est-ce que veut dire la simplicité et comment cela pourrait aider mes projets informatiques courants et à venir.

En passant, la simplicité est une des valeurs recommandée par l’approche « XP Programming ». On la définie alors dans ce contexte comme étant :

La façon la plus simple d’arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple sera plus facile à faire évoluer.

Bref, on n’ajoute rien de plus qui n’est pas nécessaire au système pour éviter une lourde maintenant dans le futur. Voilà ce que j’avais savais sur la simplicité avant lire « Laws of Simplicity ».

L’auteur, John Meada, tente de nous expliquer dans le livre, comment se traduit la simplicité en 10 lois et 3 points clefs. Il est à noté que ce livre ne parle pas d’une technologie précise. Il se veut descriptif de la simplicité en général lorsque abordé dans les domaines suivants :

  • Design
  • Technologie
  • Affaires
  • La vie courante

Les différentes lois sont décrites brièvement sur le site de John Maeda. Je vais donc me passer de vous les décrire ici en détails. Je vais simplement en faire la liste :Tranquility 4

  • Law 1: Reduce
  • Law 2: Organize
  • Law 3: Time
  • Law 4: Learn
  • Law 5: Differences
  • Law 6: Context
  • Law 7: Emotion
  • Law 8: Trust
  • Law 9: Failure
  • Law 10: The One

En conclusion, j’ai bien aimé ce petit livre (qui ne fait que 100 pages d’ailleurs). Les chapitres sont courts et concis et les illustrations sont simples (évidemment !) et évocatrices. On y retrouve aussi plusieurs anecdotes relatant des faits de la vie de cet auteur d’origine japonaises et qui est aussi professeur au MIT. De mon côté, j’aime bien les petites histoires vécus car je trouve que cela apporte du détail et de la couleur au texte. Par contre, certaines personnes pourraient trouver cela un peu moins utiles.

Mes points clefs à retenir :Darts 

  • La simplicité demande souvent de bien faire la balance avec la complexité. Certaines choses complexes ne peuvent être simplifiées. Il faut alors utiliser la simplicité pour les catégoriser et les cacher.
  • La simplicité est importante, elle aide à rendre les choses plus claires et plus saines
  • La simplicité se résume à enlever ce qui est évident et superflu, et à ajouter ce qui est significatif

Blogue « Code Complete »

Steve McConnell, un des mes auteurs favoris, vient de partir son blogue à l’adresse suivante:

http://forums.construx.com/blogs/stevemcc/default.aspx

Il est l’auteur, entre autres, des excellents livres suivants:

Code Complete (Guide très complet sur les manières de bien construire le code)

After the gold rush (essai sur la profession d’informaticien en général et autres trucs. Intéressant à lire)

gr.gif (9552 bytes)