What about juniors?

Start at the beginning.

Last week I wrote about how the role of the most senior tech ICs has changed. Today, I wanted to share some thoughts on a more difficult topic: how the role of junior software engineers, folks just starting out on their career, has changed or will change.

First, the good news. In last week’s post, I wrote this about senior folks:

It’s hard to admit where you’re wrong. It’s hard to go back to being a beginner.

Junior engineers don’t have this problem. They’re already beginners, and provided they approach the field with that mindset, that comes with a significant advantage. In any time of change, the people who can learn and adapt fastest are most likely to succeed. The senior’s advantage is that they have a lot of knowledge and context. The junior’s advantage is that they come in knowing that they need to learn, adapt, and change.

So far, those are the easy answers. Other than learning, what do junior engineers do?

To get an idea of this, I think we need to go look at other fields where similar transformations have happened. Notably, the transformation that separated the tasks of engineering and implementation, either automating the latter or passing it off to a different group of people.

In my experience, junior software engineers are insulated from the business and customer context of their work. This isn’t unique across engineering fields¹, but I do think the extent of it and the length of the expected period of this insulated apprenticeship is unusual. That additional time seems to have been allocated to learning the craft and science of software engineering, a field for which most university educations leave one rather poorly prepared. This need to learn the craft appears to becoming less valuable, as automation seems set to take over most aspects of that craft.

The new junior path appears to require getting engaged much earlier with the essence of engineering.

To quote Arthur Wellington:

to define it rudely but not inaptly, it is the art of doing that well with one dollar, which any bungler can do with two after a fashion.

or, as my engineer grandad used to say:

an engineer can do for a tickey what any fool can do for a dollar²

I like that quote so much, I bought Wellington’s book³.

I believe that this is the core work of engineering: deeply understanding the problem to be solved, the constraints, the tools available, and the environment in which it operates, and coming up with an optimal solution. This requires real creativity, because the constraints are typically over constrained, and real empathy because many of the constraints come directly from human irrationality. It also requires a deep understanding of the tools available, and what those tools can and can’t do.

This is the heart of the job that experienced software engineers are doing. It’s a job that spans customers, economics, people, and technology. Failure to engage with one or more of the parts of that complex job, or handle the complexity that comes with optimizing for all of them at once, is the most common reason that I see for engineers’ careers stalling out.

This doesn’t mean that junior engineers shouldn’t engage with the craft and science. Machinists who appreciate mechanical engineers who’ve spent time in the shop, for example. Engaging with the craft of programming is one way to learn what tools are available. Engaging with the science, both the quantitative and theoretical parts of computer science, carries even more value. This is a time in our industry when having a broad, but deeply grounded, imagination for what’s possible is valuable among nearly all other skills. And what’s possible is both changing fast, but also based on core ideas and principles which are barely changing at all. Science gives the engineer a rock on which to stand, and a fulcrum on which to bear our lever.

The high level is fairly clear: the new junior path engages much earlier with economics, product, and people, has less emphasis on the practice of the craft of programming, but more emphasis on the deep technology and science behind the systems we are building. It’s more connected to the real world, and more connected to theory. More feet-on-the-ground, more head-in-the-clouds.

Again, this is something of an easy answer. What does it mean for the real day-to-day?

Back in 2019, on learning to build distributed systems I wrote:

If you’re lucky enough to be able to, find yourself a position on a team, at a company, or in a lab that owns something big. I think the Amazon pattern of having the same team build and operate systems is ideal for learning. If you can, carry a pager. Be accountable to your team and your customers that the stuff you build works. Reality cannot be fooled.

I often disagree with my past self⁴, but I still believe this is the best path to learning to build big systems. Be an owner, be a builder, be hands-on and responsible. Carry a pager. Own a deadline. I don’t think that path has changed much. The day-to-day has changed, and will change more, but the high-level picture remains the same.

For the manager, this remains an incomplete answer to the question. What does a new engineer do on my team? They build. And, much earlier in their career than you might have been comfortable with before, they own. Own a project. Talk to a customer. Own a deadline. Get exposed to all the messy customer, economics, business, people, and other constraints that they need to understand in order to optimize for. Set high expectations for using deep knowledge of technology to solve problems in new ways. That’s going to be hard for some, especially those who came into the field expecting a purely technical (or barely technical) career.

The real good news here is that software engineering is more powerful than ever before, and seems set to become even more powerful. The economic and societal opportunity represented by software is greater than ever before. Junior software engineers who are comfortable expanding their scope shouldn’t, in my opinion, worry about their careers. Those who want to remain narrow, or don’t want to do the hard work, or want a low-ambiguity job taking tasks off a backlog, have a less clear path.

Footnotes

1. Hillel Wayne has done some good work highlighting how software engineers’ conception of real engineering tends to be rather mistaken. See Are We Really Engineers? and Is Software Engineering Real Engineering? for example.
2. As an engineer, he should have known better than to mix units in this way, but that’s grandads for you.
3. The first five chapters of that book are very much worth your time if you’re an engineer of any kind.
4. Whether that’s because I’m smarter than I used to be, or because I used to be smart and now I’m an insufferable blowhard, is an opinion left up to the reader.

Similar Posts

• 20 Mar 2026 » My heuristics are wrong. What now?
• 18 Mar 2026 » Music To Build Agents By
• 25 Feb 2026 » SFQ: Simple, Stateless, Stochastic Fairness