Slashdot Mirror
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.
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.
... 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.
We suffer more in our imagination than in reality. - Seneca
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.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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.
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.
excitingthingstodo.blogspot.com
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.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
No thank ATS computer systems like Taleo.
Here is how it works:
1. Sales man from Oracle oversells Taleo to HR VP as hey no more recruiting. Our system does it for you
2. HR fires recruiter since a software program and website can do the job.
3. System only looks for exact job description in every job and tallies up the score.
4. Since your previous employer didn't have exact job wording you are filtered out with a lower score
5. That hole on your resume in 2012 during the recession? Ha unemployable loser I see! Filter out
6. If you have all the same qualifications but did not list them for EVERY job then you are underqualified as you have 2 years experience not 5. Filter out.
7. Job description doesn't match word for word. Deducting from years of experience as last job doesn't count. Now underqualified. Filtered out.
OMG no qualified applicants look!! Idiots
You know it wouldn't hurt to actually have a human read these resumes? No really.
Linus Torvalds himself is unhirable according to these ATS job applicant systems. He has a gap on his resume from working with Transmedia to working on Linux fill time. Linus also doesn't have 3 professional managerial references...hmmm what is Linus trying to hide?? Also Linus doesn't have Oracle, RoR, node.js, tibco spitfire, Ms office VBA, Oracle reporting, and other corporate program BS list in his resume. Worst Linus Torvalds doesn't have exact same job title.
His resume won't make it HR and will be deleted. This is to show how ludcrious the situation is today
http://saveie6.com/
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 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.