How can little Timmy swim against the current?

I started writing a piece about "5 lukewarm programming takes", but I started to really hone in on this particular topic, and realized it might in fact be a hot take, and not belong in my listicle of lukewarm takes at all.

Part of the reason I want to write about this topic is that I do not like the "doom"ism of the never-AI people. It simply doesn't seem like a good stance to say that because agentic software development changes the way we learn programming, it must be thrown out entirely. It's not reasonable at this point to be a never-AI person, and it, dare I say, lacks creativity. But I also don't like the "I never read code" people. So I'm trying to think practically and land somewhere in the middle.

It is harder for junior software developers to progress to senior than it used to be

Is that a fair thing to say at this point?

Junior software developers used to get hired and then get assigned tasks appropriate to their skill level. They would go through this very natural process of doing work, bumping up against hard problems, and cutting their teeth on them. The industry became accustomed to this career progression pipeline. Juniors were protected from the hardest/most complex problems, and exposed to a certain amount of friction and difficulty, and gradually gained the valuable skills, intuition, and "finger tip feel", or "Fingerspitzengefühl", as Lars Faye describes here, until they could finally take on the most unwieldy of tasks.

There now exists, however, some "economic" pressure to incorporate LLMs and agents into their workflow. I say "economic" in quotations because I'm not sure what the perfect word is to describe what's happening. I do think there is some level of "temptation", you could say, for a fledgling developer to just offload the difficulty of their job to Claude and then accept its output. But... I think that this particular issue is solvable with some willpower and intentionality. This "temptation" is a factor, but it's not the hardest part of the problem to solve, in my opinion.

If a junior developer is smart (and maybe if they have a good mentor helping them), they'll figure out that in order to grow and gain skills as a developer, they must swim against the current.

There is a tremendously strong current in this proverbial river, and it feels like if they just go along for the ride, they can immediately have a meaningful impact on a project. And that part is probably true! They can do AI-assisted development and probably make meaningful contributions. It will not be equal to a senior developer, but they will complete real, meaningful work.

The only problem with this is that:

1. almost anybody could be accomplishing what they're accomplishing, and;
2. there is very little opportunity for learning in this style of work

Now, what if instead of going with the flow, they swim against the current?

Now, if little Timmy spends all day writing code by hand and learning and going down rabbit holes, he's going to very quickly have management breathing down their neck, wondering what he's doing, and how and why he's so massively unproductive.

I've written about and linked this paper before, but I keep coming back to this idea of a more official "preceptorship" model. I believe that there needs to be clearly defined expectations of the junior roles that allow for more exploration, and maybe even being completely unproductive for some amount of time. They might even cause negative productivity, as more experienced developers must spend time teaching the newcomers.

But, again, the "economics". The economics of it all don't necessarily make sense. Why would a company invest time and money into a junior engineer, in order train them up while they are potentially negatively productive? Worst case scenario, as soon as that developer becomes productive, they leave to be productive elsewhere.

That is the tension. Should little Timmy go with the flow and be productive using Claude right out of the gate? Or should he swim against the current, sacrifice productivity, feel the friction and the difficulty of hard problems—all for the pursuit of future excellence? And why would a company support little Timmy in this pursuit?

I don't believe the industry has figured out how to solve this issue yet. Unless little Timmy is protected by a good mentor/manager, or unless the company has read about the collapse of the talent pipeline and consequently reshaped their engineer department, there is going to be a tremendous amount of pressure for little Timmy to be productive from day 1, and he's not going to have access to same learning opportunities that the experienced developers of yesteryear had access to.

So what do we do?

Refuting the Rebuttal

It's entirely possible that I am overstating the degree to which learning opportunities have actually changed. Maybe I'm operating out here in philosophical software management fairy tale land. Maybe there are still valuable learning curves that junior devs are exposed to, they're just different than they once were, and that's okay, and I'm being overly alarmist.

To that I say, if nothing else, we're in uncertain times. These concerns are not unique to me. We all feel the potential de-skilling of software engineers, even senior+ level, whether there are studies and data that are able to validate that or not. I've had early-in-career engineers talk to me about worries they have about their ability to gain valuable skills and the prospect of crossing that chasm from junior to senior.

I, however, am not a junior developer anymore, so I cannot say for sure what this feels like first-hand.

As always, all opinions in this piece are my own and are in no way a reflection of my current employer.

Thanks for reading!

- Nick Agliano