(no subject)
Jan. 15th, 2002 09:35 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jazzfishNo coder is interested in the results of testing.
If a bug is a "real" bug, the coder will have found it himself, and already fixed it. Bugs found by testers are by their very nature trivial. "No one will see that," says the coder. "Or if they do, they won't care."
Coders find the fixing of bugs to be demeaning. How much better to write new features into the code, features that may cause more purchases when they are advertised. No coder wants to spend his time attempting to decipher code written weeks or months ago, simply to fix trivial bugs.
One imagines it would be the job of management to ensure that bugs become fixed. This becomes unlikely when management is also a coder.
At this time I have over fifty bugs listed in the bug-tracking database. Some of these bugs date from August; at least one is from June. Perhaps one-third are truly "trivial", things that in fact no one would ever do. Few of my reported bugs are from later than early November, becase at that point I essentially gave up on using the bug-tracking database. What's the point of bothering to enter a bug if it will languish, not only unfixed but un-looked-at?
I would seek employment at another company, but I suspect that the process at any small software company would be more or less the same, and I have serious doubts about my ability to get a job at a larger company without a degree. So I plod on.
No coder is interested in the results of testing.
If a bug is a "real" bug, the coder will have found it himself, and already fixed it. Bugs found by testers are by their very nature trivial. "No one will see that," says the coder. "Or if they do, they won't care."
Coders find the fixing of bugs to be demeaning. How much better to write new features into the code, features that may cause more purchases when they are advertised. No coder wants to spend his time attempting to decipher code written weeks or months ago, simply to fix trivial bugs.
One imagines it would be the job of management to ensure that bugs become fixed. This becomes unlikely when management is also a coder.
At this time I have over fifty bugs listed in the bug-tracking database. Some of these bugs date from August; at least one is from June. Perhaps one-third are truly "trivial", things that in fact no one would ever do. Few of my reported bugs are from later than early November, becase at that point I essentially gave up on using the bug-tracking database. What's the point of bothering to enter a bug if it will languish, not only unfixed but un-looked-at?
I would seek employment at another company, but I suspect that the process at any small software company would be more or less the same, and I have serious doubts about my ability to get a job at a larger company without a degree. So I plod on.
No coder is interested in the results of testing.
Bugs and Small Companies
Date: 2002-01-15 07:58 am (UTC)Andy has said we *might* start hiring again in Feburary...
Be Seeing You,
Nathan
no subject
Date: 2002-01-15 08:01 pm (UTC)http://www.livejournal.com/users/jazzfish/day/2001/01/12
no subject
Date: 2002-01-16 05:43 am (UTC)1. Yeah, and when I started working fast food I figured it was a step up from having no job. I was right, too. Doesn't mean it didn't suck nonetheless.
2. Interestingly, Exegetics was arguably a better job. Better pay and benefits, obviously, but also my immediate superior actually _gave_a_damn_ about me being able to do my job right, as opposed to my immediate superior firmly believing that the best thing I could do would be to leave her the fuck alone. I worked in a hallway in both places, although Exegetics had nerf basketball (and/or beach basketball) in said hallway. There are actually free sodas available here, as opposed to there where there were theoretically occasionally sodas. Usability is more important in general here, but that's hardly difficult.
Christ, have you ever tried to _use_ the Data Sources dialog? Click to select a row and then double-click a cell to edit it. No TABbing or arrow-key navigation, despite the appearance of a spreadsheet-like thing. Pressing ENTER to finish editing a text field closes the dialog. An Apply button and an OK button, but no Cancel button (and the Big Black X works as OK). But that's the way it was implemented, and it would take actual coder _effort_ to improve it, so by God that's the way it's going to be-- and not only that, but this style is reused in the Constraints and Methods dialogs, and (I think) in the Select Source/Target dialog as well.
Don't get me started about the context-menu crashes, either. That's only going to get worse with multiple diagrams... "I right-click and... hey, there's no Close option in the context menu! Okay, I'll just go and close the diagram window and... hey, the program crashed!"
This, of course, is just the pent-up aggravation from the testing side. I spent yesterday putting together a list of new features in 8.1 so that we could release. One might conjecture that Dan had me do this because he felt it was important. Clearly one would be wrong, as evidenced by a complete lack of implementation (from the coder side) of a menu item proclaiming "What's New in 8.1"...
gah. I'm losing it.