All journeys of significance have high points and low points. Debugging a difficult problem is no different.

I’ve been at this for a while, but the thrill of fully understanding a problem and the solution after a debugging journey has not worn off yet. Or as a friend puts it, “the one part of this job that never gets old is when things go from not making any sense to making sense again.”

That point is the peak. But to get there requires grit in the valley.

In the valley, things still don’t make any sense. Often it seems there’s no way out.

Press on.

Because as soon as you have exhausted every possibility and absolutely cannot figure it out, you’re close.

Jacob Kaplan-Moss:

People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it.

Sometimes, programming feels like magic: you chant some arcane incantation and a fleet of robots do your bidding. But sometimes, magic is mundane. If you’re willing to embrace the grind, you can pull off the impossible.

This is the most important trait of a software developer. The willingness to embrace the grind, every day, is more important than technical knowledge or skill of any kind.

(Via Daring Fireball.)

During my first week at my first job, I met one of the senior developers on my team.

He asked me if I liked spicy food.

“Not really,” I responded.

He paused.

“You’ll never make it in this industry.”

---

I love spicy food today.

Of course, you don’t have to enjoy eating any type of food to make it in software. But be it debugging a difficult problem or discovering the obvious mistake that held you up the last three days: you do need to have a tolerance for pain.

The future is wireless. From cellular phones, to Bluetooth earpieces, all the way to AirPods: the allure of these products is created by the magic of freedom from wires.

The experience is magical–when it works. But sometimes it doesn’t work, because creating such magic requires additional complexity. And since the complexity is intended to be invisible, the inevitable failures end up invisible too.

In contrast, consider a wire. A wire trades being magical for being understandable when something doesn’t work. Is the output device connected to the audio source? Understandable. Is it a bad wire? Understandable.

But my point has nothing to do with consumer electronics. (I own and enjoy both wired and wireless headphones, for the record.)

When writing source code, are you pursuing magical or understandable?

Using esoteric constructs or features of a language, applying a design pattern that doesn’t quite fit, oversimplifying an API because incorporating the required error handling would compromise its elegance—practices that lead to invisible failure are created in the hunt for something magical.

Magical code is usually not great code. Great code is code that you can understand and debug years from now. Actually, great code is code that someone else can understand and debug years from now.

The basics are difficult enough. More often than not you will be better served by just using a wire. When things inevitably don’t work you want understanding, not magic.

Recently I got stuck debugging one of those bugs. It was one of those bugs that defies the laws of the universe. It was not possible.

I yo-yoed. I walked away. I threw everything I could at the bug, but I still had not cracked it.

So I asked for help. I shared my screen with two co-workers. I explained everything I knew, and everything I had tried. They asked questions, made suggestions, and together we solved the problem in that meeting. Group debugging is a powerful technique.

But, I don’t think that if we all shared a screen the first time I examined the bug it would have been solved in a single meeting.

The value of group debugging is in differing perspectives, but shared focus. As the area of focus tightens, the value intensifies. The smaller the haystack, the more effective (and less frustrated) each additional person becomes in finding the needle. As you debug, both in pursuit of the truth and in preparation for explaining your progress to others, work to tighten the focus.

Ask for help when you get stuck. But first get stuck.