|
If you suffer from multiple personality disorder, does it count as fixing a co-workers bugs?
|
|
|
|
|
If co-worker is my friend or a beautiful girl I would hop in and help them out.
If its opposite case then I will help if I requested, to show that I have a good heart to help to no-friend and make them as a friend
Thanks,
•…♥…ЯΚ…♥…•
|
|
|
|
|
Great! Now I know who to look first when I need help.
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
Cheers...!!!
Thanks,
•…♥…ЯΚ…♥…•
|
|
|
|
|
"Yes, but I go and let the air out of their tires afterwards!"
Anything that is unrelated to elephants is irrelephant Anonymous ----- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 ----- I'd just like a chance to prove that money can't make me happy. Me, all the time
|
|
|
|
|
All 3 yes options should be available. If the bug is preventing me or another co-worker from getting their stuff done ill just jump in and get it fixed. Also if i come across a bug i will fix it after-all we are a team and playing the blame game does nothing but take more time. So if i just stumble across a bug ill fix it up then just let the dev know when i have it fixed.
Don't comment your code - it was hard to write, it should be hard to read!
|
|
|
|
|
Not sure what you think the missing option is - sounds like you should just pick "Yes" as you'll fix any bug...
|
|
|
|
|
|
Generally, I'd straight up sort out the bug myself. But it really depends on the context. If the bug is caused by code written by a junior programmer who's recently started the job, I'd task them with solving it. This is mainly to help them improve their abilities in resolving code bugs. If, however, they take too long solving the issue, I'd definitely jump in and help.
In goes the energy drinks & pot noodles, out comes code.
|
|
|
|
|
Yes whenever I find one which I know how to fix....
Prabhat Singh
Software Engineer
"Developing software from requirements is like walking on water,both are easier when the later is frozen"
|
|
|
|
|
If you see a bug you should fix, or if you have a process, at least raise it.
Who cares who was the original writer?
Obviously you do need to be 100% sure it is a bug.
|
|
|
|
|
I think this is a type of question where mutually exclusive choices can't provide much real data.
So much depends on one's role, and the context.
Compare being a programmer on a team where the "technical culture" uses Agile, Scrum, MMA, or some other collaborative software development methodology, with frequent code-reviews ... with being an off-site contractor working on specific delegated tasks
In any case, I think that if there is a QA reporting procedure, then it would seem "criminal" not to, at least. report bugs you notice whether or not they are directly affecting your code.
If your role in getting software into golden-master and out-the-door is to do "whatever it takes;" there may not be enough time to flag QA, or signal your colleague who wrote the code. You just fix it, pronto.
“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet
|
|
|
|
|
Although I do help other students with solving bugs. Does that count?
(I am the only employee of my 'company', so if there is a bug, and it isn't in 3rd party code, I put it there, so I fix it).
<voice type="Ebeneezer Scrooge"> Bah. dumb bugs </voice>
|
|
|
|
|
I actually think this question should accept multiple answers.
Actually, I will correct other bugs if it is an "ancient" bug and the person is not working on that problem anymore, if I am told to, if the bug must be solved to let me (or someone else) advance in their work and possibly many other reasons.
Yet, I will not correct a bug if the other developer just put the bug there. I will ask him to correct the bug. I can help him correct the bug by explaining alternatives etc, but simply it is unnaceptable to keep correcting other's bugs while they are still creating new bugs.
|
|
|
|
|
|
I usually point out the "oops" and a possible fix.
Steve
_________________
I C(++) therefore I am
|
|
|
|
|
since there is no bacon in team that means we have to share everything. expect me however to share bacon and you have another coming to you.
|
|
|
|
|
And for the sake of projects, the answer should be YES
|
|
|
|
|
I'm fortunate to work for a director who still codes - and we've no ego problems about calling for help (someone else's eyes) to find/fix a problem. We also have different expertise. Sharing ideas, possible solutions, etc.
By and large, a gestalt.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
....there's a full stop at the end of each answer, sometimes there isn't.
|
|
|
|
|
A simple yes. Anything else and you're a selfish, pretentious prat.
The key is knowing what to fix, how, and when. Fixing a bug does not mean rewriting someone's code just because you don't like how they did something or the coding style. It does mean making sure you know what you're doing, and that you're not breaking something else with your change. If the change is significant, it also means that the original author knows what you're doing and why.
In other words, since this question is only meaningful in a cooperative development environment, that you respect and cooperate with your fellow team members. I've worked with the same group of folks for nearly 15 years now. We've written several million lines of code together. Our products have been successful, and there have been relatively few major disasters along the way. This only happened because we maintain a fair professional courtesy with each other while we fix each other's bugs. If it's minor, we leave a comment. If it's major, we talk to the author and make sure we understand what's going on. Sometimes the answer is "yeah, that code's always been flaky." Sometimes it's "don't touch it - I've got a fix waiting until after XYZ is ready."
Software Zen: delete this;
|
|
|
|
|
No,
The only profesional thing to do, is to report the bug in TFS ( or simular ) and let a superior decide by who and when ( if at all ) to fix the bug.
If you fix the bug and unwilingly break other code that depends on the broken code then you are responseble and should be fired.
My second computer is your linux box.
|
|
|
|
|
It sounds like your workplace differs substantially from mine. My management doesn't care who fixes the bug, just that it gets fixed. In fact, I think they would wonder why we needed them to make the decision.
Software Zen: delete this;
|
|
|
|
|
What if you were in the middle of a critical piece of code that had to be released ASAP and you worked on fixing a bug that your lead knew could be fixed by someone else who was idle at that point? If it's a big bug you would be delaying launch by fixing the bug instead of delegating.
cheers
Chris Maunder
|
|
|
|
|
I'm criticising the attitude presented by the "No, I won't fix other people's bugs" responses in the poll. My point is that you should decide whether or not to fix the bug based on what's best for the product and the company, not on whose code it is. The example you cite is obvious - 'you' should tell the lead that you're busy with the critical piece of code, and to ask the idle guy to work on it instead. For that matter, in my workplace, I'd go ask idle guy to work on it myself.
Software Zen: delete this;
|
|
|
|