The Best Career Advice for Junior Engineers in the Age of AI

Thorsten Ball, who works on Amp and wrote books on building an interpreter and a compiler, shared an email on X that he wrote to a junior engineer who had just graduated. He says he often gets emails from junior engineers asking him what to do, and this was his reply. It really touched me, and I think it's some of the best advice you can give someone starting out in programming right now.

It opens with three words most people giving career advice avoid.

"I don't know"

"Honest answer: I don't know. And I don't think anybody does, really." - Thorsten Ball

AI has progressed so much in the past few months that it's nearly impossible to predict what happens next. Only time will tell, and that's the thing most people are afraid to say. They're afraid to accept that they don't know where the world will be, and that's exactly what makes "I don't know" such a powerful statement.

Thorsten is honest about how much has changed for him too. In 2011, a friend told him that if you can program well and prove it, you'll have a job and nobody will care about your degree. That advice fueled him for over a decade. He read programming books before his day job, learned languages, did open source, gave talks, and wrote about what he learned. Now he estimates that "30%? 50%?" of what he invested his time in doesn't matter that much anymore, things like getting good at Vim, arcane command line stuff, and syntax and stdlib knowledge.

Code was never the point

When a young engineer at a talk asked him what he recommends to juniors, Thorsten told her to think from first principles about how you can add value to the business as someone who can manipulate the digital world.

"Forget titles, forget 'programming,' forget languages and frameworks, forget Engineer vs. Product Manager, but ask yourself: what problems this business has can I solve with technology?" - Thorsten Ball

He admits this isn't new. It was true all along, but for the last few decades it wasn't an immediate question "because there was so much syntax and typing to hide behind."

I agree with him. Code was never the point. The point was to improve processes and businesses with the help of technology, and code was only the means to get there. I'm not saying code quality should be ignored. I'm saying the focus has shifted from syntax to actual productivity. It's not about how many lines of code you write, it's about what impact you make.

Out of the things Thorsten thinks will always be valuable, two stood out to me.

• Ownership and agency. In his words, "Own the whole chain: from business problem statement to customer value." As he points out, nobody ever really valued the person who did their part and didn't care what happened to it afterward.
• Systems thinking. He says that when he prompts his agents now, he thinks "in terms of subparts of systems interacting, not about code."

The rest of his list is knowing what to build and why, and communication, which he sums up as "Learn to write well." He also links two of his older posts, The Basics and Ownership, which he says still matter.

Fundamentals matter more now than before AI

In a follow-up, Thorsten added that you still need to know how computers and software work, no matter how good the models become. His examples include what a database is and how it works, what a compiler is, what TCP/IP is, what a filesystem is, how virtualization works, big O notation, when to use polling vs. WebSockets, and how Electron is different from a native app. As he puts it, "you still need to know how software is built in order to build it."

I'd go a step further. Fundamentals are more important now than they were in the pre-AI era. Without fundamental domain knowledge, it's hard to debug what's going on, and your only option is to rely on the AI (if it's any good).

Here's a small example from my own workflow. When I give a task to an AI coding agent and it runs a command wrong and fails again and again, I can tell it's made a mistake. To stop it from repeating that mistake, I add the correct instructions to my AGENTS.md file. That takes human oversight and some domain knowledge. I had to know bash to tell the agent what the correct command was.

If I didn't know bash, I'd be stuck asking the same agent to fix its own mistake and hoping it gets there.

I wrote something similar after the AWS and Azure outages. All of these complex systems are abstractions built on top of really basic technologies like DNS, and when those basics break, everything above them breaks too. The same goes for the code an agent writes for you. It still runs on databases, networks, and filesystems, and someone has to understand them when things go wrong.

Thorsten also jokes that AI taking over programming is a dream come true for computer science professors, who can now talk about space and time complexity, big O, and recursion vs. iteration without wrestling with syntax and compiler errors.

What to focus on if you're starting out

Nobody knows exactly where this is going, and it's fine to admit that. What I'm sure of is that fundamentals, systems thinking, and agency are what we should focus on, and the syntactic sugar is what we should offload to AI.