One of the great things about working within a team is to witness behaviors that shape the course of an entire team's morale and culture. Often, those behaviors are triggered under typical day-to-day situations, during routine checks, feature implementations, bug fixings, or discussions.

I am very fond of bug-hunting and fixing. Most people I know consider it one of the tedious aspects of the software engineering cycle. But not me. I believe that - if done correctly - fixing bugs can give you plenty of insights into the inner workings of a project (or even an entire company) and is a crucial opportunity to get to know your team better, as well.

Why don't we like solving bugs?

It's not (always) part of the creative process.

Fixing bugs is not always part of the creative process. Instead, they usually include debugging code and the business behind the code.

Maybe I'm lucky (or unlucky), but most of the bugs that I have found in my life are rarely the result of lacking proper software engineering practices.

Don't get me wrong; I have seen architectural decisions so bad that it took three times as much time to fix them as it took to develop. Some of the most challenging bugs I have faced were the result of a technical error. However, most of the tedious bugs I have encountered were caused by a business misunderstanding between the developers and the business stakeholders.

In those cases, solving the bug usually involves direct communication between the manager and the developer. The developer often waits for feedback from the project manager's dependencies or the feedback from other systems providing with necessary information.

In short, a significant part of bug-hunting involves no coding. And that seems like a career hindrance.

People view it as less exciting.

It amazes me how the 90/10 rule seems to apply everywhere. That means 10% of the project you are developing demands 90% of your time. That part is called refinement.

During the refinement stage, a lot of bugs are coming up, a few of them serious, some others are minor, but they are bugs nonetheless. The work stops being fun anymore; no new features are coming up. The previous day's work exposes as many features as the next one's.

After the production release, there comes the maintenance stage. That's where essential bugs come up (because they primarily affect real users and clients). Bugs need to be taken care of asap, and something new always comes up. Although the maintenance stage could mean that the developer can - at last - reap the benefits of their previous efforts and relax their workflow with a bit of bug-fixing, it's often not seen this way.

The most creative stage of a product tends to be the creation stage, where most developers seem to be happier. I can't blame them; I have witnessed projects taking a year to refine after just three months after the initial beta. It wasn't pretty.

Is bug-hunting a chance?

Under some circumstances, it is.

Every bug has a history behind it, and to make myself avoid viewing it as a chore, I try to make forensics a part of my development process.

There are cases where this has been very rewarding for me, and I view it as a chance to learn something (or someone) new.

It's a chance to know your team.

There are no people in the world that can write the same code. Writing code is about expressing your ideas in a bunch of lines. And each one of us has different opinions and articulates them differently.

How one writes code is a part of themselves. There are patterns that each one of us follows when writing code, and to the code reviewer, this is evident.

Bug hunting is about finding flaws in how someone has articulated an idea about a possible solution. Sometimes, there is a fault in the implementation; other times, there is a fault in the basis of the whole logic. Going through someone's code allows you to sit next to the person who wrote this piece of code and learn about the thought process that went into writing this part of the product.

Not only is this a way of bringing people closer, but it also improves the knowledge of both the person that wrote the buggy code and the person who is trying to solve it.

It's a chance to know your product.

No one knows every software part developed in larger teams/products. I have participated (and created) large platforms, and after the team grew, they took over most of the inner mechanics of the product and evolved it to serve the business better.

Whenever a team member has an issue that I suspect wants a bug-hunting session, I prioritize this over anything else. I often cancel meetings so that I don't miss the chance to go deeper into something technically challenging to solve.

I cannot even remember how many times the team and I have uncovered business issues that needed to be communicated to the project managers due to such bug-hunting sessions. Some of those sessions even changed the course of the entire product (simplified the business model, rearchitected part of the solution as the whole because of a performance issue, etc.).

Bugs sometimes spawn entire new solutions and features.

Sometimes, the bug is hidden under a pile of performance issues. Other times, the complexity of the business model causes faults to be exposed. However, regardless of the cause of the bug, a good team can build an entirely new solution upon this.

I vividly remember one situation where uncovering a performance bug in our cluster (dedicated to some campaigning system) spawned an entire 7-day bug-hunting process (performance measurements for many microservices) and consequently a 10-month re-architecture of the solution as the whole.

We discovered that the performance issue was due to a very stressful algorithm inside a microservice, causing too much i/o; the Business guys were adamant that they could not simplify this algorithm due to the client's requirements. We could have easily chosen the "double the amount of resources" approach to solve the performance issue. But we decided to invest the next ten months into creating integration tests for the existing solution, developing a new one with a Redis-based caching mechanism, and ditching the old algorithm in a live and very critical project. The integration tests were used to verify that the solution would work exactly as before. We even managed to establish micro-cms to help the business team to alter part of the campaigning system.

It felt gratifying for the team.

This project refactor was triggered by a performance bug that could be solved by allocating more resources. We could have easily seen this as just another bug, but we decided to view it as an opportunity to follow a different approach.

Bug-hunting allows you to stay in touch with the code.

For those who don't have the time to code or sit through entire plannings and meetings over new features, solving a bug is an injection of something that causes your creative process to spike.

When people address me for solving a bug, it's usually a happy distraction from meetings and other organizational things. And the bonus is that (usually) solving a bug does not need a time-consuming alignment or some planning during a team meeting.

Conclusion

Software engineering is about solving business issues. But, software engineering is about solving problems created by itself, too.

Provided that this is not becoming the norm for a long time, I welcome every opportunity to fix some bugs because it allows me to stay in touch with what makes my day-to-day routine fun: the team, the code, and the product. I am also thrilled when I see teams coming up with new ideas and features during the bug-hunting process; it's gratifying when that happens.

To conclude, I would recommend allocating a specific portion of your time into bug-hunting willingly and not jumping on the train of new feature implementation all the time. It will be beneficial for your team, the product, your career, and your attention to detail in general (as a personality trait).