Période difficile pour les conférences développeur
L'article analyse les difficultés financières et de participation que rencontrent les conférences pour développeurs dans le contexte économique actuel et l'avènement de l'IA.
Jérémy DECOOL is a software architect at Activinnov in Lyon, France, driven by Unix and Open Source principles. He focuses on building simple, efficient, and maintainable software with a strong emphasis on technical quality, clean architecture, and user-centered design. With a pragmatic mindset, Jérémy designs modular and evolutive systems adapted to constantly changing business needs. He is particularly interested in software architecture, team organization, developer experience, and engineering culture, regularly sharing insights on topics such as onboarding, collaboration, testing practices, and technical decision-making. Committed to continuous learning, he keeps a close watch on modern development and project management practices, with the ambition of evolving toward Lead Developer and Technical Manager roles. Outside of software engineering, he is a passionate sports enthusiast.
198 articles from this blog
L'article analyse les difficultés financières et de participation que rencontrent les conférences pour développeurs dans le contexte économique actuel et l'avènement de l'IA.
Explique le concept des profils T-Shaped en développement : une expertise profonde couplée à des compétences transverses pour une meilleure collaboration d'équipe.
L'article défend que les problèmes logiciels sont souvent dus à un manque de contraintes et de validation, et non à la faute des utilisateurs.
L'auteur explique sa migration d'hébergement vers un fournisseur français pour aligner ses choix techniques avec ses convictions sur la souveraineté numérique.
L'article discute de l'utilisation des "boring technologies" (technologies ennuyeuses mais maîtrisées) et du moment opportun pour changer de solution technique.
L'article explique l'importance cruciale des rétrospectives d'équipe en développement pour l'amélioration continue et la dynamique de projet.
Présente le concept de "Documentation Vivante", une documentation générée automatiquement à partir du code pour éviter l'obsolescence.
L'article souligne l'importance cruciale de la forme et de la clarté dans la communication technique au sein des équipes de développement.
L'article explique que les bonnes pratiques en développement logiciel sont contextuelles et ne doivent pas être appliquées aveuglément d'un projet à l'autre.
Récapitulatif 2025 d'un blogueur technique : partage de contenu, articles populaires sur l'architecture et DDD, et réflexions sur l'impact de l'IA.
L'article explique comment les raccourcis techniques tolérés deviennent des standards, menant à une baisse de qualité, et souligne l'importance de maintenir des conventions d'équipe.
L'article explique comment simplifier l'intégration des développeurs avec une commande unique pour configurer l'environnement de projet.
Conseils pour gérer efficacement les réunions hybrides (présentiel/distanciel) et éviter que les participants à distance soient oubliés.
L'article défend l'utilisation des technologies éprouvées et stables (« boring technologies ») plutôt que les solutions à la mode, pour plus de fiabilité et de maintenabilité.
L'article explique pourquoi la taille idéale d'une équipe, notamment en tech, se situe entre 5 et 9 personnes pour optimiser communication et agilité.
L'importance de la documentation et des standards pour maintenir la cohésion et la connaissance dans une équipe de développement lors des changements de membres.
L'article analyse les problèmes organisationnels en entreprise, notamment les silos entre équipes, et propose l'organisation en équipes produit pluridisciplinaires comme solution.
L'article explique pourquoi il est préférable d'expliquer un concept technique avant de le nommer, pour éviter les biais liés aux buzzwords.
Comment prioriser les développements logiciels en utilisant Domain Driven Design pour classer les fonctionnalités en Core, Support et Generic.
Analyse du dilemme stratégique "Build vs Buy" pour les solutions logicielles, expliquant quand développer en interne ou intégrer une solution existante.