When I first started learning programming, I thought getting better at it meant knowing more stuff.
More syntax.
More commands.
More frameworks.
More things I could remember without having to look them up.
And yeah, obviously knowing things helps.
But the longer I do this, the more I think a huge part of programming is just learning how to investigate things.
Because half the time, the situation is basically:
Something is broken.
I don't know why.
Cool.
Now what?
You start poking at it
Maybe there's an error message.
Maybe there isn't, which is always fun.
Maybe a function is returning something weird.
Maybe the app works locally and breaks the second you deploy it.
Maybe a library is doing something that makes absolutely no sense based on the docs.
So you start poking around.
Check the logs.
Print some values.
Read the error again.
Actually read the error this time instead of immediately deciding what you think it means.
Look at the data.
Check the docs.
Search GitHub issues.
Change one thing.
Run it again.
Break something else.
Undo that.
Eventually you start collecting enough little pieces that the problem stops feeling like one giant mystery.
Debugging is basically narrowing things down
Usually the first version of the problem is:
"Why the hell isn't this working?"
Which is not exactly actionable.
So you make the question smaller.
Is this function actually running?
Is the request being sent?
Did the server get it?
Is the data shaped the way I think it is?
Did this value become undefined five steps earlier?
Am I even looking in the right place?
Is this actually my bug, or am I misunderstanding how the library works?
Every answer knocks out a few possibilities.
Then eventually you're not debugging "the app."
You're debugging one function.
Then one condition.
Then one stupid value.
And suddenly there it is.
Some tiny ridiculous thing that caused all of it.
Knowing what to search for matters more than I realized
Searching for technical answers is its own skill.
Sometimes you can paste an error message into Google and get the exact answer in thirty seconds.
Sometimes the error is basically useless.
Sometimes the answer depends on your operating system, browser, package version, GPU, runtime, build tool, phase of the moon, whatever.
The better you get at figuring out what part of the problem actually matters, the better your searches get.
That was a big shift for me.
Instead of searching:
"Why is this broken?"
You start searching something much more specific.
And suddenly you stop finding ten pages about completely unrelated problems that happen to contain the same error message.
Docs help, but they're not always the whole story
I probably read documentation more now than I did when I was first learning.
Not because I've become some kind of responsible documentation-reading adult.
Usually because something has gone wrong.
Sometimes the docs give you the answer immediately.
Sometimes they give you enough information to realize you've been thinking about the problem wrong.
Sometimes they're outdated.
Sometimes the answer is buried in a GitHub issue where somebody casually mentions:
"Yeah, this doesn't work when that option is enabled."
Ah.
Cool.
Would have loved to know that an hour ago.
And sometimes I end up reading the source code because at a certain point I just want to know what the damn thing is actually doing.
You don't have to understand the entire library.
Sometimes you just need to follow one function far enough to answer one question.
I think beginners get the wrong idea about experienced developers
When you're new, it's really easy to think experienced developers just know everything.
They look at a problem and immediately understand it.
They know which function to use.
They remember every command.
They never have to search anything.
Meanwhile you're sitting there thinking, "Why do I have to look up the same thing for the fourth time?"
But I don't think that's really what experience looks like.
A lot of it seems more like being better at getting unstuck.
Knowing where to look.
Knowing what information matters.
Knowing how to make a big confusing problem smaller.
Knowing when your assumption is probably wrong.
And being willing to keep digging instead of staring at the code hoping it suddenly explains itself.
AI didn't really remove this part
AI definitely makes investigating things faster.
I use it constantly.
It can explain a weird error.
Help trace through unfamiliar code.
Suggest what to check next.
Point out something obvious that I've somehow looked directly at six times without seeing.
But it can also be wrong.
Sometimes very confidently wrong.
It can give you an answer for the wrong version of a library.
Invent an API.
Miss the actual cause.
Fix the symptom and leave the underlying problem sitting there waiting for you.
So I don't think AI replaced the investigation part.
It just became another thing I use while investigating.
A very useful thing.
But still not something I trust blindly.
I think this might be one of the biggest programming skills
You're never going to know everything.
There is always going to be another library, another framework, another weird edge case, another error message you've never seen before.
And honestly, that used to bother me more than it does now.
Because I don't think the goal is to know everything anymore.
It's being able to hit something you don't understand and think:
"Okay. I don't know what's happening yet. But I can probably figure it out."
Then you start narrowing it down.
Check assumptions.
Collect clues.
Test things.
Read.
Search.
Break stuff on purpose sometimes.
And eventually the weird thing stops being weird.
At least until the next weird thing.
Which is apparently most of programming.
Top comments (9)
I think this oversimplifies what programming experience (or even debugging) is.
Yes, investigation is a huge part of software engineering. But experienced developers aren't people who got better at Googling, reading logs, and narrowing down problems.
A big part of building experience is creating mental models, meaning you can understand how systems behave, start/keep recognize patterns, knowing which assumptions are most probably wrong, predicting where the errors/failures can happen, and choosing the right abstraction or debugging strategy before even start this investigation.
'Keep narrowing the problem down until you find the error' is debugging 101, not some defining insight about programming. Knowing things still matters, a lot. You have to have this experience so you can prevent AI solving the wrong problem. Or be x10 faster or x10 economic on your token usage by pinpointing exactly where you think the error is coming from.
Having experience of solving and debugging is not that after years you have memorized everything, to be fair, i can't memorize anything. It's that the things you do know give you better models for reasoning about the things you don't.
Otherwise we're basically defining software engineering as 'Google stuff until something works.' 😅
That’s fair, and I agree that experience builds better mental models, not just better search habits. I probably compressed that part too much in the post. What I was trying to get at is that knowing how to investigate is a huge part of what lets you use those mental models when something unfamiliar happens.
The more experience you have, the faster you can form a useful hypothesis, know which assumptions to question, and avoid chasing the wrong thing. So yeah, I definitely wouldn’t reduce software engineering to “Google until it works” The investigation gets better because your understanding gets better.
The deepest takeaway for me is that programming isn’t really about how much you know—it’s about how effectively you can figure out what you don’t know.
A beginner often tries to remember solutions. An experienced developer learns to break problems into smaller questions, challenge assumptions, gather evidence, and eliminate possibilities until the real cause becomes clear.
That’s why debugging isn’t just about fixing bugs. It’s about developing a better way of thinking.
And perhaps one of the most valuable mindsets in programming is:
“I don’t know the answer yet, but I know how to find it.”
Once you develop that mindset, a new language, unfamiliar framework, or confusing code stops being intimidating. It simply becomes another problem you can investigate and solve.
Yep, exactly this. I think the biggest change for me was realizing I don’t need to have the answer sitting in my head already. If I can break the problem down, test assumptions, and keep narrowing it down, I can usually get there. That makes new tools and unfamiliar code a lot less scary too.
I really liked the point that experienced developers aren’t necessarily the ones who know everything, but the ones who know how to get unstuck. Debugging, reading docs, searching the right error, and testing assumptions are all part of the problem-solving process.
The point about AI is especially relevant too. AI can speed up investigation, but understanding the problem and verifying the solution still matters. Great reminder that programming is less about memorizing everything and more about knowing how to find the answer.
Yep, exactly. I think getting better at programming is a lot less about memorizing everything and a lot more about getting better at figuring things out when you don’t know the answer. AI can definitely speed that process up, but you still have to understand what you’re looking at and know when something doesn’t add up.
The "no error message, which is always fun" line is the whole skill, honestly. Last week a service in our stack silently stopped working — no exception, no crash, clean exit code. The kind of thing that makes you question whether you're even looking at the right layer.
What cracked it was exactly this: narrowing the question until it was small enough to answer. "Is the tool even receiving input?" was too big. "Is stdout clean JSON on the transport channel?" was the right size — and that one was only findable because a second investigator (we run a separate verifier that re-checks work instead of trusting the first pass) re-ran it in a context the original didn't.
"Read the error again. Actually read the error this time." That has saved more hours than any framework knowledge I own. That's the takeaway I'd underline for every beginner.
Yep, this is exactly it. The silent failures are the worst because you don’t even get the courtesy of a useful error to be mad at 😂 I really like your point about having a second investigator too. Sometimes the fix isn’t knowing more, it’s having someone ask a question you stopped thinking to ask.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.