10 ms·

The article is about how to make a positive impact as soon as possible, impressing people is only a side effect of that. It sounds like you're looking for tick

The article is about how to make a positive impact as soon as possible, impressing people is only a side effect of that. It sounds like you're looking for ticket monkeys; the article is about how to become more than that for the people that aspire to that. The fact that you call your new hires "newbies" and don't expect them to make suggestions for a year is a huge red flag for me. Either you didn't understand that the article is targeted towards experienced professionals switching jobs (first sentence), or you think that a professional will take an entire year to understand your org and be more productive than work on tickets. Most devs that I know worth their salt are comfortable switching jobs every 2 years or so (whether they choose to or not). The contrast between that and not even being expected to think for a year is massive.

w0m 9y ago
Depends on the size and life of the project and average term of service. If your project is a decade old and massive, where many on the team have been on the project for 5+ years - Yes, a 'newbie' needs a (non-trivial, 1 year could be too long or too short) amount of time to ramp up on why things are like they are before they can make a nuanced suggestion for improvement. A smaller project that's in a constant state of flux? Of course suggest giant overarching changes when they appear to make sense. What's proper depends heavily on the context of the group and project.
- hyperpape 9y ago
  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.
gwbas1c 9y ago
> don't expect them to make suggestions for a year That's not the problem. The problem is that some newbies want all of the code to be their design pattern of choice; or just want to refactor things until they understand it. Some will just refuse to follow established design patterns and do things like bypass our dependency injector. For me, it's a red flag whenever someone comes on a team and immediately wants to refactor to use their favorite design patterns, frameworks or style. It's not that their preferred design patterns are better or worse than what we're using; it's that you just don't refactor code on a say-so.
- roesel 9y ago
  I feel like the article is not about this at all though. If you behaved according to the algorithm as a newbie, you would only refactor and change the design pattern if people told you that that should be done. Which your newbies weren't told according to what you're saying.
  - gwbas1c 9y ago
    No, but I'm responding to the comment.
mercutio2 9y ago
It sometimes seems like we software developers travel in really distinct worlds. People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org, and they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome. The idea is that coming in and working on the problems you’re assigned is good because you can more deeply understand the problem space AND make things better. I expect this, better and faster and with more humility and wisdom, from senior engineers. That doesn’t make anyone a ticket monkey in my book, it makes them effective at their very highly paid job. As an aside, I highly recommend the article’s strategy for appearing (and hopefully actually being) wise and humble, as long as you’re getting your assigned, bare minimum work done. Anyway, it sounds like maybe we mutually wouldn’t want to work with one another, which is why it seems like we live in different worlds to me.
- JackFr 9y ago
  > they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome. I think there's a role for humility on both sides. In my current role, I was an experienced hire. After a month on the job my manager and his manager pulled me aside and said "What are we doing wrong?" The interesting thing was that when I told them that I thought their module system was seemed backwards, the response was "Yeah, we know. It's a quirk of history that it ended up that way, and we've got a plan to fix it. Anything else?" They very much valued a fresh set of eyes to ensure that they weren't missing something they had become house-blind to. At the same time, as a set of fresh eyes your attitude should be one of questioning, "Why are we doing it that way?" rather than "We're doing it wrong" or "This way is better".
  - mercutio2 9y ago
    This is an excellent tool for the manager toolbox, thanks for sharing. Agreed that it’s great to get the fresh eyes benefits recorded/locked down. The key is understanding that your teammates are probably pretty smart, you can learn a lot from them. You’re probably really smart, too, better to show your new team this with actions and quiet side conversations than showy pushes for unwelcome change, at least for the first year.
rdiddly 9y ago
Why the bias against solving problems that are ticketed? Problems that haven't been discovered yet are seldom more important than the ones that have already been discovered. Unless we're optimizing for your ego, or the existing team truly are idiots whose entire list of known problems deserves to be blown off. (Or more gently, they've made some glaring oversight of a worthwhile value-adding solution.) Anyway, the article is more about humbly learning how the team works, not about rewriting their codebase just yet, i.e. the opposite of your point about "ticket monkeys."
smsm42 9y ago
I don't know about a year, but usually understanding how things work take time. Understanding why they work this way and not another also takes time. If somebody doesn't take time to learn the background of decisions taken, they are liable to repeat the same mistakes and stumble at the same bumps as have been already passed before and encoded in organization's common lore. There is something called Chesterton fence principle: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence - before proposing to change something, give it an earnest try to figure out why it was like this before, and what changed. Sometimes there's no good reason, or the reason once existing is long gone, and a fresh eye is useful to shake out those cases. In other cases, there are complex and unobvious reasons that cost a significant effort to figure out, and may be not apparent to the fresh eye. So it's better to keep an open and humble mind and at least at first, approach new system with the attitude "please help me learn why it's like this" instead of "this looks wrong, let's throw it away and re-do it from scratch". I'm not sure about a year, but at least a month or two would probably be appropriate. And my experience showed dealing with bugs can actually be very instructive about how things work and why they work this way and not the other.

w0m 9y ago

Depends on the size and life of the project and average term of service. If your project is a decade old and massive, where many on the team have been on the project for 5+ years - Yes, a 'newbie' needs a (non-trivial, 1 year could be too long or too short) amount of time to ramp up on why things are like they are before they can make a nuanced suggestion for improvement. A smaller project that's in a constant state of flux? Of course suggest giant overarching changes when they appear to make sense. What's proper depends heavily on the context of the group and project.

hyperpape 9y ago
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.

gwbas1c 9y ago

> don't expect them to make suggestions for a year That's not the problem. The problem is that some newbies want all of the code to be their design pattern of choice; or just want to refactor things until they understand it. Some will just refuse to follow established design patterns and do things like bypass our dependency injector. For me, it's a red flag whenever someone comes on a team and immediately wants to refactor to use their favorite design patterns, frameworks or style. It's not that their preferred design patterns are better or worse than what we're using; it's that you just don't refactor code on a say-so.

roesel 9y ago
I feel like the article is not about this at all though. If you behaved according to the algorithm as a newbie, you would only refactor and change the design pattern if people told you that that should be done. Which your newbies weren't told according to what you're saying.
- gwbas1c 9y ago
  No, but I'm responding to the comment.

mercutio2 9y ago

It sometimes seems like we software developers travel in really distinct worlds. People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org, and they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome. The idea is that coming in and working on the problems you’re assigned is good because you can more deeply understand the problem space AND make things better. I expect this, better and faster and with more humility and wisdom, from senior engineers. That doesn’t make anyone a ticket monkey in my book, it makes them effective at their very highly paid job. As an aside, I highly recommend the article’s strategy for appearing (and hopefully actually being) wise and humble, as long as you’re getting your assigned, bare minimum work done. Anyway, it sounds like maybe we mutually wouldn’t want to work with one another, which is why it seems like we live in different worlds to me.

JackFr 9y ago
> they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome. I think there's a role for humility on both sides. In my current role, I was an experienced hire. After a month on the job my manager and his manager pulled me aside and said "What are we doing wrong?" The interesting thing was that when I told them that I thought their module system was seemed backwards, the response was "Yeah, we know. It's a quirk of history that it ended up that way, and we've got a plan to fix it. Anything else?" They very much valued a fresh set of eyes to ensure that they weren't missing something they had become house-blind to. At the same time, as a set of fresh eyes your attitude should be one of questioning, "Why are we doing it that way?" rather than "We're doing it wrong" or "This way is better".
- mercutio2 9y ago
  This is an excellent tool for the manager toolbox, thanks for sharing. Agreed that it’s great to get the fresh eyes benefits recorded/locked down. The key is understanding that your teammates are probably pretty smart, you can learn a lot from them. You’re probably really smart, too, better to show your new team this with actions and quiet side conversations than showy pushes for unwelcome change, at least for the first year.

rdiddly 9y ago

Why the bias against solving problems that are ticketed? Problems that haven't been discovered yet are seldom more important than the ones that have already been discovered. Unless we're optimizing for your ego, or the existing team truly are idiots whose entire list of known problems deserves to be blown off. (Or more gently, they've made some glaring oversight of a worthwhile value-adding solution.) Anyway, the article is more about humbly learning how the team works, not about rewriting their codebase just yet, i.e. the opposite of your point about "ticket monkeys."

smsm42 9y ago

I don't know about a year, but usually understanding how things work take time. Understanding why they work this way and not another also takes time. If somebody doesn't take time to learn the background of decisions taken, they are liable to repeat the same mistakes and stumble at the same bumps as have been already passed before and encoded in organization's common lore. There is something called Chesterton fence principle: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence - before proposing to change something, give it an earnest try to figure out why it was like this before, and what changed. Sometimes there's no good reason, or the reason once existing is long gone, and a fresh eye is useful to shake out those cases. In other cases, there are complex and unobvious reasons that cost a significant effort to figure out, and may be not apparent to the fresh eye. So it's better to keep an open and humble mind and at least at first, approach new system with the attitude "please help me learn why it's like this" instead of "this looks wrong, let's throw it away and re-do it from scratch". I'm not sure about a year, but at least a month or two would probably be appropriate. And my experience showed dealing with bugs can actually be very instructive about how things work and why they work this way and not the other.