Live data from Hacker News

Who Killed the Junior Developer?

medium.com

231–240 of 803 posts

Re: Who Killed the Junior Developer?

#231

In an industry, glorified itself with automation, it is not really that hard to find out the automation first happens within itself.

There are always higher abstraction levels and new problem domains. If you lose your job to automation as a software dev, you've gotten complacent. Put junior devs to work on the new stuff, not what you started on yourself.

Junior dev needs to establish trust before they can be put into the 'new' stuff. They are called junior, for a reason.

Ultimately, this industry now has enough people to spare, impact is what everyone is fighting for, this applies for junior dev as well.

Re: Who Killed the Junior Developer?

#232
post #125

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…

Totally agreed. This is, in essence, what I would define as the line between "junior" and someone escaping it.

Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.

Re: Who Killed the Junior Developer?

#233
post #125

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…

Ask the right question is a skill, and a good indicator for growth. If you have an ineffective team member on your team, you will know the pain. Junior dev isn't necessarily bad, some of them can ramp and contribute really fast, but some are just lacking.

Re: Who Killed the Junior Developer?

#235
post #152

Earlier quoted context omitted.

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…

Agile doesn't really foster collaboration in general. You can't have one ticket assigned to two developers and have them pair program, from the business perspective rather than the best way to develop inexpensive new talent pair coding is a massive waste of time and resources. However agile works really well for remote workers who have little social contact outside of the daily standups and slack. It helps to be an a…

Actually you can have a ticket applied to more than one person in an agile process. You must've been thinking of Scrum in particular which does not allow the practice.

(The original agile process called Extreme Programming actually mandated pairs.)

Indeed, a task not budgeted in time is not done. That pertains to tests, static quality analysis, performance optimizations and use case analysis. None of these are explicitly budgeted in agile processes, though they say "write tests" or "definition of done", these are taken as suggestions.

Re: Who Killed the Junior Developer?

#236
post #176

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…

These are pretty hard questions for an average junior role. But depends on a company.

Re: Who Killed the Junior Developer?

#237

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…

Full disclosure: I work at Dropbox. Dropbox is a company that values mentorship. It is something that is explicitly called out and rewarded in performance evaluations, and it's one of the reasons I chose to accept the job offer from Dropbox. I have been lucky enough to work at a place that pushed me to be a mentor, and another place where I got to influence culture to value mentorship, and I have seen junior developers who barely had any idea what they were doing and needed lots and lots of guidance, grow into some of the most amazing and capable engineers I've ever worked with.

Re: Who Killed the Junior Developer?

#238

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

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 no concept of a team to me?... Which makes them no-hire types at my job. I help people regardless of what they're working on. If any of us fails it affects all of us in the long run.

I love programming and helping others achieve it and working with others to learn is one of the better and more fun parts of it.

Re: Who Killed the Junior Developer?

#239
post #173

Earlier quoted context omitted.

The impression I got was not that he was inferring that short-termism has infested culture due to the fact that he is no longer able to mentor junior devs. I believe he was saying that short-termism (which his belief is everywhere and I assume he has this opinion based on external beliefs not listed here...) is the root cause of this. Not many people hire junior devs anymore. I tend to agree with him, and believe it…

Implying management isn’t tech? You mean isn’t engineering? (Well, people engineering....)

It isn't tech nor engineering nor science. Managers do not properly and scientifically measure their performance or performance of their teams. Nor run proper experiments on management practices.

Re: Who Killed the Junior Developer?

#240
post #176

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…

Most of these things are not “junior” level at all. There are exceptional people though and I suppose it makes sense for you to try and hire those. But large amounts of disappointment are very much part of the process then.
Post reply on HN