It's probably a professional bias, but I notice bugs A LOT. And often they prevent me from using some software.
Last week, I wanted to shop for some clothes online and spotted several bugs in key functionality, and one of them was critical.
The support chat window was buggy, the page with size tables shows plain HTML, and the most ridiculous - I wasn't able to submit a purchase, because adding an address endpoint returns 500. And it was a world-famous brand. The support asked me to send them my email and password so they could do a purchase for me - very secure - and still won't work.
Then today I was checking out one of the job-searching platforms from the top 3 in Google search results and couldn't add my current location on one of the onboarding steps - they have CORS issues for that request.
My favorite example: not being able to approve an identity for a bank account for more than 6 months because of a bug in the form validation.
The truth is that having bugs is an absolutely normal state. You just can't completely avoid having them if the application is under extensive development. You need to accept it. If someone claims that there are no bugs in the application, well, it's just that it hasn't been tested enough.
But what you can do - aim to produce as few bugs as possible. Here I want to share my personal thoughts and experience. This checklist will be helpful not only for engineers but also for product people. Let's see what we can do.
Have you tested it?
When I'm mentoring beginner engineers, and they want to show me their work so I can review it, the first thing I ask:
Have you tested it? How many times? 1? Check at least 3 more times with different scenarios.
This is so simple, so basic, but sometimes it is still ignored. I mean, all bugs that I've mentioned could be spotted if the happy flow was tested at least once!
Manual testing is still a must, even if you're sure it is working, even if your code is covered by automated tests (they may not spot the problem), and even if your code was reviewed by 5 LLM-agents.
How can you be sure your basic flows work?
Engineers like to measure the test coverage. And it is definitely a useful benchmark. But not all the functionality is equally important.
Some actions might be used once per year and are not the crucial part, like changing the profile image, but some are used thousands of times per day. Crucial flows that are most important for business must be heavily tested by unit, integration, and e2e tests. Every time they change the code, engineers can be sure that the core functionality works.
I would also like to address here something I've heard a lot: the customer pays for writing features, not writing tests. And it triggers me, because tests are not something separate - they are part of the features. When you do an estimation, consider writing tests + manual testing. The customer would be happy not to pay for fixing bugs that could be easily avoided.
Is the application observable?
There are tons of observability tools of different types: for managing logs, monitoring infrastructure, and application performance.
Nowadays, you might also need LLM/AI observability tools. Pick any of your taste, configure useful filters and notifications.
I also highly recommend having a logs dashboard for local development. It's much more convenient than getting through Docker container logs and console output.
Do you know why you are doing this feature?
This is less about engineering, but more about the product side.
Clear requirements lead to code that aligns better with business needs. Which means there will be less unexpected or undesired behavior.
If you're an engineer and you have no idea what this feature should really do - don't start until you understand the requirements. This is actually part of your job - aligning code with the requirements.
Do you understand the domain?
This point is also more about the product. Domain knowledge is something that is acquired over time. It is important to help the engineering team understand the domain. The best experience I had was when the company held workshops to explain different topics in the domain to engineers. For me, personally, it helped a lot. And it also helps to increase quality, because engineers could start noticing missing pieces and edge cases.
So, if you feel a lack of domain knowledge, feel free to ask questions. If you're leading a team, consider organizing knowledge workshops and creating documentation explaining the domain.
Another important thing - the team must speak the same product language. If you want to know more about this, I'd like to invite you to check this article How Ubiquitous Language Can Solve Your Communication Issues
Conclusion
There are a lot of things that could also be mentioned here, like clean code, application architecture design, or coding agents that automatically fix reported bugs. But my idea is to begin with simple, small steps that, over time, will get you where you want to be.
P.S. When spotting a bug, don't be angry - we all have been there. Be nice and report about it, so the support team can address it to the development team, and you and other people can continue enjoying the software. You're capable of describing an issue much better than an average user, so your input is valuable.
I, personally, report a lot, trying to make the description as clear as possible. It could be my favorite online bookstore or Android skin. It's so nice to notice that the issue is gone.
The artwork used in the cover is "Insects on a stone slab" by Jan Van Kessel.
Top comments (0)