What New Developers Need to Develop

The toughest part of becoming a developer? Landing your first role. Opportunities for those 1–3 years of junior experience are a challenge for recent graduates, bootcamp students, and self-paced learners alike.

There’s a big jump between academia and a professional coding gig, just like there’s a big jump between building a chair and joining a home-building crew. The gap keeps widening, too: more specializations, more tools, more to-dos, more complexity. More stuff, which can easily take years to bridge.

Who’s responsible is a topic unto itself (and it’s a mix of all three parties — the learner, the curriculum, and the employer). We’ll stick with what: What will new developers need to pick up after a typical course of study?

Drawing from onboarding experience (our own, our clients’, and that of agency peers), time spent mentoring, and panel participation, here’s what pops up repeatedly.

Pattern Recognition

Saying “you need experience!” to get experience is a bit on the nose, but the biggest side effect of time spent is pattern matching. In development, patterns inform:

• How to (and how not to) approach a problem
• How to set something up in a team-friendly way
• How to set something up for the future
• How to try out new patterns and get unstuck
• How to review code samples, found or generated

It’s like your first drive through a city’s “downtown.” You’ll be in the wrong lane a few times, miss a couple turns, and wonder where the heck parking is. Several attempts later, it’ll be an old hat — and, crucially, you’ll be able to route around new issues (accidents, closures, backups, and such). Development needs reps, too.

Dealing With an Old Codebase

Recent grads tend to have the same four-to-six-class-projects-of-increasing-complexity portfolio. No major issues there, but those projects have a few characteristics that stick out:

• The student is the sole contributor
• The age of the code can be measured in days, weeks, or (maybe) months
• Each activity started from scratch against a well-defined set of specifications

The point? Developers tend to learn (out of necessity) in a controlled environment. Live products, on the other hand, differ with:

• Many contributors, and many former contributors
• Years — or decades — of changes, additions, duct tape, dragons, and dusty corners
• Decisions that conflict with an ever-changing roadmap

New developers are pulled out of their workshop and tossed into an active construction site, tasked with sorting out where to look, what to trust, what not to trust, where all the technical debt hides, and what chain of decisions led to the wild code they’re reviewing. It’s overwhelming. Bonus points if automated tests or peer reviews are missing: Nothing builds confidence like breaking the production build.

Picking Up New Tools

Are you familiar with a specific hand saw, or are you familiar with the ins-and-outs of cutting wood? (Sorry, it’s construction analogies all the way through.)

Initially, it’s tough for a developer to know the difference: Is this a pattern tied to a language or framework, or a foundational programming idea? How well does JavaScript array manipulation transfer to Ruby? When’s a new tool worth picking up? We’ve arrived at the oft-quoted Maslow’s hammer: “If all you have is a hammer, everything looks like a nail.”

Knowledge transfer is a big component of the “senior” developer rank. They’re able to get professional results out of something new in a hurry.

Options, Alternate Paths, and Advocacy

From new tools, though, comes the need to pick one. And it’s rare to have a perfect answer. For a junior developer, this means:

• Getting good at “keeping up” with what’s out there, at least at a surface level
• Adding clarity to pros and cons in different contexts to different teams
• Knowing where to compromise and where to stand your ground

We’ve stumbled on the communication aspect of development, and it tends to be the most important part. A project team is a collection of folks with different goals and agendas, and technical decisions are part diplomacy, part politicking to marry them all together. Sometimes, that’s a thin line: raising concerns without being a wet blanket, advocating for your opinion without picking a fight, and so on.

Whether you’re responsible for a task, a feature, or the entire project, there’s a level of built-in ownership that falls to the developer.

Playing With Time

Development estimates are hard, to the point of being a (unfortunate) running joke in the software world. There are helpful exercises — breaking tasks down into smaller pieces, prototyping, pairing up — but they don’t stop project leaders from mentally adding 2x or 3x multipliers to everything. Just like pattern recognition, reps are needed to find success here.

The calendar looms, too. Developers are overly optimistic about what’ll be done today, this week, this sprint, and off into the future. As tasks slip, the “built-in ownership” we were just discussing kicks in, adding anxiety that junior engineers internalize more than anyone else. What follows (working overtime, doubling down, dealing with long periods of stress) only makes it worse.

The biggest part of time is timing: knowing when to stop, when to ask for help, when to communicate, and when too long is too long. A concern raised early is easy to recover from; one raised late is a scramble.

Playing Well With Others

Combining just about everything we’ve talked about so far, the real shift into a professional role is tied to people. Outside of that controlled learning environment, development is no longer a solo task. Now you’re facing:

• Business needs (budgets, timelines, metrics) that conflict with engineering needs
• Incomplete information while teams meet with other teams to meet with other teams about meeting to make decisions
• Decisions (design, business, or otherwise) that add significant complexity
• Other developers tinkering in and around your code
• Managers looking for regular status updates and time estimates

A project team marries a lot of domain experience in a lot of domains — and some will be prioritized above engineers’ preferences.

It isn’t a mistake that these last three “gaps” are all communication-related. Coding skills and pattern recognition are absolute musts, but the part-of-a-team context is where real strides are made. Interestingly, it’s here that change-in-career developers can set themselves apart: If their previous job navigated interpersonal dynamics, that can help break a tie in the hiring phase.

One-Size-Fits-None Training

The training materials are better than ever (and we have experience). The tools are better than ever, too. More quality, more complexity, more standards — and a more difficult path for junior engineers just to get some production-ready code under their belt. Today’s senior developers got their reps when the industry had a different relationship with best practices, issues, and team sizes, and it’s hard to give the emerging generation similar opportunities.

It’s all a kind of helicopter parenting thing that’s hard to break as the outputs become more and more valuable.

Everyone comes to development with different goals, experiences, backgrounds, and preferred ways of learning. There’s no one-size-fits-all path or role to bridge the gap. It’s a challenge the industry continues to tackle: coding copilots are a start but, as we’ve explored, there’s a lot of “people stuff” to cover, too.