Live data from Hacker News

Who Killed the Junior Developer?

medium.com

301–310 of 803 posts

Re: Who Killed the Junior Developer?

#301

> we don’t hire junior developers because we can’t afford to have our senior developers mentor them. That feels too dumb to be real (which is exactly why it's probably a real thing). You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too! You hire senior devs to guide you WHAT and HOW to code. And they can do that so much more effectively if they don't have to…

Actually, the cost of mentoring is not necessarily only cost of lost productivity. Sometimes (I hope, more likely mostly) there are pieces of old, arcane, barely and wrongly documented pieces of codebase that there is exactly one senior in the company who knows how it works. Assigning said senior from coding literally means pushing deadlines. So it is kind of tragedy of the commons.

This is probably the biggest difference between companies who excel and those who don't. Some companies get that employees are assets and training them is worth it even if they might leave.

Re: Who Killed the Junior Developer?

#302

Earlier quoted context omitted.

In my current job, for a tech company with less than 12 people, at least 5 are interns. Two of them were recent hires (January) and before they were onboarded, i had a meeting with my boss and the other senior developer regarding the new interns and my boss stated he didn’t want me and other senior dev spending too much time mentoring the interns and that if they couldn’t manage by themselves, he would just let them…

Is there no room to fight management or make them understand?

High probability of “not productive effort”, i’m fighting my own rather serious battle with management at the moment.

On further note, before i started the contract i was asked to bring my own laptop as work computer, i didn’t necessarily agree (for all the obvious reasons as security and business/personal risk) but he was being pushy about i said i could take my laptop (at least to get started) and i was expecting to get a working computer. I never did. Management recently purchased brand new macbook pros and iphonex for themselves (which they are in their full right to do).

So i didn’t even dare to criticize them regarding the interns. I already got myself in boiling water by criticizing management in that the way projects and tasks were being managed was highly unprofessional and my only wish is if i could leave a warning sign for interns (and devs) to keep clear of this company (or think really hard on how much they need the job)

Edit: which is unfortunate given that the projects there are interesting in my opinion

Re: Who Killed the Junior Developer?

#303
post #152

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…

I feel like the current trend of agile development process common in startups now somewhat works against senior devs' interests to mentor junior devs. There simply isn't time allocated for this. Senior devs are held accountable for what they deliver, and doing so on time. This is among other things like code reviewing PRs and attending meetings. For most senior devs working under this circumstance, the best they coul…

I have the same suspicions about the agile process as well. Great to be fast and producing but it's counter-productive if not everyone is at a similar level of output.

Re: Who Killed the Junior Developer?

#304
I recently put together a dev team from scratch. I specced it out as: One Senior Dev, one Project Manager, one Team Leader (an existing employee experienced in the company politics and able to manage), one Ops/Infrastructure role, and one Designer.

Needless to say it didn't quite work out like that. We ended up with two junior devs, one developer, one project manager, the ops guy, and the team leader. One of the people we interviewed for a Junior Dev role was actually pretty experienced (not enough for the Senior role though). Two of the devs could design well enough to be able to do the UI work. We're still looking for a Senior Developer. The team will need to learn as they go, but I'm able to cover for them enough so they can make mistakes (ahhh, the pleasure of being a CEO with a techie background).

I hope to continue bringing on new Junior Devs as the team grows and learns. Creating a pipeline of talent is essential to finding the best people. Because the best people aren't found randomly, they're trained and coached, built up to be the people that the team needs.

It's all about long-term planning rather than short-term thinking. I'm pretty sure that in about six months this team will be doing all the things we need it to, and in about 18 months we'll have lost (at most) one of them and the team will be exceptional.

Re: Who Killed the Junior Developer?

#305

Companies have woken up to the fact that for the most part people no longer stay in one job for more than a few years. Training junior people makes sense economically only if they get up to speed and positive productivity within a small fraction of the time they'll be with your company. Since a bad developer creates enormous negative productivity, it can be years before a new programmer's contributions are productive…

You shouldn't have this problem if you 1) hire for intelligence, drive, cooperation, and passion about the mission or opportunity, 2) give them continual opportunities to grow and take on increasing responsibility, and 3) compensate them appropriately (as a manager, privately reevalute title and comp every three months for the first year).

Of course, these are the same things (among others) that are true for every engineer.

There's an endless supply of juniors to choose from, so there's no excuse for a bad hire. If they leave for more money that you could have paid them, that's on you, too.

Do those things and you'll win their loyalty.

Re: Who Killed the Junior Developer?

#306
post #39

It is a tragedy of the commons scenario. Everyone wants senior devs, who were at one point junior devs. No one wants to train junior devs. The OP points out why: * cheaper to have juniorish work done overseas * juniorish work is automated away * juniors on a team slow it down (compared to a team of all seniors) So everyone competes for the senior talent. A more sophisticated long term analysis might look at the benef…

A key point that you're missing is that junior devs are likely to jump ship at least once in their career trajectory before they become senior devs. So yes, junior devs do need to be trained by someone , but if you're going to put in a lot of work and not receive much of the benefit, it's not in your best interest. There's a variety of reasons for why devs jump ship so often (including compensation), but unless you c…

Not just the risk of them jumping ship, the problem is that because mid to senior dev salaries are highly desirable it attracts juniors into the field who are not suited to the job but like the idea of working in the industry or the potential money in it. So, you spend time training a group of people where some aren't suited for the job but you spend a lot of time on them and the better ones leave quickly. If you don't pick the juniors carefully in the first place and if you don't have the environment and renumeration to keep the better ones from leaving then it's probably better to just not spend too much time on recruiting them. It actually might work well for a company that doesn't want or need a large dev team. Also, not everyone is good at mentoring, some of the best people are often self taught and some of them find it difficult to teach others.

Re: Who Killed the Junior Developer?

#307

> we don’t hire junior developers because we can’t afford to have our senior developers mentor them. That feels too dumb to be real (which is exactly why it's probably a real thing). You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too! You hire senior devs to guide you WHAT and HOW to code. And they can do that so much more effectively if they don't have to…

Actually, the cost of mentoring is not necessarily only cost of lost productivity. Sometimes (I hope, more likely mostly) there are pieces of old, arcane, barely and wrongly documented pieces of codebase that there is exactly one senior in the company who knows how it works. Assigning said senior from coding literally means pushing deadlines. So it is kind of tragedy of the commons.

That's like, a great motivation to assign said senior AWAY from coding! "Single points of failures" are your greatest enemy, your senior my get a better offer. Or might get sick. Or might get in a car accident. Why would you want to bet your entire company on a single person? I mean... sometimes you have to do it because there's no other way, but it's a big warning sign, and you should diligently work to get out of that situation ASAP. "Pushing deadlines" might very well be a price worth paying in a situation like that.

Re: Who Killed the Junior Developer?

#308
post #32

The growth of undergrand CS program enrollment is pretty insane, same with bootcamps. Lots of these people have no real interest in the positions outside of pay, which is fine for most careers. But in tech we put a lot of value on self learning and interest. I've definitely seen the number of new grad applicants and bootcamp grad applicants at least quadruple in the past few years. Most of these can make an Angular a…

That's something I have noticed too. In the 90s most people I worked with were genuinely interested in the work and often came from very eclectic backgrounds. Almost nobody had a CS degree. Now it seems a lot of people go into programming because it pays well and looks like a good career but they don't really care for tech. I definitely found the industry more fun in the 90s but that may just be the fact it's becomin…

During the dotcom boom there were a lot of people attracted to the industry that were ill suited to it. I feel it's a bit like that now again. Then the dotcom crash came and many of those people lost their jobs in the industry but it had a limited impact on those who had true skill and passion for the technology. The rest had go back to the kind of careers that suited them better, like real estate agents...

Re: Who Killed the Junior Developer?

#309

Earlier quoted context omitted.

Sounds like senior devs who can't even do teamwork. At my job I'm a junior and guess what I can ask a senior for help cause if my job fails they also fail because oh guess what? Its a team and we are all on the same boat and wait it gets better! I end up spending my own time helping out senior developers in places they get stuck! (Inconceivable!) Yeah sounds like a management team and a bunch of senior devs who have…

Completely agree, it should always be team first.

Now I will admit there are exceptions, if helping a junior (or senior : ) takes up your whole day (aside from just helping them get things up and running the first time) unless told to help them 'get it done' by upper management you might want to back off and let them get burned a little bit while you get your own work done.

Re: Who Killed the Junior Developer?

#310
post #198
post #135

Earlier quoted context omitted.

Code review is horrible way to teach. Especially with reviewers common in tech who just can't tell difference between differences of opinion and crappy code. Or difference between "how I would did it" and bad code.

If the reviewers are giving crappy code reviews, what makes you think they would be better at mentorship?

I it is different task. And you could assign it to different person.

Also, there is level of knowledge to be acquired about teaching and working with people. A culture that does not conflate code review with teaching nor talk about it as a primary means of how to deal with less experienced developers have better chance to develop that knowledge.

As in, admitting that those are different tasks is first step.

Post reply on HN