Niche stacks, code review horror stories, and design systems💡
Monday Ideas — Edition #142
💬 Unblocked • understand how your codebase works and why!
This week I am happy to promote Unblocked, which is a long-time partner or Refactoring!
Unblocked augments your team’s source code with knowledge from Slack, Confluence, Notion, and more, to instantly answer questions about your application.
Now everyone can get their work done – without having to dig for answers or interrupt their teammates.
Teams like Drata say they save an hour or more a day per engineer with Unblocked.
1) 🔨 AI will make niche stacks thrive
An underrated benefit of using AI coding tools is that you get Universal Basic Proficiency in pretty much everything. This especially helps niche languages and frameworks, making them easier to pick up.
Why is this important? Because I feel like we spent the last decade consolidating most of web dev around very few choices, making suboptimal calls to prioritize reusing the same skills, vs choosing the right tool for the job.
Nobody ever thought Electron apps would feel or work better than native ones, but Electron still dominates because 1) you can write once and run everywhere, and 2) people prefer to write (e.g.) React than Swift.
Or, Rust is widely admired for its performance, memory safety, and concurrency. But even when these features matter, how many teams are actually learning Rust vs lazily creating yet another Node service?
AI reduces the barrier to entry for any language and tech. This, I believe, will do wonders for the diversity of our stacks, which, in turn, will improve the quality of our apps.
I wrote more predictions about AI (at my own risk) in this recent piece 👇
2) 🎨 Use design systems
Early last year I listed a set of practices that I believed you needed to consider in 2024.
Have you done it?! I don’t want to know 😄
Out of them, one of my favorites is using a design system. Design systems are not a novel idea — but they are an idea that has only been growing and improving with time. They address two issues:
Delivering consistent products at scale, and
Making design work more efficient
So, what started as simple, static style guides, usually for corporates, has evolved today into full component libraries and best practices that can dramatically improve any team’s workflow.
Modern design systems also bridge the gap between design and development: they are typically coded, version-controlled, and supported by dedicated tools, like Storybook.
So, just like there is consensus today about investing in platforms and DX, I believe design systems are going to follow the same route and become commonplace, especially in the age of AI and product engineers.
Here are a couple of recommended resources:
Design Systems — a publication by Figma entirely dedicated to… well, you guessed it.
Design ADRs — we covered the benefits of ADRs above, and you can make the same arguments for design work. Check out this great article to learn more.
And you can find our full technology radar below 👇
3) Code review horror stories 🔍
Code reviews are the main (and possibly only) feedback loop on how your team writes code.
This feedback loop not only catches defects but also aligns practices and culture. From high-level principles to naming conventions, many of these are enforced and even born out of code reviews.
This is sometimes hard to understand, so let me tell you two stories:
A no-reviews story ❌
I worked as an EM on a team that didn’t review code. The team of 4 senior engineers pushed code to prod all the time.
Things seemed fine, and code quality was good, but there were invisible problems:
Gatekeeping — Each engineer had personal areas of ownership, impenetrable to others.
Inconsistency — Different parts of the code had inconsistent naming, libraries, folder structures, etc.
No docs — Little incentive to write and update docs.
These problems eventually led to more issues:
Collaboration — Design, tradeoff, or estimate discussions were hard due to silos.
Hiring — Onboarding new engineers was a nightmare.
Resource allocation — Hard to invest in specific product areas.
Key man risk — Individual engineers became too important, which was concerning.
This story shows the impact of not doing reviews goes beyond “more bugs in prod”. It affects almost everything you do in the long run.
A slow-reviews story 🐌
The other end of the spectrum is equally bad. Bad code reviews are usually bad in two ways, often simultaneously:
They are slow — delaying release for hours or days.
They are superficial — not improving the code or sharing knowledge.
Superficial reviews have the same problems as no-reviews, so no need to elaborate.
Slow reviews mess up engineers’ work. Once a developer submits a PR, their work isn’t over: they may need to implement improvements based on the review and ensure everything works in production.
Including several hours of delay (multiplied by review iterations) makes engineers switch tasks, increasing WIP, cognitive load, reducing productivity, leading to batched releases, and a cycle of badness.
More thoughts on code reviews:
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
will you do New Tools and Techniques for 2025 and beyond? 😇