Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Who Killed The Junior Developer? ( 386

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.

This discussion has been archived. No new comments can be posted.

Who Killed The Junior Developer?

Comments Filter:
  • by Qbertino ( 265505 ) <> on Sunday February 18, 2018 @12:44PM (#56147344)

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

    • Killed themselves (Score:5, Insightful)

      by Spazmania ( 174582 ) on Sunday February 18, 2018 @01:25PM (#56147522) Homepage

      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.

      • by whoever57 ( 658626 ) on Sunday February 18, 2018 @02:40PM (#56147906) Journal

        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.

        • by Jeremi ( 14640 ) on Sunday February 18, 2018 @03:18PM (#56148084) Homepage

          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! :)

          • That sounds like a great idea if the amount you'd save on the new tech is likely to be greater than or equal to the cost of experimenting and migrating from whatever is happening now.

            • If youâ(TM)re not taking time to experiment and find what will work for your company, then you are destined to fall behind and lose to a startup who will do it faster and cheaper because they donâ(TM)t have the legacy technical debt to deal with.

              • For a modest sized company (36 servers if you will recall), cloud management systems are not a competitive advantage, they are a risk to be managed carefully.

                It is not incumbent on every organisation to try every new technology that covers everything you do, especially in a space as crowded as cloud management. If you have a solution that works well enough at your scale, you may be better off letting those who can afford it to learn, and then learn from them.

        • by Spazmania ( 174582 ) on Sunday February 18, 2018 @05:18PM (#56148656) Homepage

          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.

        • by Actually, I do RTFA ( 1058596 ) on Monday February 19, 2018 @02:29AM (#56150606)

          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.

      • by raymorris ( 2726007 ) on Sunday February 18, 2018 @03:24PM (#56148116) Journal

        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.

        • by raymorris ( 2726007 ) on Sunday February 18, 2018 @05:06PM (#56148584) Journal

          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.

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

          • Wiki documentation (Score:4, Insightful)

            by raymorris ( 2726007 ) on Sunday February 18, 2018 @09:21PM (#56149786) Journal

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

    • Not lack of experts, lack of competence. Schools aren't teaching good programming anymore, or extra domain skills. They all show up and think it's all supposed to be like web programming or apps.

      • It's a bit of both: you need students who are taught good programming, but no matter how good their education, it's unlikely that they will be familiar with all of your tools and procedures. They will need some serious handholding.

        "we don't hire junior developers because we can't afford to have our senior developers mentor them"

        This is why I quit my last employer around 10 years ago (been freelancing ever since). At the time, I was a medior dev. I don't consider myself to be a senior developer even though that was my job title. I maintain that my former employer didn't have any senior devs because th

    • Because companies don't plan long-term anymore, the lack innovation power in the short and mid-term.

      Of course they do, to think otherwise demonstrates a poor understanding of how the game (business) works: The vast majority of investors only care about growth in the long term; if they thought a company wasn't going to be around in the long term, they wouldn't invest in them and instead they'd be more likely to short them. Kind of hard to raise capital that way, don't you think? Sure, there are companies built to bilk investors, but companies like the one mentioned seem unlikely to do this. Personally, I'm

  • by edgedmurasame ( 633861 ) on Sunday February 18, 2018 @12:49PM (#56147358) Homepage Journal
    Tata, Accenture, Cognizant, Infosys, IBM Global, and other firms have contributed greatly to the decline of junior developers.
  • H1-Bs did (Score:5, Insightful)

    by rsilvergun ( 571051 ) on Sunday February 18, 2018 @12:50PM (#56147370)
    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.
    • 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.

      Agree completely with this. And an additional irony is many of the people hired through this program are very junior people marketed as "experienced".

      • Re:H1-Bs did (Score:5, Insightful)

        by Darinbob ( 1142669 ) on Sunday February 18, 2018 @02:38PM (#56147894)

        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 (Score:5, Insightful)

          by magzteel ( 5013587 ) on Sunday February 18, 2018 @03:31PM (#56148132)

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

          • Re: (Score:3, Informative)

            by Anonymous Coward

            I agree. My company doesn't hire local junior American developers. Management would rather hire cheap "preferred vendors" like TCS. Their skills are weak. As an experienced American, when I "fix" their bugs, I am (1) training foreign workers and (2) I'm reinforcing the notion that foreign outsourcing is working.

    • they can also set an low pay rate the USC will not take say $50K in the bay area for an 50+ hour work week. to get an H1-B in as well.

  • Void in the middle (Score:4, Insightful)

    by sanf780 ( 4055211 ) on Sunday February 18, 2018 @12:56PM (#56147386)
    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?

  • by Gravis Zero ( 934156 ) on Sunday February 18, 2018 @12:57PM (#56147388)

    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!

    • HR is not to blame (Score:3, Informative)

      by Anonymous Coward

      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

      • Hiring good people is a critical competency. It is what separates great companies from mediocre companies. It is amazing how many companies assign tech resume screening to a 22 year old HR intern with a liberal arts degree and a nose ring.

        • by AmiMoJo ( 196126 )

          They need to accept that it takes six months after you hire someone for them to learn the company systems, full any gaps in their knowledge and become the employee that the company wants.

        • Oh I believe that. I used to see lots of really great candidates in the past, and we could afford to be picky. Then at a different company we'd get totally incompetent people who couldn't answer simple questions about programming.

      • HR are the people who convert "I need a junior person" into "5+ years experience with C, network experience required, AI proficiency a plus, and ability to work unsupervised on the company's critical infrastructure."

        I've seen my director look at job postings and be confused about which job the position is for since they don't match anything he requested.

        • So, what you're saying is, I should ignore the requirements and apply anyway?
          • To be honest, going through HR automatically gives you a lower chance of getting the job, versus going in via a reference to the hiring manager, or friend-of-a-friend, or other networking. If a hiring manager tells HR, "here, take a look at this resume and set up an interview" then that works well; but if the resume first shows up at HR then unless you've hit all the buzzwords and have tons of experience, it may just sit on file for a very long time.

      • by teg ( 97890 )

        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.

        And how does management know what to ask for? The ones I've worked with don't just pull that out of thin air, they either ask their team - often starting on what worked last time, just use what they asked for last time or gives the CV of some of the guys they've had good experience with to HR, with instructions to adjust it a little in a direction ("Like Ann, but a couple of years younger"). If I'm writing from scratch, I list up some skills I want, the background I want and meet the candidates.


    • Re:It's very simple. (Score:5, Informative)

      by Billly Gates ( 198444 ) on Sunday February 18, 2018 @02:18PM (#56147774) Journal

      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

    • Unfortunately, we don't often get a lot of open job reqs. We NEED a senior person, and would like to have one or more junior people who can grow into the job, but we get one slot only. We can't afford to be teaching someone remedial programming.

      • If you NEED a senior person and don't have 1-2 mid-level positions that are learning what they need to be senior developers at your shop, you are probably doing it wrong. And 1-2 junior developers for each mid-level position. If we continue to not train and mentor and teach from the junior level on up, we are not going to HAVE any senior developers.
    • What is with the bizarre derailment into man-shaming? Boy, that really came out of left field.

      The men I know who are below average know quite well that they are below average. They're not hitting on the pretty girls. In fact, due to constant negative reinforcement, they're not hitting on anyone at all. They stay at home with computer games and porn and sex dolls and cry themselves to sleep at night. But go ahead and speak truth to the powerless, my socially just friend. Comfort the comfortable, afflic

      • Oh dude, clearly you have never met incels. It's not exactly common but it's also not a strawman. There are even incels of above average looking guys out there who are so brainwashed with severe body dysmorphia that they think they're hideous.

  • Interships (Score:5, Insightful)

    by HockeyPuck ( 141947 ) on Sunday February 18, 2018 @01:03PM (#56147424)

    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 (Score:4, Interesting)

      by Vektuz ( 886618 ) on Sunday February 18, 2018 @02:48PM (#56147950)
      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.
      • Re:Interships (Score:5, Insightful)

        by SvnLyrBrto ( 62138 ) on Sunday February 18, 2018 @05:31PM (#56148708)

        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.

  • by QuietLagoon ( 813062 ) on Sunday February 18, 2018 @01:05PM (#56147438)

    ... That's what companies believe they are losing on junior devs. ...

    ... but "investing in"

  • They want experienced developers just out of school. "Long-term planning" in these companies is equivalent to "What's for lunch?" Yeah... that'll go far.
    • Pretty much this. I applied for a position earmarked for college grads when I was a semester away from graduating. I was told I needed more experience.
  • by gurps_npc ( 621217 ) on Sunday February 18, 2018 @01:17PM (#56147482) Homepage

    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.

    • by AmiMoJo ( 196126 )

      It's often just a scam to drive wages down. Ridiculous requirements that no candidate can meet, so they can advertise a good salary but offer you a much lower one.

      If you are a junior dev you can just apply for the more senior stuff on this assumption. That's how I got started.

    • Or it's an ad for a position that is already filled: by someone in the process of applying for a green card.

  • Offshoring and SaaS (Score:5, Interesting)

    by ErichTheRed ( 39327 ) on Sunday February 18, 2018 @01:23PM (#56147512)

    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 are good examples of 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.

    • Same thing here...some years ago they offshored all dev for our SAP and related systems. Ended up ditching the first firm they hired after the initial 3 year contract was up because, unsurprisingly they were terrible. Hired a different offshore provider, did the whole knowledge transfer thing, and now it's a few years later and people are finally starting to realize that they are terrible.

      Management shake-up...which is that the PHB's in charge left/were pushed to roles at other companies (to screw them

  • Junior AutoCAD drafters are no longer required because the software automates many of the tasks that they used to perform. So, insufficiently-experienced juniors get "promoted" to more senior positions while the old farts get laid-off because why not? They're too expensive anyway.

    Well, this is what happens if the work hasn't already been offshored to India or China in the first place.

    Ever try mentoring someone who is 12 time zones away and asleep while you are working?
    • Junior AutoCAD drafters went away once (sufficient) Junior Engineers came into the workplace and knew CAD and could draft faster than they could mark up drawings. Senior drafters stuck around, as they could work from less robust markups.

      Revit creates more jobs though (despite the automation), because it automated the wrong things. It does make it harder for junior level people to be useful though, as all the automated data requires more knowledge to be able to do anything.

  • Senior Tools (Score:5, Insightful)

    by holophrastic ( 221104 ) on Sunday February 18, 2018 @01:36PM (#56147570)

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


    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.

    • Explain what you mean by "API"? There's a building I see that once had a banner saying "We love APIs!" which I thought was the stupidest thing ever, and I suspect it was a software group (ie, backoffice, programming mostly being customizing existing components). We've had APIs since the 70's though, what about them now makes them a "tool"? An API to me is just an application programming interface, big deal. You create one so that you and your cubicle neighbor have a common way to have their code work tog

    • by bosef1 ( 208943 )

      We've encountered the same problem as your Second in my organization as well: senior engineer's time is too valuable to spent teaching the ropes to the very junior employees; so our rationally-acting senior employees don't do it.

      Part of it is our management failing to make "mentoring junior employees" part of the senior employees' evaluations (but that's just management acting rationally, and prioritizing "productive" over "non-productive" work). I hypothesize this defect is being revealed, in part, by our

  • If we had unions with apprenticeships! and then we will not have this issue.

  • ...the fact that even at a low wage, heck, even free, a junior developer is going to cost so much of a senior's time to mentor and clean up after that they end up being really expensive.

    Then when they get to be worth a shit, instead of sticking around for you to recoup your investment, they rationally take a job at higher pay somewhere else. You could raise their wage to keep them, but there's no incentive to train them up then. Why would I invest in a junior when I can poach a senior?

    The only way I got i

    • by ghoul ( 157158 )

      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 bu

  • The story summary after this one has the following headline: "US's Greatest Vulnerability is Ignoring the Cyber Threats From Our Adversaries, Foreign Policy Expert"

    A quick skim of the comments on Slashdot shows almost all the Anonymous Cowards and a significant number of the identified commenters think it's the job of the US government to get the hell out of the way of business and watch it turn America into some kind of libertarian utopia.

    Sadly, this is what happens instead. Business won't provide entry

  • The other things people mentioned are certainly a factor. But I think another factor is education. The "computer science" degree is what people normally study to go into a programming profession. But I've found the education typically rather lacking... people coming out of schools may know a couple interesting algorithms, but they don't know anything about software design, architecture, communication systems, or teamwork/planning. In addition, no one really learns how to be a true "author" of software.

    • Unfortunately, so many businesses require a Computer Science degree that it's difficult to get a job without one. And the colleges aren't interested in teaching the nitty gritty for the job details, they're more interested in teaching the fundamentals and abstractions behind code. Which means that CS grads, like myself, graduate with an understanding of how things work, but not much experience in making them work. That's why junior positions are so critical to fostering them from degree holders to developer
  • by Average ( 648 ) on Sunday February 18, 2018 @02:26PM (#56147828)

    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.

  • I recently retired (as a senior developer) from a very large technology company that, in recent years, pretty much ONLY hired "junior developers". "Recent College Graduate" was the term used, and even then it was difficult to find promising candidates. The company also "strongly encouraged" hiring of women and "underrepresented minorities" (that is, not from India or China). I was not a hiring manager, but I did interview candidates and reviewed CVs - nearly all of them were from foreign-born applicants.


  • by west ( 39918 ) on Sunday February 18, 2018 @03:08PM (#56148046)

    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.

  • But on the senior level companies complain they can't find good developers.

    I'm a senior developer. Here's the problem as I see it in the senior recruitment arena: The majority of company HR departments and recruiters are bad at recruiting senior developers.

    The modern tech landscape is filled with hundreds of different technologies technologies and tools. HTML, CSS, Javascript, hundreds of Node modules, PHP, Ruby on Rails, Linux, Windows, OSX, C++, Java, Python, Go, Rust, Perl, Git, Agile, Waterfall,....

  • by OrangeTide ( 124937 ) on Sunday February 18, 2018 @03:22PM (#56148104) Homepage Journal

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

  • by RhettLivingston ( 544140 ) on Sunday February 18, 2018 @03:27PM (#56148120) Journal

    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.

  • They just don't call them "Junior Developers" any more, it's considered demeaning. Just like we can't call people "janitors" or "secretaries". In IT we call them things like "Network Administrator 1" or "Systems Administrator 3" to create pay bands and allow for personal professional growth. We use a matrix to tie things like traditional education, industry certifications, years of professional experience, annual evaluations and tenure with the organization to move them up.
  • It's up to us (Score:4, Insightful)

    by Just Some Guy ( 3352 ) <> on Sunday February 18, 2018 @04:03PM (#56148272) Homepage Journal

    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.

  • Decades ago, when the Earth was young and we slew the dinosaurs with our might slide rules, I attended a Digital Equipment Corp symposium. There was a Q&A session there with the leading lights in real time device driver development, including the maximum leader of device drivers, Ralph Stamerjohn. During the Q&A, a user in the audience, concerned about training new real time driver writers, in environments where mistakes can be deadly (he worked with industrial robots)., asked "What should be don
  • by teg ( 97890 ) on Sunday February 18, 2018 @04:23PM (#56148384) Homepage

    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?

    • by swilver ( 617741 )

      People leave because companies don't pay them what they're worth. A person that knows all your systems is worth much more than a similarly skilled person that is starting fresh, yet they're often paid the system with a small margin of error (a couple of 2% raises each year).

      So this person takes their new skills, applies somewhere else (but this time as a medior developer) and gets an instant 20-30% raise.

      Explaining your reasoning to your manager / boss / HR drone results in *NOTHING*. But stuff often sudd

Prototype designs always work. -- Don Vonada