Live data from Hacker News

Who Killed the Junior Developer?

medium.com

781–790 of 803 posts

Re: Who Killed the Junior Developer?

#781
post #80

Earlier quoted context omitted.

You can lead a horse to the water but you can't make him drink. It's completely okay to "just" do your job professionally. However, skill development, transfer of skills to junior developers and mentoring is a different issue - if you want to learn from me, you have to want to learn; if you're just here for the paycheck, then I'm not going to go out of my way to educate you even if (which is the case for many junior…

This. Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did. This is good, this should be that, name your variables better, etc. If you let juniors figure it out the hard way, they will learn better, or they will fail. If they fail to learn by themselves, they will never become senior.* *Shitty code bases should be given a lot of leeway…

> Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did.

That's one (totally fine) way of mentoring, but it's by no means the only one.

A lot depends on the work environment and the relationship. I work with a couple junior engineers that are also friends, and in addition to "pointing people in a direction", code reviews, etc.:

* We frequently tackle harder issues together, pair-programming style (using a shared tmux session)

* In addition to code-reviewing their work, I have them code-review mine, and I walk them through my code and thought process

* Talks/meetings once a week or more about architecture/up-front design for projects, in which the junior devs are often included or free to attend

* We have a non-work-related Hackerspace that we attend every 2 weeks where we work on side projects / fun creative projects

Certainly this situation is not possible on many development teams, but I just wanted to point out that mentoring is a wide-open thing that has many approaches and options.

Re: Who Killed the Junior Developer?

#783
When I got started, Junior developers were assigned to senior developers doing maintenance programming. It was important work but it also gave you time to come up to speed on the system without the crush of new feature development deadlines. Sadly, it seems that not only do companies not do that these days but the new breed of developers seem to think they are too good to do maintenance programming. I learned a great deal about how systems really work and how to write robust software from some great mentors who had been moved to maintenance work as they neared retirement but companies these days are quick to lose older developers in favor of less experienced and less expensive younger developers. Lots of tribal knowledge is lost in that fashion every year.

Re: Who Killed the Junior Developer?

#784

Having recently had to do a lot of hiring and also played too much FIFA, I couldn't help but wonder if a argument couldn't be made for software engineering job contacts to work more like soccer player contracts. One issue is you might hire a junior dev, train them and just when they start to provide value BigCorp makes them an offer they can't refuse and you are left with the bill. If on the other hand the was a cont…

That is pretty ripe for abuse - junior developers take whatever since the first job is critically important to get, and then have zero negotiation power since it costs an exorbitant amount of money to "poach" them and pay them their fair market value. I mean, yeah, it'd be good for employers. Not so much for employees. Likely an illegal or unenforceable contract, too.

Why would it be illegal or unenforceable for software development but legal and enforceable for sports?

Re: Who Killed the Junior Developer?

#785

Earlier quoted context omitted.

What city?

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

"The City" - also refers to NYC if you are in the surrounding area, refers to Manhattan if you are in an outlying Borough, and refers to San Francisco if you are in the outlying Bay Area. I am sure there are more :)

Re: Who Killed the Junior Developer?

#787

Earlier quoted context omitted.

That is "coding fast". Coding fast doesn't mean literally churning out a lot of code and pull requests.

Managers often have trouble recognizing the difference, though. Even if they know the difference, measuring actual productivity is difficult and subjective, measuring number of pull requests or number of JIRA tickets closed is easy and objective.

> easy and objective.

that’s the worst kind of data - gives a meaningless feeling of objectivity.

Re: Who Killed the Junior Developer?

#788

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

I'm not sure what juniors you talk about, but most juniors I've met can code "barely enough", get stuck often and code pretty bad so the pull request will stay there for quite a while before all corrections are applied

Re: Who Killed the Junior Developer?

#789
post #762
post #412

Earlier quoted context omitted.

This doesn't work if you need help and resources to find solutions to said problems. You cannot solve everyone else's problems and implement solutions for them. You can suggest solutions, but someone has to give the okay and devote the time to implementation. If every problem you see requires you to submit a lengthy solutions proposal to the people who should be solving it themselves, you'll get burned out.

No, but you can solve the problems you can solve. That will give you currency to buy respect, trust, and responsibility. I'm not suggesting you shouldn't do anything without getting permission first, but for the things you do need permission for, the above advice might help.

Do you really want to use that currency to buy, trust respect, and responsibility for things outside your job description?

You have to watch out that a "go getter" attitude doesn't result in you just getting overburdened.

Re: Who Killed the Junior Developer?

#790
post #358

Earlier quoted context omitted.

Those headphones only block constant background noise, not conversations . In order to do that you have to put your hearing at risk with enough actual noise to overwhelm the rest.

I have tried some decent quality ones. They don't block out conversations completely, but it does sound a lot quieter. They are definitely an improvement over not wearing them.

I think he meant "conversations" as in someone walking up and interrupting you to have a conversation
Post reply on HN