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 (0)