Side project or not ?


Une nouvelle techno à tester, une idée de plus qui vous traversé l’esprit et voilà, en 3 lignes de commande un nouveau projet est né ! Toutes nos félicitations aux parents pour leur 3ème, non 4ème, non pardon 17ème enfant !

Grande nouvelle pour la famille Dev, dont le dernier né a à peine 2 jours et n’atteindra malheureusement pas plus d’un mois de développement soutenu, avant d’être abandonné, stoppé en plein élan. Saas révolutionnaire ? Générateur de citations de Kaamelot aléatoires (oui, ça existe !) ? Personne ne le saura jamais.

Je suis le premier à avoir initialisé plus de projets que je ne peux me rappeler, mais dans cette famille l’aîné des projets reste aussi le plus abouti, ce blog. En fait, j’ai même grandi avec ce projet, doucement au début, puis de plus en plus vite. Je crois même que cela s’accélère encore depuis quelques mois.

Pourquoi un side project ?

Quand on commence le développement, les TP qu’on réalise en cours sont généralement assez limités, un CRUD autour d’un thème comme une application de commande de pizza, une application de gestion de collection de livres etc. et j’en passe.

En travaillant hors des cours, il m’arrivait souvent d’essayer de refaire (en vain…) ces projets, mais sans y trouver un grand intérêt. D’expérience, trouver un sujet qui vous concerne est le meilleur moyen de débuter un side project qui vous motivera. Les premiers projets que j’ai mené étaient destinés à me notifier de la mise à jour des dates de réservations du centre de loisirs de mes enfants. Le sujet était bateau, j’ai découvert qu’il existait des outils tous faits pour le faire, mais l’intérêt était là, et j’ai mené à bien le projet dans un temps raisonnable. Il est malheureusement devenu obsolète le jour où le site web a demandé une authentification sur sa page d’accueil avant de pouvoir consulter les fameuses dates.

Des idées d’applications j’en ai quelques-unes en stock, un peu trop pour le temps que j’ai pour développer sur mon temps libre 😅.

Coder pour soi

Coder sur son temps libre c’est coder pour le plaisir, sans impératifs, sans autres exigences que les vôtres. Coder sans obligation de résultat. Pour ma part, j’ai testé des outils, que j’ai ensuite présenté dans des articles de blog. À force d’expérimenter, j’ai ajouté quelques briques à la liste des technologies sur lesquelles je commence à avoir une expérience significative, comme le framework JS Astro, ou encore Tailwind CSS. Peut-être pourrai-je bientôt ajouter Angular à ces technos !

Coder pour découvrir

Parfois, au détour d’une conversation, notre curiosité est piquée par quelqu’un parlant d’un outil, d’une technologie qu’on ne connaît pas. Rien de mieux que de récupérer le “Getting Started” de l’outil en question et d’expérimenter par soi-même.

Un proche ayant suivi le même parcours que moi à quelques années d’intervalle, j’ai parfois été amené à tester des outils afin d’être à même d’apporter mon aide.

Coder pour progresser

Quand on est en mission et qu’on suit une formation, il n’est pas nécessairement possible de pratiquer immédiatement la technologie sur laquelle on vient d’être formé (ou de se former). Du coup, pour pratiquer indépendamment de ma mission actuelle je me suis attelé à la réalisation d’un outil de “gestion/monitoring” de mon blog avec Angular (délai avant le prochain article, stocks d’articles, diversité des sujets).

The dark side of side projects

La pire chose à faire quand on souhaite initier un nouveau projet, c’est de passer des heures, des jours, des semaines à chercher LA techno parfaite.

Spoiler alerte, ça n’existe pas. Chaque techno qu’on rencontre en développement a été créée afin de répondre à des problématiques techniques rencontrées par d’autres.

À ma connaissance, aucun outil n’est parfait, et chaque nouveau framework / langage / bibliothèque (on dit PAS “librairie” 😠) naît de la frustration et du mécontentement de ses utilisateurs sur certains aspects techniques.

Sérieusement, pour l’un de mes premiers projets j’ai dû passer 3 mois à chercher LA techno idéale. Au final, 3 mois de perdus et un projet réalisé avec PHP non pas pour la techno elle-même, mais pour aider un ami.

Ne cherchez surtout pas à faire du parfait dès le début. Si votre code initial est moche et que vos fichiers on 400-500 lignes ce n’est pas grave. Le moment venu, il y a des chances que de vous-même vous commenciez à tout remettre en ordre. En résumé, faites du sale qui fonctionne, ensuite vous ferez du beau qui tourne comme une horloge suisse.

Conclusion

Éclatez-vous ! Si vous codez avec un objectif inatteignable laissez tomber, ce n’est pas la peine. C’est pareil si vous codez sans conviction, vous allez juste vous dégoûter du code et alimenter votre syndrome de l’imposteur (SI SI, celui qui lit l’article avec vous en ce moment-même 😱).

Si vous trouvez une problématique qui vous concerne, ça ira tout seul. Je ne dis pas que vous ne rencontrerez pas de murs, mais que vous aurez l’envie, le désir d’aller au-delà de ces murs pour parvenir à réaliser votre projet. Plus qu’une chose à faire, lancez-vous !

Cet article vous a plu ? Contactez-moi sur   LinkedIn  😉 !

Articles en lien