Hey, Luca here, welcome to a weekly edition of the💡 Monday Ideas 💡 from Refactoring! To access all our articles, library, and community, subscribe to the full version:
Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • 📣 Advertise
1) 💻 Everything as Code
One of the things on which AI is remarkably worse than humans is at using GUIs and navigating websites.
It is wildly better at writing code, which means that in your tech stack it makes sense to use code—instead of graphical interfaces—whenever you can.
We discussed this several times lately: I discovered that Shopify betted the farm on configuration as code, and Convex goes even beyond and talks about everything as code.
This strategy has always brought benefits — reproducibility, version control, self-documentation, automation — but at the expense of more cumbersome UX and having people need to remember complex DSLs. The good thing is that the downsides have largely disappeared now, because AI is extremely good at writing this stuff, leaving you mostly with the upsides.
Linking below the article I wrote with Jamie from Convex, which explains this well 👇
2) 🐛 Bad code is bad only if it needs to be changed
I love the definition of bad code as code that’s hard to change.
But when you think about it, this is only a problem if you actually need to change it. Bad code that’s stable isn’t concerning by itself.
So, your tech debt work should be focused on what Adam Tornhill calls hotspots: parts of your codebase that are both 1) problematic, and 2) frequently changed.
While this seems obvious, humans are bad at judging this intuitively. So most tech debt work is misguided: it targets either bad-but-stable code, or active areas already in good shape.
This is also hard to evaluate because activity distribution is extremely skewed: in most codebases, ~5% of the code gets 90% of the activity.
This reminds me of something from my startup days.
During an M&A conversation, the buyer’s consulting firm ran a technical due diligence. They found several areas of poor quality code—as we expected. In fact, over time we had doubled down on specific parts of the product we cared about, while phasing out others. The latter stayed experimental: less testing, more duplication, etc.
What I didn’t expect was how hard this proved to be to argue. We pointed to the strategic core we were proud of, but they weighted sketchy marginal code as an equal part of the whole.
In other words, the frequency of change wasn’t considered.
Eventually the M&A failed for a variety of reasons. This was not explicitly mentioned as a blocker, but I always suspected it contributed.
You can find the full article from my chat with Adam below 👇
3) 🔔 Use notifications for process accountability
In September I interviewed Antonia Scheidel from Duolingo, who told me how she was able to create reliable automated processes for her team.
A key insight from her story is the tactical use of notifications.
Antonia uses them to create what>«<»»> she calls system accountability, rather than invasive micromanagement. For example, when a feature is ready for design review, both the engineer and designer are tagged in a public channel notification:
“It brought the engineers into the conversation. Now when something wasn’t ready, it was easy for the engineer to say, ‘Hey, sorry designer, we’re pushing this back a week.’ The responsibility shifted from being toward me to being toward each other.”
Antonia’s notification strategy follows specific principles:
👥 Two-person tagging — always tag both stakeholders to create mutual accountability.
📍 Public but focused channels — use team channels where other conversations happen, not dedicated notification-only channels.
⚠️ Escalating reminders — DM first, then public tag if the issue persists
🚫 Volume limits — maximum 5 notifications per day, to avoid notification blindness
The most important aspect was helping people understand they had responsibility to the process, like a classroom pet—a shared system everyone needed to help maintain, rather than something the manager was personally demanding.
This transformed the dynamic from “Why should I do this for Antonia?” to “We need to help this automated system work properly,“ making compliance feel collaborative rather than punitive.
Here is the full interview with Antonia:
You can also find it on 🎧 Spotify and 📬 Substack
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca