|
The biggest question with the way people are shuffled around between projects is if the person who wrote the old code is currently on the project.
If they're not I might have a quick chat to confirm my understanding of what the code is supposed to do (assuming it hasn't been so long they forgot); but by default I'm the person who has to fix it.
If they're on the project at the present time: I generally give them right of first refusal; which is nuanced by if it's something that's a trivial fix or complex, and if it's a critical blocker or I can wait a few days until they're able to work on it.
How I feel about the person can occasionally have something to do with it. I was a lot more likely to say "No. It's your bug, you fix it." when I had the misfortune to be dealing with a (former) cow-orker who was blasting the project with a stream of almost never worked right the first ( ...or second, or third ...) time; especially when a significant number of his fails were so severe I was unconvinced he did any "testing" beyond "did it compile" before committing the initial version.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I generally don't mind fixing someone else's bug, although I might consult them for ideas. They can fix my bugs as well.  It's good for cross knowledge training. You don't want dark hole sections of code that only "Jimmy" knows how to fix.
|
|
|
|
|
This is a tricky subject, you have to deal with ego and such. I've been in shops where its OK, and others where it is agony when a problem like this arises. To me, I always ask myself, will this problem hurt the product or company, and I let that be my guide; after all, we are there to make the company money not stroke our own ego.
|
|
|
|
|
Most of the time I fix their bugs... but they rarely fix MY bugs...
|
|
|
|
|
Because : I - the handsome one - am the one who made them, and my co-workers will fix them.
It's just unlucky to be my co-worker . . . 
|
|
|
|
|
There are just bugs in the software and they need to be fixed. The system I work on was originally written in 1990's by people who are not with the company or even in the industry any more - you bet I fix "their" bugs.
|
|
|
|
|
Agreed. Where I work we are all a team, and we do whatever needs to be done to deliver a successful project.
|
|
|
|
|
Personally I’m quite happy with that.
I appreciate a ‘heads up’, but I cannot be anything but happy when somebody is willing to put in the effort required to work on something I’ve done - as long as they also make sure that unit and integration tests are still working.
Ideally I’d also like to see a regression test that ensures that the bug stays fixed in the future too. 
|
|
|
|
|
But when the bug was actually a feature and the clever fella that fixed it hadn't bothered to read the documentation, Grrrrr!!!
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
By documentation, you mean the manual? I would understand not reading that, but ignoring comments in the code about its featurefulness would be pretty thick of them.
|
|
|
|
|
If you come from an engineering background the rule is 'when all else fails, try reading the manual'. 
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
At one job I had, every bug that came in was assigned a 'caused by' as in who's code broke the build. Developers then got assigned bugs to fix on the number they caused, but they were generally other people's bugs. The idea was that the more care you took in development the less time you had to spend in maintenance. I thought it was a good idea.
|
|
|
|
|
Of course, taking a less positive view, you're putting the eggs in the basket of the clumsiest.
| "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 |
|
|
|
|
|
all are expert than me at current company. but if I ask to assist me, then my assignment will be done by them not allowing me to do at all  .
|
|
|
|
|
"I don't have coworkers."
|
|
|
|
|
What happened to "we don't have bugs"?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: "we don't have bugs"?
That's a synonymous for "we don't have users".
|
|
|
|
|
Nope, we just document the bugs and call 'em "features"! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
I just claim the bugs were caused by the Chaos Theory. If you ramble long enough about how it apparently applies people lose interest in complaining fairly quickly.
|
|
|
|
|
Although I work in a large business with many software devs and teams I tend to work solely on projects by myself.
|
|
|
|
|
It might not be a bug - it could be I misinterpreted it - or it might be a bug which makes his code work.
If I fix it, it could break his code.
I'd talk it over and work out a solution that doesn't break anyones code before I went ahead unilaterally.
Not that it happens here, obviously.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Oh, and of course this won't be an issue if it is related to a CListCtrl...
This said, which was the first bacon and listctrl post here  ...
Yes, we do it... once a bug is detected we try to find out what has originated it and then we try to solve it as a team.
|
|
|
|
|
I usually tell the author about the bug, and ask if he wants me to fix it or if he prefers to fix it by himself.
|
|
|
|
|
My upvote - I fully agree! In a team you should talk first and not silently fix someone else's code. If possible, the "owner" fixes, but if circumstances mandate/allow, anyone should be allowed to fix or even to rewrite.
Cheers
Andi
|
|
|
|
|
... signed in triplicate, sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
