March 29, 2021

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.

In Defense of Wires

February 15, 2021

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.

Getting Stuck

January 30, 2021

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.