|
Every person has there own coding practices, even we have standard. If the code is not readable enough to me I don't really like to fix it. However, if it's really stop my or someone else progress then only I'll fix it.
If you've never failed... You've never lived...
|
|
|
|
|
Yes, the bug itself tells me whether to fix it. If the bug requires changes in dependencies I'm not planning to work, I do not touch it. Generally this comes from the fact I do not like how the dependency is written. (Generally by personal preference to language/libraries and so on). Sometimes fixing a bug is just telling your teammate to fix it.
|
|
|
|
|
I would fix the bug with the other person's full knowledge so that we could collaborate. Sometimes junior programmers really just need to be shown how to do it correctly. Sometimes senior programmers get lazy or over think their solution.
God forbid sometimes I just miss the "reason" for what looks like a hack. BTW it generally is they just didn't want to try and figure out the clean solution or ask for help.
I always try to take a mentoring approach so that if I am right the other developer doesn't feel like I am ripping on them and if I am wrong it is an easy transition to learner.
Thanks
JD
http://www.seitmc.com/seitmcWP
|
|
|
|
|
Normally I work under bug tracking and supporting a large number of devs and teams so grabbing this kind of work is a real no-no, it messes everything up because it happens all the time so tracking will be bogus really fast.
Anyway, if a fix is obvious & simple I'll fix it for my local build if it's stopping me but not check it in, then let the lead or PM know what's up, if you let them know you have a fix working because it was easy & a showstopper normally the assignment is switched right away and you can check it in and close it.
Just to say, many times they won't reassign the bug, even a simple typo.
tom mallard
b'vue, wa
|
|
|
|
|
Yes, I remember not being allowed to fix a null pointer bug due to it not having a ticket, and not being allowed to raise tickets (they had to derive from user issues or features).
There's something wrong with a "quality" system that prevents fixing bugs.
And of course, the user may not know why an app hangs periodically and may not even bother reporting it.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Hmmm,never heard of a system where you couldn't file a bug as a dev but obviously they exist!! ... too weird.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
