Sign up for your FREE personalized newsletter featuring insights, trends, and news for America's Active Baby Boomers

Newsletter
New

Programming Doesn’t Happen At The Keyboard — But It Also Does

Card image cap

Early in my career, a senior manager told me something that didn’t quite sink in at the time: “We pay you to work 24/7. I want you thinking about work every waking minute.” Eight years later, I finally understand what he meant.

Programming isn’t just about typing code into a file. While writing code is necessary, it’s not at the core of programming. Programming is fundamentally about solving problems—sometimes incredibly complex ones. And problem-solving requires deep thinking, not just time at the keyboard.

To properly reason about the problems you are trying to solve, you need to have knowledge about three things:

The problem itself – Understanding the problem is harder than it seems. Your ability to recognize patterns and solutions depends on the problems you’ve encountered before.

The domain and context – Every business has its quirks. Knowing how an existing system works—its rules, constraints, and legacy code—can make or break your solution.

The tech stack – Your tools shape how you solve problems. Mastering languages, frameworks, and platforms helps you make informed design choices.

This is why being a junior developer is so difficult—you haven’t yet accumulated enough knowledge to see past surface-level issues. Even experienced developers struggle when switching jobs because the codebase, tech stack, or business domain may be unfamiliar.

Bridging the Knowledge Gap

There’s no shortcut to expertise. You have to build understanding over time by:

  • Reading about the problem domain and talking to colleagues who have experience.
  • Studying the technology stack and experimenting with features you don’t yet fully grasp.
  • Observing how existing code is structured to understand why certain decisions were made.

No matter how much you read or discuss, true understanding only comes through experience—which means writing code.

Writing Code as a Thinking Tool

Mark Manson’s Do Something Principle tells the story of a novelist who had written over 70 books. His advice for being prolific? “200 crappy words per day. That’s it.”

The same applies to programming. To truly learn and improve, you have to sit down and write code—imperfect, messy, and often frustrating code. Challenge your assumptions by rewriting pieces of your codebase from scratch. Try different approaches. Each iteration sharpens your understanding.

That said, writing code without thinking often leads to bad or incomplete solutions. If you catch yourself coding before fully understanding the problem, pause. Sketch out possible solutions. Talk through your ideas. Then, when you write, you’ll produce cleaner, more structured, and well-thought-out code.

The Balance Between Thinking and Coding

It took me eight years to understand this balance. Programming happens in your mind first, at the keyboard second. But sometimes, writing code is what clarifies your thinking. The best programmers know when to pause and think—but also when to just start coding to explore ideas and uncover insights they wouldn’t find otherwise.


Recent