On the writing front #
If all goes as planned, I should be exhibiting the weekend of June 7th at the Printemps des Viennes in Troyes.
The Voie Verte des Viennes is a lovely wooded path that follows the two Viennes rivers, connecting Troyes to Rivière de Corps (yes, there’s a city in Aube actually called Rivière de Corps), passing through Saint-André-les-Vergers and Sainte-Savine. Every year around June, the association Les Amis de la Coulée Verte organizes the Printemps des Viennes, a weekend where you can discover local associations (some active nationally, like the LPO, and others very local) and regional artists. This year, Les Maraîchers des Viennes, where I buy my organic vegetables grown just a few hundred meters from my home, have invited me to share their booth.
I’ll be offering the paper version of Suzuha, my short story Le Don de l’Hiver (a bit out of season, but never mind), my illustrations of The Lioness of the Sands and The Sleeping Fox, as well as a new type of goodie I’ve been thinking about for a while.
On the web front #
I’m a consultant. Lately, I’ve been spending more time auditing codebases than actually coding. My job is to analyze my clients’ projects to determine the best path forward for achieving their goals.
Often, this involves maintenance. Many companies struggle to integrate technical maintenance into their processes. Since the value isn’t as visually tangible as a new feature, developers sometimes find it hard to convince management of the importance of maintenance tasks. Moreover, many developers lack project management instincts and simply don’t see it as their role to explain to their managers why this work needs to be included in roadmaps. The result? Slow, hard-to-maintain apps that fall behind web standards, behind multiple major versions in their dependencies, and teams unsure of where to start modernizing their stack, or even whether they should start over with a different framework. My job is to open up the best possible path for them and provide an action plan to reassure them and restore visibility on where they stand and where they should go next.
In my career, I’ve seen three methods for integrating technical stack maintenance into development:
-
The dedicated team: The most common approach. A dedicated technical team serves as the reference for everything related to developer experience (DX). This team manages dependencies, continuous integration (CI), monitors performance, test durations, and more. They listen to feature-focused developers and build tools to make their work easier. The team must be large enough to effectively implement changes, depending on the size of the application and the rest of the teams. This approach is effective but requires significant investment.
-
The rotating squad: Less common but effective in some companies. Instead of a dedicated team, there’s a single technical lead who prepares and prioritizes the technical tasks the project needs. However, they can’t do it alone, they need a team. This team is formed by taking one developer from each feature-focused team, creating a temporary squad for the required duration. For example, suppose an app has six functional modules managed by six teams. A new best practice is recommended by the linter, but the current code doesn’t implement it, generating lint errors in 120 different files. Suppose one developer can fix three occurrences of the error per day. The rotating squad system allows the technical lead to have six developers, one from each of the six teams. They can assign four of them to the lint error for two weeks while the other two tackle something else. After two weeks, this squad is replaced by other developers who will work on the next technical tasks or reinforce ongoing ones. This approach fosters good knowledge transfer within the codebase but requires strong organization and cooperative managers.
-
The “20% time”: Each developer allocates 20% of their time, which means one day per week, to technical work. This is one of the simplest and most intuitive methods to implement. I’ll be blunt: it doesn’t work. It might suffice for basic dependency maintenance, but it doesn’t allow for innovation or addressing deeper technical issues. Having just one day isn’t enough to focus deeply; it takes weeks to see the beginning of meaningful progress. And the little poop on the cow patty: developers are often lost at sea. They are left to their own devices, alone, with a vague “Go do cool stuff” encouragement, without a clear vision of the whole project’s technical needs. As a result, the 20% time often fizzles out, with low participation rates and most developers preferring to continue working on the feature they started the day before.
On the culture front #
I hadn’t mentioned it before, but some time ago, I watched Zootopia 2. I found it quite enjoyable, probably even better than the first one, though I don’t remember the first one all that well.
The original Zootopia was criticized for flipping the metaphor of systemic oppression. In Zootopia, all animals live in harmony: predators coexist peacefully with their prey without devouring them. But beneath this idyllic surface, oppression exists, and you can sense a hierarchy along the lines of “large predator > large prey > small predator > small prey.” In the first film, predators, victims of a conspiracy, revert to their terrifying, rabbit meat-craving selves (more or less). The population then starts pointing fingers at them, framing them as an oppressed group. The issue? The fear of predators is rational to begin with. It’s at least odd to critique baseless oppression by victimizing the group originally at the top of the hierarchy… I enjoyed the first film and found it entertaining, but this criticism strikes me as valid.
I felt the second film avoided this problem and instead set things straight. The relationship between the two protagonists isn’t framed through a predator-prey lens, and the antagonistic groups are carnivores. In short, if you didn’t like the first film for the reasons mentioned above, I think you might still enjoy giving this one a chance.