Productive constraints, QA mindset, and first wins 💡

Monday Ideas — Edition #85

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:

New Tools and Techniques for 2024 📡

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.

---

📈 Better Stack • spot, resolve, and prevent downtime

I first spoke to the guys at Better Stack about a year ago when they only did incident management and monitoring. Since then, they have shipped logs, metrics, and dashboards and are now used by over 120k developers around the world.

If you want to improve your observability stack, with Notion-like collaboration, 10x speeds of Elastic thanks to the Clickhouse database, and work in a beautifully designed, simple, and integrated platform, go check them out.

Better Stack is a sponsor of Refactoring 🙏 here is how we run sponsorships transparently.

---

1) 🧠 QA is a mindset

In November I chatted with Jon Perl, CEO of QA Wolf, about what good QA looks like.

Early in the chat I told him that I couldn’t come up with a satisfying definition of QA, and he schooled me by saying that QA is a mindset, rather than a specific process.

QA is making sure you meet an expectation of quality for your product, and in particular that you don’t go below that quality. Some people think it’s simply “we don’t have to ship bugs”, but things are more nuanced than that:

1. If you ship a bug on something no one’s using — obviously it doesn’t matter.

2. If you break your most critical workflow and you have hundreds of paying customers, it matters.

3. If you break your most critical workflow but you only have a few customers, and they don’t pay or don’t pay a lot, it may not matter, too.

This awareness about where the value is, is the reason why we talk about Quality Assurance, as a broad function, as opposed to simply Testing.

Good QA requires sorting out what’s really valuable from what is not, and while you might argue this applies to testing in general, QA does this from a product / business standpoint, rather than a pure engineering one.

This mix of product and tech duties is also why QA is confusing to handle: should PMs do it? Or should engineers? Or should you have dedicated people for it? I wrote more about this in the full article 👇

How to do QA ✅

---

2) 🍱 Constraints enable productivity

I believe performance and creativity are enabled by constraints. As per Parkinson’s law, work without constraints tends to fill up all the available time, like a gas with its container.

Conversely, working backwards from constraints forces us to find clever solutions, both in work and life.

So, for anything you do, you can move from the “I can’t make it in one day” mindset, to the “What can I make in one day?” mindset. Deadlines work best when you work backwards from them: you set your appetite first, and define the scope later.

I have found that constraints not only force you to be creative — they make you literally more productive.

I think of myself as a disciplined person; I write the newsletter the same time everyday, I have all my set of ceremonies, and I just follow a predictable routine. However, every week, the time where I am the most productive — where I literally write the most — is the day before publishing. Every single week! I am just more focused and I seem to have more energy, because I am driven by a real constraint.

So, I believe peak performance is about finding a sweet spot where:

• You are not frustrated by having too little time, and

• You are not sluggish because you have too much.

And, I can tell you, the optimal amount of time is always going to be less than you think.

We talked constraints, kids, and side projects with Vic Vijayakumar late last year 👇

How to Build Side Projects 🕹️

---

3) 🏆 Find early wins

When you join a new company, one of the most common advice you hear is to find some early wins. But what do these look like?

In my experience, you can try to identify something that is 1) impactful, 2) low-risk, and 3) non-controversial.

Here is some advice on how to choose:

• 🔍 Check with your manager — that’s step one. Your manager might already have something in mind for you to take on. For managers: yes, you should.

• 🤗 Help people — have 1:1s with people on your team, including your manager, to figure out what bugs them, and help them out.

• 🔌 Fill in the gaps — find something nobody owns, so you create value without stepping on someone else’s toes.

• 🐄 Avoid the sacred cows — finally, all companies have some strong beliefs, justified or not, that you better not question early on. You want to find something that doesn’t piss anybody off.

Also, wins take many shapes:

• 📈 Small feature — deliver something meaningful for the product.

• 🔄 Process improvement — automate some parts of a process (= save someone else’s time) or make a process more effective.

• 🔀 Take over something — take ownership of a small piece of the product / process, freeing someone else from managing it.

You can find more advice on how to spend your first months in this previous piece 👇

How to Spend Your First 90 Days 🗓️

---

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

1) 🔒 Subscribe to the full version — 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