Remember getting stuck?

The good-ole-days

You probably remember what it was like to get stuck on a software problem:

• Try brute-forcing the solution → No luck

• Go to StackOverflow → Nothing

• Find a 7-year old blog post from a guy named Dimitri → Helpful, but outdated

• Read the docs → Nothing

• Open an issue on the doc repo asking for clarification → Nothing

• Sit through an hour-long YouTube lecture from the maintainer hoping for a clue → Nothing

Eventually you came to the fateful conclusion:

It’s just me and this problem.

No one is coming to save me.

You went for a walk, considered joining a construction crew, remembered that time you hit your thumb with a hammer, and decided to stick to software. You returned ready to roll up your mental sleeves and do some work. The only thing that was going to get you out of this situation was thinking deeply, tearing the problem apart, and putting it back together differently.

I thought I hated this part of the job. It frustrated me to spend an entire week making no progress. I remember spending six days on a Redux problem. A week fighting with an Electron about file-permissions. Five weeks on a refactor.

That struggle is now the part I miss the most. I miss how those problems forced me to think deeply and slowly. They revealed the gap between my model of the world and reality. I had to seek out new information, to learn. I left scared that I’d fail and jeopardize my career. When I eventually returned with a solution, I felt empowered to tackle even harder ones. I was the hero who returned from a grueling adventure that tested me, and I won.

That mental journey doesn’t happen any more in non-frontier software.

Deep thought isn’t the bottleneck.

It’s QA, strategy, marketing.

If the software sucks, it probably doesn’t need deeper thought; it just needs more prompts.

My desire to keep thinking deeply has led me away from software recently. I’m reading math and physics papers. It’s a struggle. I’m not good enough to derive the answers myself. I don’t even know half the symbols they’re using. I feel fraudulent telling real scientists that I’m trying to read them. But it’s scratching that itch that I used to get while in the depths of a software problem. It’s making me think deeply, learn, and understand the world differently.

I’m not going to become a physicist. I’m not going to stop building software anytime soon, either. But I’m also not going to stop thinking deeply. If I can’t find a way to think deep while solving software problems, I’ll find other problems to ponder.

Building software was a bundle of activities, some of which really interested you.

• Understanding the interaction between bits and hardware

• Turning user feedback into improvements quickly

• Building something you could use on your own

• Thinking deeply

• Minimizing clicks, latency, CI build times

• And 100 other things

Now that the bundle has changed, I think this is a good time to identify what elements of it you care about the most. For me, it’s deep thought.

What is it for you?

» What’s element of building software is most important to you?

Answering that might help you get more clarity about your current role. It might inspire you to go into a new field entirely. Or it might just give you permission to stroll down a different section of the library and read something unfamiliar.

The job of building software has changed a lot, so why not take the time to revisit the JD?