Who Killed the Junior Developer? • Hacker News Board

Re: Who Killed the Junior Developer?

#591

Post by ethbro » Wed, Feb 14, 2018, 5:44 PM UTC

logfromblammo wrote: post #553

devopsforlyfe wrote: post #523

Earlier quoted context omitted.

You are confusing senior devs and rockstar devs. Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team…

You hire the rockstar to write version 1. That's the one that gets you to market fast, and the one you should be planning on throwing away. It's the one you keep in production as your non-rockstar ninja and guru coders write version 2 from scratch. Once you release version 2, you really need to fire your rockstar. They will never be happy in maintenance mode, and that's fine, because they're usually bad at writing fo…

Well said. Especially the "Version 2/3" part.

I think the never getting there often happens because management isn't aware of the current quality of their software vs hypothetical quality of a rewrite.

And I get it: I imagine every one of them has been burned by an overly optimistic developer. "It'll be rewritten in 3 months and run 2x as fast" types.

As a discipline, inculcating "respect that the years of person-work in the current version weren't done by idiots solving unimportant niche use cases" would be very healthy.

Re: Who Killed the Junior Developer?

#592

Post by cptskippy » Wed, Feb 14, 2018, 5:46 PM UTC

nathanaldensr wrote: post #6

I love mentoring. I always have. I used to help out other kids in my high school programming classes. Despite holding several high-level software development positions, what is the total number of times I've been asked by management to mentor more junior folks? Zero. I did it because I love sharing knowledge and I like seeing looks of understanding appear on my colleagues' faces when they "get something" for the firs…

> The short-termism that's infested our culture--it seems like all Western culture--is truly sickening. It feels like "Well, I got mine, screw the next generation." This goes way beyond just junior developers.

This is a byproduct of the erosion of loyalty that's pervasive in business these days. Businesses use to be loyal to their employees and in return their employees were loyal to them. That's no longer the case because over the last 30-40 years businesses have shown they aren't loyal to their employees.

Pensions are gone in favor of the 401k scam with many employers no longer even matching contributions. Medical Benefits get worse every year while the cost to the employee rises. Merit increases are virtually nonexistent and in many cases you're lucky to get a cost of living increase.

Why would an employee have any loyalty to a company that treats them like a commodity? It's gotten to the point that many functions are just outsourced to another company (e.g. HR, Maintenance & Facilities, Administration, IT). The staff are employed by the contracting firm and thus they are a fixed unit cost commodity and there's no long term obligation to them.

Re: Who Killed the Junior Developer?

#593

Post by Caveman_Coder » Wed, Feb 14, 2018, 5:46 PM UTC

madamelic wrote: post #577

bobthechef wrote: post #366

Really? The "killing" of the junior developer seems like an anecdotal claim. Hasn't ageism been a concern here on HN? Doesn't that tend to suggest that older, and thus more senior developers are "discriminated against" in favor of younger, CHEAPER labor? The reasons being that either: - you don't need a senior developer for your needs - you can't fork out for a senior developer - you could really use a senior develop…

>- you don't understand the difference between a junior and a senior developer I think it is this. The title Sr Engineer is handed out constantly to people with little to no experience. You are basically Junior for a year then you get the title change. It is a bit absurd. So yes, there is a shortage of Jr engineers... but there are plenty of not very good Sr Engineers who should be Jr Engineers.

You're absolutely correct on this point. My first job after obtaining my CS degree was "Senior Developer" even though I had never developed software professionally before. I got the Senior title because the company had their pay buckets tied to titles so in order for the company to bring me on at the rate I requested, they gave me the Senior title. Titles apparently are nonsense, at least from what I've seen.

Re: Who Killed the Junior Developer?

#594

Post by jacquesm » Wed, Feb 14, 2018, 5:47 PM UTC

nawitus wrote: post #573

jacquesm wrote: post #363

Earlier quoted context omitted.

That's a silly generalization. I've got a pretty good overview of software development in Western Europe and NL isn't a special place for better or worse compared to the surrounding countries. If you want to get paid a lot more and you have the right skills the City or Silicon Valley are good options (assuming you are allowed to move there).

What city?

"the City": London's financial services sector.

Re: Who Killed the Junior Developer?

#595

Post by alistairSH » Wed, Feb 14, 2018, 5:49 PM UTC

runedog wrote: post #441

vinceguidry wrote: post #364

There were never any junior dev jobs. You have always had to lie, cheat, and steal your way into the field. I have a buddy who legit cheated his way to the top Magento certification and now cycles through $150k+ jobs where they keep him on long enough to realize he doesn't have any coding skills then they fire him. Reason is software is always an ancillary concern to the business. You see this in other fields, like s…

What do you suggest for those of us who believe we would be terrible at management? Add to that, I also think I would be miserable doing it.

Find an employer that values career programmers? We have a "Technical Fellow" career path for devs/engineers/architects who want to remain in a technical role beyond the typical "tech lead" or "principle whatever" roles.

Re: Who Killed the Junior Developer?

#596

Post by Fradow » Wed, Feb 14, 2018, 5:50 PM UTC

jfasi wrote: post #176

mgenglder wrote: post #154

Earlier quoted context omitted.

I'm curious about what the common deficiencies that your encountering are. Do you mean lack of knowledge and testing and more applicable skills?

Unfortunately I can't share the exact questions we ask, but here's a smattering of the sorts of pitfalls I encounter, in no particular order: * Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess…

From what you asked, I can deduce you work in an environment where performance is important.

For my startup (and I'd say at least a non-negligible number of companies), half of what you ask is just not important.

Background to read what follows: small 5-year old startup with 2 developers, which don't do anything "complicated" like ML, computation or things like (mostly apps, with a CRUD back-end).

I'll try to rephrase as what I'd expect instead:

* Big-O is not important there. What you need to know is to have some knowledge to how to leverage your DB to do things instead of looping yourself over data just queried from your DB. And that's not number one.

* Edge cases is actually a valid concern for every programmer, no matter the field

* it might be useful to have a rough idea of what you expect to offer a proper solution, but it's generally pretty obvious

* justifying a solution is also a valid concern for every programmer, no matter the field

* manually doing operations already handled by your framework/library is a red herring, barring very specific situations that require an explanation. Be it sorting, filtering or whatever.

Bonus point

* bringing manual parallel processing reeks of premature optimization (as an environment where performance isn't generally a problem, remember). It has to have a real explanation, and other obvious optimizations have to be done already. So far, I've never reached that point in my professional career (but tools I use DO use parallel processing, I just don't roll it out myself, that would be NIH syndrome)

* don't forget caching! If the cache performs badly, it's time to start investigating why, but you don't need to worry about cache performance if you don't do crazy things, for the most part.

* Testing is also important wherever you go, but I also let this one slide because entry-level candidate aren't teached that in school, unfortunately.

Re: Who Killed the Junior Developer?

#597

Post by laythea » Wed, Feb 14, 2018, 5:52 PM UTC

shabangcohen wrote: post #578

jmvoodoo wrote: post #381

Earlier quoted context omitted.

My "standard" team typically has two jr engineers, and two Sr engineers. When we hire Sr engineers we hire people that like to mentor others and see it as part of being Sr. Jr engineers know that in order to become Sr one of the skills they need to master is mentoring. This is 100% a management issue, and it starts at the hiring filter. Hiring Jrs btw is its own skill as you are filtering for potential not skill or k…

As a woman currently applying/interviewing for a new grad role, I think you're definitely right about most companies caring only about current knowledge/skill.

Why is that bad? Jobs should be filled based on skill/knowledge. (The ability to learn is a skill too, one that means what you know currently matters less). I take slight offence to your statement. Why is being a woman relevant to anything, unless your company is going for 50/50 male female. But in my opinion that is wrong, and amounts to sex discrimination against men, because if 50% of roles are filled by men, even if there is a better male candidate, then the female will get the role. (And vice versa, but that is generally not the case in my experience). This is wrong. It's about what the person can do, not evening numbers. Sex discrimination gone mad!

Re: Who Killed the Junior Developer?

#598

Post by mixmastamyk » Wed, Feb 14, 2018, 5:52 PM UTC

wccrawford wrote: post #497

apthnz wrote: post #138

Earlier quoted context omitted.

As someone starting to teach myself how to code, I'd be interested to hear more about the basic coding tasks people are failing at.

We have a pre-interview test that is basically "use flickr's api to show some pictures", with a few details about how the pictures are sized and arranged. Applicants that have gone to bootcamps and even college frequently fail this miserably. Many of the rest fail to understand the details. We even had one use a completely different end point than the one specified by URL to the documentation. Some have just given up…

I think teaching is a bit behind on the rest api thing, probably isn’t specifically taught. Doesn’t mean they couldn’t learn it.

Why do you refuse to mentor a few of them? /s

Re: Who Killed the Junior Developer?

#599

Post by dsfyu404ed » Wed, Feb 14, 2018, 5:54 PM UTC

megaman22 wrote: post #482

ams6110 wrote: post #478

Earlier quoted context omitted.

> accountants leave school fully capable of employment Well, fully capable of entry-level employment. Anyone who graduates from a reputable school with a Comp. Sci. or InfoSys type of major is also fully capable of entry-level employment. Accountants aren't really capable of anything but grunt work until they pass the CPA which normally is after several years of grunt work and additional learning and study. Programme…

> Anyone who graduates from a reputable school with a Comp. Sci. or InfoSys type of major is also fully capable of entry-level employment. No, they're really not, for at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally useful…

>or at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally usefu

A year?!

You're either scraping the bottom of the barrel for new hires, have a terrible on-boarding process, over-estimating the difference between the code someone fresh out of college writes or have absolutely terrible documentation or some combination thereof.

I'm leaning toward on-boarding and/or documentation. Junior devs are the ones who most need documentation because they're not gonna be able to infer the existence of policy and best practices from existing code and procedures as well as a senior dev will.

Either you and your HR is doing a terrible job giving new hires a lead on what to be asking and where to find information or that information just doesn't exist outside of the heads of existing employees.

I work at a CDN. We have plenty of issues with legacy code, cumbersome interactions between business units, outdated policies/docs, lack of documentation on stuff and all the other BigCo problems.

A huge chunk of new hires at any time are fresh out of school. It takes ~3-4mo before they're dealing with stuff on their own with perfectly fine results.

People aren't idiots but they don't know what they don't know. People with more experience are better at knowing when there's something that they don't know. Fix your process and you'll be able to get good value for junior devs.

If you don't fix your process don't whine when someone who has business practices that let them deliver the same results at lower cost by utilizing cheaper labor comes along and undercuts you.

Re: Who Killed the Junior Developer?

#600

Post by Caveman_Coder » Wed, Feb 14, 2018, 5:54 PM UTC

sidlls wrote: post #125

whiskyant wrote: post #113

Earlier quoted context omitted.

I don't think dedicated mentorship is required for junior devs. There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.

Junior programmers may not (even probably don't) have a good idea of what questions to even ask. Younger juniors (e.g. right out of college) may even feel intimated or anxious that their question is "stupid". This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy. Reliance on online resources is, in my view not a s…

> "This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy."

I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.