4 ms·

> Promote them. (Not move them into management, promote them to your equivalent of senior engineer.) I think this is controversial. If you have a software engi

> Promote them. (Not move them into management, promote them to your equivalent of senior engineer.) I think this is controversial. If you have a software engineer being promoted to senior software engineer (1 -> 2) without at least intermediate knowledge of the codebase, that'll make other seniors suspicious/wary. Personally speaking, if you hire a software engineer that does mainly/only glue work, you mis-hired. What you meant to hire was a technical project manager. Move that person to a TPM if they want to (and are great at what they do) instead of having a senior software engineer who hasn't really shipped anything noteworthy.

red_admiral 6y ago
I can see your point, but it depends on how technical their glue work is, if you like. In the post, she mentions for example: > The manager has a bunch of teams and is starting to rely on Engineer to know what's going on with this one. Hey, Awesome Coder seems blocked. Do you know what the deal is? > > Our Engineer investigates, discovers that Awesome Coder needs information from another team but is mired in a three week long email thread. She talks to some people in real life, figures out what the confusion is, sorts it out. Awesome Coder is unblocked. He says thank you, writes thousands of lines of code. This sounds to me like she knows exactly what's going on in the relevant part of the codebase to be able to get the information to unblock Awesome Coder. > A customer comes in with a request: they want data that the API really should be able to provide but the team hasn't prioritised this feature yet. Our friend here spends a couple of days manually getting the data the customer needs. The customer is overjoyed. Again, it looks like she's perfectly fine writing productive code when you let her. I've worked with several great people in the past who exactly fit the description of "glue person" - although most of them were male - and I found that mostly, while the Awesome Coder types had an excellent understanding of their own part of the code, the glue people were the only ones who really understood how things worked together. So you got someone in team A saying why not replace libX with libY because it makes our Z easier, and the glue person speaks up and says actually I worked with someone on Team B last week, and they're using feature W of libX. Tanya herself admits that "is this person a Senior Engineer" is controversial. But I'd say that someone who is glue in a way that clearly demonstrates a deep technical understanding of the codebase should qualify, even if that understanding is not demonstrated by writing her own code.
- BossingAround 6y ago
  > Again, it looks like she's perfectly fine writing productive code when you let her. I think this is exactly the controversial part. If the person manually gets some data and documents how to get the data, that's not writing code. That's understanding how to use a system, and can be done by an L1 or L2 tech support person. > This sounds to me like she knows exactly what's going on in the relevant part of the codebase to be able to get the information to unblock Awesome Coder. But yes, that's what I thought too. You often can't, it seems to me, make out these issues without deep understanding of the problem. In general, I understand your perspective too. It's just a hard problem to solve. I would say that if I'm hired to do X and for whatever reason, I mostly do Y, that should be a huge red flag. The manager should have stepped in a long time before promotion talk comes around (as the post mentions), but it would be to me, personally, as well (did the company lie in their job interviews?).
  - red_admiral 6y ago
    I think we're mostly in agreement - definitely a hard problem - and that we'd both take "hire an actual project manager and let the glue person spend her time coding instead" as a solution.
  - chrisweekly 6y ago
    Hiring is hard for many reasons. Even on relatively short contract gigs (let alone LT or FT / roles), IME what a given org thinks it needs and what's actually required are often revealed to be quite different. To me it's not necessarily a red flag, rather a reflection of the complexity and uncertainties inherent in planning software projects. My consulting process incorporates an explicit "discovery" phase, largely for this reason.
  - mikewarot 6y ago
    >"I think this is exactly the controversial part. If the person manually gets some data and documents how to get the data, that's not writing code. That's understanding how to use a system, and can be done by an L1 or L2 tech support person." Why would you stop a step short of writing code to do it for the customer? That essential time spending now to save many future hours is the root of why we code, and defines being a programmer, in my opinion.
ritchiea 6y ago
Why did you immediately assume the software engineer the original comment was theorizing about would not have intermediate knowledge of the codebase?
- BossingAround 6y ago
  Based on the talk [0] where the OP suggested it number of times. She mentions the engineer being rusty and having significantly fewer code contributions than her peers. In general, if the glue person has intermediate knowledge of the codebase, they'd get promoted without much controversy. In such a case, it should not be difficult for them to bang out a couple of features and ship it, for example. [0] https://www.youtube.com/watch?v=KClAPipnKqw https://www.youtube.com/watch?v=KClAPipnKqw
DominikD 6y ago
> If you have a software engineer being promoted to senior software engineer (1 -> 2) without at least intermediate knowledge of the codebase, that'll make other seniors suspicious/wary. She clearly did. Without that she would not be able to onboard or contribute to the design discussions and would not be able to help customers out. You can't assume that customers implies non-technical. In mid to large orgs most of your customers are other teams with very technical needs. > if you hire a software engineer that does mainly/only glue work, you mis-hired No, it depends on what your team needed. You can't have a 5-person team where everyone is great at crunching code unless your only success metric is LOC produced. You need diverse set of skills to deliver and maintain the product. You mis-hired only if your glue competencies are already covered. In general I see this as a massive problem that many engineers believe that technical excellence is all that's needed to build a product. It isn't. Design reviews, code reviews, and onboarding for technical staff are very much technical. And simple technical tasks that are tedious and boring are still technical tasks. And as a senior I would never assign them to a junior developer unless there's a lesson to be learned by doing them (once). If your glue person is picking them and you judge glue person's output by the complexity of those tasks (not technical enough!) then your metrics are wrong.
- chrisweekly 6y ago
  "success metric is LOC produced" == worst metric ever (even for strong programmers / IC's whose "only job" is writing code) -- and this is nearly universally accepted.
- chrisweekly 6y ago
  "simple technical tasks that are tedious and boring are still technical tasks. And as a senior I would never assign them to a junior developer unless there's a lesson to be learned by doing them (once)" Given your technical seniority / superiority, whose time is better spent on tackling the thorniest challenges?
  - sethammons 6y ago
    Depending on time sensitivity, the senior should be mentoring the junior on how to deal with the thorniest of challenges (appropriately scaffolded).

red_admiral 6y ago

I can see your point, but it depends on how technical their glue work is, if you like. In the post, she mentions for example: > The manager has a bunch of teams and is starting to rely on Engineer to know what's going on with this one. Hey, Awesome Coder seems blocked. Do you know what the deal is? > > Our Engineer investigates, discovers that Awesome Coder needs information from another team but is mired in a three week long email thread. She talks to some people in real life, figures out what the confusion is, sorts it out. Awesome Coder is unblocked. He says thank you, writes thousands of lines of code. This sounds to me like she knows exactly what's going on in the relevant part of the codebase to be able to get the information to unblock Awesome Coder. > A customer comes in with a request: they want data that the API really should be able to provide but the team hasn't prioritised this feature yet. Our friend here spends a couple of days manually getting the data the customer needs. The customer is overjoyed. Again, it looks like she's perfectly fine writing productive code when you let her. I've worked with several great people in the past who exactly fit the description of "glue person" - although most of them were male - and I found that mostly, while the Awesome Coder types had an excellent understanding of their own part of the code, the glue people were the only ones who really understood how things worked together. So you got someone in team A saying why not replace libX with libY because it makes our Z easier, and the glue person speaks up and says actually I worked with someone on Team B last week, and they're using feature W of libX. Tanya herself admits that "is this person a Senior Engineer" is controversial. But I'd say that someone who is glue in a way that clearly demonstrates a deep technical understanding of the codebase should qualify, even if that understanding is not demonstrated by writing her own code.

BossingAround 6y ago
> Again, it looks like she's perfectly fine writing productive code when you let her. I think this is exactly the controversial part. If the person manually gets some data and documents how to get the data, that's not writing code. That's understanding how to use a system, and can be done by an L1 or L2 tech support person. > This sounds to me like she knows exactly what's going on in the relevant part of the codebase to be able to get the information to unblock Awesome Coder. But yes, that's what I thought too. You often can't, it seems to me, make out these issues without deep understanding of the problem. In general, I understand your perspective too. It's just a hard problem to solve. I would say that if I'm hired to do X and for whatever reason, I mostly do Y, that should be a huge red flag. The manager should have stepped in a long time before promotion talk comes around (as the post mentions), but it would be to me, personally, as well (did the company lie in their job interviews?).
- red_admiral 6y ago
  I think we're mostly in agreement - definitely a hard problem - and that we'd both take "hire an actual project manager and let the glue person spend her time coding instead" as a solution.
- chrisweekly 6y ago
  Hiring is hard for many reasons. Even on relatively short contract gigs (let alone LT or FT / roles), IME what a given org thinks it needs and what's actually required are often revealed to be quite different. To me it's not necessarily a red flag, rather a reflection of the complexity and uncertainties inherent in planning software projects. My consulting process incorporates an explicit "discovery" phase, largely for this reason.
- mikewarot 6y ago
  >"I think this is exactly the controversial part. If the person manually gets some data and documents how to get the data, that's not writing code. That's understanding how to use a system, and can be done by an L1 or L2 tech support person." Why would you stop a step short of writing code to do it for the customer? That essential time spending now to save many future hours is the root of why we code, and defines being a programmer, in my opinion.

ritchiea 6y ago

Why did you immediately assume the software engineer the original comment was theorizing about would not have intermediate knowledge of the codebase?

BossingAround 6y ago
Based on the talk [0] where the OP suggested it number of times. She mentions the engineer being rusty and having significantly fewer code contributions than her peers. In general, if the glue person has intermediate knowledge of the codebase, they'd get promoted without much controversy. In such a case, it should not be difficult for them to bang out a couple of features and ship it, for example. [0] https://www.youtube.com/watch?v=KClAPipnKqw https://www.youtube.com/watch?v=KClAPipnKqw

DominikD 6y ago

> If you have a software engineer being promoted to senior software engineer (1 -> 2) without at least intermediate knowledge of the codebase, that'll make other seniors suspicious/wary. She clearly did. Without that she would not be able to onboard or contribute to the design discussions and would not be able to help customers out. You can't assume that customers implies non-technical. In mid to large orgs most of your customers are other teams with very technical needs. > if you hire a software engineer that does mainly/only glue work, you mis-hired No, it depends on what your team needed. You can't have a 5-person team where everyone is great at crunching code unless your only success metric is LOC produced. You need diverse set of skills to deliver and maintain the product. You mis-hired only if your glue competencies are already covered. In general I see this as a massive problem that many engineers believe that technical excellence is all that's needed to build a product. It isn't. Design reviews, code reviews, and onboarding for technical staff are very much technical. And simple technical tasks that are tedious and boring are still technical tasks. And as a senior I would never assign them to a junior developer unless there's a lesson to be learned by doing them (once). If your glue person is picking them and you judge glue person's output by the complexity of those tasks (not technical enough!) then your metrics are wrong.

chrisweekly 6y ago
"success metric is LOC produced" == worst metric ever (even for strong programmers / IC's whose "only job" is writing code) -- and this is nearly universally accepted.
chrisweekly 6y ago
"simple technical tasks that are tedious and boring are still technical tasks. And as a senior I would never assign them to a junior developer unless there's a lesson to be learned by doing them (once)" Given your technical seniority / superiority, whose time is better spent on tackling the thorniest challenges?
- sethammons 6y ago
  Depending on time sensitivity, the senior should be mentoring the junior on how to deal with the thorniest of challenges (appropriately scaffolded).