L’homme orchestre, partie 1 : les casquettes

Depuis 4 ans, j’écris un MAM libre en Java. Comment arriver à ne pas se laisser dépasser par l’immensité du travail à fournir ? Un article en deux parties très subjectives et relèvent de l’expérience que j’ai pu tirer avec le temps (je ne suis pas développeur de métier ni de formation).

Publié le

Pour écrire du code, et construire des applications, il faut un peu avoir l’instinct de bricoleur. A force de brancher des fils entre eux, on fini par faire tourner quelque chose.

Puis avec l’habitude, on voit plus grand, plus loin. On imagine ce que l’on pourrait faire si seulement on reliait de gros morceaux entre eux. Et un jour, on ouvre un IDE, et on y va, et on se plante.

Il faudra parfois du temps, mais à un moment votre code mal pensé vous dégoûtera. Il y a un travail à faire autour du code à proprement parler sans quoi la structure ne tiendra pas très longtemps.

Déjà, il faut accepter d’avoir différentes casquettes et il faut savoir en changer quand il le faut.

Pour ce projet, je doit être :

  • Ingénieur R&D : bricoler des bouts de scripts, essayer des trucs, tenter des choses, bref faire du non propre mais valider si ça peut marcher ou pas. Si vous voulez construire vous même votre voiture, assurez vous que vous arrivez déjà à faire tourner un moteur sur une batterie avant même de commencer à dessiner les plans de la voiture elle même, car une voiture sans moteur restera une boite à savon…
  • Architecte logiciel : ce n’est pas bien méchant, mais avant d’avancer durablement dans une direction, il faut déjà la choisir. MySQL ? Python ?  jQuery ? Comment je nomme ? Comment je structure les choses ? Bref, à chaque itération du travail je doit me poser ce type de question. C’est fondamental : vous payez très cher chaque erreur que vous ferez ici. J’ai déjà dû supprimer un mois de code car j’avais mal pensé, et sous estimé un détail fondamental qui à rendu inexploitable le reste tout autour. Ce travail est chiant car il est à l’opposé de la R&D. On aimerait tous utiliser le dernier truc à la mode… Mais est-ce pertinent là maintenant pour ce que je veux faire par rapport au reste autour ?
  • Chef de projet, ou se contenir pour rester dans les clous, respecter les conventions que l’on s’est donné, dans les objectifs prévu, alors que l’on a tellement envie d’intégrer un nouveau truc mais qu’il y a quelque chose de plus urgent à faire pour le moment, comme corriger des petits bugs moches ou le script d’installation. C’est le garant qui fait avancer les choses.
  • Développeur : c’est simple, on écrit du code dans le cadre que l’on c’est donné et on debugge le plus possible.
  • Contrôle qualité. Le moment casse pied arrive, c’est le moment où on devient super chiant sur tout le travail déjà fait. C’est à ce moment là où on repère les erreurs faites lors des étapes précédentes. Et il faut être sans pitié. Si ça ne marche pas bien, c’est que cela ne marche pas. On ne met pas un outil dans les mains des gens si il n’est pas parfaitement fonctionnel, sinon ils auront une mauvaise image de votre outil et de votre travail que vous n’arriverez pas a leur enlever de la tête.
  • Administrateur système : écrire du code, c’est bien, le faire fonctionner hors d’un environnement de développement, c’est mieux. C’est à ce moment-là que vous découvrez que la fabuleuse fonctionnalité que vous avez écrite ne marche pas sous le Linux de vos serveurs ou que vos dépendances ont des problèmes de version entre votre environnement de production et de développement. C’est tellement drôle à résoudre ce genre de problème que vous en venez à haïr votre architecte : c’est à dire vous même.
  • Utilisateur. Quand vous proposez votre application à des gens, ayez la décence de l’utiliser aussi ! Encore plus si c’est une application métier comme la mienne. Et là, vous pourrez savourer le moment où vous vous demanderez « Mais pourquoi ce comportement stupide ? Quel est le génie qui à pensé ça !? Mais c’est moi ! ». Après, le plus fou sera de découvrir qu’une petite fonction de rien peut changer la vie de beaucoup de monde, au point où vous serez étonné de constater que « j’ai écrit ça en trois heures il y a deux ans et on l’utilise toujours ? »
  • Marketing. J’ai dû apprendre mettre en valeur mon code, car un code, ça fait des choses, point. Tout le monde se fiche de savoir comment. Alors ces choses qu’il fait doivent être mises en avant, pour donner envie à d’autres d’y mettre les doigts dessus (utilisateurs) ou dedans (développeurs et contributeurs). Il ne s’agit pas de mentir, ni non plus de sous estimer votre travail. Après tout, vous y avez passé du temps, ce n’est pas pour rien. Montrez le ! Faites un site, une vidéo, des graphiques à la mode avec des couleurs. Le faire, ça change les idées, ça force à prendre du recul. Ça sera peut-être moche, mais au moins ça sera mieux qu’un README avec du ASCII art à la racine du Git.
  • Commercial. Enfin la partie ardue. Le marketing donne envie. Le commercial agit. L’économie du logiciel libre montre qu’il n’y a d’autres façons de gagner sa vie en écrivant un logiciel que de vendre du binaire fermé et restreint. Par exemple, MyDMAM est libre et gratuit, pourquoi alors parler de commercial ici puisque qu’il y a rien à vendre ? En fait si : mon temps. Être payé pour écrire le code de son propre projet, c’est un type d’idéal. Encore mieux quand cela fait vivre plusieurs personnes. Pour ma part, je n’ai pas de business autour de mon code actuellement. Mais je sais vendre son utilisation selon qui j’ai en face de moi. Apprenez à parler de votre projet, insistez sur les méthodes élégantes que vous avez utilisé pour résoudre des problèmes impossibles. Si vous êtes développeur, ne faites pas l’autiste et employez des mots simples pour parler de votre modeste création et faites naître l’envie. C’est indispensable pour ne pas être le seul sur votre projet (ce qui est actuellement mon cas).

A chaque itération de travail (comme une nouvelle fonctionnalité), je doit redevenir R&D, puis Architecte, puis Chef, puis Dev, puis QC, puis Admin, puis Utilisateur. Et je recommence. De temps en temps un peu de Marketing. Enfin, quand je « sort » je suis plus Commercial.

Simple, non ? Mais il y a une suite