5 ms·

Personally I want the seniors on my team actually delivering on the really hard stuff. Helping juniors do their job is great and all, but you still need experi

Personally I want the seniors on my team actually delivering on the really hard stuff. Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that. You don't want to be in a situation where you have really really well implemented low-value features, but the high-impact and high-priority hard stuff was not done because some of your most experienced folks were helping the less-experienxed people write effective unit tests or whatever.

spyhi 3y ago
A senior engineer can work through a hard problem assigned to a junior engineer, resulting in a well-implemented hard feature and a less junior engineer. Just because a junior engineer is working on it doesn’t mean by default it’s an easy problem—how are you going to grow your engineers otherwise?
- wizerdrobe 3y ago
  Some firms simply hire nothing but Seniors. You trained up a Junior-Mid-Senior? Cool, well offer him 20k more and call it a day.
  - jen20 3y ago
    > Some firms simply hire nothing but Seniors The firms that claim to do that almost invariably do not hire people with 20 years of experience, they hire people with 2 years of experience 10 times over. Sometimes that's fine. Usually it's not.
    - zerbinxx 3y ago
      Agreed, I will almost always take someone with 5 years of experience at a couple of good shops rather than 20 years of experience broken up across 10 different ones.
      - mattmanser 3y ago
        Really? I have a lot of 2 year stints, as well as some clients I worked with for 5+ years that always invariably turned into occasional month here and there. Often the long-term guys I met are the shit guys who are coasting, still writing code as if it were 2005. Worse still is when their language knowledge has coalesced around an old language version and they're not using any of the new stuff, as I've seen code bases that are entirely incompatible with new libraries. Like all new libraries generally depend on DI, but all the code is written in static methods and classes so nothing can be easily injected and you get all sorts of threading issues when you try.
        zerbinxx 3y ago
        Well there you said it, you work some places for 5+ years, therefore I would strongly consider you. The main reason is that longer stints give you an opportunity to become a master with at least one set of tools. If you interview and are apparently not masterful with your own toolset, then I’ve caught a coaster. I’ve found that it’s much harder to acquire this signal vs. noise thing with exclusively 2 year stint people because they spend half of their life on boarding or unemployed. Also, I get what you’re saying, but DI was around in 2005 and some good engineers (older than I) were using it back then. It seems lot of good ideas skipped a generation!
    - alex_lav 3y ago
      This seems like nothing more than a desire to gatekeep experience? Being employed as a programmer means you're gaining experience...Even if you work at a single company for 20 years, you're not going to get some mythical competence that you could only get by staying in one area. This line of thinking seems like nonsense.
      - jen20 3y ago
        Whether you have a single year of experience 10 times (or whatever ratio you experience) is orthogonal to whether you work for the same company. Being employed as a programmer may or may not gain you new experience (which is what matters if you are to be a good generalist). Whether it does depends on whether you are _doing things new to you_ while being employed.
        alex_lav 3y ago
        Doing new things is experience. Repetition in one area is also experience. This concept you're describing is just made up.
        jen20 3y ago
        Sorry, no. What you have just described is being a generalist vs a specialist. Also, all concepts are “made up”. By definition.
        alex_lav 3y ago
        > What you have just described is being a generalist vs a specialist. Sorry, no. Those concepts are unrelated to what we're describing. > Also, all concepts are “made up”. By definition. I was trying to be polite. Made up by you and nonsensical, is the more accurate phrasing. Respectfully. But I'll be stopping here. Enjoy the day!
        jen20 3y ago
        > Those concepts are unrelated to what we're describing. No they aren’t. They’re literally the subject of the conversation before you joined it.
  - theshrike79 3y ago
    This, sadly, needs to change. The pool for experienced senior level talent won't grow unless _someone_ spends the resources to hire and train juniors. The incentive being that they can keep the best juniors for themselves and let the others back into the pool for others.
lawn 3y ago
One of the points of the post is that this person also helped the seniors do their job better. But yeah, the job of every senior cannot be to only help the juniors.
brabel 3y ago
Agreed. Tim was not doing the job of a programmer if he never actually wrote code that delivered value. Tim was a coach. Which is fine if that's what you hired Tim for, but I suspect that if you wanted a coach, you would've hired one. Hard features simply can't be done by juniors even given infinite amounts of time: they just don't have the skills yet, and to gain those skills takes years. Sure, they need a senior to help now and then, but if that makes the senior developers produce nothing, then what's the point for the company?? Just give hard features to people who are senior enough to do them, and if you really want the juniors to learn, let the senior share easier parts of that work (and walk through what he's doing) with the junior. It's very nice of Tim to help everybody else, but doesn't anybody find it odd that all the other programmers need lots of help in the first place, so much that Tim has zero time to deliver anything himself? Seems that the problem is not with Tim, but with management that thinks it's ok for a professional to need help all the time, and for a volunteer like Tim to be there for them any time regardless of what he's paid for (which in this case, was story points as made clear by the author).
starky 3y ago
You are taking the wrong lesson from the article if you think they are saying every (or even most) senior developers should be doing this. You absolutely don't want every senior developer spending their time mentoring/working with junior developers, but having a couple of those people on the team is a force multiplier and benefits the team as a whole. They may not have realized it when they hired him, but he found a useful niche and once the company identified it they should have changed his role to make it official.
CRConrad 3y ago
> Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that. Or, it could be said, you need to refactor your codebase so no job is all that "hard and complex". Should have had one of those seniors build it in the first place, eh, then juniors could be trusted to modify it. Or, what you say, he did? Then why is he "a senior" in the first place, if stuff is "hard and complex" because of how he built it...?

spyhi 3y ago

A senior engineer can work through a hard problem assigned to a junior engineer, resulting in a well-implemented hard feature and a less junior engineer. Just because a junior engineer is working on it doesn’t mean by default it’s an easy problem—how are you going to grow your engineers otherwise?

wizerdrobe 3y ago
Some firms simply hire nothing but Seniors. You trained up a Junior-Mid-Senior? Cool, well offer him 20k more and call it a day.
- jen20 3y ago
  > Some firms simply hire nothing but Seniors The firms that claim to do that almost invariably do not hire people with 20 years of experience, they hire people with 2 years of experience 10 times over. Sometimes that's fine. Usually it's not.
  - zerbinxx 3y ago
    Agreed, I will almost always take someone with 5 years of experience at a couple of good shops rather than 20 years of experience broken up across 10 different ones.
    - mattmanser 3y ago
      Really? I have a lot of 2 year stints, as well as some clients I worked with for 5+ years that always invariably turned into occasional month here and there. Often the long-term guys I met are the shit guys who are coasting, still writing code as if it were 2005. Worse still is when their language knowledge has coalesced around an old language version and they're not using any of the new stuff, as I've seen code bases that are entirely incompatible with new libraries. Like all new libraries generally depend on DI, but all the code is written in static methods and classes so nothing can be easily injected and you get all sorts of threading issues when you try.
      - zerbinxx 3y ago
        Well there you said it, you work some places for 5+ years, therefore I would strongly consider you. The main reason is that longer stints give you an opportunity to become a master with at least one set of tools. If you interview and are apparently not masterful with your own toolset, then I’ve caught a coaster. I’ve found that it’s much harder to acquire this signal vs. noise thing with exclusively 2 year stint people because they spend half of their life on boarding or unemployed. Also, I get what you’re saying, but DI was around in 2005 and some good engineers (older than I) were using it back then. It seems lot of good ideas skipped a generation!
  - alex_lav 3y ago
    This seems like nothing more than a desire to gatekeep experience? Being employed as a programmer means you're gaining experience...Even if you work at a single company for 20 years, you're not going to get some mythical competence that you could only get by staying in one area. This line of thinking seems like nonsense.
    - jen20 3y ago
      Whether you have a single year of experience 10 times (or whatever ratio you experience) is orthogonal to whether you work for the same company. Being employed as a programmer may or may not gain you new experience (which is what matters if you are to be a good generalist). Whether it does depends on whether you are _doing things new to you_ while being employed.
      - alex_lav 3y ago
        Doing new things is experience. Repetition in one area is also experience. This concept you're describing is just made up.
        jen20 3y ago
        Sorry, no. What you have just described is being a generalist vs a specialist. Also, all concepts are “made up”. By definition.
        alex_lav 3y ago
        > What you have just described is being a generalist vs a specialist. Sorry, no. Those concepts are unrelated to what we're describing. > Also, all concepts are “made up”. By definition. I was trying to be polite. Made up by you and nonsensical, is the more accurate phrasing. Respectfully. But I'll be stopping here. Enjoy the day!
        jen20 3y ago
        > Those concepts are unrelated to what we're describing. No they aren’t. They’re literally the subject of the conversation before you joined it.
- theshrike79 3y ago
  This, sadly, needs to change. The pool for experienced senior level talent won't grow unless _someone_ spends the resources to hire and train juniors. The incentive being that they can keep the best juniors for themselves and let the others back into the pool for others.

lawn 3y ago

One of the points of the post is that this person also helped the seniors do their job better. But yeah, the job of every senior cannot be to only help the juniors.

brabel 3y ago

Agreed. Tim was not doing the job of a programmer if he never actually wrote code that delivered value. Tim was a coach. Which is fine if that's what you hired Tim for, but I suspect that if you wanted a coach, you would've hired one. Hard features simply can't be done by juniors even given infinite amounts of time: they just don't have the skills yet, and to gain those skills takes years. Sure, they need a senior to help now and then, but if that makes the senior developers produce nothing, then what's the point for the company?? Just give hard features to people who are senior enough to do them, and if you really want the juniors to learn, let the senior share easier parts of that work (and walk through what he's doing) with the junior. It's very nice of Tim to help everybody else, but doesn't anybody find it odd that all the other programmers need lots of help in the first place, so much that Tim has zero time to deliver anything himself? Seems that the problem is not with Tim, but with management that thinks it's ok for a professional to need help all the time, and for a volunteer like Tim to be there for them any time regardless of what he's paid for (which in this case, was story points as made clear by the author).

starky 3y ago

You are taking the wrong lesson from the article if you think they are saying every (or even most) senior developers should be doing this. You absolutely don't want every senior developer spending their time mentoring/working with junior developers, but having a couple of those people on the team is a force multiplier and benefits the team as a whole. They may not have realized it when they hired him, but he found a useful niche and once the company identified it they should have changed his role to make it official.

CRConrad 3y ago

> Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that. Or, it could be said, you need to refactor your codebase so no job is all that "hard and complex". Should have had one of those seniors build it in the first place, eh, then juniors could be trusted to modify it. Or, what you say, he did? Then why is he "a senior" in the first place, if stuff is "hard and complex" because of how he built it...?