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.
π 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:
If you ship a bug on something no oneβs using β obviously it doesnβt matter.
If you break your most critical workflow and you have hundreds of paying customers, it matters.
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 π
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 π
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 π
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
Hey Luca, link to "How to do QA β " is broken. I couldn't access it from library either - is this article unpublished?