Don’t Fight the Fire. Find the Spark.

A lesson in finding the root cause when everyone is fighting symptoms.

One afternoon, a developer on my team deployed a new feature to our staging server. Five minutes later, that server was dead in the water. The QA team was completely blocked. All other development work ground to a halt.

I’m the Tech Lead for our team. My job isn’t just to write code; it’s to solve technical problems and enable my team to perform at their best.

In a crisis like this, most teams descend into chaos. The manager starts pinging for status updates. Teammates start pointing fingers. And the developer who pushed the code starts sweating, staring at their own code, and praying for a miracle. It’s a classic recipe for a long, painful night.

But I’m different. I was confident I could end the chaos in under an hour.

This isn’t about raw talent. It’s about having a process. It’s the fundamental difference between a professional who knows how to solve problems and everyone else.

The Incident: “The Server is Unresponsive.”

Here’s how it went down. My teammate, let’s call him Bob, shipped a feature enhancement for a user data collection service. Immediately, our team’s Slack channel blew up.

“I can’t log in. The request just timed out!” “Same here. Can’t test anything.”

Bob looked pale. Our manager pinged the channel: “Any ETA on a root cause?” Bob, feeling the pressure, typed back, “Sorry, I’m looking through my code now…”

This is the worst possible first step. Staring at your own code under pressure. It’s a classic case of not seeing the forest for the trees. The entire forest is on fire, and you’re examining a single leaf on a tree you planted.

I stood up, walked over to Bob, who was clearly struggling, and said:

“Hey Bob. That looks like a nasty one. Want a second pair of eyes on that?”

This isn’t about blame. This is my job: to unblock the team. I had Bob pull up a chair next to me as I opened my terminal. Not to find his mistake, but to show him, step-by-step, how we solve our problem.

My Approach is Radically Different: I Look at the System, Not the Code.

I started explaining my thought process out loud.

“Okay, Bob. Before we even look at a line of code, let’s listen to what the server is telling us.”

ssh user@staging-server top

The terminal showed me exactly what I expected to see.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12345 app_user 20 0 8.5g 2.1g 123m S 100.0 25.5 15:30.12 java ...

“See this?” I pointed. “Our Java application is eating 100% of the CPU. This isn’t a server issue; it’s a program issue. That’s a huge clue. Now, we need to look inside that program and see what’s going on.”

Dissecting the Process to Find the Real Culprit

I explained the next step as I typed.

“A process at 100% CPU means something inside is spinning its wheels, working frantically but going nowhere. We’ll use jstack to take a snapshot of what every single thread is doing at this exact moment.”

jstack 12345 > thread_dump.txt

I took three dumps, a few seconds apart. When I opened the files, I had to smile. It was a shocking sight. Dozens of threads were all stuck, completely frozen, at the exact same lines of code.

at com.mycompany.UserDataCollector.checkUserLevel(UserDataCollector.java:88) at com.mycompany.database.UserRepository.findUserById(UserRepository.java:25) ...

“Bingo. Right here.”

I pointed it out to Bob. It was a piece of his new data collection feature. Before saving a new event, the code was first checking the user’s status by fetching their profile from the database. When multiple requests came in at once, this single piece of code was creating a massive bottleneck.

Bob let out a quiet “Ah…” The realization dawned on him.

The Smoking Gun: Getting the Database to Confess

“Alright, final step. Let’s ask the database why this query is so slow.”

I copied the SQL query from the repository, prefixed it with the magic word EXPLAIN, and ran it. The result was clear. Full Table Scan.

I explained it to Bob. “The user_id column wasn’t properly indexed. So, to find one user out of millions, the database was literally reading the entire table, row by row, every single time. It was fine when you tested it by yourself, but it immediately fell apart under concurrent load.”

The Fix, and the Real Lesson in Leadership

The solution was a single, anticlimactic line of DDL to add the index. The moment we applied it, the server came back to life.

Bob was incredibly relieved and thanked me. I told him just one thing. “It’s okay. Everyone writes bugs. What matters is that the next time this happens, you know how to follow this process yourself.”

The lesson here isn’t about technology.

A true developer, doesn’t point fingers. They solve the problem with the team and use it as a teaching moment to make everyone stronger. They have the courage to step away from the code, open a terminal, and diagnose a problem based on data.

That is what puts you in a different league.

And now, you’re ready to handle any fire your team might face.