3 ms·

This was readily apparent at my last shop when we had a range of junior (months out of college) and seniors (20+ years experience), and the expectation was simp

This was readily apparent at my last shop when we had a range of junior (months out of college) and seniors (20+ years experience), and the expectation was simply that seniors were to clear more tickets/points per sprint. We didn't allocate more architectural tasks to seniors, or pair them with juniors, or give them long running slices of work across sprints.. we just were like "more points please". We ended up with under-engaged seniors all leaving, and juniors being given tasks they couldn't accomplish.

WJW 3y ago
This has been a very underappreciated point in all companies I've worked for so far. The difference between an good programmer and a bad one is not (just) that the good one is faster, it's that they can solve problems that the bad one cannot solve at all. The terms "junior", "senior", etc make it appear as if the latter is just an older version of the former, but the correlation between work experience and actual skill is far from 100% in my experience.
- steveBK123 3y ago
  I use senior here also to point out - we had a team composed of people who had literally built a similar/same system elsewhere, and kids who are working for a living for the first time in their lives for a few weeks. The idea that everyone gets a vote on story points & planning meetings in a conference room for hours&hours, while democratic, is counterproductive. Further, as it turns out, the dev who has done the thing 2-3 times before knows all the mistakes not to make, and move onto make new & unique mistakes (joking, sometimes) whereas the junior gets to make all the mistakes all over again. The senior is always going to give a higher effort estimate, but will generally be able to accomplish the task within that estimate more often. A junior has no ideas what they don't know, and can often be off by orders of magnitude on their estimates. Usually because they consider only what is required for the "happy path" of the code to work as expected when used as expected, with no bad data/etc. Further they will include the time it takes them to get the first cut of the code working on their box, undocumented, uncommented, not in git, not tested, and not ready for release.

WJW 3y ago

This has been a very underappreciated point in all companies I've worked for so far. The difference between an good programmer and a bad one is not (just) that the good one is faster, it's that they can solve problems that the bad one cannot solve at all. The terms "junior", "senior", etc make it appear as if the latter is just an older version of the former, but the correlation between work experience and actual skill is far from 100% in my experience.

steveBK123 3y ago
I use senior here also to point out - we had a team composed of people who had literally built a similar/same system elsewhere, and kids who are working for a living for the first time in their lives for a few weeks. The idea that everyone gets a vote on story points & planning meetings in a conference room for hours&hours, while democratic, is counterproductive. Further, as it turns out, the dev who has done the thing 2-3 times before knows all the mistakes not to make, and move onto make new & unique mistakes (joking, sometimes) whereas the junior gets to make all the mistakes all over again. The senior is always going to give a higher effort estimate, but will generally be able to accomplish the task within that estimate more often. A junior has no ideas what they don't know, and can often be off by orders of magnitude on their estimates. Usually because they consider only what is required for the "happy path" of the code to work as expected when used as expected, with no bad data/etc. Further they will include the time it takes them to get the first cut of the code working on their box, undocumented, uncommented, not in git, not tested, and not ready for release.