Systemic performance, good monoliths, and hardcore culture 💡
Monday Ideas — Edition #67
Hey, Luca here! Welcome to the Monday Ideas 💡
Every Monday I will send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
You will also receive a long-form, original article on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
</> Coderpad
Have you ever had to reverse-sort a binary tree at your job? Probably not.
That’s why 4,000+ engineering teams (including Netflix, Lyft and Spotify) have ditched the algorithm interview questions and use CoderPad’s collaborative IDE to actually code with candidates (See the Sandbox) 👇
With a realistic and customizable IDE that supports 40+ languages and frameworks, you can drag and drop a repo, add packages with npm install & watch code playback after the interview.
It’s a great way to pair program with candidates to see if they would be a good fit for your team.
Coderpad is a sponsor of Refactoring 🙏 check out here how we run sponsorships transparently.
1) 🥇 Performance is systemic
I recently wrote an article about how to help underperformers.
As a manager, you are bound to have some reports that don’t match your expectations. It is just statistics. And, in my opinion, that’s where you pull your weight.
There has been nothing more rewarding to me than taking someone who was struggling, working with them to turn things around, and watching them blossom into awesome professionals.
One of the most frequent mistakes in dealing with underperformers is not to address issues early, when they are easier to solve. In many cases, this happens because it is not 100% clear what is expected of people, so, conversely, managers can’t easily point their finger at what is not working.
Good performance is about matching or exceeding expectations about some behaviour or output. In situations where there is clarity about these and people are put in the condition to go after them, underperformance is rare.
In fact, I believe 90% of performance is systemic, rather than individual.
There is a lot of talk around finding 10x engineers, but we should rather focus on building 10x teams.
Great teams make great engineers, while the opposite is not always true.
You can find the full article below 👇
2) 🗿 Good microservices start with good monoliths
Consider the Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Paraphrasing it, good microservices designs are invariably found to have evolved from good monolithic designs.
Likewise, if your monolith looks like spaghetti, moving to microservices will not magically fix it. Rather, it will turn it into distributed spaghetti, making problems worse.
More ideas on monoliths and microservices 👇
3) 🦸 Hardcore culture and heroics
Last year I wrote my take on the whole Elon Musk/Twitter situation, from an engineering/cultural point of view.
One year later, whether we like it or not, Elon’s playbook set the example for many entrepreneurs, who today push for hustling and hardcore culture.
Engineering-wise, a problem of being hardcore (whatever this means) is that it lends itself to rewarding heroics, which, in turn, is often anti-engineering.
When you praise hustling, you may end up rewarding the guy who puts out the fires, rather than the one who prevents them from happening. The best engineering work, in fact, is usually nothing glamorous or heroic. It is invisible, and even boring.
This reminds me of the famous WWI story about planes and survivorship bias. During the war, the US military analyzed planes that were coming back from engagements to figure out where they would need the most armor. For a good while, they focused on the areas where, statistically, planes got hit the most, and reinforced those.
Abraham Wald, a Hungarian mathematician who had fled to the US to escape the Nazis, and was working with the military, pointed out that those numbers only considered planes that came back — despite getting hit. Engineers should have focused on areas that apparently didn’t get hit much, because planes that got hit there probably crashed.
If the aircraft is only reinforced in the most commonly hit areas, this is survivorship bias because data from crashed planes is ignored; in fact, those hit in other places did not survive.
So, just like with the planes, what’s most visible ≠ what’s most valuable.
I talked about this and a lot more with Jean Hsu, a few months back 👇
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. You can 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