I’ve been writing code long enough to remember when Stack Overflow didn’t exist.
If you didn’t know something, you read documentation.
If document...
For further actions, you may consider blocking this person and/or reporting abuse
Excellent post. When I was a beginner, I made the same mistakes. Before training, I realized the real problem, as you described: we're not taught to think. And I think this applies not only to programming but to other fields as well. That's why I don't like learning in the traditional sense - I've never signed up for any courses or watched any super-detailed tutorials where someone spends five hours explaining how to do something step by step (200 steps, I think). I just do this:
Fixing these is precisely what provides the basis for learning, and I find it much more interesting to learn when I have finished code and can immediately see the results. Even changing a few lines of this code yields results, and seeing that it works motivates you to keep doing it, and it simply makes you happy.
And it's not like reviewing and modifying someone else's code - the LLM essentially provides you with an entire description of that code, which helps you understand it. After all, real learning is practice, not theory.
Love this perspective — especially the part about “we’re not taught to think.” That’s such a core technical issue, not just in programming but in how we approach problem-solving overall.
I also agree that copy-pasting from an LLM isn’t real learning by itself. The real growth starts exactly where you pointed: when the code hits the IDE and breaks — dependency conflicts, version mismatches, runtime errors, or subtle logical bugs. That debugging phase forces you to understand execution flow, environment setup, and why something fails. That’s where engineering thinking is built.
I see LLMs less as shortcut machines and more as accelerators for experimentation. The key is not generating code, but dissecting it — tracing stack traces, refactoring parts, rewriting functions without looking, and testing edge cases. That’s where curiosity turns into skill.
Really appreciate you sharing this — I’m especially interested in how we can balance fast iteration with deep understanding. That tension is the real learning engine.
The real issue is that modern tooling (Copilot, AI assistants) optimizes for speed, not learning. Juniors ship faster but build slower, if that makes sense. Debugging instincts come from pattern recognition that only develops through repeated failure. How do we redesign onboarding so juniors get the benefits of AI without losing the struggle that builds intuition?
You hit the nail on the head—AI speeds up delivery but doesn’t teach the deeper debugging patterns. I think onboarding could mix guided AI use with small “failure zones,” where juniors experiment and troubleshoot on their own. It’d be exciting to see a framework that balances AI efficiency with intuition-building—definitely something I’d love to explore further.
Absolutely agree with you. Blending guided AI usage with intentional “failure zones” sounds like a powerful way to build real problem-solving skills. AI can accelerate learning, but true intuition comes from struggling, debugging, and reflecting on mistakes. Exploring a framework that balances speed with deep understanding would be incredibly valuable—I’d definitely be excited to work on or learn from something like this.
Totally agree! Combining AI guidance with deliberate “failure zones” seems like a smart way to strengthen real problem-solving skills. Speed is great, but intuition really grows through debugging and reflecting on mistakes. I’d be excited to see or contribute to a framework that balances both.
For real though... Yeah. 100%. Growth feels painful. We don't like pain so we sanded down the rough edges. No pain, no growth. You can't get good at debugging nonsense if you've never been eyeball-deep in your own self-created nonsense with no clear way out.
Love this take — seriously. You’re absolutely right.
Growth in engineering almost always comes from friction. When you’re deep in your own messy logic, chasing a race condition, untangling a weird state mutation, or tracking down a side effect you introduced three refactors ago — that’s where real debugging skill is forged.
You made an excellent point
Thanks.
I have been there to mentor people. I wish that I can program to be my assistant. The robot will make our life a bit easier.
That’s awesome — mentoring is seriously underrated and super impactful 👏
I really like your idea about programming an assistant. Honestly, we’re already moving in that direction with AI copilots and automation tools. The real technical challenge now isn’t whether we can build assistants — it’s how to design them to actually understand context, write reliable code, and reduce cognitive load instead of adding more noise.
I want to talk with you further.
Could you contact me via t.g?
Thanks, Ben! I completely agree—mentorship really shapes careers and helps share knowledge forward.
I also think you’re right about AI: tools like Gemini 3 Pro are improving fast, but they still can’t fully replicate human judgment or complex cognitive reasoning. Exciting to see how quickly the tech is evolving!
I’ll reach out via your email and look forward to continuing the discussion.
Yes, it is 100% for the mentorship. I agree with you that the technology is changing rapidly.It is really cool. I see the potential of AGI in AI in a good way. I am afraid of the technology because we can use AGI is a different context with hacker. I am glad that AGI is still theory on paper for now.
It sound good! Your email might go in my spam folder in my gmail. I will keep an eye on your email in both my inbox or my spam folder.
Ben
I completely agree with you, Ben — mentorship is becoming even more important as technology evolves so fast, especially with AI moving toward concepts like Artificial General Intelligence; the potential is exciting, but the real technical challenge will be building strong security architectures so it can’t be misused in malicious contexts. I’m also glad AGI is still mostly theoretical for now, since it gives us time to focus on safe implementation, and I’ll definitely keep an eye on both my inbox and spam folder for your email.
Exactly! I am curious. What is your first name? I don't write "hello art light" when I send my first email to you.
I have sent message to you, please check your inbox.
I got your email!
The point about juniors not being taught to think is something I keep coming back to. harsh2644's comment above about "ship faster but build slower" is exactly right.
Here's what I've started wondering: if we know the right habits — read error messages carefully, break problems down, understand before copying — why don't they stick? I think it's because methodology stays as advice, not as practice. You read "always understand the code before using it" and nod, then forget it the moment a deadline hits.
One thing that's worked in my own workflow: I write my best practices as executable instructions rather than notes I have to remember. Instead of a doc saying "always write a spec first," I have a workflow file that makes my AI tools automatically ask for a spec before generating code. The methodology runs whether I'm disciplined that day or not.
Not sure how well that translates to mentoring juniors, but the underlying idea — make the right behavior the default, not the aspiration — seems broadly applicable.
This is such a sharp observation — turning methodology into enforced workflow instead of relying on discipline is a powerful systems-level solution, especially when deadlines start pressuring decision quality. I’m really interested in pushing this further in mentoring juniors too, maybe by embedding thinking checkpoints directly into code reviews or tooling so “understand first” becomes the default execution path rather than a motivational slogan.
"Architecture is trauma-informed design" — that line is going to stick with me for a while.
I've noticed the same thing mentoring newer devs on my team. The biggest gap isn't knowledge, it's comfort with ambiguity. They want a clear answer before they start, but real debugging is more like detective work — you form a hypothesis, test it, adjust. That loop is uncomfortable at first.
One thing that's helped: instead of code reviews where I just point out issues, I started doing "thinking out loud" sessions where I debug something live and narrate my actual thought process. The messy parts. The wrong turns. The "wait, that can't be right" moments. It demystifies the whole thing way more than any tutorial.
Your point about emotional regulation is underrated. The ability to sit with "I have no idea why this is broken" without panicking is genuinely a skill you have to practice.
Thanks, I really appreciate your insight! I completely agree—mentoring juniors often shows that handling ambiguity is the real skill. I love your “thinking out loud” approach; sharing the messy debugging process is such a practical way to build intuition. I’ve been experimenting with something similar—pair debugging while narrating hypotheses—and it really helps normalize trial-and-error. Emotional regulation in debugging is huge, and your point reminds me I should emphasize that more when guiding others.
Great read! I am also just going to graduate, and this was really really helpful. I was in my second year of college, when LLMs really started to take speed. I was hesitant at first that, no I won't use it to do my assignments but slowly slowly seeing the sheer speed at which works is completed and even explained to us took me into the wave as well.
Although I still think about the fact that, were my most important years of learning wasted with LLMs and not man pages? Did I miss the thrill of figuring stuff out on my own? I still sometimes go to man pages just to see if I can read and understand. But I understand that we need to give ourselves the space to try and fail. In the world where everyone knows everything and all syntax is perfectly written, and all methods have sensible names, maybe we need to give ourselves the space to miss the semi colon here and there.
Love this comment — and congrats on graduating soon! 🎓
I really respect that you were hesitant at first. That shows you care about actually learning, not just finishing assignments fast. And honestly, that’s the real technical challenge here — not whether we use LLMs, but how we use them.
I don’t think your important years were “wasted.” If anything, you learned in a different environment. Reading man pages builds depth. Using LLMs builds speed and pattern recognition. The problem starts only when we stop thinking critically and just copy-paste without understanding memory usage, complexity, edge cases, or why a certain abstraction exists.
I still believe we should sometimes go back to raw docs, break things intentionally, read stack traces, debug without autocomplete. That friction builds real engineering intuition.
And I fully agree with you — we need space to fail. Missing a semicolon is not the problem. Not understanding why the program broke is.
That is so true and very real. I also mentor developers, and they do struggle with being overwhelmed. Some want to be very good immediately, and when they realise they cant they panic. I usually don't know how to help them. Thank you, this gives me an idea of a better approach.
I really appreciate you sharing that — mentoring developers is no small responsibility, and you're absolutely right that the pressure to “be great immediately” can overwhelm them, especially when they start facing real-world complexity like architecture decisions or debugging production issues.
One thing I'd add: juniors often skip understanding why a pattern works and just copy code that passes tests. The most effective fix I've seen is requiring them to explain their solution out loud before submitting a PR — not as gatekeeping, but because articulating logic exposes the gaps that syntax won't. Rubber-duck debugging as a mandatory step, not an afterthought.
That’s a really strong point — I completely agree with you.
Copy-pasting patterns without understanding the why behind them is one of the biggest technical gaps at the junior level. Code can pass tests and still hide design flaws, wrong assumptions, or poor scalability decisions.
I really like your idea of explaining the solution out loud before opening a PR. When someone walks through their logic — data flow, trade-offs, edge cases — the weak spots show up immediately. It’s not gatekeeping at all; it’s forcing clarity in thinking.
Honestly, I think this should be part of every code review culture. Rubber-duck debugging as a required step could reduce shallow fixes and improve architectural awareness early on.
Great insight — I’m definitely going to push this more in my team.
The biggest thing I've noticed mentoring junior devs: they optimize for writing code, not reading it. They'll spend hours building a feature but won't spend 20 minutes reading the existing module they're modifying.
The best junior devs I've worked with read 3x more code than they write. Not glamorous advice but it compounds fast.
Absolutely, I totally agree! Reading existing modules is such a force multiplier—spending that time upfront often prevents messy refactors later. I’ve found pairing reading with small exploratory experiments helps me understand code faster and catch hidden edge cases. Definitely something I try to prioritize more now.
Thanks for the post. The best part of the article is the authenticity as well as the vulnerability aspect, that somehow people are beginning to believe AI will handle for me (or hide/not expose me). There are no short cuts, AI will not be a short cut, it will be (and is) a multiplier to help engineers be more productive in a % of their work. We cannot grow oranges in a farm in 05 days, we need to let the process take its time - and this 'time spent' is not wastage, it is the journey via which one grows, it's just how all of us have gained competency in anything, let alone software engineering.
Loved the statements:
All in all, I believe this article is re-iterating that formal process/grooming, step by step, methodical progression - not rushing, not taking short cuts - cannot ever be bypassed if one truly wants to be a successful software engineer. Rushing will not help, stepping back, charting a path and moving forward will.
I also talk about Junior developers in my article here - hope it helps someone- dev.to/shitij_bhatnagar_b6d1be72/d...
Thanks once again.
Really appreciate this thoughtful comment 🙌
You captured the core issue perfectly — AI isn’t a shortcut, it’s a multiplier. It can speed up implementation, refactoring, or boilerplate, but it can’t replace the mental models we build through debugging production issues, making architectural trade-offs, or owning failures. That “time spent” is exactly how we develop judgment.
I especially agree with your point about process. Real engineering growth comes from understanding why a pattern works, when it breaks, and how systems behave under real load — not just making code compile. Production code forces you to think about edge cases, scalability, maintainability, and long-term impact.
Loved your reflections as well — especially the reminder that seniors aren’t just faster typists; they think differently.
I’ll definitely check out your article on junior developers. Always interested in learning how others approach mentorship and growth in this AI era.
Thanks again for adding real depth to the discussion 👏
The “debugging instincts” point really hits.
It feels like modern tooling and AI reduce friction so much that juniors sometimes skip the phase where confusion teaches pattern recognition. The hard part isn’t writing code anymore — it’s learning how systems fail.
Curious: when mentoring, how do you intentionally help juniors build debugging instincts without just throwing them into frustration?
That’s such a sharp observation — you’re absolutely right, the real skill isn’t writing code anymore but understanding how and why systems break under real conditions. When mentoring, I try to intentionally slow things down by having juniors trace execution step-by-step, read logs before touching the code, and form a hypothesis first — so debugging becomes a structured thinking process instead of random trial-and-error, and I’m really interested in refining this approach even further.
Good post, thank you! It is a golden age with the amount of resources available, as well as LLM, but it is also a curse; it is hard to know where to start and by using ChatGPT we don't really learn anything, we don't learn to struggle and we don't learn programming..
I agree it’s a golden age, but the real technical challenge now is learning how to use tools like LLMs without skipping the fundamentals and problem-solving process. In my view, the key is treating them as assistants for debugging, architecture checks, or alternative approaches, while still struggling through the core logic ourselves so real engineering intuition can develop.
Some real nuggets of wisdom here for any junior reading this. You can learn technical concepts faster than ever these days with access to all kind of tools to accelerate this learning. But actual situations such as serious production incidents can only be learned the hard way on the job and this takes time and experience to handle at a technical but especially emotional level. Thanks for sharing this useful post.
Thanks a lot! I really appreciate your insight. I completely agree—tools can speed up learning concepts, but handling real production incidents teaches skills you can’t get elsewhere. I hope to explore more practical approaches to managing these situations efficiently while staying calm under pressure. Your perspective is inspiring!
Again, amazing article. I was talking with some friend and am working on a post about it, but what do you see the future of interviews looking like? For entry? For senior? For arch?
Love this question — and really appreciate you taking the time to think deeper about it 🙌
I honestly think interviews are going to shift from “algorithm performance” to “decision-making clarity.”
I think that makes complete sense and entry level developers will spend their first few years understanding patterns and architecture not just how to write a for loop.
You really hit the nail on the head.
Thanks so much for sharing your honest perspective — I really appreciate it!
Interessanter Artikel, wie lange machst du das schon??
Vielen Dank, das freut mich sehr! 🙌
Ich arbeite seit einigen Jahren in diesem Bereich. Dabei habe ich beobachtet, wie viele Entwickler nicht mit der Syntax, sondern mit Architekturfragen, Skalierbarkeit und der Entwicklung wartbaren Codes zu kämpfen haben. Genau deshalb habe ich diesen Artikel geschrieben – um die tieferliegenden technischen Herausforderungen aufzuzeigen.
Mir liegt besonders die Verbesserung des Systemdesigns und der langfristigen Codequalität am Herzen. Ich lerne jeden Tag dazu.
Such a prosperous article with intentions, great job dear!
Thanks.
Thank you very much for this guide
It has absolutely changed my perspective as a junior developer
I’m glad it resonated. I’d love to hear which part you found most useful or how you plan to apply it—it’s always interesting to see different approaches in practice.