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
Tata, Accenture, Cognizant, Infosys, IBM Global, and other firms have contributed greatly to the decline of junior developers.
"Forget the engineers." -Carly Fiorina, briber of MIT Technology Review.
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/
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?
HR is to blame because they have unrealistic standards. It's like a guy that is a "4" that will only date women who are a "9 or 10", shares all the same interests in Star Wars (but not Star Trek!) and is rich being caught off guard because "there are no women to date!"
Stop looking for developers that are willing to take a pay cut and know exactly all the things you are looking for in a candidate (especially the technically incorrect ones like 10 years with PHP 7) and surprise, you'll find there are lots of people that fit that category!
Anons need not reply. Questions end with a question mark.
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.
... That's what companies believe they are losing on junior devs. ...
... but "investing in"
HR works for management. They get the requirements for jobs from management.
Blaming HR is complete nonsense.
I know, I've heard managers blame HR but it's because they are too chicken shit to fess up to their incompetence.
Every manager wants to have people to "hit the ground running" so they can make the deadlines that were forced upon them by their managers or deadlines they over promised to get their bonuses at the end of the year.
See, most tech managers are former techies who went to some weekend classes taught by charlatans and therefore are completely incompetent. This desire for "rock star" programmers is to cover up for unskilled and incompetent management.
People like to pick on managers here, but a competent and skilled management team can do wonders.
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.
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.
Junior developers generally need good specs, narrow goals, well specified tools, well-defined tests, etc.
And those are *exactly* the sorts of tasks that are very amenable to out-sourcing.
It's pretty hard for companies to justify spending $60K on a junior developer, when they can purchase the services of someone with roughly the same skill set for $10K and get fairly similar results.
Of course, foolish companies feel they can also replace the $100K developers with a $10K developers, but that generally ends in tears fairly quickly.
When I can hire an experienced foreign worker for the same amount?
“Common sense is not so common.” — Voltaire
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.
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.
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.
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.
Dewey, what part of this looks like authorities should be involved?
Taking on a fresh developer takes a lot of resources - not only do they need to learn company routines, all the tools, how to work with teams and how to actually do development in a non-school setting, but they also need to learn how to actually work: Show up, what's not acceptable for taking days off, how to interact with all sorts of internal and external stakeholders etc.
As the average time a developer spends before switching jobs decreases - apparently Job Hopping Is the 'New Normal' for Millennials - the commitment from companies will go down too. Why spend a lot of time and resources to groom someone if he's probably going to leave anyway? Why not just get someone who's past that in the first place?
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.
just copy and paste the full job description in white text at 1pt in to your resume at the end.
> 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.
Companies in India make people sign a 3 year bond. The company will hire you and train you. The first year you are a drain on the companies resources but they make their money back in the next year and the third year is profit. The starting salaries are shit but you learn a hell of a lot. The kids are motivated and put in 16 hr days just so they can learn. Once they have doen 3 yrs in an Indian company (equivalent to 6 yrs in the US as they are putting in 16 hr days compared to 8 hr days) their salary is bumped up by 20% each year to keep them in the company or they are sent to the US for a 4-5X more salary. In this way an Indian company can retain a kid from graduation all the way upto his 30s while keeping costs pretty low. Around 30 these kids would now have greencards, families and enough skills and experience to go work for product startups, manage teams of vendor programmers or work for the client companies.
In the US by trying to ensure workers' rights of 21 yr olds we have removed the bottom rung of the ladder. Rights are useless without a job
**Life is too short to be serious**
Fizzbuzz isn't a selection test, it's a deselection test. You don't ask a candidate to implement Fizzbuzz to show you that they're competent, you ask it to show that they're not incompetent. It filters out the people who wrote '10 years C++ development' on their CV but don't actually understand for loops and if statements. Anyone with more than a couple of weeks worth of programming experience should be able to do it.
The problem for people hiring is that a lot of people that make it to interview can't - and if you can't implement Fizzbuzz then you're not going to be able to write any nontrivial software.
I am TheRaven on Soylent News