When I first started learning programming, I thought getting better at it meant knowing more stuff.
More syntax.
More commands.
More frameworks....
For further actions, you may consider blocking this person and/or reporting abuse
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 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 "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.
"Having someone ask a question you stopped thinking to ask" β we institutionalized exactly that, and it scales further than people expect. After the fix, a fresh pair runs the whole reproduction on a clean checkout, not against the summary. The questions they ask are mechanical, but they catch the drift your own memory edited away: "did it actually fail before the fix?", "did the last edit happen before the tests ran?", "is this a real reproduction or a happy path?". Silent failures in the service are bad; silent failures in your own verification loop are worse, because you think you have a safety net that isn't there.
Yeah, I really like that. Itβs interesting how quickly your own memory starts smoothing over the messy parts once you think you understand the bug. Having someone re-run the whole thing cold and ask those basic questions sounds incredibly useful, especially for silent failures where your βsafety netβ might not actually be catching anything.
The "safety net might not be catching anything" bit is exactly why we stopped trusting nets that have never tripped. A check that has never failed is just decoration β you don't know if it would fire on the failure you're currently missing. So we require every net to have a fail-before/pass-after pair: we prove it catches the bug when introduced, and catches nothing once fixed. If we can't make it fail once on purpose, we assume it's silent too. The cold re-run is the second layer of that β it re-asks "did any of our nets actually trip?" without the bias of knowing which one should have.
That makes a lot of sense. I really like the βfail-before/pass-afterβ rule because it forces you to prove the check is actually useful instead of just assuming it is. Otherwise you can end up with a whole pile of tests and safeguards that look reassuring but never actually catch the thing theyβre supposed to catch. The cold re-run idea is really smart too, because it removes some of that βI already know where the bug wasβ bias.
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.