Learnings

Before touching the code, understand what is working and what is broken.

If the team is small and the development environment is not well-established, be even more careful. Many bugs may have been overlooked before you start.

Context

A small audio technology company with fewer than 10 people. Small team, tests are checked by everyone during the morning meeting. I had been at the company for about 3 months.

What happened

There was an unnecessary infinite loop in a core audio data processing thread, so I removed it.

→ This uncovered new bugs.

→ I worked on fixing them in parallel.

As a result, during the morning meeting tests, I repeatedly made fixes and failures. I ended up taking up everyone’s time, which I regret.

Each time, I fixed the relevant code, but overlooked checks and latent bugs in the fixes caused endless debugging cycles.

What I did

I reverted the codebase back to its original state. Then I checked functionality from a clean slate.

As a result, all the regressions that had been found were existing bugs. They were not caused by my changes.

Since my changes were not the cause, they could not have been fixed by me.

What went wrong

• I didn’t check existing bugs beforehand.
• I tried to fix things hastily with Claude.
• I ended up trying to fix multiple bugs at the same time, which made things more complex.

Audio data processing is inherently complex. Because the system involves both mobile app + Virtual Room simultaneous connections, it is affected not only by audio data processing itself, but also by state changes from external actions (e.g., recording + playback, or user mute state while only playing audio).

Lessons learned

Thoroughly cover test cases and carefully verify behavior beforehand. In this case, since it involved core audio data processing, there were many scenarios: microphone on/off, input device changes (built-in mic or Bluetooth), STT provider (Azure, Google, or our own STT server), etc. The likelihood of existing bugs is higher in such cases.

You must also understand whether a bug is caused by your change or is pre-existing. Even if it was an existing bug, I was touching core logic that could easily be mistaken as being caused by my changes.

Follow-up

Successfully improved CPU and memory usage. I've tested for 1 hour speech-to-text usage on our app.

Before

• 400%-500% CPU usage
• Memory leaks

After

• 100%-200% average, peak at 300% CPU usage
• Half the CPU time
• No memory leaks