Layers of change, stepping stones, superficial cloud native 💡
Monday Ideas — Edition #81
Hey, Luca here! Every Monday I send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
Paid members also receive a long-form, original essay on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider joining 1400+ engineers and get the paid membership!
p.s. learn more about the benefits of the paid plan here.
🐺 QA Wolf (Sponsor)
Kiss bugs goodbye with fully automated end-to-end test coverage!
QA Wolf offers a cost-effective approach to getting 80% test coverage in just 4 months.
They will build and maintain your test suite in Playwright (no more dealing with false positives or flaky tests) + provide unlimited parallel test runs on their infrastructure at no additional cost. The benefit? No more manual e2e testing, no more slow QA cycles, and no more bugs.
They have multiple case studies of customers saving $200k+/year in QA engineering and infrastructure costs. Schedule a demo to learn more.
QA Wolf is a sponsor of Refactoring 🙏 learn more here about how we run transparent partnerships.
1) 🔺 The Three Layers of Change
One month ago we reviewed Atomic Habits, by James Clear, in the community book club.
One of the most memorable ideas from the book is thinking about change as being made of three layers:
🌟 Identity — the person you want to become. It is the improved version of you that you look forward to, which unlocks the why you are doing this.
🔄 Processes — your systems, or habits, to bring you closer to your improved identity, and make the outcomes happen.
🏆 Outcomes — the specific things you want to achieve. It can only work in combination with the other two.
The author argues that the strongest habits are identity-based, rather than outcome-based.
Outcomes in fact, like goals, are temporary — what happens after the goal is achieved? — while identity is forever. Outcome-based habits tend to be weaker, while a strong identity is what allows you to play infinite games and make things stick.
As an example, rather than thinking that you should “lose weight” and focus on a target weight, think about what it means to be a healthy, active person. What does this version of you look like? What do they do every day?
Visualize this person and their life, and make it happen with habits.
You can find the full book review in this previous Refactoring edition 👇
2) 🗿 Stepping Stones
In the latest edition about engineering culture I briefly mentioned my chat with James Cowling, former Principal Engineer at Dropbox, and his way of handling big projects.
When there is no linear path from start to finish, James likes to break down work into stepping stones. Stepping stones are not your generic milestones — they need to have these qualities:
📈 Incremental — you can continue building on top of each one.
🏆 Valuable — they are useful. They solve the problem, even if in an inefficient / expensive / precarious way.
🔍 Instructive — they make you learn more about the problem space, so you can eliminate some of the fog of war and design better solutions in the next iterations.
Let’s make a practical example of the Dropbox storage system that James designed. The end game for this might look like a giant, multi-exabyte system deployed in data centers around the US. But, put like this, 1) it would cost a huge sum of money, and 2) it would involve daunting technical challenges, like designing a file system and its hardware architecture.
So, James scopes the problem down into deliverables that get you closer and closer, while being valuable on their own:
Let's build an in-memory storage system that just works on one node.
Make it run on one node and store data on a disk.
Turn it into a distributed system — still not efficient — but correct.
Make the distributed system efficient and scalable.
Good stepping stones are a win for all the people involved:
They unblock stakeholders — because they have a partial solution they can interact with. They can give you feedback and create more alignment with engineers.
They motivate the team — because they shipped something that works!
They might be a stopping point — they might turn into stopping stones (hehe) if the company decides it’s enough.
The last point is the real litmus test: if, after a stepping stone, you can drop the project and get some value, then it’s a good stepping stone.
And this will happen.
If you do your job right, you will definitely drop projects before the supposed end. In fact, engineers often think that systems need to be more optimal than they really need to be. A surprising upside of good stepping stones is that they often make you do less work, because you discover you didn’t really need part of it.
You can find the full chat with James here 👇
3) ☁️ Beware superficial cloud native
Cloud providers today have a strong influence on how applications are designed.
That’s because, over time, they have gradually expanded from simply renting servers to people, to running managed services that you can use like building blocks for composing your software.
Since these services are well-designed in isolation, you may be fooled into thinking that by taking many of them and combining them you will naturally end up with a good design.
This is wrong, of course, and lies at the core of many mistakes I see people making with trendy patterns like microservices, serverless, and more.
Cloud services provide real, tangible benefits, but they should support your system design — which is largely independent from them — rather than the other way around.
You can find more ideas about cloud, monoliths and microservices, in these previous articles:
📊 Stepsize (Sponsor)
Last week we promoted Stepsize, which uses generative AI to automatically create stunning digestible updates about your product development.
It integrates with issue trackers like Jira or Linear and intelligently analyzes your project data, linking tasks, goals, and activities to create context-rich sprint and cycle reports.
Your first report is completely free and, as a Refactoring reader, you get an additional free month when signing up for the Team plan, by using the REFACTORING code.
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. 1400+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca