Hipster PDA : bilan après 4 mois d'utilisation

J'ai écris, au moins d'août, un article sur ma méthode de gestion du temps : hPDA, TODO-list, ce que certain appellent de la "procrastination". Si vous n'avez pas lu l'article, lisez-le avant celui-ci.

Le bilan est assez simple : je n'ai pas trouvé grand chose de mieux, et mon argumentaire n'a pas réellement changé. Cependant, j'ai déjà appliqué quelques modifications. Bilan.

Tâches du lendemain (plugin)

J'ai ajouté un petit "plugin" : un quart de feuille A6 mis à jour tous les jours permettant de sélectionner les tâches à faire le lendemain. L'idée est de libérer les listes de TODO (Perso et Travail) de toutes les tâches courtes qui l'encombrent et m'obligent à recopier régulièrement les listes (assez long...).

Cette méthode est aussi plus efficace, car je parcours les listes de TODO chaque soir, et je peux créer une liste très courte pour le lendemain et écrire les rendez-vous de la journée dessus.

Noter les dates proches

L'autre légère modification est de réserver le tiers supérieur de chaque liste de TODO pour écrire les rendez-vous : j'utilise pour cela un point en début de ligne.

Calendrier annuel en deux feuilles

Vraiment pratique ! Dépasse largement le calendrier d'un smartphone.

Les feuilles pour le mois courant et le mois prochain

Utile lorsque l'on a beaucoup de dates à noter. Je les utilise très peu en ce moment.

Mes conseils de programmation

Je vais essayer de décrire dans ce documents quelques principes de base que j'applique en programmant. Pour trouver l'essentiel, il m'a fallu prendre du recul sur mes habitudes.

Le nom doit permettre de comprendre ce que fais la fonction ou la variable

Pour les fonctions, l'habitude et de mettre un verbe d'action dans le nom. Pour les plus courants on trouve :
récupère (get) : elle renvoie quelque chose (il n'y a aucune raison que dans son code elle modifie une quelconque variable !! sinon, lui trouver un autre nom)
modifie/ajoute/supprime (set/add/del) : modifie une valeur/une liste ou un tableau
On peut l'étendre à n'importe quel verbe d'action : tri, analyse, nettoie...

Si la fonction est dans un package, il peut parfois être pratique (en C, par exemple), de donner le nom du package aux fonctions. Par exemple : donnéesInit, donnéesReset, donnéesAjout...

Important : si on modifie le contenue d'une fonction, il faut penser aussi à mettre à jours son nom si son but change, ou au moins sa documentation.

Pour les tableau, utiliser le terme "tab" dans le nom est souvent assez pratique.

Documenter ses fonctions (toutes)

Description de la fonction
Paramètres : liste des paramètres avec l'utilité. Indiqué s'il sont modifiés.
Retour : ce qui est retourné.

Sur les fonctions ou procédures complexes, on peut ajouter les champs suivants : Requis : ce qui doit être fait avant l'appel. Par exemple : appel à "init" requis.
Garantie : ce que l'on assure après (par exemple, "le tableau T est trié ou vide")

Dans le cas où le champ requis a été utilisé, il est peut-être intéressant de placer une assertion en début de fonction, pour assurer que cela a été fait.

Être capable de dessiner sa structure de données

Prendre une feuille de papier et dessiner ses tableaux, ses listes chainées... Ce conseil est sans doute le plus "scolaire" que je puisse donner, mais il vous propulse instantanément au rang de serial coder, surtout dans les langages comme le C où les pointeurs rendent le code peu lisibles.

Apprendre à dessiner une structure de donnée
Il n'y a plus qu'à faire la correspondance. En C, le tableau deviendra [], les pointeurs, dessinés par des flèches, deviendront des étoiles...

Classer ses fonctions par package (même en C, avec les .h)

Permet de leur donner une logique globale. Cela facilite aussi la factorisation du code. Être capable de classer ses fonctions traduit le fait que l'on comprend l'architecture de son programme. Dans le meilleur des cas, il faut décrire quel seront les packages avant même de commencer à coder. Il est intéressant aussi de décrire les interactions entres les différents packages.
Nb. Pour la programmation objet (Java, C++), c'est encore plus vrai.

Éviter les effets de bords (modification de variables)

Il faut éviter de modifier des variables du programme depuis une fonction (mais c'est parfois indispensable ou juste plus lisible). Dans ce cas, on doit comprendre ce qui est modifié juste en lisant la documentation de la fonction et son nom.
Exemple (trivial), en lisant la documentation de la fonction int get_numéro(), on ne s'attends pas à ce qu'elle modifie une variable. On s’attend juste à ce qu'elle renvoie le numéro.

Pour les procédures c'est moins vrai : "l'effet de bord" est leur seul moyen d’interagir avec l'extérieur. Cependant, si elles modifient plusieurs variables, il faut se demander si le développeur s'y attend, juste en lisant la doc.

Appeler ses fonctions avant de les écrire

Cela permet de s'assurer qu'elle est utile avant de l'appeler et d'évaluer quels seront les paramètres. Parfois, j'aime même effectuer les appels de toutes mes fonctions, et les écrire ensuite. Ça peut être inutile, si vous savez exactement quoi coder.

En conclusion, nous voyons que la programmation nécessite une certaine rigueur : savoir à tout instant POURQUOI j'écris cette ligne. Le code est à destinations de machines, mais il doit surtout être lisible par des humains, c'est pourquoi il est important de le rendre compréhensible.

Mon premier "Hipster PDA"

J'ai lu que le Hipster PDA a été inventé en 2004. Il est pour moi le meilleur objet pour s'organiser au quotidien. Voici comment.

J'ai utilisé pendant très longtemps un agenda septembre-septembre. Dans un premier temps pour écrire uniquement les dates importantes et les travaux à rendre. Cependant, il fallait parcourir tout l'agenda pour retrouver les dates et les travaux futures. J'ai donc commencé à écrire sur la page du jour les choses à faire durant les prochaines semaines : ma Todo list était née. Chaque page de mon agenda était devenue une liste de choses à faire.

L'agenda a plusieurs limites

  • Il est gros (toute l'année, les anciennes pages ne s'enlèvent pas)
  • Utilisé en Todo list, il faut recopier chaque jour ce qui n'a pas été fait la veille même si la page est encore lisible.
  • On ne dispose pas d'une vue d'ensemble du mois courant (j'utilisais un agenda une page par jour, car il est plus compact que les agendas A4).
  • Impossible d'ajouter des feuilles sans les coller

J'ai essayé le carnet A6 « Rhodia ». Cependant...

  • L'ordre des page est fixe
  • Aucun calendrier
  • Pas d'historique
  • Impossible d'ajouter des feuilles sans les coller

Avec le carnet, j'ai résolu deux problèmes importants de l'agenda : la taille (les pages s'enlèvent, et on peut acheter des carnets plus petits). Cependant, la fonction calendrier n'est plus présente.

Enfin, j'ai découvert le Hipster PDA dans sa version la plus élémentaire (mon cher Watson) : une pince clip, des feuilles A6 découpées dans un vieux cahier et une couverture cartonnée pour faire le support.

J'ai aussi découpé une boîte pour archiver les fiches, stocker les fiches vierges et avoir une copie de sauvegarde de mon calendrier.

Mon Hipster PDA
(Admirez la photographie talentueuse)

Les avantages du hPDA (et de sa boîte) sont

  • La taille : une dizaine de feuilles
  • La possibilité d'ajouter des feuilles et de changer l'ordre
  • L'historique

Contenu du hPDA (dans l'ordre)

  • 1 fiche TODO Cours (ou travail)
  • 1 fiche TODO Perso
  • 4 fiches vierges : la dernière est munie d'un marque page autocollant pour accéder aux suivantes facilement
  • 2 feuilles : mois courant et mois prochain (liste d'événements, d’anniversaires et de choses à faire)
  • 2 feuilles calendrier (cf. plus bas)
  • Un Spark File (feuille « étincelle ») : liste d'objets à acheter (peut-être), de noms, de films à voir, de lieux, de choses à faire (ou ne pas faire)... Rien d'urgent, juste des idées.

Contenu de la boîte

  • Copie du calendrier
  • Archive des TODO Perso (datés)
  • Archive des TODO Travail (datés)
  • Fiche mémo (ex : consommation d'essence, citations de Cocteau...), procédures récurrentes...
  • Feuilles vierges

A propos du calendrier en 2 feuilles A6

J'avais besoin d'un calendrier pour avoir une vue d'ensemble de l'année. J'ai créé un tableau sur deux feuilles A6. Je le trouve finalement assez lisible. Il n'y a rarement plus d'un événement par semaine, donc j'ai fais une semaine par ligne, la date à gauche correspond à la date du lundi. Ensuite, il suffit de cocher (avec une croix ou une lettre) et d'utiliser le blanc en fin de ligne pour les détails.


Exemple de calendrier au format A6. L'année tient sur 2 feuilles.

Les | (pipes) indiquent le premier du mois. J'utilise aussi des lettres : E pour examen, T pour théâtre, P pour projet... Les cases grises sont occupées (cours) et les blanches sont libres (vacances ou jours fériés).

A vous de jouer !

Un été de spectacles

Voici les spectacles auxquels j'ai pu assister cet été et que je vous conseille :

Théâtre

  • Dommage qu'elle soit une putain (tout public) de John Ford. Mise en scène Jean Briault (Vu au théâtre du Tremplin, Avignon Off) : Très bon spectacle, mise en scène et jeu de qualité. C'est une tragédie contemporaine de Shakespeare.
  • The Heavy Mental Flamenco Show de Paul Morocco et sa troupe Olé! : Cette troupe, récompensée plusieurs fois depuis 1991 est vraiment à voir. Le flamenco est prétexte à faire rire : le spectacle est un mélange hilarant entre du jonglage, de la musique et des gags diverses autour de 3 guitares.

Cirque

  • El Nucleo : acrobaties impressionnantes, jonglage... J'ai vu le dernier de la saison, ils préparent un nouveau spectacle.

Musique

Non, les réseaux sociaux n'ont pas tué les blogs

La poussière numérique n'existe pas, mais quand on visite un blog qui a pour dernière publication la sortie de Firefox 1.5, il y a comme une odeur de Naphtaline qui se dégage du flux RSS. Bien sûr, certains articles de fond sont indémodables : comparez par exemple (de manière caricaturale) les articles anciens de Framablog à ceux de Tom's Hardware. L'un donnera des articles de fond, alors que le second donnera des articles beaucoup plus temporels, mais nous avons affaire ici à deux styles de médias différents.

Pour moi les réseaux sociaux ont modifié un certain type de blogs, les blogs plus classiques, c'est-à-dire, à mi-chemin entre un blog de fond et un blog temporel. Avant l'arrivée de Twitter (et Facebook) ces blogs mélangeaient les articles de leur composition (articles de fond), et les informations "relayées". Les articles de fond étaient alors noyés au milieu de simples redites, souvent très temporels. Aujourd'hui, il me semble que le nombre de publications a baissé, car ces informations relayées ont un vecteur beaucoup plus adapté : les réseaux sociaux.

Ne pensez pas que je condamne le relayage d'information. D'ailleurs, si vous souhaitez le blâmer, ne le rejetez pas en bloc car par exemple, Framablog relaie parfois de l'information, mais il s'agit d'une part, d'un article de fond, et d'autre part d'une traduction. La nuance est de poids.

Les détracteurs des réseaux sociaux diront qu'ils ont contribué à faire fuir les commentaires, pour moi ils les ont simplement déplacés sur les réseaux sociaux.

Le changement vient aussi des marques (ou de n'importe quel site "officiel"). En arrivant sur les réseaux sociaux, les entreprises ont facilité la propagation de leurs informations sans passer par les blogs, par un simple Partage ou Retweet. Pourquoi répéter le contenu d'un article alors qu'un simple clic permet de le relayer ?

Les réseaux sociaux ont aussi apporté de la diversité aux lecteurs (et donc aux rédacteurs). Suivre un flux RSS, c'est se tenir informé sur un site. Follower quelqu'un sur Twitter, c'est se tenir informer sur tous les sites que lui-même lit. Reste juste à trouver un compte qui a les mêmes gouts que vous...

Ainsi, les réseaux sociaux n'ont pas détruit les blogs, au contraire ils ont permis de moins les surcharger et d'apporter de nouvelles sources d'informations à leurs auteurs. Une autre manière de poser la question : que sont les réseaux sociaux sans les blogs ?