Outils de productivité partie 1: GTD

Rule your mind or it will rule you

– Horace Mann (1796-1859)

Voici le premier billet d’une série de cinq sur les outils et techniques de productivité que j’utilise. Le but est de vous présenter un résumé simple de ces techniques et de mes commentaires face à leur utilisation.

getting-things-done.jpgEst-ce que vous vous sentez parfois submergés et désorganiser ? Alors, évitez la procrastination et prenez le contrôle de votre vie !

Nous allons commencer notre série avec la technique « Getting Things Done » de David Allen. Ce consultant et coach à élaboré cette technique dans le but de se libérer l’esprit de nos multitudes tâches et autre afin d’être productif sans être stressé.  De cette manière, notre esprit et nos idées sont clairs et il est possible alors d’atteindre de meilleurs résultats. En passant, cette méthode est bonne pour à peu près n’importe qui et n’est pas utile qu’à ceux qui travaillent dans les technologies de l’information.

Le problème qui nous arrive trop souvent est que nous recevons de multiples demandes et que nos tâches changent régulièrement au travail. L’idée alors est de se mettre dans un état mental afin d’être productif lorsque c’est requis.

Les principes en gros de cette méthode sont les suivants:

  • Se faire une liste ou collection de tout ce que l’on a en tête
  • Mettre au clair ce que l’on doit faire
  • Décider ce que l’on fait
  • Garder nos tâches à faire dans un système organisé.

Le processus est une approche de style « Bottum-Up » afin de tout sortir ce que l’on à faire (au travail, à la maison, projets personnels, etc.) et d’en faire une gestion suivant le worklow suivant:

  1. Collect : Avoir un outil pour noter toutes nos tâches à faire on incomplètes. Voir à vider ces listes de manière régulière.
  2. Process: Évaluer une action à la fois. Est-ce qu’on la fait plus tard ou immédiatement ?
  3. Organize: Se faire différentes listes. Mettre des rappels dans notre calendrier. Voir notre prochaine liste d’actions. Exemple de listes:
    • À faire
    • À revoir
    • Un jour
    • Projet
    • En attente
    • Délégation
    • À surveiller
  4. Review: Évaluer le portrait global de notre vie. Idéalement de manière hebdomadaire. Voir quand revoir quand.
  5. Do ! : Regarder nos prochaines actions. Voir s’il y a des nouvelles qui arrivent. Priorisé les tâches.

Cela demande donc de revoir comment on classe nos dossiers physiques, nos boîtes de courriel et autres. Pour certains, ils vont trouver que cela manque de structure sur quelques-uns de ces aspects. Alors que pour d’autres, cela peut bien réussir ainsi. Cela dépend un peu de votre style. Mais ce que je trouve intéressant pour moi, c’est que le GTD en n’étant pas trop structuré, est facilement adaptable et ainsi chacun peut le personnaliser selon ses besoins.

Et voilà, c’est pas mal tout en ce qui concerne cette méthode. Ce simple résumé et la visite de sites en référence plus bas peuvent vous suffire. Par contre, le livre explique en détail toute cette technique et donne plein de conseils et d’exemple.

Quant à mon essai de cette méthode, voici mes commentaires:

  • Au travail: Je l’applique assez bien et cela donne de bons résultats. Ma boîte de courriel est toujours vide et je vois facilement les prochaines actions à faire selon leur priorité.  Aussi, en révisant régulièrement mes tâches, c’est peu fréquent que j’en oublie
  • À la maison: l’application de la méthode dans mes dossiers personnels s’est avéré un peu plus compliquée. J’ai beaucoup plus de paperasse qu’au bureau et j’ai tendance à tout mettre dans un coin. J’ai commencé à bien ordonner mes classeurs, mais je n’ai pas encore pris le temps de tout classer comme il le faut. Il me faudrait plusieurs jours de temps libre pour finir l’établissement de ce processus…

Bref, je remarque que parfois l’application de GTD peut bien se passer tandis que pour d’autres contextes, c’est compliqué, car on a plusieurs choses à établir en même temps pour que cela soit fonctionnel. GTD ne mentionne pas aussi comment garder le focus sur une tâche particulière ni de voir ce qui nous motive ou comment choisir nos prochaines actions. Nous allons aborder ces aspects dans les autres billets de cette série sur les outils de productivité.

Mes points clefs :

  • C’est très important de s’organiser, surtout dans le classement des ses tâches
  • Tout mettre dans notre système, peu importe si c’est pour le boulot ou non. Il faut libérer notre cerveau le plus possible de ces tâches.
  • La revue hebdomadaire est cruciale dans le succès de l’application de cette méthode

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é

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 ?