5 ms·

I work on a system that has 15 year old code in it, lots of it in a bad state (it's being removed, but slowly). I've seen a lot of people come in (category A)

I work on a system that has 15 year old code in it, lots of it in a bad state (it's being removed, but slowly). I've seen a lot of people come in (category A) who can spout best practices that we're not following, but can't ever wrap their heads around the way the system works, the amount of effort that implementing an idea will take, and the amount of payoff it will offer. They just cargo cult best practices. With those people, I want to say "please just crank out tickets until you understand more". However, there have also been a small handful of people (category B) who come in, and quickly find ways to make beneficial changes that are achievable and worthwhile. Those people are incredibly valuable. Concrete advice: if you take a year for any new hire to understand things enough to make changes, you need to work on the understandability of your system, your onboarding, or stop hiring exclusively from category A.

mercutio2 9y ago
How is “quickly find ways to make beneficial changes that are achievable and worthwhile” distinct from resolving tickets? That seems like a perfect description of doing a good job at resolving tickets to me. Because if the change was beneficial, it was presumably not just navel gazing architecture astronauting, it was solving an existing problem, right?
- lumost 9y ago
  General expectation for Senior engineers in the orgs I've been a part of is that they are great problem finders, as well as problem solvers and implementers. If you have a significant backlog of useful improvements that are relatively straightforward to implement, then it's likely better to bring on a few junior engineers to tackle those rather than Seniors. If you're looking to turn the large backlog into a small backlog thanks to innovative solutions or break into new areas, Seniors tend to handle it better. The red flag in the ramp up curve is really for Senior engineers. If I didn't have a solid understanding and demonstrated ownership of my problem domain within six months along with meaningful projects getting pushed through - my manager would likely be starting an awkward conversation with me.
  - hyperpape 9y ago
    This is really well said. Part of problem finding is also taking vague inputs "that subsystem is kinda wonky" and transforming it into "that system has these specific problems, which can be fixed with this approach, which will take roughly this long, and help out this much". The existing group may not have made tickets for something because they think "it'll take six months" or "we'll have to change x,y and z before that idea is gonna help us", because they don't have the time to analyze a known pain point for how painful it is, or even because they haven't thought of the improvement. Then someone realizes that those assumptions are wrong, and finds a big improvement.
    - mercutio2 9y ago
      If it doesn’t solve a problem the existing team already acknowledged, or at least very directly accelerate the fix for one of those problems, that doesn’t sound like a good outcome from a new hire to me.
      - hyperpape 9y ago
        I can't decide whether to agree with you or not. On the one hand, I think a lot of the changes I'm talking about changes that should accelerate the fix for problems you have (what team doesn't think "it's too hard to work with x" at some point?). On the other hand, I feel like you're coming at this from the perspective that your existing team is omniscient, or at least always knows better than someone new. We used to have that dynamic, and I think it's better that we're now more open to new ideas (onboarding is still way slower than I'd like, but it's improved).
        mercutio2 9y ago
        Current team certainly isn’t omniscient. Just that you’re liable to make enemies, not friends/develop career, by coming in and proposing brand new, undesired/unforeseen changes and winning the argument with management. Brand new not-desired-by-team features/changes often end up owned and maintained by the existing team for a long time, often long after you’re gone. You, as a new person, probably aren’t shouldering much maintenance burden yet, bad to be perceived as adding more rather than reducing load. Much better to fix a generally acknowledged problem, reducing maintenance burden for the existing team.

mercutio2 9y ago

How is “quickly find ways to make beneficial changes that are achievable and worthwhile” distinct from resolving tickets? That seems like a perfect description of doing a good job at resolving tickets to me. Because if the change was beneficial, it was presumably not just navel gazing architecture astronauting, it was solving an existing problem, right?

lumost 9y ago
General expectation for Senior engineers in the orgs I've been a part of is that they are great problem finders, as well as problem solvers and implementers. If you have a significant backlog of useful improvements that are relatively straightforward to implement, then it's likely better to bring on a few junior engineers to tackle those rather than Seniors. If you're looking to turn the large backlog into a small backlog thanks to innovative solutions or break into new areas, Seniors tend to handle it better. The red flag in the ramp up curve is really for Senior engineers. If I didn't have a solid understanding and demonstrated ownership of my problem domain within six months along with meaningful projects getting pushed through - my manager would likely be starting an awkward conversation with me.
- hyperpape 9y ago
  This is really well said. Part of problem finding is also taking vague inputs "that subsystem is kinda wonky" and transforming it into "that system has these specific problems, which can be fixed with this approach, which will take roughly this long, and help out this much". The existing group may not have made tickets for something because they think "it'll take six months" or "we'll have to change x,y and z before that idea is gonna help us", because they don't have the time to analyze a known pain point for how painful it is, or even because they haven't thought of the improvement. Then someone realizes that those assumptions are wrong, and finds a big improvement.
  - mercutio2 9y ago
    If it doesn’t solve a problem the existing team already acknowledged, or at least very directly accelerate the fix for one of those problems, that doesn’t sound like a good outcome from a new hire to me.
    - hyperpape 9y ago
      I can't decide whether to agree with you or not. On the one hand, I think a lot of the changes I'm talking about changes that should accelerate the fix for problems you have (what team doesn't think "it's too hard to work with x" at some point?). On the other hand, I feel like you're coming at this from the perspective that your existing team is omniscient, or at least always knows better than someone new. We used to have that dynamic, and I think it's better that we're now more open to new ideas (onboarding is still way slower than I'd like, but it's improved).
      - mercutio2 9y ago
        Current team certainly isn’t omniscient. Just that you’re liable to make enemies, not friends/develop career, by coming in and proposing brand new, undesired/unforeseen changes and winning the argument with management. Brand new not-desired-by-team features/changes often end up owned and maintained by the existing team for a long time, often long after you’re gone. You, as a new person, probably aren’t shouldering much maintenance burden yet, bad to be perceived as adding more rather than reducing load. Much better to fix a generally acknowledged problem, reducing maintenance burden for the existing team.