3 ms·

Alot of companies think they need senior devs, when in reality what they really need is more junior or mid-level devs. Most developers aren't architecting whol

Alot of companies think they need senior devs, when in reality what they really need is more junior or mid-level devs. Most developers aren't architecting whole new apps, or building out massive feature requests. Most of the time, it's fixing bugs, maintenance, adjustments to existing features, and other work that mainly requires navigating existing code and infrastructure, with the occasional new feature here and there. You do need one really good lead developer on the team, to help mentor people. This is the one area that is sometimes a bit lacking. Most leads are great engineers but aren't very good at leading, mentoring or any of the other people type work they need to do. But, all they really need is some training and a personality adjustment, in some cases.

btilly 9y ago
You underestimate the cost of communication overhead and rework. As a flat team scales, the cost of communication scales with the number of people squared. If you solve this with process, everyone's productivity is dropped. Data that you can find in Software Estimation: Demystifying The Black Art quantifies this. The overall productivity of a team increases until it has 5-8 people. Then it goes down. A team of 12 actually accomplishes LESS per month than it would if you fired half the people. However once you get to 20-25 people, productivity is back. And then increases fairly close to linearly. Going from 5-8 people all the way to 20+ with no increase in throughput is really, really painful. And those aren't cheap people. This provides companies with a huge incentive to figure out how to get a small team to be as productive as possible. And you don't get the most out of a small team by filling it up with junior to mid-level devs.
xkcd-sucks 9y ago
It's okay for front-line devs to think this, but when the people in charge of salary and hiring believe it, your team ends up a crew of fresh graduates herded by a senior dev who is exclusively occupied with making sure the junior devs don't make things worse. And most failures of junior devs (breaking stuff) are considered the responsibility of the senior dev managing them, so the senior dev bears just as much responsibility as before but now with less control and more unpredictability. It is certainly good to have juniors on the team, but managing them should not take the greatest part of your senior devs' time, and your product should not be written exclusively by juniors. Some CEOs deflect accusations of cheapness by claiming they don't want "rockstars/divas," but that's a personality trait, not a skill, and the crappiest of crappy junior devs are certainly capable of embodying rockstar arrogance. Most work is tweaking an existing codebase, and quick fluency in arbitrary code written by strangers is definitely not a junior-level skill. In fact, CS-heavy stuff with little external integration is perfect for fresh graduates, as they did learn it in school.
- scarface74 9y ago
  It's okay for front-line devs to think this, but when the people in charge of salary and hiring believe it, your team ends up a crew of fresh graduates herded by a senior dev who is exclusively occupied with making sure the junior devs don't make things worse. Why is that bad thing? I'm in that position now more or less - senior Dev (official title architect) working with mostly with inexperienced but smart junior developers and legacy developers. I'm just not expected to do too much actual coding.
johngalt 9y ago
Whenever people ask for fullstack do-it-all seniors with part time devops responsibilities, I assume that means "We have no idea how to create or manage a functioning technical team, and instead want a tech-wish granting genie." You don't need 10 rockstar ninja genius senior engineers. You need five devs, three Ops, one PM, and an intern. Ideally you can divide it up further where certain devs are more back-end and others front-end, one dev is more of a database pro, one ops is metrics focused etc... Then you have to manage this team of people. Which means solving difficult trade-offs, mediating disputes, finding gaps, removing obstacles, etc...

btilly 9y ago

You underestimate the cost of communication overhead and rework. As a flat team scales, the cost of communication scales with the number of people squared. If you solve this with process, everyone's productivity is dropped. Data that you can find in Software Estimation: Demystifying The Black Art quantifies this. The overall productivity of a team increases until it has 5-8 people. Then it goes down. A team of 12 actually accomplishes LESS per month than it would if you fired half the people. However once you get to 20-25 people, productivity is back. And then increases fairly close to linearly. Going from 5-8 people all the way to 20+ with no increase in throughput is really, really painful. And those aren't cheap people. This provides companies with a huge incentive to figure out how to get a small team to be as productive as possible. And you don't get the most out of a small team by filling it up with junior to mid-level devs.

xkcd-sucks 9y ago

It's okay for front-line devs to think this, but when the people in charge of salary and hiring believe it, your team ends up a crew of fresh graduates herded by a senior dev who is exclusively occupied with making sure the junior devs don't make things worse. And most failures of junior devs (breaking stuff) are considered the responsibility of the senior dev managing them, so the senior dev bears just as much responsibility as before but now with less control and more unpredictability. It is certainly good to have juniors on the team, but managing them should not take the greatest part of your senior devs' time, and your product should not be written exclusively by juniors. Some CEOs deflect accusations of cheapness by claiming they don't want "rockstars/divas," but that's a personality trait, not a skill, and the crappiest of crappy junior devs are certainly capable of embodying rockstar arrogance. Most work is tweaking an existing codebase, and quick fluency in arbitrary code written by strangers is definitely not a junior-level skill. In fact, CS-heavy stuff with little external integration is perfect for fresh graduates, as they did learn it in school.

scarface74 9y ago
It's okay for front-line devs to think this, but when the people in charge of salary and hiring believe it, your team ends up a crew of fresh graduates herded by a senior dev who is exclusively occupied with making sure the junior devs don't make things worse. Why is that bad thing? I'm in that position now more or less - senior Dev (official title architect) working with mostly with inexperienced but smart junior developers and legacy developers. I'm just not expected to do too much actual coding.

johngalt 9y ago

Whenever people ask for fullstack do-it-all seniors with part time devops responsibilities, I assume that means "We have no idea how to create or manage a functioning technical team, and instead want a tech-wish granting genie." You don't need 10 rockstar ninja genius senior engineers. You need five devs, three Ops, one PM, and an intern. Ideally you can divide it up further where certain devs are more back-end and others front-end, one dev is more of a database pro, one ops is metrics focused etc... Then you have to manage this team of people. Which means solving difficult trade-offs, mediating disputes, finding gaps, removing obstacles, etc...