How to do your best when everybody is too busy? [closed]

Question

Sometimes I have seen some code or part of the project which I could improve but is not related with my current team project.

Those times I have a conflict because despite wanting to help, many teams lack enough people and doing extra work seems like betrayal. Obviously any managers will appreciate much more if you focus your effort on their tasks

What do you do in in these cases?

Answer 1

I have two guiding principles in cases like this:

1. I am here to do what my boss wants. If it's sweep the floors I can either do it or find another job but as long as I'm here that's what I'm to do.

2. If the boss makes a bad decision and I know better and tell him and he decides it anyway, it's the boss's prerogative. If I don't tell him then it's my fault.

Unless there's overriding circumstances this dictates that in the case where the code is outside my assignment I tell my boss that the code can be made better, and give him an idea what that means to him in real world terms, and ask whether he wants me to do it or not.

Yes, it does come back to bite me sometimes when I don't just do it, but he's paying me to do X and if I'm tinkering with Y then I'm not doing what I'm paid to do. He just has to pay me to fix it when it does come back to bite me(us)!

Answer 2

I think the key part of your statement is this:

which I could improve but is not related with my current team project

This sounds harsh, but it is based on experience and should be read with an open mind - keep out of it. One thing you learn as you get more dev experience under your belt is that you stay in scope, don't go diving off to fix something that is not scheduled. Here are a couple of reasons why:

• when someone is planning the project, they are working with a known set of problems. If you randomly decide to "fix" things you are changing that known set, it is like when you are navigating using a map and someone is changing the map on you

• you may think your fix is good for the product but it introduces extra complexities, like who is going to test your fix?

• no matter how good you think you are, you run the risk of introducing another bug or unintended side effects into the application

• how do you communicate your change to the other team members who may be working in that area?

• how do you know for sure the scope of your change, how do you know that you haven't suddenly changed the context of a piece of code elsewhere?

You have good intentions, but if you start doing things like this you may be seen as a cowboy, and others will dislike you pretty quickly.

It is a skill you have to learn - know when not to touch things. You will see ugly code - don't touch! Don't recode things simply because you think it can be done better.

I hope this helps :)