10 ms·

> 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 ge

> 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.
- throwanem 6y ago
  > 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. This is the correct call, both technically and for the customer. The feature is planned but not prioritized, so pulling it in right now screws up the sprint. It will almost certainly also take longer to write, debug, test, and ship than it will to just pull the data - and even that assumes no UI is required for the customer to use it. A manual pull is the fastest way to satisfy the request, and that's why it's the right call from that perspective. Note also that our friend does not only pull the data, but also documents how that was done. This means that when the relevant feature ticket does come into a sprint, it comes with detailed information and a worked example on exactly how it needs to do what it does. That'll save whoever picks it up a ton of discovery time, and that's why it's the right call from that perspective. "Programmer" isn't the job title. "Engineer" is. There's a lot of reasons why. This kind of thing is one of them.
  - mikewarot 6y ago
    That's very insightful.... I think the term Engineer is used rather loosely when applied to programmers... now I get the difference. Writing the code is the easy part, knowing what to write is the skill, thus Engineer.

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.

throwanem 6y ago
> 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. This is the correct call, both technically and for the customer. The feature is planned but not prioritized, so pulling it in right now screws up the sprint. It will almost certainly also take longer to write, debug, test, and ship than it will to just pull the data - and even that assumes no UI is required for the customer to use it. A manual pull is the fastest way to satisfy the request, and that's why it's the right call from that perspective. Note also that our friend does not only pull the data, but also documents how that was done. This means that when the relevant feature ticket does come into a sprint, it comes with detailed information and a worked example on exactly how it needs to do what it does. That'll save whoever picks it up a ton of discovery time, and that's why it's the right call from that perspective. "Programmer" isn't the job title. "Engineer" is. There's a lot of reasons why. This kind of thing is one of them.
- mikewarot 6y ago
  That's very insightful.... I think the term Engineer is used rather loosely when applied to programmers... now I get the difference. Writing the code is the easy part, knowing what to write is the skill, thus Engineer.