Taking the Stairs.

A while ago, I encountered an article that used “taking the stairs” as a metaphor for choosing the harder path in life. The imagery stuck with me. In today’s world of Large Language Models where shortcuts are just a prompt away, maintaining the discipline to take the “stairs” – to embrace the harder path – becomes increasingly difficult. Yet this choice often makes all the difference in our personal and professional growth.

My Early Days of Learning

My programming journey began like many others – searching for the easy way out. I found myself stuck daily on what seemed like straightforward tasks, desperately seeking quick solutions. I remember posting on Stack Overflow, only to receive the response: “We are not going to do your homework.” While frustrating at the time, this tough love proved invaluable.

Eventually, programming clicked for me, but not through copying and pasting solutions. It happened through countless nights of wrestling with problems, sometimes solving them directly, other times discovering exciting tangential paths that expanded my knowledge in unexpected ways. The breakthrough came when I realized that real learning wasn’t about finding answers – it was about understanding the answers.

Learning in the Age of AI

Looking back, I wonder how different my learning experience would be in today’s environment, where LLMs offer instant solutions to complex problems. While these tools are powerful aids, they can also become crutches that prevent deep understanding. To those embarking on their learning journey, especially in programming, I offer this advice: resist the urge to immediately search for answers. Take a moment to think, struggle, and explore.

Why Take the Stairs?

Taking the stairs means:

• Building comfort with not knowing the answer yet
• Developing debugging instincts that only come from being stuck
• Stumbling into adjacent problems that turn out to matter
• Actually understanding the answer when you finally find it

Know When to Take the Stairs

One of the most crucial skills in software development isn’t technical at all – it’s knowing when to invest in deep understanding versus when to implement a quick solution. It’s about being strategic with your learning journey.

Ask yourself these questions when facing a problem:

Is This Part of Your Foundation?

If you’re working with core concepts like:

• Data structures and algorithms
• Language fundamentals
• System design principles
• State management
• Authentication flows

Then you absolutely need to take the stairs. These are the building blocks that will shape how you think about problems for years to come. When I skipped understanding promises in JavaScript early in my career, I spent months writing fragile code that I couldn’t debug effectively. The time I “saved” led to weeks of frustration later.

Is This a One-Off Solution?

Sometimes you genuinely just need to convert a timestamp or center a div. In these cases, it’s okay to take the elevator. The key is being honest with yourself about what category the problem falls into.

The “Future You” Test

When deciding whether to invest time in understanding something deeply, I ask myself:

• Will I need to modify this code in the future?
• Would I be comfortable debugging this at 3 AM during a production issue?
• Could this become a critical part of the system?
• Will other developers need to understand my implementation?

If any of these answers is “yes,” it’s time to take the stairs.

Remember: You don’t need to deeply understand every line of code you write, but you absolutely need to understand the code that matters. The trick is developing the wisdom to know the difference.

Only through struggle you can learn to debug

Perhaps the most valuable skill you can develop through taking the stairs is the art of debugging. It’s a skill that no tutorial can truly teach and no AI can replicate – because debugging is more than just fixing errors. It’s about developing intuition, pattern recognition, and systematic problem-solving abilities.

When you encounter a bug you gather clues through error messages, develop hypotheses about what might be wrong, and systematically test your theories. This investigative mindset only develops through hands-on experience and, yes, plenty of frustration.

Through debugging yourself, you develop:

• The instinct to check variable scope when seeing “undefined” errors
• The habit of reading error messages thoroughly instead of just copying them
• The ability to work backward from an error to its root cause
• The confidence to tackle similar issues in the future

The 72-Hour Challenge

Try this for the next 72 hours: when you hit a programming problem, before searching or asking AI:

1. Set a 15-minute timer
2. Write down:
   • What you think the problem is asking
   • What approaches you might try
   • What pieces you don’t understand
3. Attempt at least one solution, even if you think it’s wrong
4. Only then, if still stuck, seek help

Document your experience. You might be surprised how often you can solve problems with just a bit more patience and persistence. Even when you don’t find the solution, you’ll likely understand it better when you do look it up.

The Path Forward

The most useful things I learned from programming — how to debug, how to think about systems, how to sit with a problem until it makes sense — came from the times I couldn’t immediately find the answer. LLMs are useful. They’re not a replacement for that.