Being in the right room, plans vs value, and bias for building 💡
Monday Ideas — Edition #79
Hey, Luca here! Welcome to the Monday Ideas 💡
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.
📊 Stepsize (Sponsor)
Before we start, I am happy to spend a few words to promote Stepsize, a fantastic product whose founders I have been in touch with for a long time.
Stepsize uses GenAI 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. Keep all of your stakeholders up-to-date without lifting a finger.
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.
1) 🚪 Be in the right room
Earlier this year I interviewed Thiago Ghisi, Director of Engineering at Nubank.
Thiago is one of the most thoughtful people I know when it comes to career advice, and during our chat we talked about the famous saying: if you are the smartest person in the room, you are in the wrong room.
That’s a good point, but I believe you can go a bit further and ask yourself: what does the ideal room look like? Who should be there?
Our answer was:
Someone you deeply admire for their skills and from whom you can learn from.
Someone who is receptive to your needs, sponsors your work and gives you the opportunity to shine.
Peers you get along well and with a diverse set of skills with respect to yours.
As long as your work has all three, you are set!
You can catch up with Thiago’s interview here 👇
2) ⚖️ Buy vs build bias
The buy vs build dilemma is one of the most common in engineering work.
Even though this is often portrayed as a binary choice, things are more nuanced than that. At the very least, you can make the argument for it to be three-fold:
🛒 Buy — e.g. you use a SaaS.
🧩 Integrate — e.g. you use an open source library, or a no/low code tool.
🔨 Build — e.g. you create your own code from scratch.
But the truth is this is more a continuum than discrete options, as within each camp you have various degrees of freedom.
For example, say you want to integrate authentication in a Rails app:
You might code it from scratch, because how hard can it be (joking, don’t do it please) and it would be 100% build.
You can use Devise, the most popular library for it. This counts as… integrate?
You can use a service like Auth0, which looks like a 100% buy (heck, you pay for it) but it still takes a decent amount of coding.
You can use something like Memberstack on the frontend, which is the closest you get to turnkey auth, but it would be pretty limited.
Some of these solutions are totally different and hard to compare. So, aside from matching your practical requirements, how should you decide?
These days, most engineering work is (or should be) about patching things together, rather than building them from scratch. I believe you should only build with your own hands what makes for a core IP of your company and gives you a unique competitive advantage.
Custom tech is incredibly expensive to develop and maintain, so we should treat it as an exception, rather than the rule.
I would even go as far as to say that, if you can’t find anything pre-made that fits a specific need of yours, you should be suspicious of whether your need this at all. After all, if your need is legitimate, chances are other companies would have it as well, and someone would have built a product/library for it.
🏗️ Bias for building
So, if you feel like I am pulling the rope for the “buy” team, the reason is that I believe most engineering conversations are biased in favor of building, and need to be rebalanced.
Most engineers I have known have kind of a build-first mindset — and I get it. They feel their work is to build things, so the more sophisticated the building, the more they are proving their value.
But this is, of course, dead wrong.
The goal of engineering is to serve the business, and to do it in the most efficient way possible. Engineers who find the simple, clever solution should be rewarded, as opposed to those who simply built the biggest castle.
I wrote more ideas about choosing technology in this previous guide 👇
3) 🗺️ Delivering value vs delivering plans
I have found that the more you invest in planning a feature / project, the more you are pressed to follow the plan because of 1) sunken cost, and 2) commitment with stakeholders.
That is not bad per se, but you should not forget the final goal of software is to deliver value, not to deliver plans.
If you find better ways to deliver value to the user, you should change the plan and go for it.
When delivering features is valued more than the actual outcome for the user you end up in a bad place. Martin Fowler has a great name for it: Feature Devotion.
So, you should invest in a plan that is detailed just enough to support your decision making, not more.
I wrote a couple of pieces about making plans and estimating software:
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