Mon Bilan 2010 et Mes objectifs 2011

New Year 2011J’ai passé une bonne année 2010 sur le plan professionnel.

Elle fut assez mouvementée avec un changement d’emploi et une implication plus grande que prévu avec la communauté Agile de Québec.

Histoire de faire un bon bilan, revoyons mes objectifs de l’an passé et mon auto-évaluation de ceux-ci :

  • Se pratiquer davantage avec le “Visual Thinking” (Mind Map, Visual Note-taking, etc.) : Excellent !
  • Continuer de lire sur comment fonctionne notre cerveau: OK
  • Explorer Visual Studio 2010 et ses nouveautés avec C# 4.0 : 4/10: J’ai fait quelques petits « peek » techno, mais sans plus.
  • Continuer de faire de la programmation, de l’architecture en .NET et le tout en mode Agile: OK
  • Parfaire ma connaissance des designs patterns, du TDD et des principes de l’orientée-objet : À approfondir davantage
  • Apprendre de nouveaux langages: Toujours en tête d’apprendre le F# et le Ruby
  • Faire un petit projet de programmation personnel : J’ai plusieurs idées de notées. Il faut juste s’y mettre alors.
  • Bloguer plus régulièrement: Pourrait en faire davantage

 

À la manière de Seth Godin voici mes réalisations en 2010:

  • Changement d’emploi: Je fais moins de programmation qu’avant maintenant mais j’ai davantage de responsabilités comme le coaching des programmeurs, la revue de code et établir les environnement de développement et de tests, entre autres.
  • Blogue:
    • Transfert de mon blogue sous WordPress
    • J’ai composé 13 billets en 2010. Environ un par mois.
    • 1400 visiteurs en 2010.
  • Communauté Agile de Québec:
    • Membres de CA.
    • Nous avons organisé avec brio la conférence Agile Tour 2010.
    • J’ai été responsable des démarches pour inviter Mark Levison en mai dernier
    • J’ai présenté l’atelier « Gestion Visuelle » lors de l’Agile Tour
  • 8 livres en rapport avec ma profession ont été lus

 

Point à améliorer:

  • Blogue: Davantage de blogues. J’ai eu un automne assez chargé et cela ne fut pas facile de me trouver du temps.
  • Programmation: J’ai différentes responsabilités dans mon nouvel emploi et je fais un peu moins de code. Il me faut trouver un moyen pour en faire davantage histoire de maintenir tout cela.
  • Lectures: C’est bien beau lire des livres et les commentés ici, mais j’ai ai aussi plusieurs déjà commencés et qui seraient à finaliser.

 

Mes objectifs:

J’en avais beaucoup l’an passé et certains étaient un peu vagues. Je vais donc en prendre moins cette année et ils seront plus précis:

  • Blogue: Je vais embarquer dans le challenge « Post a Week 2011 » de WordPress. Donc, objectifs de 52 billets en 2011.
  • Programmation: Je vais faire le défi du Code Kata et publier le code dans mon compte GitHub. Je vais donc pouvoir me pratiquer avec les langages que je connais bien (C# et VB) et aussi dans ceux que je veux apprendre, soit le F# et le Ruby.  Je veux aussi regarder le développement sous Windows Phone 7, mais en tant qu’objectif optionnel
  • Lectures: Lire au moins 6 nouveaux livres. J’ai aussi à terminer certains livres que j’ai commencés dans les années passées et que je trouver pertinent de lire au complet. Ma page « Mes Lectures » sera donc mise à jour régulièrement selon mes livres lus

 

    Références:

    Publicités

    Atelier Gestion Visuelle

    clip_image002

    Aujourd’hui, lors de l’Agile Tour Québec 2010, j’ai eu l’occasion d’animer un atelier sur la gestion visuelle. Le tout s’est bien déroulé malgré le temps plus restreint (1 heure) pour mener l’activité.

    La participation de tous fut excellente et une bonne créativité en est ressorti dans le tableau des tâches de tous et chacun. Bravo !

    J’avais aussi mentionné que je publierais sur mon blogue les ressources en questions mentionnées lors de la séance ainsi que les photos prises des tableaux.

    Les voici :

    Aussi, si vous voulez discuter ou poser des questions au sujet de la gestion visuelle, juste à mentionner le hashtag #GestionVisuelleQc sur Twitter. J’y participerai avec joie aux discussions qui pourront y avoir lieu.

    Merci encore à tous les participants de l’atelier et à ceux de l’Agile Tour Québec 2010 en général !

    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é

    Pourquoi je n’aime pas les générateurs de code ?

    639165_old_factory

    Je n’ai jamais vraiment beaucoup aimé les générateurs de code.

    Vous savez, le genre d’outils qui peut vous générer des centaines et parfois même des milliers de lignes de code avec simplement quelques paramètres ?

    Dans cet article, je vais discuter des points positifs et négatifs quant à l’utilisation d’outils de générateurs de code. Des exemples de différents générateurs seront aussi décrits.

    On mentionne  souvent que ces outils nous font économiser des centaines d’heures et aide à avoir du code plus standard, je pense par contre qu’à moyen et long terme, il peut y avoir certains effets négatifs.

    Comme par exemple :

    • Nuit à l’apprentissage: C’est le point le plus important d’après moi. Le simple fait que de ne pas avoir touché à une partie du code, nous rend vulnérable par rapport celle-ci. Aussi, il est important de bien comprendre un système informatique dans son ensemble et non seulement les parties du code qui n’ont pas été générées. Faut aussi savoir que tel générateur ne sera pas disponible dans un autre projet… Exemple: un générateur de code se charge de produire les contrats de services et de données en WCF. Il se charge de bien créer les classes et de mettre les bons « tags » relatifs à WCF. Dans ce cas, on ne peut pas dire que nous avons gagné de l’expérience avec WCF. Si on arrive dans un autre mandat ou projet et que le générateur n’existe pas, il nous faudra approfondir WCF car finalement, on ne le connaît pas vraiment malgré son utilisation dans un précédent projet.
    • Difficultés lors de la recherche d’erreurs : Les générateurs de code produisent en général du code un peu obscur et difficile à lire. Si une erreur se produit dans cette partie du code, la recherche peut s’avérer longue et douloureuse.
    • Pour une simple correction, on a souvent pas le choix d’utiliser le générateur de code: C’est en général non-productif de devoir refaire l’exécution du générateur pour faire un petit changement, comme renommer une méthode par exemple ou changer de type une propriété. Pour ces gestes, c’est tellement plus facile et rapide d’y aller manuellement…

    Bien que j’aie déjà utilisé certains de ces outils, je peux avouer qu’ils sont parfois efficaces et, probablement, valent la peine d’être utilisé selon le contexte. Dans certains environnements avec des dizaines de programmeurs, on n’a pas trop le choix de standardiser certaines parties du code malgré les inconvénients. Bref, je crois que l’idéal est d’avoir une bonne balance entre productivité à court terme et l’apprentissage à long-terme.

    Voici quelques-unes de mes expériences avec les générateurs de code:

    Bonnes:

    • LINQ to SQL: Le code généré à partir de tables SQL Server n’est pas trop gros. C’est certain qu’il n’est pas très beau non plus, mais c’est assez facile de se créer une classe « extended » pour y ajouter des options particulière, comme une chaîne de connexion qui peut changer selon certaines conditions. Mais dans ce cas, le gain se fait surtout par l’utilisation directe de LINQ pour lire et modifier nos classes SQL. Le code que l’on créé ainsi manuellement est beaucoup plus lisible et simple avec LINQ.
    • Resharper: La génération de code dans Resharper se charge surtout de petits bouts de code qui seront intégrés à notre classe. Après cela, on les manipule comme on veut. Voyez ici les exemples .

    Négatives:

    • Smart Client Software Factory: Il y a une bonne volonté ici de faire des outils pour générer nos vues, contrôleurs et autres structures nécessaire au pattern MVP-C. Par contre cela en résulte en un nombre assez nombreux d’événements. Lorsqu’il faut faire du débogage, on ne se sait plus trop ou donner de la tête lorsque cela saute d’un événement à l’autre.
    • CodeSmith : J’ai déjà utilisé cet outil pour générer une couche d’accès aux données dans un précédant projet. Je trouvais terrifiant de voir des milliers de lignes de codes produite pour simple une table avec une dizaine de colonne seulement. Par chance que les erreurs ne s’y trouvaient pas souvent. Noter aussi que CodeSmith a d’autres outils que je n’ai pas essayé et qui sont probablement intéressant malgré tout.
    • L’outil « Add Service Reference » de Visual Studio pour WCF: Je n’aime pas cette option qui se fait un peu trop facilement avec un clic droit de la souris. Le gros problème c’est que le fichier de configuration est rempli plein d’options sélectionnés dont plusieurs ne sont pas utile. Aussi, c’est un peu embêtant si on ajoute un deuxième service en référence dans le même projet. J’aime beaucoup mieux la méthode manuelle tel que décrit dans l’article WCF the Manual Way…the Right Way

    Et vous, que pensez-vous des générateurs de code ?

    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.

    Mes objectifs pour 2010

    Happy New Year!Histoire de bien commencer l’année, J’ai décidé de faire la liste des différents sujets que je désire approfondir au courant de la nouvelle année durant mes temps libres et au travail si possible.

    Ces sujets, techniques et autres, me serviront à continuer de progresser dans ma vie personnelle et professionnelle.

    Je ferai aussi la rétrospective de cette liste en fin d’année pour voir ce que j’ai accompli.

    Donc, là voici :

    SNAG-0014 Se pratiquer davantage avec le “Visual Thinking” (Mind Map, Visual Note-taking, etc.)

    SNAG-0014

    Continuer de lire sur comment fonctionne notre cerveau, comment bien retenir ce que l’on apprend à tout les jours (essentiel lorsque l’on travaille en TI) et ce qui touche un peu la neuro-plasticité.

    SNAG-0014 Explorer Visual Studio 2010 et ses nouveautés avec C# 4.0

    SNAG-0014 Continuer de faire de la programmation, de l’architecture en .NET et le tout en mode Agile, bien évidemment !

    SNAG-0014 Parfaire ma connaissance des designs patterns, du TDD et des principes de l’orientée-objet

    SNAG-0014 Apprendre un nouveau langage histoire d’élargir mes connaissances: Ruby et le framework Ruby on Rails

    SNAG-0014 Faire un petit projet de programmation personnel histoire de se pratiquer plus régulièrement pour devenir un bon Software Craftsmen

    SNAG-0014 Bloguer plus régulièrement (environ 1 fois par semaine)