Hey, Luca here! Welcome to the ✨️️️️️️️ monthly free essay ✨️️️️️️️ from Refactoring.
Every week I write an article to 170K+ engineers about how to make good software together. To get access to all our articles, resources, and our private community, subscribe to the full version.
Today I want to share some thoughts about what I do at Refactoring, how it changes (and how it doesn’t change) because of all that’s happening in tech, and some plans for next year.
Since the beginning, the mission of Refactoring has been to help people work well together in making software. That hasn’t changed since day one, and I don’t think it will change anytime soon. Like with good interfaces, though, what can change is its implementation — that is, what it takes to actually accomplish it.
Even more so, I expect this to change. Software is never done, teams are never done, so Refactoring itself should be about continuous change and improvement, hence the name we picked. The same goes for our symbol: a spiral 🌀 keeps moving, continuously, toward the center, which for me is about looking for truth and getting a little better every time.
So the question is: what does it mean to keep Refactoring relevant for today’s world?
Trying to answer this question, here is the agenda:
📈 Software engineering has changed — a widening gap, and roles getting closer.
🧭 What this means for our mission — helping teams bridge this gap.
🔧 Tolaria and more — experimenting directly, plus Android and web coming.
🎙️ In-person podcast — and who I am talking with next.
💬 Community — the group version of all this, and an in-person gathering.
🧵 Articles — deeper, more researched, while still easy to skim.
Let’s dive in!
📈 Software engineering has changed
Nobody really knows where all of this goes, and I am not good at predictions anyway. Still, when I look at what I see in the data, on the podcast, in the community, and in my own work, two vectors of change look very clear to me.
1) The gap between teams is widening
We have always known, at least since the first works of quantitative research about software delivery, like Accelerate, that productivity in software follows a power law. The best teams are several times better and faster than the median.
At first, we might attribute this to how young our industry is, and think we will eventually reach more consensus on how to build software, so that this gap partially closes. This is not happening. In fact, the gap is getting bigger.
Last week I was in Hamburg at code.talks, where I gave a keynote and interviewed Randy Shoup and Sam Newman for the podcast (episodes coming out soon!). Randy, who is now SVP of Engineering at CircleCI, told me about one finding from their quarterly research: in Q1, the throughput gap between elite teams and the median was 8x. In Q2 it became 9x, and in Q3 it was 10x.
We also covered some of this research in Acceleration Whiplash, and The Era of the Software Factory before that.
I believe the gap is widening for a combination of three factors:
Productivity tech (aka AI) keeps improving at a faster rate than the median team can absorb.
Good teams are faster and better at adopting new tech than the median team.
AI disproportionately benefits teams who already have good practices in place (What’s good for humans is good for AI).
When you think about it, only #2 is somewhat obvious, while #1 and #3 are not. In fact, we could easily imagine a world where:
AI / productivity tech plateaued, or improved at a slower rate.
AI behaved in a way that makes a lot of traditional practices irrelevant, thus leveling the playing field.
None of this is happening, and the result is that whoever is ahead keeps, at least for now, increasing their lead.
2) What people do, and how they work
The second vector is about how the work itself changes.
This is harder to assess because, if the numbers above are clear about what’s happening downstream, what’s upstream is often messy and diverse. I have been in tech for ~20 years, and I can confidently say there has never been less consensus about how to work together than today.
However, if you look at the elite teams we were discussing, a few trends surface, and one is particularly interesting: the scope of what people do is increasing.
In teams that are being productive with AI, people are not just working faster, they are doing things they didn’t do before: PMs write prototypes, engineers ship features, designers write code. Granted, each category distrusts the others doing so — engineers complain about slop code, designers about slop design, and so on — but the genie is out of the bottle and we are never going back.
This means the traditional roles in product and engineering teams are getting closer. Each keeps its own core, but they are broader, they overlap more, and teamwork is more tight-knit.
So, to me, these two are the most interesting elements of this whole change, because they are both about how we work together, which is exactly what Refactoring is about.
🧭 What this means for our mission
So, if there is a gap, I believe Refactoring should help teams bridge it. And I see two steps to doing that:
Quality reporting of how the best teams work — because that is not clear in the first place. A lot of what is out there today is either hype or hot takes, and it’s hard for people to tell what is actually working, for whom, and under which conditions.
Deconstructing how that works — so that it becomes easier for others to get there. Practices rarely transfer directly between teams, so the job is to break them down into the principles behind them, and into steps that a different team, with different constraints, can actually take.
This has always been what we do, but the stakes now feel higher, because the gap is growing and the practices themselves are changing much faster than before.
So, how will we do it? In four ways: building things myself, the podcast, the community, and the articles. Let’s look at each of them, together with what’s coming next for each.
🔧 Tolaria and more: experimenting directly
There is no substitute for trying things yourself.
I am working on Tolaria, on my own software for running our operations (which I will write more about in the next edition of the Tolaria updates), and these days I am even tinkering with building a game!
Some of this is directly useful to our business, some is for my enjoyment, but all of it is for getting ground truth about how software can be made today, as opposed to just repeating what I hear or read elsewhere.
About this, I often think about Anush Elangovan, VP of AI Software at AMD, whom I had on the podcast back in July. Anush leads an organization with more than 1000 engineers, yet he spends 40% of his time hands-on, writing software himself. He generated more code in the last four months than in the previous four years combined.
I can’t say I have a precise split myself, but something around 40% of my time on building feels right, and it’s the main reason why I can write about AI coding from real experience.
About Tolaria, here is what’s coming next:
Tolaria for Android — after the iOS app, Android is the natural next step, as the app is built in React Native. I just want to ship it when I’m confident it works well.
Tolaria on the web — to bring Tolaria closer to how something like Google Docs works, where you can share specific documents with colleagues and partners, real-time collab, and more. Like the rest of Tolaria, it will be open-source and self-hostable.
🎙️ The podcast, now in person
The most successful people I know are not writing about their experience, so the podcast becomes even more central as a way to go there and extract good information from tech leaders’ heads!
For this reason, I am doubling down on it and moving to in-person conversations only: the quality of the chats changes completely when you are in the same room. I have seen this already with Randy and Sam in Hamburg.
I am also broadening the scope a bit. So far I have mostly talked with tech leaders and engineers, but now I also want to talk with people in product, design, coaching, and more. With roles getting closer, I believe these perspectives become more valuable for engineers — who stay the main readers of Refactoring — than they were before.
So here is the new season! After Hamburg, I’ll be in New York, San Francisco, and more, to meet and interview some of my favorite people in tech. Here is the lineup so far:
Randy Shoup — SVP Engineering at CircleCI, after leading engineering at eBay, Google and more.
Sam Newman — author of Building Microservices, and of the brand new Building Resilient Distributed Systems.
Camille Fournier — VP Engineering at CoreWeave and author of The Manager’s Path.
Melissa Perri — founder of Product Institute and author of Escaping the Build Trap.
Charity Majors — co-founder and CTO of Honeycomb, who shaped a lot of how we think about observability.
Michelle Parsons — founder and CEO of Lora, and former CPO at Hinge.
Ben Fox — career coach who helps senior tech leaders find work that actually fits them.
We will explore what’s happening in tech right now, how individuals and teams are navigating it, and what’s coming next. If there is anything you would like me to ask them, let me know!
💬 Community – the group version of this
An ugly side of the AI transition is that we are getting more isolated.
This was already happening with remote work, and it’s now worse as we do more things by ourselves, ask Claude instead of our colleagues, and more. It’s convenient, and I would never say we should take it away, but we are also losing something along the way.
The Refactoring community is the place we are building to host these conversations, and it’s becoming more and more central to how we do things here. We bring more of our members’ perspectives into the articles, like we did recently with How AI is changing engineering management, and we host live online events twice a month.
Lately, together with our awesome Community Lead Melinda Seckington, we have also started running monthly themes, as a way to work all together on one topic at a time and get deeper insights.
October was about Management in the Age of AI
November is about Simplification
Each theme ties together our recurring formats:
The Mastermind, where leaders bring a real problem and we work on it together
The AI Club, where people show what they learned that month (including what didn’t work)
Plus a book club, polls and challenges in between. In fact, the management article I mentioned above came straight out of October’s conversations!
But some rapport is hard to build on Zoom, so we are starting to work on a big in-person Refactoring gathering for late next year. It’s still early, so no dates or places yet, but I am very excited about it.
🧵 Articles – our flagship long-forms
Last but not least, the articles themselves.
You may have noticed they have recently become deeper and more grounded in more examples and case studies of companies doing things. They always work from first principles, as we like to do, but they will also give you more pointers if you want to dive deeper.
This is where AI is really helping us: doing more research and connecting more dots between different pieces of content. This particularly shines for a publication like Refactoring that has more than 600 editions published in over 6 years, so for everything I write about there is usually a lot of additional material from the past that can be referenced: articles, interviews, diagrams, and more.
We have also learned how to make good use of AI for writing, and it took a while. The bad use is having AI write things directly. The good use, for us, is at the beginning and at the end of the process: first for research and then for review, while I put the ideas together and write the words myself. That’s what I do, and it’s what I intend to keep doing.
So you can expect Refactoring articles to become deeper and more researched, while still being easy to skim, and still conveying complex things in a simple way, as they have always tried to.
And that’s it for today! As always, if you have thoughts about any of this, I’d love to hear them.
I wish you a great week!
Sincerely 👋
Luca