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?