Glass swords, moving fast and breaking things, and advocating for quality💡

Monday Ideas — Edition #109

💰 BCM — a community of developers with side hustles!

One of the most rewarding parts of my work at Refactoring is watching its community grow, and people learning from each other.

For this reason, today I am happy to promote the BCM community of developers, which launched in beta in January, and is now accepting applications for new members.

In addition to being developers, members are also newsletter writers, course creators, speakers, consultants, and more! They have many streams of income and can’t be contained by one title.

Membership includes weekly events, masterclasses, coaching and small group masterminds.

Spots are limited and applications close on June 30th. You can apply below and use the code LucaxBCM to give your application priority 👇

Back to this week’s ideas!

---

1) ⚔️ Don’t be the Glass Sword man

In one of the most hilarious episodes of PawnStars, a man walks in with a glass sword he fabricated himself.

He said he couldn’t find any glass swords in existence, so he made one. This reminded me of this tweet by Camille Fournier, about internal tools 👇

At this point in my career, I'm a firm believer that:

1. If it isn't related to your core business, and

2. No one else has an offering or one that is any good for you to use

You shouldn't build a better solution, you should ask yourself why no one else needs to solve this problem.

This is basically The Fermi’s Paradox of internal tech.

The tweet above is from 2021 and is even more true today. When it comes to internal workflows, tools today are so advanced that building bespoke code is an exception to the rule. Think of SaaS products (e.g. Airtable), low-code builders (e.g. Retool), and of course AI.

So, if you find a use case for which 1) you can’t find a fitting product, but 2) it should be common to other businesses as well, then why hasn’t anyone built it yet?

Three answers come to my mind:

Solutions exist but you don’t know them 🔍

This is extremely common, because looking for good tools to buy / integrate is harder than it seems.

In my experience, your best strategy about it is to nurture your network so you can eventually ask peers what they do in similar scenarios.

You can (and should) also leverage communities for the same reason — like the Refactoring one 👀

You can duct-tape it 🩹

Maybe there isn’t anything that works out of the box because it is easy to build with Zapier and a few automation tricks.

You can also try Pipedream or Make for deeper automation capabilities.

You don’t need it 🙅

If you can exclude the first two solutions, and it is not related to your core business, you should really ask yourself why no one else needs this — as Camille points out.

Basically, don’t be the glass sword man.

---

2) 🔨 On moving fast and breaking things

A few weeks ago I spoke with Denis Yarats, CTO of Perplexity, on the podcast.

Among other things, he told me that Perplexity places a high value on quality and thoughtfulness, understanding that the bar they have to clear to make their product win over established competitors (e.g. Google) is extremely high.

In other words, Perplexity is not a move-fast-and-break-things type of company.

They strive to ensure their product works seamlessly — it should deliver incredibly fast, accurate and high-quality answers every single time.

This commitment to quality is ingrained in their operational philosophy and influences every aspect of their development process.

This reminded me of another interview, with Aditya Agarwal, employee #10 at Facebook and, later, CTO at Dropbox.

Facebook had indeed that move-fast-break-things attitude, which meant shipping things to production every day, multiple times a day, with zero or very few tests.

While this attitude was good to get the product faster in the hands of users, Aditya believes they could afford to be reckless because Facebook was never a critical product in people’s lives — if a page didn’t load, you would just retry later.

In fact, when he joined Dropbox later, he found a very different scenario. Dropbox required high security and reliability, due to its nature as a storage service. This shaped a culture which was closer to the Perplexity one — focused on sweating the details and getting things right.

The lesson here is that there is no such thing as a universal engineering culture — each company has to find its own, based on its stage, product, and founders’ DNA.

You can find the respective podcast episodes below 👇

How Perplexity Works — with Denis Yarats 🎙️

Facebook, Dropbox, and Modern Engineering Teams — with Aditya Agarwal 🎙️

---

3) 🏅 How to advocate for quality

A few weeks ago I published a round-up of lessons learned throughout our community mastermind sessions.

One in particular led to many replies and follow-up emails, so I am including it here.

A Senior Software Engineer asked the group about a classic conflict happening on their team. The engineer takes pride in writing quality code, but doesn’t feel like their manager is supportive of this — instead, they push for quantity and speed of execution.

What to do in this case?

I have seen this many times and, as a first step, you need to make sure people are on the same page about definitions:

• What is quality code? — Are we talking about basic hygiene, like writing tests, or is it about future-proofing it through the right abstractions, or else? What parts of these do you agree vs disagree with your manager? Two people may have different definitions of quality, which need to be explored in order to make progress.

• What is speed? — When your manager pushes back on your estimate and asks to do something in one week, is it because they think your estimate is plain wrong, or is it because one week is how much the team can afford to spend on the task?

Conflicts often arise when people stop at the first order meaning of their respective concerns, and do not go further at trying to understand each other.

• Why are you concerned about quality? — is it about your professionalism? Is it because bad code leads to more maintenance? How has bad quality impacted your team in the past?

• Why is your manager concerned about speed? — is your team behind on their goals? Do you have hard deadlines? Is there some general lack of trust? Why?

There is always a question behind the question. Understanding this is the first step towards understanding each other.

When you go deep enough, you often discover you don’t really disagree — you are rather missing some context about each other’s work and goals. And once you get it, you can find ways to make the ends meet: how can quality make the team go faster?

You can find the full mastermind lessons below 👇

Lessons from our Mastermind sessions 🧠

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the paid version — if you aren’t already, consider becoming a paid subscriber. 1500+ 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