Showing posts with label gripe. Show all posts
Showing posts with label gripe. Show all posts

Wednesday, August 5, 2009

please talk louder, I can't hear you

The personnel manager of my company is seated in an office near my cubicle. This morning, when I arrived, she was engaged in what turned out to be a lengthy conversation with her assistant. The conversation was loud, and large pieces of it drifted into my consciousness. Quite a lot of it was of a personal nature. At times the conversation would become muted, at which point I surmised they were talking about something (possibly work related) that they didn't want others to hear about. This was an indication to me that they were aware of the fact that people sitting nearby could hear every word of what they were saying.

Later, around 10 am, the guy in the cubicle adjacent to me began having a loud and detailed telephone conversation about his car loan. This went on for about five or ten minutes.

Then at around 2 pm, a guy further away began having a rancorous phone conversation, apparently with a car mechanic, about the unsatisfactory service he'd received. Despite the fact that he is two rows away from me, I could hear every word.

In between all this was the incessant chatter from two nearby cubicle dwellers who can't seem to stop free associating about non-work related topics for a large part of the day.

I think my number one complaint about my current job is the incessant noise due to inconsiderate coworkers who have different standards about what constitutes appropriate workplace discussion and the volume thereof.

I am a programmer, working at a software company. That means I spend long hours thinking in front of a computer. Ideally, I'd be sitting in an almost noise-free environment, with infrequent interruptions. For example, right now I am at home typing at my computer. There's a bit of noise from the apartment across the hall - I sometimes hear a child making, well, child noises. Sometimes there's car noise from the parking lot. Overall, it's pretty quiet, and there's no sound of people talking. At home, this is true all day long.

Normally, I am a very focused person, and I find I can frequently block out the conversation noise at work. After about a year at my current place, that no longer seems to work. I've noticed that several coworkers use headphones. I don't like headphones; they eventually begin to hurt my ears. Further, I do not focus well with background music drilling into my brain non-stop. I work much better with quiet, and it's frustrating being forced to take steps to block out noise which should not be there in the first place. Because these people are not even having work-related discussions. They are just blabbing about personal stuff during work hours.

The company culture overall encourages this. I'm within earshot of a couple of more senior people who have loud phone conversations (work related or personal) from within their offices. These are not cubicle dwellers, but they still find it necessary to leave their doors wide open when talking on the phone. What's amazing to me is that these people do actually sometimes close their doors when on the phone. Presumably this means something particularly private is being discussed. Don't they realize that no one wants to hear their non-private discussions, either? Just be considerate and shut the door when having a conversation, for crying out loud!

In my list of grievances at my current job, this ranks pretty high. The noise is bothersome, but just as aggravating is the apparent lack of consideration by numerous employees. Sometimes it seems like these people are deliberately talking loudly as a way of showing how important they are. Or maybe they're just thoughtless blowhards. Either way, I wish they'd STFU. But I guess that's not going to happen, so I need to put my ass in gear and start looking for a new job.

Saturday, August 1, 2009

how much time will it take?

I'm one of just a few developers working on a poorly supported software product. The product was barely maintained for the last several years, since it was first released. Many moons ago, it was decided to give the product a complete overhaul, front end and back. Meantime, the main caretaker of the product wisely decided to leave for greener pastures. He was tasked to add as many new features as he possibly could before leaving, and he did so.

He pretty much had free rein over the product while adding enhancements and rewriting code. So far as I can tell, there was no extra pair of eyes checking to see what he did. Management trusted this developer to do everything in the "correct" way. The problem with that lack of oversight is that you are trusting a developer to do everything the way you expect without much (or any) feedback. In many cases, even the product owner doesn't know what to expect, so this imputes impossible, magical abilities on a developer. Naturally, some things are not working correctly, and additions have to be made.

Next thing you know, I've been assigned to finish up the work that was started by the departing developer. There are areas of the application that are incomplete. The code base is quite large, and the application is complicated. I don't know what things work or don't work until I happen to run across them while debugging some other problem.

I've been asked to supply an estimate for how much more time will be required to take this project to completion. So far, I have equivocated, saying that it is very difficult to make that estimate at this point. I am still unfamiliar with a lot of the code base. No one knows how many bugs are in the current iteration of the product. I don't have a specification for what needs to be done, or a checklist of things that have been changed or are still needed.

Truth is, it looks to me like there is still a lot of work ahead, but I can't tell how quickly that can be done. It's even harder to make an estimate because one developer keeps getting pulled away to put out fires in another development effort, so progress is even more unreliable than it usually is in software development.

How do you make an estimate in a case like this? I have a gut feeling for how much more time is needed, but I can't justify it. I'd like to take a few days to run through every feature in the product and see just what is and isn't working. At least then I'd have an idea of how much stuff is still broken. But management would not approve that. I'm supposed to spend every minute developing or bug fixing.

So I can't come up with any justifiable estimate. Meantime, management decides to supply their own deadline. I believe this date was pulled out of thin air; it certainly is not realistic. I don't understand why you'd pull a deadline out of a hat and not expect to be disappointed. I've seen this happen with another project. They kept rescheduling the deadline for months. It makes no sense.

Wednesday, July 15, 2009

the blame game

bug
There are a couple of developers where I work who are in the habit of making public announcements when other people's bugs are found. They'll write it in a bug report: "I found these lines of code written by X", followed by the egregious offending lines of code. Or they'll announce it in a meeting: "Yesterday, I was working on a bug that had been assigned to me, but it turned out to be a problem introduced by Y's implementation of the foo feature."

Is this normal, common, or in any way productive? In my view, it is counter-productive: there's an element of public humiliation in it, where there doesn't need to be. And it does no good that I can see; rather it engenders a hostile and competitive work environment, whereas I prefer a cooperative one.

I am probably too thin-skinned about this, but it really grates on me. My gut reaction is to want to retaliate by publicly pointing out every bug made by these finger-pointers.

However, I see no reason to publicly call someone out on such a thing. Instead, I apply my default behavior to everyone equally. If I find something wrong in someone else's code, I fix it, and in the bug report, I'll write something like "the problem was in the implementation of foo in class Blah, where == was used instead of the equals method." If the person is still at the company, usually I'll walk on over to them, point out the problem, and ask if they agree with my solution, or if they want to fix it themselves. I don't do this to rub their noses in it, but because that's the way I'd like to be treated - I want to know when I've made a mistake, and be given a chance to correct it.

To be fair, the finger-pointers do, on rare occasions, point out bugs of their own making. So maybe they're just applying their own standards to everyone. Still, it seems like the standard (and friendly) behavior is to point out a bug, but not call attention to the bug creator. I wonder what motivates those who insist on playing the blame game.

Tuesday, July 7, 2009

engineer vs bugzilla

bugzilla logo by Dave Shea
In my view, a good bug report contains an ordered list of steps to take to reproduce the bug. I realize this is not always possible (e.g. the bug is intermittent, and QA does not have the time or resources to nail it down).

In reality, I rarely see a sequence of steps in a bug report where I work. I haven't quite figured out why. I think that QA is often just poking around the application, trying things out. They do a sequence of steps, and suddenly something goes wrong. However, they haven't recorded the series of steps as they went along, so the reports go something like this:
Widget on the fribble panel sometimes vanishes. See attached screenshot. May have clicked the foo button three or four times in rapid succession before that happened, not sure, was doing some other tests at the time.
This kind of bug report makes life difficult for me. It means I have to spend a lot of time trying to figure out just how to reproduce the bug, time that could be better spent doing actual development work.

I suppose I could just mark such bugs as invalid, or reassign them back to QA, with a request for reproducible steps. I haven't done this, yet, at least not without a good faith effort to try to reproduce the bug. I get the feeling that QA doesn't take it well when you send bugs back to them in this way.

In my view, QA and development should all be one big team, trying to make the software work. In reality, it sometimes feels like the two departments are at war. Is that common in the industry? Is there a way to stop it?

Tuesday, June 30, 2009

people that you meet

The crowd at the conference
photo by Stephan Ridgway by use under cc license

Recently, I was having a discussion with an unemployed software developer. I will refer to him as X (just so we're clear, "X" is not his real name).

X had a few words to say about taxes and the attempts to nationalize health insurance; he was against both. I didn't get to dig much deeper because we were in the midst of discussing something else, but I did disagree with him immediately on the latter point, since I am perfectly happy to try nationalizing health insurance. He later mentioned to me that while he was unemployed, a huge part of his health insurance was being covered by the government-run stimulus plain. He seemed to be happy about that.

X told a story about a guy he knows who is on disability, who gets all of his health care provided for by the government, and who, in addition, is taking off for a three-week vacation. I wasn't quite sure what the moral of his story was. But it sounded a lot like he was ranting about how such people cheat the government and steal his tax money.

X is taking a few weeks of vacation in August. He indicated that he was planning on drawing unemployment compensation while he's on vacation. I urged him not to, pointing out that it's illegal and unethical.

While discussing these things, I tried to keep polite when disagreeing. My natural tendency in such situations is to avoid conflict, neither disagreeing or agreeing, and to move the conversation along away from hot-button issues. And later, I try to avoid getting into discussions with the person. Possibly I'm overly non-confrontational (<sarcasm>is that because I'm female?</sarcasm>), but I don't see any point in getting into random arguments with strangers. I'm not sure what to do in this case. I met X at a professional meeting, and was hoping that he'd be a good networking contact, but I think I was mistaken. This most recent conversation gave me a pretty big "ick" factor. How picky should you be with your networking contacts, anyway?