We're All Human

Over the last several days, I've encountered numerous instances of programmer bashing. I've heard nontechnical managers complaining about the "idiot programmers" in their shop, had test managers claim the programmers were "user hostile," and most recently read a comment on a Web site calling for legal action against individual programmers who introduce security holes. In each case, it seemed that the commenter intended the comment to be humorous. At least for me, the humor is wearing thin. An attitude of blame lay just behind the humor: "The programmers make the bugs, blame them for poor quality!"

Every time I hear a comment painting large groups of programmers with the same brush, I think of programmers I've known who don't deserve that treatment.

Mikey, the youngest programmer in an Internet tools company, prided himself on producing 100 percent reliable, robust code. He had a standing offer: If you found a bug he didn't know about in his code, he'd buy you lunch. He didn't have to buy many lunches.

Ward, an old-timer who'd learned to program on punch cards, had a patient and calm demeanor no matter how hairy the project. He took the time to do things right, even when that meant standing up to a manager who wanted Ward to cut corners. His approach paid off. By the time he delivered his code to test, there were few bugs. Those that did appear were minor oversights or unpredictable integration issues. Further, the time he spent drafting comprehensive specifications made it easy to design the tests and write the documentation.

Karen specialized in internal tools. If you could envision it, she could build it and build it quickly. She was so speedy, she often had it built within a few hours after you said, "wouldn't it be cool if..." Generous with her knowledge, she was a patient if sometimes demanding mentor.

In fact, the more I think of all the programmers I've ever worked with, I can remember only a bare handful that were incompetent or even remotely deserving of ridicule. The vast majority of programmers are diligent, capable folk. They truly care about the quality of their work and want the software they produce to be useful. They are more interested in producing a good product than playing CYA games. They work hard to make sure they are implementing the right features and writing solid code.

I have, however, seen a few situations where programmers seemed to lose their focus on the customer. Betty, an otherwise quality-conscious programmer, surprised me by insisting we should ship software that was causing intermittent blue screens on Windows machines. She pointed out that the blue screens were rare, couldn't be debugged because they couldn't be reproduced, and couldn't possibly be caused directly by her code. I was shocked. I insisted, in a nastier tone of voice than I intended, that we weren't going to ship anything that caused blue screens. Betty and I ended up in a screaming fight-one of the few in my career-and it took a VP to force both of us to back down long enough to talk about the real problems.If I'd stayed calm just a little longer, I would have realized how much pressure Betty was under. Her bonus, and quite possibly her career with the company, rested on her doing well with this project. It was a high profile, quick turnaround project and had been handed to her because of her previous track record for releasing well-received products within tight timeframes. Betty had a reputation to protect and difficult expectations to meet.

Unfortunately for Betty, she was building on a none-too-stable base. Her code worked on top of an existing system, a system rife with stability problems. Her code manifested the intermittent blue screen, but the underlying fault had been there all along. Sick of still having a six-week project on her plate after twelve weeks, she was anxious to declare victory. From her perspective, the project had been done some time ago. She figured it was someone else's responsibility to fix the other code on which her product depended.

Of course from my perspective her attitude was indeed hostile to the end users. I'm sure I called her an "idiot programmer" and worse during that project. But she didn't deserve it. She was simply reacting to a difficult situation. Ultimately, she agreed that we shouldn't ship until we could resolve the blue screen issue. She realized that no matter who was at fault, she was responsible for fixing the intermittent crash.

The next time you're tempted to think of your programmers as idiots, incompetents, or quality hostile, remember that no matter what else they may be, they're people first. It is far more likely that they are having a very human reaction to a particularly bad situation than that they are incapable. Perhaps, like Betty, they're feeling trapped in a no-win situation. Before you condemn them, ask what's going on from their point of view.

Similarly, the next time you're tempted to hang a programmer up by his toenails, remember the last time you made a mistake. I've made some real whopper mistakes in my time. We all have, whether or not we choose to admit them or even remember them. It may be that some programmers don't care about users, but it's more likely that bugs are honest mistakes made under difficult circumstances.

I don't expect you to put a bumper sticker proclaiming "Have You Hugged a Programmer Today?" outside your work area. But the next time you're tempted to vent your anger at a programmer, see if you can imagine the factors contributing to his or her behavior. After all, we're all human, with all the brilliance and fallibility that implies.