Who Killed The Junior Developer? (medium.com)

Melissa McEwen, writing on Medium: A few months ago I attended an event for women in tech. A lot of the attendees were new developers, graduates from code schools or computer science programs. Almost everyone told me they were having trouble getting their first job. I was lucky. My first "real" job out of college was "Junior Application developer" at Columbia University in 2010. These days it's a rare day to find even a job posting for a junior developer position. People who advertise these positions say they are inundated with resumes. But on the senior level companies complain they can't find good developers. Gee, I wonder why?

I'm not really sure the exact economics of this, because I don't run these companies. But I know what companies have told me: "we don't hire junior developers because we can't afford to have our senior developers mentor them." I've seen the rates for senior developers because I am one and I had project managers that had me allocate time for budgeting purposes. I know the rate is anywhere from $190-$300 an hour. That's what companies believe they are losing on junior devs.

Comments

Offshoring and SaaS

[ErichTheRed]

The company I work for is _finally_ starting to take back work from offshore companies after realizing they were being left with an unmaintainable mess...and this took almost 10 years. Lots more companies are still addicted to cheap coders. That's where all the onshore junior developer jobs went when it comes to custom applications and software.

The other thing that's happening is software as a service applications that are good enough out of the box to not need as much dev work done on them Things like SharePoint Online and Salesforce.com are good examples of this...plus every single corporate niche application (travel, scheduling, etc.) are being targeted. The best a junior developer can do is get hired at one of those companies, but they tend to use offshoring or other cheap soiurces of labor.

It's not a good thing, because we really do need a bunch of new recruits in the pipeline who are capable of learning and don't mind spending time gaining experience. Companies want people to jump from freshly-printed CS degree to rockstar full-stack 10x developer, and it's just not possible without real-world, low-level experience.

Your junior dev is some script from Github

[Average]

When I think back, a lot of 'junior dev' assignments were classes of code that had clear specs and were mostly just doing CRUD on the back end. A whole lot of boilerplate code. Code that is now pretty much replaced by some MIT-licensed library in Maven/PyPi/Rubygems/NuGet, etc. At one level, it should make a junior dev more productive... "just reference the library". But, remaining tasks left are closer to the business logic, more open-ended, and generally higher-level architecture questions.

The 'getting started' pipeline problem is even more obvious in the ops/sysadmin realm. I picked up my UNIX chops through installing bare-metal servers, configuring BIND domains, Apache, Sendmail, etc. Junior dev tasks. Now... why would you run your own DNS? Make an API call to a provider, automate it, and scale x1000. Manage a giant fleet with Ansible or Puppet... great. Now, we go heavy into containers. Great.

But, I haven't met many people who were very good with containers or Puppet who didn't first have 10 years of basic sysadmin. But, those tools have obviated the need for paid entry-level jobs getting that 10 years of basic sysadmin knowledge.

Our formal education system doesn't help. I look at the computer classes on offer at my local Community College and weep. 3 hours of C++... for loop and data structure... write some itty-bitty bit of code. Great, the fundamentals. But, that's all they ever get. What I need... check out from Git, read a third-party's API definition, and add a little function into an existing large codebase based on some huge framework. Oh, and/or write a test for that addition too, please. We're finding that the bootcamps (at least, the best of them) are more connected to real-world needs than most US colleges and universities.

Re:Interships

[Vektuz]

The other thing that I've noticed is that the juniors nowdays do tend to move around a lot. They're much, much much more likely to quit after internship and take a job at a different big corp than YOUR big corp, after thanking you for all the training.

I've noticed that goes even moreso for juniors nowadays. More and more, people work very short stints at any given job, especially in silicon valley type jobs... When people keep taking other jobs, it doesn't make as much sense to spend what amounts to 50k+ of expert time mentoring them just so that they hop to a different place at the end of it.

This job-hopping trait seems to be a trait that is increasing in the younger generations - I won't judge whether its good or bad (in that hey, its up to them what they do with their life) but it does mean that it impacts mentoring decisions and how companies spend their money.

Lol true. We seniors could mentor better

[raymorris]

The newer guys at my company wouldn't shut up about Amazon Lambda (not to be confused with actual lambda functions). No matter what the question, their answer was always "Lambda!"

Tiring of "arguing" with them all the time (shooting them down), I eventually let one proposal proceed to the point where they scheduled a meeting to discuss how to move a certain project to Lambda, with management present. It was a process that handles processing a data feed from Microsoft. In that meeting, I didn't shut them down right away. I let them talk about the many benefits of Lambda vs the current system, mainly scalability. And ... scalability. Yeah pretty much just scalability. After they pitched it pretty hard, I asked "so the main driver of this, the primary reason to take a couple of weeks to rewrite this using Lambda, is for massive scalability, right? It could run thousands of times per second, right?" "Yep, that's the great thing about Lambda", they said. "Our current implementation can only run about once per minute, right?", I asked. "Yeah, the current code takes a minute or so to run". "And what it does is process the Patch Tuesday data which comes out once a month, right? We need to run it once a month?" "ummmm....". "We need to scale in case Patch Tuesday starts occurring thousands of times per minute?"

After stammering for a minute, one of them piped up with a great answer "we'll be able to parse more feeds, from other sources!" "True, that might be good", I said. "Our current system does four feeds. It probably can't handle more than about 500-1,000 feeds. Over the last six years, we've added a total of four feeds. How long do you think it will be before we have more than 500 feeds and need something more scalable? 25 years? 50 years? 200 years? Should we plan on building something that can handle 500 feeds and schedule to that project 50 years from now?"

I haven't heard a word about Lambda since then.

What I HAVE done since then is found a good pattern to maximize the productivity of the team, seniors and juniors combined, while making my job more fun. Some trivial problems the juniors just handle. Anything that might benefit from a senior developer's attention, I look at at make some notes about generally how it might be solved, and any traps that may be lurking. I might include a link to a certain third-party module that may be useful. Then the junior person has my notes pointing them in the right direction. At each morning scrum, I remind the team that I *love* helping to solve problems and helping people understand things they are having trouble with. So they reach out when they hit a wall or need help choosing between two options. Then when they finish the task we do code review - I, or another Senior, looks over the code and makes suggestions as needed. The junior guys handle the details of actually implementing the ideas I suggest. They write the unit tests. They fill out the change request forms. All the bureaucratic red tape is theirs. It works great. I can guide five to ten times as much work as I could do myself. Their code isn't quite what mine might be "in the small", but the approach they use, the overall design, is either what I suggested, or something better they found. Code doesn't go to production with glaring errors that would be obvious to me, because I've looked over all the code, and made a unit test policy. It works quite well.

So junior devs work out nicely in my system, IF they can do one particular thing right - know when to ask for help. Don't ask me AGAIN the same thing you've asked me ten times, knowing the right answer but just lacking confidence, and don't go charging ahead when you have no idea wtf you're doing. Ask when you need to ask, and not when you don't. If they can do that, a team of junior devs and senior devs who have a solid system of working together can be very productive, multiplying the benefit of the Senior dev's experience. My company also isn't paying me senior salary to fill out change request forms and crap. The juniors can do that, based on the documentation that I wrote for them.

Re:Lol true. We seniors could mentor better

[complete loony]

Similar experience here. I've worked with a number of juniors, who all had to learn a new programming language, get their head around our application, source control, red tape, etc. Initially, every task I assign to them takes more of my time to explain and review than if I did it myself. Maybe I'll try to explain what I mean a couple of times, then just quickly type the solution and tell them to read the help pages for every function I used that they don't know yet.

If they hit a problem, I'd tell them to try to find the answer on their own for maybe half an hour, then come and ask. Don't waste a whole day on a question that I can answer in 5 seconds, but try to research the problem first. You may not find the solution, but you might find something else that's equally useful.

After about 3 months, that tends to break even. They should have picked up enough that together we can do slightly more than I could alone. I can flesh out a rough design for a task that might take me a couple of hours alone, answer a couple other questions while they work on it, and they finish it in maybe a day with test cases and any other red tape. The financial break even point comes a bit later, when they are getting the same amount of work done per dollar paid, but working that out was generally someone elses problem.

Provided a junior is showing progress towards that break even point, I don't mind spending the time. But if it feels like I'm doing their work for them for too long, and they aren't showing enough evidence of learning on their own, their days are numbered.

Though I will say that we were very picky about who we hired. We ran graduate students through a 3 hour programming test that nobody finished, to see what they know and how they think. On average, we probably tested 60 people for every person we hired. Every time management hired someone without going through that process, we regretted it.

Re: This fits todays complaints ...

[Z00L00K]

That looks good on paper - until you realize that someone has to bring order to the random mess that was created by the offshore developers.

If you don't specify in detail what you want then you end up with a mess. I know because I'm in an organization where we still are cleaning up stuff that was specified up to 10 years ago that nobody understands well.

And in India you are a senior developer if you have worked 1 year at the same job.

PS - all credit to the juniors. PPS - I'm junior

[raymorris]

PS I always make sure that I praise the Junior's work in a team meeting, rather than taking credit myself. They obviously wouldn't want to do the grunt work while I took the credit. Conversely, when I very much direct any praise their way, they often feel the need to "set the record straight" by pointing out that the cool thing was my idea. "I just had the idea, YOU made it actually work", I'll reply. I suspect it won't take too long for our new project manager to notice a pattern there. :)

On a different note, my initial post may have sounded arrogant. I'm not the best programmer in the world. We're ALL the biggest fish in a small pond, if you define a suitably small pond. When I'm working with the main Linux kernel devs, I'm the junior. Working on Linux kernel raid, I asked Neil Brown for guidance and certainly he (and others) reviewed my work. I'm a tiny guppy in the kernel pond. I happen to be "the biggest fish" (most experienced) at my particular office. If I went to work for Red Hat, I'd probably report to Florian Weimer and I'd be a guppy again compared to him.