5 ms·

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied. You don't have ground to stand on, and even if your input is right, and well reasoned, it can't come _from you_ because your voice has no weight. By all means, try to change the system, but telling others they should too is advice from an extremely privileged position.

nix23 6y ago
First i do what my boss says, when i did that and we both have a little time to talk, i explain to him why i was thinking the other stuff was more important, often he has a good point from a complete different perspective than i have, sometimes i 'win' from my 'technical' perspective, after some time passes you learn to read each other and decision's are made without questions, for me its super important to know each others and the base where decision's are made.
eska 6y ago
Yeah, the best you can do at that point is to meticulously document your work. You don't want to look unproductive and get fired just because you're constantly stopped from releasing your work. And in the case that you do get fired, you will want to give your lawyer some ammunition in the form of work logs outside of the ticket system, which you will be barred from.
WrtCdEvrydy 6y ago
I will usually drop a small comment saying 'deprioritized due to OTHER_TICKET_NAME' and mark the ticket as Done.
Etheryte 6y ago
I sincerely disagree. Taking the extreme case you described as either do it or be fired, the other party wants a result, a task done or something similar, which still won't be done if they would fire you on the spot. It seems you misread my reasoning as blindly standing your ground which is not the case I was making. If there is a good reason to switch what you're working on, you should, as I also said above. But if there isn't one, you should either ask until you get a good reason or stand your ground. The argument from privilege frankly confuses me. I've applied the same principles both when I've been the underdog and the one asking others and it's good guidance since it also gives you input whether you want to work where you currently are. Sometimes I've had harder times because of it, but I've never stayed in an abusive work relationship.
- cerberusss 6y ago
  I remember when I had ~3 years of working experience. We were on the tail end of a fixed price/fixed date contract. There was a bug that needed to be fixed, and it was in a module that everybody had worked on, and the code was pretty bad. So during the meeting, I said: that bug is just a sympthom, the module needs to be rewritten. And I knew what I was talking about. No, said a senior, we're just going to fix the bug, no rewriting. I said that's your call, but I sure am not going to fix that bug. I can tell you: nobody listened to me. So he more or less finished the discussion and said: I'm going to sit down with you, and we're going to fix that bug. And we did. At that point it was the right call.
  - Etheryte 6y ago
    In that case there clearly is a good reason though? In the scenario described, you have one known bug, in the case of a rewrite you have an unknown number of bugs. Surely, both approaches may have more unnoticed bugs in them but in the former case people have already tested the solution so that's less likely. When you rewrite, you enter new untested territory with more room for new bugs.
- TheRealPomax 6y ago
  Every junior and intermediate dev would like a word with that concept, because it sounds magical. Once you have a few years at an org under your belt, you have the creds to pipe up, but until then, you either talk with the better devs in private and hopefully convince them, or you do what your boss told you to do.

nix23 6y ago

First i do what my boss says, when i did that and we both have a little time to talk, i explain to him why i was thinking the other stuff was more important, often he has a good point from a complete different perspective than i have, sometimes i 'win' from my 'technical' perspective, after some time passes you learn to read each other and decision's are made without questions, for me its super important to know each others and the base where decision's are made.

eska 6y ago

Yeah, the best you can do at that point is to meticulously document your work. You don't want to look unproductive and get fired just because you're constantly stopped from releasing your work. And in the case that you do get fired, you will want to give your lawyer some ammunition in the form of work logs outside of the ticket system, which you will be barred from.

WrtCdEvrydy 6y ago

I will usually drop a small comment saying 'deprioritized due to OTHER_TICKET_NAME' and mark the ticket as Done.

Etheryte 6y ago

I sincerely disagree. Taking the extreme case you described as either do it or be fired, the other party wants a result, a task done or something similar, which still won't be done if they would fire you on the spot. It seems you misread my reasoning as blindly standing your ground which is not the case I was making. If there is a good reason to switch what you're working on, you should, as I also said above. But if there isn't one, you should either ask until you get a good reason or stand your ground. The argument from privilege frankly confuses me. I've applied the same principles both when I've been the underdog and the one asking others and it's good guidance since it also gives you input whether you want to work where you currently are. Sometimes I've had harder times because of it, but I've never stayed in an abusive work relationship.

cerberusss 6y ago
I remember when I had ~3 years of working experience. We were on the tail end of a fixed price/fixed date contract. There was a bug that needed to be fixed, and it was in a module that everybody had worked on, and the code was pretty bad. So during the meeting, I said: that bug is just a sympthom, the module needs to be rewritten. And I knew what I was talking about. No, said a senior, we're just going to fix the bug, no rewriting. I said that's your call, but I sure am not going to fix that bug. I can tell you: nobody listened to me. So he more or less finished the discussion and said: I'm going to sit down with you, and we're going to fix that bug. And we did. At that point it was the right call.
- Etheryte 6y ago
  In that case there clearly is a good reason though? In the scenario described, you have one known bug, in the case of a rewrite you have an unknown number of bugs. Surely, both approaches may have more unnoticed bugs in them but in the former case people have already tested the solution so that's less likely. When you rewrite, you enter new untested territory with more room for new bugs.
TheRealPomax 6y ago
Every junior and intermediate dev would like a word with that concept, because it sounds magical. Once you have a few years at an org under your belt, you have the creds to pipe up, but until then, you either talk with the better devs in private and hopefully convince them, or you do what your boss told you to do.