5 ms·

Did the author go behind his manager’s back to pick up the task, or was it assigned? Because if it’s the former, it’s possible that the issue was not addressed

Did the author go behind his manager’s back to pick up the task, or was it assigned? Because if it’s the former, it’s possible that the issue was not addressed because it wasn’t deemed high-priority compared to other tasks, regardless of the number of user complaints. If it’s the latter, well, I don’t know. Congratulations on completing an assigned task at your job?

withinboredom 3y ago
Seemed like it was a case of "cannot reproduce" and any attempt at reproducing it failed. Since it couldn't be reproduced, it was never prioritized because it never made it past triage. At least that's the workflow I imagine when reading this and from working at similar places. Also, I advise leaving a place that requires your manager to dictate which tickets you work on. Sounds like a crappy place to work.
- LambdaComplex 3y ago
  > I advise leaving a place that requires your manager to dictate which tickets you work on As someone who recently left a place like that: I agree. I'm a highly-paid professional; it was really frustrating to feel like my manager didn't trust me enough to figure out what I needed to work on.
  - bryanrasmussen 3y ago
    It really depends on what you are shipping: 1. does what you are shipping have lots of international regulations and compliance requirements per country it will be available in with new countries being rolled out on a planned basis -> your manager will determine what you should work on 2. Are there things being released on a set date due to some sort of legal requirement, business deal? -> your manager will determine what you should work on 3. Is it basically the same product in all markets / countries other than internationalized text with not pending contracts or business deals requiring specific functionalities impacting the company? You should be able to determine what you should be working on.
    - withinboredom 3y ago
      I disagree. Though (1) and (2) are good points, but they shouldn't be telling you what to work on at the individual ticket level. Even then, they should prioritize and set a healthy deadline (if appropriate); and that is it. Implementing a high priority ticket may still require addressing technical debt to implement, or dealing with other lower priority tickets first -- because they block the new, higher priority ticket. If your manager needs to know all these details and can tell you "no, you can't fix X to build Y" then I really think that is a crappy place to work; not just due to the politics involved, but also the code must be absolute crap.
  - maccard 3y ago
    Manager/Tech Lead here who had someone who would choose their tickets themselves. It's a giant pain and makes my job 10x more difficult when I tell another team that something that's low priority to us but high priority to them that something will be done, and instead find it sitting in in-progress with a tech debt bugbear of theirs in review. The priority on the ticket was set for a reason, it was assigned and scheduled for a reason. There's only so many hours in the day to explain why some things are prioritised. If you think that's wrong, be a professional and talk to me about it. I promise you, I want to have the conversation that you need to actually work with your team far less than you want to fix that JSON output.
    - withinboredom 3y ago
      You’re a manager, not a dictator. Manage that shit. If it’s a low priority for you but not for someone else, you are prioritizing wrong. Don’t complain because someone doesn’t want to play politics with you. Learn your team, play to their strengths.
      - maccard 3y ago
        There's a wide berth between being a manager who prioritises work and a dictator that assigns out stack ranked tickets with no end in sight. My job is to make sure the teams priorities are straight, and I can't do that if you or someone else are subterfuging my efforts to do so. Unless otherwise demonstrated, I trust that you (my team member in this case) are a smart, well intentioned person, and I ask that you assume the same of me. Going behind my back because you don't like what I'm asking you to do is "otherwise demonstrated".
        withinboredom 3y ago
        A team member and manager don’t operate in a vacuum. It’s your job to communicate priorities and ensure the team buys in to the priorities. If they don’t and you didn’t get that buy in, then you can’t blame them for having their own priorities. You can say “these are the priorities” all day long, but so can anyone. The team, as a team, should agree on the priorities. Your job is to communicate the business priorities, the teams job is to turn them into technical priorities which may or may not match the business’s exactly. If you’re not getting the last part and communicating it back upstream, you’re not doing your job.
- generic92034 3y ago
  > Also, I advise leaving a place that requires your manager to dictate which tickets you work on. Sounds like a crappy place to work. Would that not depend greatly on the type of ticket and the type of developer? In my experience some developers are happily working on tickets with minor impact while there are high priority tickets, where a customer is really losing money, which get no attention from them.
  - withinboredom 3y ago
    I guess that largely depends on hiring practices. If you are hiring people who prioritize “incorrectly” then you’ll have people doing the wrong thing. I usually see this filtered out by having a list of issues in the “code test” and then seeing which ones they do first and asking why.
    - ddalex 3y ago
      I feel this has nothing to do with hiring - people will change focus over time, sometimes multiple times every day. The manager is there to prioritise, to make sure everybody has the same understanding of the priorities, and to unblock progress, among other things. As a manager, I am not telling people how to do their work, I am telling them what I think it is important to deliver. I don't even make the feature list, that is the job of a product designer. Absolutely nothing in the "code test" provides any insight into how a developer would prioritise work within a product - it only tells if and how the developer can develop code up to the standards. So I think in this regard the manager assigning the task is the correct choice - the product has a deficiency, and the manager is directing a team member to fix the deficiency. If some developer wants to make their own product prioritisation decisions, they are more then welcome to develop their own product, possibly inside the same company.
      - maccard 3y ago
        Completely agree. As someone in the same role (well a small company so I'm also the "designer" in many cases), the appropriate thing to do is to tell me you disagree with the priority, and we'll talk about it. But if you're questioning every priority, and ignoring the priority, then you're not doing your job. You're doing my job without the information that I have.
- javier123454321 3y ago
  I mean, up until which point do you have full autonomy of the work you do in a bigger org? I might be misunderstanding your point, but I've only ever seen a developer that gets to choose whatever they want to work on in solo, early stage, or bootstrapped startups.
  - withinboredom 3y ago
    I worked in 5k+ size companies. You didn’t choose your product per se (though you did agree to work for the company on that team), but you had influence over the roadmap and could choose your tickets (even create new ones and create entire — gated — features if you wanted). The team had autonomy and the leads were fantastic at fostering it.
LambdaComplex 3y ago
The author says "I had never looked at this code, but was told to take a look," so I assume they weren't doing this behind their manager's back.
javier123454321 3y ago
The manager told me something along the lines of "hey this has been causing issues, can you take a look? Others haven't been able to figure this out." It's the latter part of the statement that I was musing over in the article. I'll take the sarcastic congrats, though, better than internet name calling.
- mypastself 3y ago
  Must have missed that part. But my intention wasn’t to offend. It felt like the part about solving a problem other developers couldn’t was the main crux of the article, and the insight about inertia in big companies was tacked on. But I’m sure others will disagree.
cratermoon 3y ago
I read it as saying everybody else gave excuses to get out of dealing with it while the author went ahead and did it when assigned, even though all the previous people had said it couldn't be fixed.
dontupvoteme 3y ago
I don't work in a software company so I found it interesting to see how things can become dysfunctional there.

withinboredom 3y ago

Seemed like it was a case of "cannot reproduce" and any attempt at reproducing it failed. Since it couldn't be reproduced, it was never prioritized because it never made it past triage. At least that's the workflow I imagine when reading this and from working at similar places. Also, I advise leaving a place that requires your manager to dictate which tickets you work on. Sounds like a crappy place to work.

LambdaComplex 3y ago
> I advise leaving a place that requires your manager to dictate which tickets you work on As someone who recently left a place like that: I agree. I'm a highly-paid professional; it was really frustrating to feel like my manager didn't trust me enough to figure out what I needed to work on.
- bryanrasmussen 3y ago
  It really depends on what you are shipping: 1. does what you are shipping have lots of international regulations and compliance requirements per country it will be available in with new countries being rolled out on a planned basis -> your manager will determine what you should work on 2. Are there things being released on a set date due to some sort of legal requirement, business deal? -> your manager will determine what you should work on 3. Is it basically the same product in all markets / countries other than internationalized text with not pending contracts or business deals requiring specific functionalities impacting the company? You should be able to determine what you should be working on.
  - withinboredom 3y ago
    I disagree. Though (1) and (2) are good points, but they shouldn't be telling you what to work on at the individual ticket level. Even then, they should prioritize and set a healthy deadline (if appropriate); and that is it. Implementing a high priority ticket may still require addressing technical debt to implement, or dealing with other lower priority tickets first -- because they block the new, higher priority ticket. If your manager needs to know all these details and can tell you "no, you can't fix X to build Y" then I really think that is a crappy place to work; not just due to the politics involved, but also the code must be absolute crap.
- maccard 3y ago
  Manager/Tech Lead here who had someone who would choose their tickets themselves. It's a giant pain and makes my job 10x more difficult when I tell another team that something that's low priority to us but high priority to them that something will be done, and instead find it sitting in in-progress with a tech debt bugbear of theirs in review. The priority on the ticket was set for a reason, it was assigned and scheduled for a reason. There's only so many hours in the day to explain why some things are prioritised. If you think that's wrong, be a professional and talk to me about it. I promise you, I want to have the conversation that you need to actually work with your team far less than you want to fix that JSON output.
  - withinboredom 3y ago
    You’re a manager, not a dictator. Manage that shit. If it’s a low priority for you but not for someone else, you are prioritizing wrong. Don’t complain because someone doesn’t want to play politics with you. Learn your team, play to their strengths.
    - maccard 3y ago
      There's a wide berth between being a manager who prioritises work and a dictator that assigns out stack ranked tickets with no end in sight. My job is to make sure the teams priorities are straight, and I can't do that if you or someone else are subterfuging my efforts to do so. Unless otherwise demonstrated, I trust that you (my team member in this case) are a smart, well intentioned person, and I ask that you assume the same of me. Going behind my back because you don't like what I'm asking you to do is "otherwise demonstrated".
      - withinboredom 3y ago
        A team member and manager don’t operate in a vacuum. It’s your job to communicate priorities and ensure the team buys in to the priorities. If they don’t and you didn’t get that buy in, then you can’t blame them for having their own priorities. You can say “these are the priorities” all day long, but so can anyone. The team, as a team, should agree on the priorities. Your job is to communicate the business priorities, the teams job is to turn them into technical priorities which may or may not match the business’s exactly. If you’re not getting the last part and communicating it back upstream, you’re not doing your job.
generic92034 3y ago
> Also, I advise leaving a place that requires your manager to dictate which tickets you work on. Sounds like a crappy place to work. Would that not depend greatly on the type of ticket and the type of developer? In my experience some developers are happily working on tickets with minor impact while there are high priority tickets, where a customer is really losing money, which get no attention from them.
- withinboredom 3y ago
  I guess that largely depends on hiring practices. If you are hiring people who prioritize “incorrectly” then you’ll have people doing the wrong thing. I usually see this filtered out by having a list of issues in the “code test” and then seeing which ones they do first and asking why.
  - ddalex 3y ago
    I feel this has nothing to do with hiring - people will change focus over time, sometimes multiple times every day. The manager is there to prioritise, to make sure everybody has the same understanding of the priorities, and to unblock progress, among other things. As a manager, I am not telling people how to do their work, I am telling them what I think it is important to deliver. I don't even make the feature list, that is the job of a product designer. Absolutely nothing in the "code test" provides any insight into how a developer would prioritise work within a product - it only tells if and how the developer can develop code up to the standards. So I think in this regard the manager assigning the task is the correct choice - the product has a deficiency, and the manager is directing a team member to fix the deficiency. If some developer wants to make their own product prioritisation decisions, they are more then welcome to develop their own product, possibly inside the same company.
    - maccard 3y ago
      Completely agree. As someone in the same role (well a small company so I'm also the "designer" in many cases), the appropriate thing to do is to tell me you disagree with the priority, and we'll talk about it. But if you're questioning every priority, and ignoring the priority, then you're not doing your job. You're doing my job without the information that I have.
javier123454321 3y ago
I mean, up until which point do you have full autonomy of the work you do in a bigger org? I might be misunderstanding your point, but I've only ever seen a developer that gets to choose whatever they want to work on in solo, early stage, or bootstrapped startups.
- withinboredom 3y ago
  I worked in 5k+ size companies. You didn’t choose your product per se (though you did agree to work for the company on that team), but you had influence over the roadmap and could choose your tickets (even create new ones and create entire — gated — features if you wanted). The team had autonomy and the leads were fantastic at fostering it.

LambdaComplex 3y ago

The author says "I had never looked at this code, but was told to take a look," so I assume they weren't doing this behind their manager's back.

javier123454321 3y ago

The manager told me something along the lines of "hey this has been causing issues, can you take a look? Others haven't been able to figure this out." It's the latter part of the statement that I was musing over in the article. I'll take the sarcastic congrats, though, better than internet name calling.

mypastself 3y ago
Must have missed that part. But my intention wasn’t to offend. It felt like the part about solving a problem other developers couldn’t was the main crux of the article, and the insight about inertia in big companies was tacked on. But I’m sure others will disagree.

cratermoon 3y ago

I read it as saying everybody else gave excuses to get out of dealing with it while the author went ahead and did it when assigned, even though all the previous people had said it couldn't be fixed.

dontupvoteme 3y ago

I don't work in a software company so I found it interesting to see how things can become dysfunctional there.