My software engineering cheat code

Product thinking should be taught

One of the most interesting questions you can ask of an engineer you respect is: “What’s your cheat code?” What do they do better than their peers that leads to high impact? If you were to ask the Post-It Note, it would brag about its adhesive strip that lets it stick to many surfaces.

As you can guess from my Substack's title, I would respond with “product thinking.” I can learn and think rigorously about users and their needs, which helps me be useful, not just during implementation, but throughout the product cycle.

My road to becoming a product thinker was long and winding, and I’m not alone—many engineers never learn a good cheat code. When I joined the industry, I had zero interest in users, and nobody flagged this as a problem. I struggled to make a consistent impact until I got good at it.

Product thinking is one of a few cheat codes so common that they should be taught more formally. It should be a core part of school curriculum, on-the-job training, books, subliminal message tapes, or anything to get more engineers empathizing with users!

In this post, I'll discuss how you can find your own cheat code, share my journey to finding the product thinking one, link you to some blog posts, and tease my upcoming book.

How do you discover a cheat code?

A cheat code is a game-changing skill that some software engineers practice while others don't. To qualify as a cheat code, it must be an open secret: widely known, yet:

• Not part of mainstream computer science, software engineering, or coding bootcamp curriculums. Otherwise, more would be doing it.

• Not taught via company training.

• It isn’t directly tested in most software interviews and is not part of interview prep courses. Though, interviewers will often appreciate it.

What are some examples? Well, most of the engineering archetypes embed one or two:

• A fixer's cheat code is being a fearless bloodhound in seeking out root causes, combined with keen impact assessment skills.

• A product/engineering hybrid knows their product's user personas, can simulate their actions, and understands their motivations.

• A tech lead can communicate technical ideas concisely and collaborate well with others.

• You might think a generalist would have no special cheat code, but they are often experts at balancing quick learning with doing so that they can hop to new problems.

• A right hand is a generalist who can also put aside their own ego, tech stack preferences, and agenda in favor of executing the will of a senior manager.

Other cheat codes I’ve seen are being dogged, tolerating more tedious work than others, quickly building trust with new collaborators, and being organized and thorough.

These are not easy skills to learn, but you don't need to be world-class at them, just very good. Trying instead to be the best pure-play engineer is like trying to be a chess Grandmaster—not everyone has the talent, and it's unclear how valuable it is.

I’d also love to hear about others’ cheat codes, so please treat the comments as a safe space to brag.

Beyond asking coworkers for their cheat codes, a common way to find your cheat code is to discover what's really blocking your team from doing better. If you enjoy solving that problem, it might become your cheat code.

Here’s my example:

How I radicalized as a product thinker

My journey to becoming a product/engineering hybrid archetype began about three years into my career, when I spotted such a gap on my team.

Fresh out of school at Microsoft, I had zero product sense. I’d never even had a user before. I worked on a C++ compiler team optimizing assembly code generation. I loved this job because I wanted to be "hardcore." I was one of those college grads who, when asked about career goals, would say they wanted to "do algorithms" without thinking about real-world impact.

Three years later, my team merged with a compiler framework team. Our new project was an API for building compilers and code inspection tools. (think: like LLVM) It provided foundational compiler-y abstractions like functions, types, symbols, and instructions. But the team had nobody with experience designing APIs.

Typical of C++ APIs in the 2000s, our platform was esoteric and difficult to use. The chief architect's vision was "the assembly language for building compilers!" Even as someone who diffed compiler-generated assembly for a living, I wondered: "Who wants to code in assembly language?"

I happened upon a group of luminaries in the C# and Java communities doing great work on API design principles. I found inspiring thought leadership by Joshua Bloch, Steven Clarke, and Krzysztof Cwalina, and I wanted to bring their ethos to my team.

I'd seen a gap and tried to fill it. Though I wasn't yet good at usable API design, the product benefited simply from having someone think about it.

---

Over the years, API design became an obsession, in part because so many were doing it so poorly. I cared, and I tried to get others to care, about the safety and productivity of their developer-users. It was rewarding but also frustrating—at times, I felt like founding father John Adams in the musical 1776:

  Is anybody there?
  Does anybody care?
  Does anybody see what I see?

Just as I'd looked outside the C++ community to C# and Java, I found myself exploring sources beyond software engineering. I read The Design of Everyday Things and learned about signifiers and affordances. (And I never saw doors or thermostats the same way again.) I learned about personas and scenario-driven design from PMs and participated in humbling usability studies with UX researchers.

The only training that was part of "the curriculum" was the Human-Computer Interaction course I took for my Master's degree, an elective I had incorrectly disdained, along with Fundamentals of Software Engineering, as "softcore" as an undergrad.

Ten years into my career, now at Facebook, a thoughtful manager identified my archetype. Colloquially known as “product hybrids,” we tended to excel at the earlier stages of a product lifecycle, discovering the right things to build and iterating toward product/market fit. We had all found different paths to the same realization: our teams needed product thinkers.

I slowly realized I had accidentally honed these things called "product skills" that I could and should apply beyond API usability. Good API design was only sometimes a strategic priority—which explains why I sometimes felt isolated in caring about it—but we always needed somebody to consider users.

I had my cheat code.

Reading about product thinking

Ten years was a long time to discover a cheat code. My mission is to help others do it faster and better.

If you’re interested, let me direct you to a couple of posts:

• The Pragmatic Engineer blogged about product/engineering hybrids, noting the positive traits we share.

• The Elevate Substack recently posted advice for getting good at user-centric engineering. I particularly like Addy pointing out how user empathy reaches rather deeply into architecture and system design.

Over the coming months, I’ll post on interesting product-thinking topics. Stay tuned.

If you’re a book person, my book, The Product-Minded Engineer, is out from O’Reilly. Read it on O’Reilly Online or purchase on Amazon.

---

Acknowledgements: Thanks to Dan Davison, Patrick Dowell, and Claude for your help with this post.

Thanks to Midjourney for the image, though it needed a lot of edits—teaching it the Konami code was like trying to stuff cats into a whack-a-mole machine.