Most bugs are a waste of time
Some recent contrarian insight from a Terminal tech talk made me pause to rethink my perspective on bugs.
In an interview with Stergios Anastasiadis, formerly of Google, Shopify, and now heading up engineering at a startup called ROSS Intelligence, he brought up 2 points that I’ve never heard championed before.
1) Avoid preoccupying yourself with bugs
If it’s possible, not to worry about bugs at all, don’t do it (don’t worry about them).
What? What about those initial users, or that permanently nagging Slack integration with your bug reporting, or your peers noting telling you to your face?
Occupying yourself in hundreds of bugs, and triaging them in P3s and P2s, in my opinion is a complete waste of time. Try to improve your process, and just focus on P0 items. That’s it. I would not put yourself in a scenario where you’re just focusing on bugs all the time.
Keep in mind that he’s speaking from a Series A context — this is when startups are primarily fluctuating somewhere between product market fit phase, and validating big and bold new features that they aren’t afraid to throw out if they don’t work. I think deep down inside I’ve been practising this for sometime.
I used to panic and drop everything to fix a bug. Every bug. But if you do this, before long you’re dropping everything, every day. That’s a lot of things being dropped.
It reminds me of when I used to work in a kitchen before I got involved in programming. If I’m making a pizza, rolling out the dough and assembling it for the oven, am I going to waste time worrying about every sprinkle of flour being spilled onto the floor?
No I’m not, and it’s not just because my head chef was abusive (although that was part of the reason). It’s because if I repeatedly did that then the customer would cancel the order and walk out the door because I never got their pizza in the oven. It’s a retraining of the mind — we are told to focus on the little things to be good diligent workers. But ignoring the pedantic aspects to focus on the bigger picture, is arguably an even more diligent practise…only that conventional wisdom never preaches that to us.
Stergios is unearthing a more holistic approach here, where by focusing on the bigger goals, you are going to iron out these smaller bugs and improve the process along the way anyway.
Any bug other than an extreme high priority is a waste of time, otherwise it’s a distraction to yourself and the broader startup goals.
The next point kind of ties into the whole bug and focus thing, but from a different angle…
2) Keep your developers working on the core product rather than fulfilling incidental asks from customers in the field
Somebody in the crowd asked Stergios about handling situations where your tasking developers with the quick and dirty work, until it doesn’t work. Until it doesn’t scale.
My favourite answer to that question is NO.
I have personally been in this situation before, where the CFO was disrupting us on a daily basis with requests from customers, or himself, that were probably better off being validated by someone who is tech savvy but not tasked with engineering the core product.
What would be best to do would be to find people who know their way through the system to answer that question that maybe are not developers. The jewell of your organization at that time in your journey, is the team pushing the product out the door.
In short, keep your developers from being taken away from key deliverables.
These “incidental asks” he refers to could be bugs, but not necessarily. They might be wouldn’t it be cool feature suggestions, or some kind of pushy request for arbitrary data. I like cool, and I like cool features. 😎 But I also like finishing something, and being part of a team that knows how to finish, validate, reflect, improve, optimize, start again, etc.
This is sound advice for any stage of a career in tech.
