Un coup de gueule sur les projets de logiciels personnels

En parcourant votre disque dur et GitHub, vous trouverez peut-être des centaines de notes et de squelettes de référentiels Git. Un véritable cimetière de projets annexes logiciels. Le déroulement typique de bon nombre de ces projets est le suivant : avoir une idée, ruminer sur l’idée jusqu’à ce qu’elle devienne excitante, pour finalement devenir plus excitante que le projet parallèle actuel, des notes sont capturées, un référentiel est créé et le travail commence à un rythme effréné comme la concentration et l’excitation sont là. Il peut y avoir des réécritures ou des changements de direction. La question de savoir si le projet en vaut la peine ou « qu’est-ce que ce projet devrait-il réellement être ? » commence à se poser. Finalement, l’enthousiasme s’estompe à mesure que ces questions continuent de se multiplier. Les progrès ralentissent car la voie à suivre semble moins claire qu’autrefois. Le projet est soit au coucher du soleil avec une triste promesse de revenir un jour, soit tranquillement mis de côté alors que quelque chose de nouveau et d’excitant vient prendre sa place. Semble familier? Peut-être pas, mais les principes ici pourraient être utiles.

Cet article particulier est en grande partie une opinion d’un ingénieur à un autre. Il s’agit de concevoir le processus par lequel vous concevez un projet pour obtenir de meilleurs résultats. Il existe de nombreuses raisons pour lesquelles un projet peut être abandonné ou abandonné et toutes ne sont pas dues à un manque de définition claire du projet. Dans le cas où la nature du projet n’est pas claire, il peut être utile d’y penser dans un sens plus holistique/méta. Il existe deux types de projets personnels au sens large : les démos technologiques et les produits.

0b10 Types de projets personnels

Le logo en langue de rouille est marqué sur un boîtier de microcontrôleur
Essayer Rust sur un microcontrôleur est une bonne raison de faire un projet.

Une démonstration technologique concerne la technologie ou le comment. Vous essayez peut-être un nouveau langage ou un nouvel algorithme. Il est normal qu’il soit à moitié cuit et maladroit parce que ce n’est pas pour cela qu’il a été conçu. Il a été conçu pour être beau et intéressant à l’intérieur. D’une certaine manière, lorsque vous vous éloignez, le projet est terminé parce que vous avez obtenu ce que vous vouliez : apprendre.

En revanche, un projet personnel de produit se concentre sur ce qu’il fait et sur l’expérience en tant qu’utilisateur final interagit avec lui. Peut-être qu’il a un excellent README, une expérience utilisateur fluide, ou fait quelque chose de mieux que tout ce qui existe. Le fait est qu’il se concentre sur l’utilisateur final qui l’utilise plutôt que sur la personne qui le fabrique. Peu importe à quoi il ressemble à l’intérieur. Il pourrait être basé sur COBOL et être un enchevêtrement de spaghettis à l’intérieur. Un code propre aide à la maintenance et à la longévité du projet, mais il ne fait absolument rien pour l’expérience du produit.

Un robot de style BB-8
Ce robot a l’air génial ! Si tout n’est que du fil lâche et de la morve brûlante à l’intérieur, est-ce important ?

En un mot, il s’agit de concevoir l’expérience du projet plutôt que simplement le projet lui-même. Cela commence à un niveau plus abstrait, en commençant par la façon dont vous aborderez cette idée particulière. Est-ce une démo technique ou un produit ? Est-ce un projet facile à gagner ? Avec ce genre de choses à l’esprit, vous pouvez commencer à poser de meilleures questions. Des questions qui vous permettent de concevoir ce que ce sera. En étant intentionnel sur le processus par lequel vous faites quelque chose, vous influencez directement la chose que vous faites.

Laissez la bonne question être votre guide

Pour un produit, vous devez demander qui est l’utilisateur final. Même si l’utilisateur est vous, cela ne signifie pas que vous êtes statique. Un vieux mauvais code écrit par vous-même est complètement mystifiant ; pourquoi un vieux produit mal conçu ne ferait-il pas la même chose ? Un produit concerne l’utilisateur final, pas le développeur, même s’il s’agit de la même personne. Une autre bonne question serait, si Hackaday écrivait sur mon projet, sur quoi se concentreraient-ils et écriraient-ils ? (Je vais poursuivre avec « ai-je inclus des images claires et haute résolution qu’ils peuvent utiliser ? ») En tant qu’utilisateur final, quelle est l’expérience souhaitée et comment cela peut-il être plus simple. Il peut être utile d’écrire ces choses. Proposez un plan concret, ne le modifiez pas et ne laissez pas le champ d’application s’étendre. Si des problèmes surviennent, revenez aux questions que vous avez posées plus tôt, puis redéfinissez la portée. Essayez de ne pas vous laisser distraire par la technologie et concentrez-vous plutôt sur ce que vous essayez de faire. Ne vous laissez pas trop entraîner par le comment. Un excellent exemple de la façon dont un produit est conçu et fabriqué est le Flipper Zero.

Pour une démo technique, amusez-vous avec. Vous voulez y jeter autre chose ? Fonce. Peut-être que vous essayez d’apprendre un peu de WebAssembly en portant Doom. Il n’y a pas de fluage de portée car il n’y a pas de portée. Comme mentionné précédemment, l’accent est mis sur le développeur, pas sur l’utilisateur. La convivialité n’est pas l’objectif ici. Les questions peuvent être « qu’est-ce qui serait le plus intéressant » ou « comment puis-je ignorer le passe-partout ? »

Mais qu’est ce que je sais?

Bien sûr, tout cela n’est que l’opinion d’un écrivain et a une taille d’échantillon d’un. Il est possible qu’un projet se situe quelque part entre un produit et une démonstration technologique, ou aucun. Néanmoins, l’adoption de certaines de ces méthodologies a conduit à beaucoup plus de satisfaction avec les efforts des projets parallèles. Avez-vous un point de vue différent? Lorsque vous atteignez les objectifs que vous vous êtes fixés, déplacez-vous les poteaux de but ou reculez-vous pour vous attaquer à quelque chose de nouveau ?