Intro

BONUS: Software Engineers are Paid to Solve Problems, Not Write Code! With John Crickett

In this BONUS episode, we explore a thought-provoking LinkedIn post by John Crickett that challenges a fundamental misconception in software engineering. John shares insights on why engineers should focus on problem-solving rather than just coding, how to develop business context understanding, and why this shift in perspective is crucial in the age of AI.

Beyond Writing Code: Understanding the True Value of Software Engineering

"A lot of us come to software engineering because we care about building, and missed the goal: solving a problem for a customer."

John Crickett explains the fundamental disconnect many software engineers experience in their careers. While many enter the field with a passion for building and coding, they often lose sight of the ultimate purpose: solving real problems for customers. This misalignment can lead to creating technically impressive solutions that fail to address actual business needs. John emphasizes that the most valuable engineers are those who can bridge the gap between technical implementation and business value.

In this section, we refer to John’s Coding Challenges and Developing Skills websites.

The Isolation Problem in Engineering Teams

"We have insulated people from seeing and interacting with customers, perhaps because we were afraid they would create a problem with customers."

One of the key issues John identifies is how engineering teams are often deliberately separated from customers and end-users. This isolation, while sometimes implemented with good intentions, prevents engineers from gaining crucial context about the problems they're trying to solve. John shares his early career experience of participating in the sales process for software projects, which gave him valuable insights into customer needs. He highlights the Extreme Programming (XP) approach, which advocates for having the customer "in the room" to provide direct and immediate feedback, creating a tighter feedback loop between problem identification and solution implementation.

In this segment, we refer to the book XP Explained by Kent Beck.

The AI Replacement Risk

"If all you are doing is taking a ticket that is fully spec'ed out, and coding it, then an LLM could also do that. The value is in understanding the problem."

In a world where Large Language Models (LLMs) are increasingly capable of generating code, John warns that engineers who define themselves solely as coders face a significant risk of obsolescence. The true differentiation and value come from understanding the business domain and problem space—abilities that current AI tools haven't mastered. John advises engineers to develop domain knowledge specific to their business or customers, as this expertise allows them to contribute uniquely valuable insights beyond mere code implementation.

Cultivating Business Context Understanding

"Be curious about what the goal is behind the code you need to write. When people tell you to build, you need to be curious about why you are being asked to build that particular solution."

John offers practical advice for engineers looking to develop better business context understanding. The key is cultivating genuine curiosity about the "why" behind coding tasks and features. By questioning requirements and understanding the business goals driving technical decisions, engineers can transform their role from merely delivering code to providing valuable services and solutions. This approach allows engineers to contribute more meaningfully and become partners in business success rather than just implementers.

Building the Right Engineering Culture

"Code is always a liability, sometimes it's an asset. The process starts with hiring the CTO—the people at the top. You get the team that reflects your values."

Creating an engineering culture that values problem-solving over code production starts at the leadership level. John emphasizes that the values demonstrated by technical leadership will cascade throughout the organization. He notes the counter-intuitive truth that code itself is inherently a liability (requiring maintenance, updates, and potential refactoring), only becoming an asset when it effectively solves business problems. Building a team that understands this distinction begins with leadership that demonstrates curiosity about the business domain and encourages engineers to do the same.

The Power of Asking Questions

"Be curious, ask more questions."

For engineers looking to make the shift from coder to problem-solver, John recommends developing the skill of asking good questions. He points to Harvard Business Review's article on "The Surprising Power of Questions" as a valuable resource. The ability to ask insightful questions about business needs, user requirements, and problem definitions allows engineers to uncover the true challenges beneath surface-level requirements. This curiosity-driven approach not only leads to better solutions but also positions engineers as valuable contributors to business strategy.

In this segment, we refer to the article in HBR titled The Surprising Power of Questions.

About John Crickett

John is a passionate software engineer and leader on a mission to empower one million engineers and managers. With extensive expertise in distributed systems, full-stack development, and evolving tech stacks from C++ to Rust, John creates innovative coding challenges, insightful articles, and newsletters to help teams level up their skills.

You can link with John Crickett on LinkedIn.