Hacker News Reader

>What I do know is that junior people are complaining that there are only jobs for senior devs and seniors are complaining that all the jobs are for juniors.

But when you ask those juniors, a "senior dev job posting" is one that requires 3-4 of experience.

I once blew an interview badly-- after speaking to a founder... He said, "we only want the best engineers." And I asked him, "How much experience do your engineers have on average?"

"5 years or so."

(my resume had ~15 years of continuous work)

Everything went downhill from there lol

"What I do know is that junior people are complaining that there are only jobs for senior devs and seniors are complaining that all the jobs are for juniors."

It seems the job posting all want seniors. The jobs themselves usually turn out to be boring and could be done by a junior.

I remember working as an entry level and thinking that you could spend one day training a high school grad to do 90% of the job. Now I'm a midlevel and the this job is so boring and could be done better by an entry level (because they're motivated, happy just to have a job in the industry, and don't realize how boring the work is).

That last 10% is really 110% of the work.

That doesn't make any sense.

Yes it does.

I have heard so many business oriented people say that they want to do the 20% of the work that gets 80% of the way to the destination.

80% of the way to destination means "0% of the value delivered".

Percentages over 100% occur all the time in project management, such as

https://en.wikipedia.org/wiki/Olkiluoto_Nuclear_Power_Plant

where you might have spent 500% of the budget to get 50% done. (China built a reactor of that type and turned it on but they had some fuel rods burst right away and had to turn it off.)

So you're thinking on a project level. I'm talking about a resource level.

Why hire a couple senior devs to spend 90% of their time on junior tasks? A better model is to hire a couple juniors to handle the junior tasks and use the seniors for the senior tasks and oversight. Much more efficient that way.

Sure, you can have percentages over 100% for many things. When looking at a breakdown of tasks/time/work for an individual, you are constrained to 100% (the pie chart values might get bigger but it always adds up to 100%)

Projects get done when the "resource" does it what takes to make the project happen.

The data scientist who thinks he is too good to check his notebooks into version control is just one version of people who think they are "too good" to be doing what they are doing.

In small teams people do the work that is critical whether it is too "easy" in their estimation or if they have to stretch themselves to do something difficult. Sometimes they need to get help. A few people on the team can indulge in doing only the work they feel like doing, but that's because there are adults on the team who cover for them.

There are many advanced programming tasks which could, in principle, be assigned to some juniors. For instance, CS majors usually take one or more courses in compilers and programming languages. If your organization is dependent on a legacy programming language you could possibly get one of those juniors to write a transpiler that compiles it to something current. Succeeding at that takes some guidance, but it might take some form that some "seniors" would find offensive such as writing a really tough set of unit tests.

Many "seniors" on the other hand never took any compiler courses or sold their textbooks and forgot everything 10 years ago.

I think you're taking my comments out of context and changing the subject.

First, you seem to have dropped the percentage topic, which you had initially talked to. It seems like you're just changing the topic for the sake of arguing something on a tangent (isn't that against the rules here).

Now you seem to be talking about people who are too good to do things. Which is entirely different than what I'm talking about - appropriately staffing a team based on expected tasks and minimizing budget.

No, I'm rejecting your construction of "junior" and "senior".

Tasks are not really "junior" or "senior" tasks but really tasks that juniors or seniors could do with different results in terms of time, cost, quality, etc.

Sometimes a "junior" is more experienced at the latest methods. This is one thing you see with medical doctors or electrical engineers, that many people go through their careers and keep using the same methods they used at the beginning. (Think of the old saying that "Science advances one funeral at a time")

For instance 20 years I go didn't expect an undergraduate student to have any idea what version control is, today I expect them to have a Github account.

"Tasks are not really "junior" or "senior" tasks but really tasks that juniors or seniors could do with different results in terms of time, cost, quality, etc."

You are putting words in my mouth. I never called the tasks "junior" or "senior". Looks like you agree with me, but felt the need to argue anyways.

You sound like a junior manager. Experienced managers know resource management doesn’t work like that. Here’s the deal: 90% of all development tasks can be done by junior developers. But there’s two problems with your line of thought. One, you can’t always recognize a priori what that 10% is. The junior devs certainly won’t know when they’re in over their heads and their pride will keep them from calling for help. That 10% is going to get really expensive. Your other problem is junior devs aren’t going to be nearly as efficient at completing the 90% and they’re not going to do it as well - meaning there will be additional operating costs down the road.

Instead of thinking of junior devs as cheap development resources, think of them as your depth in talent. They can do the easier tasks and cover when somebody is out for whatever reason. Manage your team like a GM would a sports team.

I guess if you multiply all estimates by π, 110% is only about a third of the actual work.

Unfortunately it does. It's comparatively quick and easy to slap together an application which does the first 80%. Then, come edge cases, stuff your req engineers didn't come around to define, or which your approach moved fast and broke, or which simply couldn't fit in the architecture as your initial sprints created. Everything doable of course but...

So you're thinking on a project level. I'm talking about a resource level. Why hire a couple senior devs to spend 90% of their time on junior tasks? A better model is to hire a couple juniors to handle the junior tasks and use the seniors for the senior tasks and oversight. Much more efficient that way.

Sure, you can have percentages over 100% for many things. When looking at a breakdown of tasks/time/work for an individual, you are constrained to 100% (the pie chart values might get bigger but it always adds up to 100%)

Pro Tip: calling developers "resources" causes employee turnover.

What is a "senior" task and what is a "junior" task depends on the organization of labor.

It's certainly possible for a senior to divide a big task into small chunks that juniors can dispatch with great haste. You could possibly put 1 senior and 4 juniors together in a bullpen and get them to do the work that (say) 3 seniors or 10 juniors could do with a different organization.

To realize that you have to get the human relationships right, a theme I keep harping on is that the people involve have to feel the tasks are worthy of them. Many juniors, in a situation like that, might feel like they are being micromanaged.

Another thing you need is for the senior to have enough of a global view of the situation that their seniority really produces value. If you really don't understand where you are going and you'll need to rework everything you aren't getting value out of that kind of situation.

Around my farm we have a large number of "junior resources" available for construction work. Those young people make silly mistakes that cost time and money and that's one reason why they make $18 an hour compared to a more experienced person who makes $40 an hour because they are twice as productive.

> What I do know is that junior people are complaining that there are only jobs for senior devs and seniors are complaining that all the jobs are for juniors.

I imagine some of that is how people understand job postings over time. Reading between the lines there's a lot of fairly junior roles out there that include a lot of senior sounding requirements. It's also not hard to find many senior roles which only offer a junior salary (I wonder why those listing stay open for so long...).