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

This fits todays complaints ...

[Qbertino]

... of lack of experts. It's bullshit, as we all are aware of. Because companies don't plan long-term anymore, the lack innovation power in the short and mid-term. However, I see many positions for junior developers recently. This is the web field in Germany, so YMMV. Those companies that see the light and accept that you have to build a quality staff will remember junior and senior positoins. Those who don't will expect to hire magicians in an instant and fail miserably.

Re: This fits todays complaints ...

[Bruha]

Just no. We have plenty of qualified people already here and adding cheaper people helps no one.

India needs to own up to the mess they created. They sold a generation on easy high paying jobs and did nothing to generate them in a country of billions. So everywhere else is supposed to be their relief valve for overselling. The market will never correct as long as companies can find skilled people and entry level people wonâ(TM)t find jobs in their field. Time for both sides to face this fact and own up to it.

Offshoring firms did.

[edgedmurasame]

Tata, Accenture, Cognizant, Infosys, IBM Global, and other firms have contributed greatly to the decline of junior developers.

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.

Re:H1-Bs did

[Darinbob]

For H1B, I've seen them be very good much of the time. However, the outsourced overseas contractor, or the limited visa, those are mediocre to bad.

Re:H1-Bs did

[magzteel]

For H1B, I've seen them be very good much of the time. However, the outsourced overseas contractor, or the limited visa, those are mediocre to bad.

I agree with you on both counts. I have worked with some very good H1-B colleagues, and I like them as individuals.
That said, I believe if the laws were enforced companies would hire (or develop) local talent.

I think these programs should be amended as follows:

All H1-B employees hired must be paid at least 25% over the top of the salary scale across all employers hiring for that position. After all, they are specialists, the cream of the crop, and should be compensated as such.

Any company hiring H1-B employees is prohibited from laying off or reducing the salaries of any local employees in similar positions for a period of 5 years after all H1-B employees are eliminated.

Any company hiring H1-B employees, including outsourcing companies, must have a training program and plan in place to replace them with local employees within 2 years.

I invite anyone here on an H1-B visa to please add to this list anything you believe would improve this program. For example, "H1-B employees are at liberty to change employer at will".

Void in the middle

[sanf780]

There are various reasons I can think of.

First of all, companies love outsourcing in this globalized world in that there are more variable expenses rather than fixed ones. MBAs can tweak numbers all day along and get maximum profit. That makes long term relationships tricky, including the hire of juniors.

Second, employee retention is hitting a very low mark these days. I read on slashdot that everyone should consider a job change every two years in order to get a nice pay rise (>20%). If you stay in the same company for a long time, you are getting screwed (pay rise 3%). Playing devil's advocate, who wants to train juniors that leave after one or two years for a higher pay?

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.

Re:Interships

[SvnLyrBrto]

You omit the main reasons for job-hopping.

1) Companies have no loyalty to employees these days. Any given down quarter... even if the company is profitable, just not AS profitable as the board would like... you're liable to be laid off to cut costs so some C-Level can still get his bonus. If the company has zero loyalty to you, why should you be loyal to the company?

2) Many companies fail to keep ongoing wages and benefits competitive with the industry standards. Sometimes annual increases don't even keep up with inflation. If you've worked for a company for three years getting annual "merit increases" that barely even cover inflation, much less the rise in median wages for your position; new people with less experience than you are making more because they're getting hired into the position at currently-competitive wages; and you can get a 35% raise by changing jobs? You'd be a fool not to leave.

Fix these two problems, and I'd wager that companies would see significantly less turnover.

Everybody wants someone already trained

[gurps_npc]

They give a list of 10+ requirements that you are already supposed to know.

The problem is caused by a large number of applicants. They get 1000 applicants and need some way to winnow it down. So they give ridiculous exact requirements, trying to get someone with exactly what they need. But that person already has a job - probably paying more than what they offer - or is such a jerk no one would hire them.

It's the equivalent of saying "I want to hire a junior mechanic that has 5 years of working on a 2012 Porsche, a 2012 BMW, and a 2012 Jaguar."

The only people that meet the requirements either already have jobs or are shmucks.

Half the requirements and TRAIN THE PEOPLE to do the job. Any job that takes a smart person more than a week to learn how to do 90% of the work should be split into two jobs.

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

[whoever57]

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.

Or, perhaps it is a better tool than what you are using today, and you are letting your skills age and become out of date.

Seriously, you have 36 servers and manage each one individually? That's not the most efficient way of doing things.

Re:Killed themselves

[Jeremi]

Or, perhaps it is a better tool than what you are using today, and you are letting your skills age and become out of date.

The only real way to tell is to try it both ways and see which way works better in practice. May the best developer/envangelist win! :)

Re: Killed themselves

[Spazmania]

I'm doing what the customer wants done with his money. The customer made the call that downtime is acceptable while the cost of a highly resilient system is not.

"Wrong" is what the customer decides he does not want.

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.

Re: Killed themselves

[plague911]

"Bullshit. It is your job to educate the customer." No, not it is not always. Unfortunately much of the consulting world is divided into advisory and delivery. While everyone wishes to be on the advisory side, the bulk get the short end of the stick and get stuck in delivery, where not only is advising the client likely to be frowned upon but it can actually cost people their jobs.

Re:Killed themselves

[Actually, I do RTFA]

Or, perhaps it is a better tool than what you are using today

Obviously, there's a line to be drawn. But junior programmers almost never appreciate that a "better tool" that has to be implemented is inferior to an existing tool that's on autopilot.

If he's managing 36 servers individually, that's bad. If each one is already managed through a system, even some ad hoc thing he built himself, it becomes more of a question mark.

Senior Tools

[holophrastic]

Interesting article, but I think my life exemplifies this particular problem, and highlights the reasons behind the problem itself.

Tools.

Imagine two plumbers. One master experienced plumber. One junior plumber. Maybe the junior helps speed up the master, maybe he doesn't. In either case, the master plumber can only do so much alone.

Then we add really good plumbing tools (welders, wrenches, et cetera) into the mix. Now the master can do a lot more. As a result, these advanced tools become justifiable. With the master using advanced tools, the gap to the junior is a) even bigger; and b) easier to close with the tools. Master teaches junior to use advanced tools, junior becomes much more valuable.

I'm not a plumber. I'm a senior (owner) web developer. Our industry is very different because our tools work very differently from welders and wrenches.

In programming, our tools consist of elements that are actually far more complicated than the programming itself. Simple programming has always been simple. But IDEs, APIs, version control systems, development mirrors, and the like are actually far more complicated than logo and javascript and html ever were.

A wrench makes turning a bolt easier. An API makes turning a thousand bolts easier than turning ten manually, but APIs are far more complicated than turning one bolt.

This leads to our senior developer's advanced experience being less about experience in programming, and more about experience in how to program. This has a few complications:

First, that kind of knowledge is much more difficult to transfer -- its conceptual, its layered, its abstract. While it's likely that any junior plumber can be taught to use a torch very quickly, it's unlikely that any junior programmer can be taught to use an IDE without months of practice.

Second, and this is back to that gap from before, the senior programmer with the senior experience is far too valuable using that experience to warrant the effort to teach it. A senior developer with senior tools and senior experience, properly motivated, might be more productive than a good team of a 100 good juniors, and that's if juniors can do the job at all. Asking a senior to teach a junior is basically like saying you have no work for the senior for the year it'll take to teach a junior anything worthwhile.

Third, and this is the problem that is especially my problem, I don't want to work that hard. It's easy for me to work as a senior programmer. It's easy for me to do the work and get paid and move on. It's easy for me to charge a lot, take a lot of responsibility, and take a lot of time off. I'm fast, I'm efficient. I really don't have any interest in teaching humans. I chose a career where I tell machines what to do, in part because I have zero interest in motivating humans. Over the years I've hired junior developers, I'm fired junior developers, I've hired my own boss, I've hired sales personnel, I've hired advertisers. In the end, I've shed them all because I simply want to program, and I don't need any help with it.

The article concluded that it's an industry problem. Maybe it is, but I see it differently. It's a senior's solution. This is what I'm doing. I like what I'm doing. What I'm doing works for me. I'll keep doing it.

Why hire a junior developer

[OrangeTide]

When I can hire an experienced foreign worker for the same amount?

Schools have never produced experts

[RhettLivingston]

When I came out of school, I had theory and the experience of writing (on my own) a compiler for a largish subset of Ada 83, a cross-assembler, a couple of device drivers, a few minor device firmwares, and various assundry other useless classroom exercises. That was enough to have put me on my school's team for the ACM regionals. As a Computer Engineer, I had also designed and constructed devices and could quickly make designs without having pre-made boards like Raspberry Pis in existence. But the reality of the difficulty of accomplishing a design that also met reliability, manufacturability, and other real-world goals had not yet hit.

Within days of starting work as an Associate Engineer in Avionics, I understood that I had gone to school from ages 4 to 21 to get the learner's permit that would allow me to start learning how to design and program real-world systems. It took about three more years of 90 hour weeks with unbelievable financing and toys (the lab I was in probably had over a billion dollars of hardware) to play with to reach a level that I would consider a competent systems engineer.

In that day, virtually everyone spent their first years in corporate environments that gave you a year or so as an Associate Engineer contributing nearly nothing and two or three years as an Engineer barely breaking even in the contribution to project versus cost of mistakes equation before becoming a truly useful Senior Engineer. If we've lost that level of corporate training to season the college output, we might as well quit.

Re:These days, they're called "Interns"

[jordanjay29]

So much of the problem with interns is that I can't get an internship unless I'm a college student. I have my degree, so I don't qualify. But I can't get a job with the company because I didn't intern with them.

It's up to us

[Just Some Guy]

My company explicitly states that it's our job, as senior developers, to farm the crop of new junior developers. And FWIW, we've seen enormous success from hiring inexperienced (but talented and eager) new engineers and mentoring them in the ways of our world. The main difference between me and a new kid out of college is that I've made a lot more stupid mistakes than they've had time to. I share my experiences with them, and they share their excitement and willingness to try new things with us. If I can play a small part in helping them graduate to a senior role - either here or elsewhere - I'll consider it a personal accomplishment.

We did our time as juniors. Now it's our turn to help the next cohort learn the ropes.

Wiki documentation

[raymorris]

> 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.

I could probably do a better job giving people guidance on when to ask and when to keep trying themselves. Also encouraging them to sometimes try asking each other.

> 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

You were probably addressing two separate things here, but it occurs to me that we sometimes spend time explaining source control, red tape, etc. At a company I owned, and again at my current employer, we documented all that stuff using a wiki. I was actually a bit annoyed when my then-new boss wanted to spend so much time writing wiki docs for so many things, but it has paid off in short order. At my company, I told people "if you need me to explain something for you, it might be a good idea to make notes in the wiki." Not always, of course, but often enough, because there will be another new in six months.

Of course, his idea with the documentation might be that I would be documenting myself out of a job - writing down all the stuff that the cheap people will need to know so they can get rid of the expensive people. Hopefully the bosses see that the less-expensive engineers are a lot more effective in combination with an old guy who is practicing effective teamwork. I believe that's the cheapest (most efficient) way in the long run. I'm trying to make it so, and make it show.