The pleasure is all mine, John! Thank you for always sharing a LOT of insights, which help many people reading. I have a feeling we'll get to 10+ overall collabs in 2026 (currently at 6) :)
The stack that matters now: communication first, then problem-solving, then fundamentals, then adaptability. In that order.
Sharing what you learn is a multiplier. Writing forces clarity. Teaching reveals gaps. The engineers who grow fastest are the ones who explain what they're figuring out, not just consume it.
Any suggestions on finding tools that actually work for you? The thing I struggle with is deciding what tools to actually try... there are so many of them, that I could spend all my time just trying out new ones to figure out what works best for me.
Exceptional articlethat captures something many engineers miss right now. The Einstein framing about spending 55 minutes on the problem really resonates, because in my experience most engineers jump straight to implementation without fully understanding constraints. What struck me is how fundamentals create this compound leverage over time. When you understand why distributed systems evolved the way they did, or why certain architectural patterns exist, you can evaluate new tools much faster. Junior engineers today have access to incredible AI assistants but often lack the mental models to know when the generated code is subtly wrong. The real competitive advantage isn't writing code faster, it's recognizing when a solution violates core principles before it becomes a production incident.
Agreed it's very common for people to jump to solutions before properly understanding the problem. Often when we really understand the problem, there's a key insight that points to a very different, sometimes simpler solution.
As always a pleasure collaborating with you Gregor, looking forward to next time!
The pleasure is all mine, John! Thank you for always sharing a LOT of insights, which help many people reading. I have a feeling we'll get to 10+ overall collabs in 2026 (currently at 6) :)
“We just saw Cloudflare go down, which took out access to many AI tools. If you depend on them completely, you’re stuck the moment they go offline.”
Imagine the nightmare of not understanding your infra and how to get it back up while your ai is down and you don’t know what to do without it!
Right, nightmare situation. Thanks for quoting that part! It was a good point made by John.
The stack that matters now: communication first, then problem-solving, then fundamentals, then adaptability. In that order.
Sharing what you learn is a multiplier. Writing forces clarity. Teaching reveals gaps. The engineers who grow fastest are the ones who explain what they're figuring out, not just consume it.
Well said Hoang. You are speaking my language!
Great read. I often face similar challenges when reviewing junior engineers’ PRs, and I’ll be sharing this with them.
Glad it resonated Priyanshu. And yes, it’s really important to understand that overall accountability is on engineers themselves and never on AI.
Checking the AI generated code, optimizing it and also improving it -> all crucial things to do before opening a PR.
Well written article! I enjoyed reading and found some powerful insights. Keep up the good work - both of you.
Appreciate the kind words Arvind and glad to hear that. Thank you very much!
Thank you, much appreciated.
Any suggestions on finding tools that actually work for you? The thing I struggle with is deciding what tools to actually try... there are so many of them, that I could spend all my time just trying out new ones to figure out what works best for me.
Just pick one and learn to use it well. The skills are transferable. The skills relate to good software engineering and good communication.
Chances are your employer has already made the choice for you.
Employer has actually chosen to not allow any AI coding tools... So the AI coding tools I have used have been in my spared time on some side hustles.
Exceptional articlethat captures something many engineers miss right now. The Einstein framing about spending 55 minutes on the problem really resonates, because in my experience most engineers jump straight to implementation without fully understanding constraints. What struck me is how fundamentals create this compound leverage over time. When you understand why distributed systems evolved the way they did, or why certain architectural patterns exist, you can evaluate new tools much faster. Junior engineers today have access to incredible AI assistants but often lack the mental models to know when the generated code is subtly wrong. The real competitive advantage isn't writing code faster, it's recognizing when a solution violates core principles before it becomes a production incident.
Agreed it's very common for people to jump to solutions before properly understanding the problem. Often when we really understand the problem, there's a key insight that points to a very different, sometimes simpler solution.
Glad the article resonated!
Very insightful article! Thank you!
I recently wrote an article on how new AI tools impact software engineers wellbeing. If you are interested, please, leave a feedback!
https://olenababenko.substack.com/p/the-human-side-of-software-engineering
Thanks Olena, glad it resonated! And also thanks for sharing the article you wrote recently.