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

H1-Bs did

[rsilvergun]

at least in the States. The H1-B program requires companies try to hire a local employee first. The rules say they can only have an H1-B if no qualified applicants are available. So everybody becomes a "Senior" developer and since there aren't enough people with the necessary credentials (there never are) they can always apply for an H1-B. This is also why companies don't pay to train anymore.

Interships

[HockeyPuck]

Companies take interns, and after their internship period is over, decide to hire them. Now the company isn't taking any risks with a fake junior developer, they can hire one that has proven themselves.

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.

Killed themselves

[Spazmania]

Junior developers seem to all want to jump on the technology du jour they've heard about from Google or Facebook. The problem is: Google and Facebook have only a limited number of junior developer jobs available. Other companies have different technology needs, more often than not needs for projects operating at much smaller scales. These needs are poorly met by technologies designed to operate at Google or Facebook's scale.

Got a guy like that where I work now. Great guy but he just won't shut up about Kubernetes. We have 36 servers in the production environment, each of which does something different using different software. Kubernetes is the wrong tool for every job we have.

Until they get past the compulsion to use the Latest Greatest technology, developers limit their usefulness.

Re:Killed themselves

[Spazmania]

I didn't become the lead devops guy by failing to automate repetitive work. I also didn't get here by trying to surf each new wave that comes to shore.

Docker and Kubernetes do some very interesting things. And they don't attempt to do a number of things that their predecessors eventually figured out were essential to reliable cost-effective operations. They will or they'll fade. When they do, I'll notice.

I hate to say it, but right now Docker is primarily a way for developers to stick their fingers in their ears and say "la la la security la la la." Require the same attention to security that the OS gets and suddenly Docker is massively more complex to work with than older techniques.

Conceptually I like docker, but unless I'm building something at a scale sufficient to justify the expense of doing it well, it doesn't meet my needs. And guess what? Most positions open to junior developers don't involve building something at high scale.

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.

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.