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.
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)!
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 worked for a small company in the past, and if I saw something that I knew would impact me or someone else down the road, I generally fixed it then and there if I could do so in a short time frame without breaking anything.
You know the kinds of problems I'm talking about. If I don't spend 10 minutes to fix it now, it's going to cost me 30 minutes (over and over) later.
Otherwise, it went on the whiteboard with the other things to do (which was always full) and someone got around to it eventually.
You either clean it up when you're in someone else's house, or you step around their mess. Both choices can cause trouble. Which to choose depends entirely on you and your situation.
发布评论
评论（4）
对于这种情况，我有两个指导原则：
我来这里是为了做老板想要的事情。如果是扫地，我要么做，要么找另一份工作，但只要我在这里，这就是我要做的事。
如果老板做出了一个错误的决定，而我更了解并告诉他，而他无论如何都做出了决定，那么这是老板的特权。如果我不告诉他，那就是我的错。
除非有压倒性的情况，这表明在代码超出我的任务范围的情况下，我告诉我的老板代码可以做得更好，并让他了解这对他在现实世界中意味着什么，并询问他是否需要我做或不做。
是的，有时当我不这样做时，它确实会回来咬我，但他付钱给我做X，如果我修补Y，那么我就没有做我付钱去做的事情。当它确实回来咬我（我们）时，他只需付钱给我修理它！
I have two guiding principles in cases like this:
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.
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)!
我认为你的陈述的关键部分是这样的：
这听起来很刺耳，但它是基于经验的，应该以开放的心态来阅读 - 远离它。当你获得更多的开发经验时，你会学到的一件事是，你要留在范围内，不要潜入修复未计划的事情。以下是几个原因：
当有人规划项目时，他们正在处理一组已知的问题。如果你随机决定“修复”你正在改变的已知集合的东西，就像当你使用地图导航时，有人正在改变你的地图
您可能认为您的修复对产品有好处，但它引入了额外的复杂性，例如谁将测试您的修复？
无论您认为自己有多优秀，您都面临着在应用程序中引入另一个错误或意外副作用的风险
无论
您如何将您的更改传达给可能在该领域工作的其他团队成员？
您如何确定更改的范围，您如何知道您没有突然更改其他地方的一段代码的上下文？
你的意图是好的，但如果你开始做这样的事情，你可能会被视为牛仔，其他人很快就会不喜欢你。
这是你必须学习的一项技能——知道什么时候不要碰东西。你会看到丑陋的代码——不要碰！不要仅仅因为您认为可以做得更好就重新编码。
我希望这有帮助:)
I think the key part of your statement is this:
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 :)
我过去在一家小公司工作，如果我看到一些我知道会影响我或其他人的东西，我通常会立即修复它，如果我能在短时间内完成而不破坏任何东西。
你知道我正在谈论的问题类型。如果我现在不花 10 分钟来修复它，以后我将花费 30 分钟（一遍又一遍）。
否则，它就会和其他要做的事情一起出现在白板上（总是满的），最终有人抽出时间来处理它。
I worked for a small company in the past, and if I saw something that I knew would impact me or someone else down the road, I generally fixed it then and there if I could do so in a short time frame without breaking anything.
You know the kinds of problems I'm talking about. If I don't spend 10 minutes to fix it now, it's going to cost me 30 minutes (over and over) later.
Otherwise, it went on the whiteboard with the other things to do (which was always full) and someone got around to it eventually.
你要么在别人家里清理干净，要么绕过他们的烂摊子。这两种选择都会带来麻烦。选择哪一个完全取决于您和您的情况。
You either clean it up when you're in someone else's house, or you step around their mess. Both choices can cause trouble. Which to choose depends entirely on you and your situation.