4 ms·

"Junior" might as well be an IQ classification.. How many people change their IQ? The reality is something nobody really talks about.. When a company doesn't w

by Rapzid 7y ago

"Junior" might as well be an IQ classification.. How many people change their IQ? The reality is something nobody really talks about.. When a company doesn't want to hire a "junior" it doesn't mean they don't want to hire somebody without X amount of experience in a tech stack or without X amount of experience in the industry.. They don't want to hire people bellow a certain aptitude. Many "juniors" will never be "senior". Even if they get the title and salary. We all know "seniors" in salary and title only. Some people are inexperienced "seniors" year one.

TeMPOraL 7y ago
Viewing it from this lens, it still doesn't make sense to sacrifice productivity of people "with aptitude" for the sake of expanding your hiring pool to include people "without aptitude". Instead of bringing down everything to the lowest common denominator, one can try to assign different types of work to people with different levels of aptitude (or care). (Personally, I feel what makes "forever juniors" isn't aptitude, but lack of care. I don't see it as flaw of character - the factors like structural anti-intellectualism in the industry, lack of enthusiasm due to work being meaningless, and that not everyone is into programming beyond it being a 9-to-5 job all contribute to some people not learning. This suggests to me that expecting people to learn and making learning part of their jobs - actual part, with paid time set aside for it - can overcome this problem.)
- nsomaru 7y ago
  > anti-intellectualism in the industry Could you expand upon this point?
  - TeMPOraL 7y ago
    A bit more here: https://news.ycombinator.com/item?id=21909816 https://news.ycombinator.com/item?id=21909816. But the gist of it is: the industry prefers to work with dumbest tools possible and throw cheapest bodies they can get at a problem, instead of expecting people to keep learning, improving themselves, and applying these improvements to their work. This article is an example of that - it advocates discarding advanced tools given to the programmer by Haskell, in favor of writing dumb code that's easily digestible for beginners. Most of the advice about avoiding "clever code" is a form of that too. I find it a penny-wise, pound-foolish approach, because when you do this trade-off, you're losing in two places. First of all, you handicap your skilled team members. But secondly, the cost (in terms of time, money and incidental complexity) of a project grows faster than linear with the number of people you get involved in it. It'll be O(n!) if you do it naively, O(n logn) if you arrange people into hierarchies, but the problems still grow faster than they're solved as you scale up. The alternative approach I'm encouraging is to make responsible but full use of the power of the tools you have, and if this goes over the head of some new hire, then teach them until they understand and can make use of that power too. Embrace and encourage learning as a part of this job (actual, expected, and paid-for part). Push the industry upwards, instead of dragging it down.
mikojan 7y ago
> How many people change their IQ? Literally all of them. However, if someone never progresses to "senior" they might've just lost interest in software development. People in general are remarkable at learning about subjects arousing their curiosity. This is an important fact, too, because environments can be designed specifically to foster just that. Not everything will be working for everybody, of course, and some might never develop an interest in that field again. But that's okay, too.
sanderjd 7y ago
This isn't forbidden knowledge, it's just not correct. People learn and grow with experience. Some projects can't afford to support many, or any, people in that growth stage. But lots of projects can afford it, and the investment in their growth makes sense. I think it is probably also true that some people never become competent enough for many projects, but in my experience that is diminishingly rare, whereas junior developers who are still developing their skills are extremely common (unsurprisingly, since more and more people enter the field constantly).

by Rapzid 7y ago

TeMPOraL 7y ago

Viewing it from this lens, it still doesn't make sense to sacrifice productivity of people "with aptitude" for the sake of expanding your hiring pool to include people "without aptitude". Instead of bringing down everything to the lowest common denominator, one can try to assign different types of work to people with different levels of aptitude (or care). (Personally, I feel what makes "forever juniors" isn't aptitude, but lack of care. I don't see it as flaw of character - the factors like structural anti-intellectualism in the industry, lack of enthusiasm due to work being meaningless, and that not everyone is into programming beyond it being a 9-to-5 job all contribute to some people not learning. This suggests to me that expecting people to learn and making learning part of their jobs - actual part, with paid time set aside for it - can overcome this problem.)

nsomaru 7y ago
> anti-intellectualism in the industry Could you expand upon this point?
- TeMPOraL 7y ago
  A bit more here: https://news.ycombinator.com/item?id=21909816 https://news.ycombinator.com/item?id=21909816. But the gist of it is: the industry prefers to work with dumbest tools possible and throw cheapest bodies they can get at a problem, instead of expecting people to keep learning, improving themselves, and applying these improvements to their work. This article is an example of that - it advocates discarding advanced tools given to the programmer by Haskell, in favor of writing dumb code that's easily digestible for beginners. Most of the advice about avoiding "clever code" is a form of that too. I find it a penny-wise, pound-foolish approach, because when you do this trade-off, you're losing in two places. First of all, you handicap your skilled team members. But secondly, the cost (in terms of time, money and incidental complexity) of a project grows faster than linear with the number of people you get involved in it. It'll be O(n!) if you do it naively, O(n logn) if you arrange people into hierarchies, but the problems still grow faster than they're solved as you scale up. The alternative approach I'm encouraging is to make responsible but full use of the power of the tools you have, and if this goes over the head of some new hire, then teach them until they understand and can make use of that power too. Embrace and encourage learning as a part of this job (actual, expected, and paid-for part). Push the industry upwards, instead of dragging it down.

mikojan 7y ago

> How many people change their IQ? Literally all of them. However, if someone never progresses to "senior" they might've just lost interest in software development. People in general are remarkable at learning about subjects arousing their curiosity. This is an important fact, too, because environments can be designed specifically to foster just that. Not everything will be working for everybody, of course, and some might never develop an interest in that field again. But that's okay, too.

sanderjd 7y ago

This isn't forbidden knowledge, it's just not correct. People learn and grow with experience. Some projects can't afford to support many, or any, people in that growth stage. But lots of projects can afford it, and the investment in their growth makes sense. I think it is probably also true that some people never become competent enough for many projects, but in my experience that is diminishingly rare, whereas junior developers who are still developing their skills are extremely common (unsurprisingly, since more and more people enter the field constantly).