I was at lunch with a few developer friends a few weeks ago when a story of rather horrible code experience came up. Someone mentioned that they should send it to The Daily WTF.
“I don’t really like The Daily WTF.” I said, off-handedly.
Everyone looked at me as if I had said that I didn’t like kittens, or apple pie, or democracy.
“What?” one of them asked.
“I think it’s too mean-spirited” I said, lamely.
I didn’t always feel this way. My position on code-quality-improvement-via-harsh-mocking changed after working with a great developer (the kind that reminds me that I am merely a good developer). He was very focused on code quality and would say things like “I should hop on a plane and fly to where this guy who wrote this is and punch him in the nose for writing this method this way” or just cry out “Jesus Christ!” when he found something that he didn’t like.
Even though we always got along, it made me nervous. If this is what he’s saying about other people’s code, what’s he saying about my code? It created a sort of climate of fear. Not only that, it didn’t do any good to actually improve the codebase as a whole. We still had a team member who insisted on writing things in his own way. He brushed off valid concerns as “well, that guy just hates everything”.
This culture of harsh criticism is what leads people to be generally closed and insecure. Personal example: I thought about releasing the source code to my little Survival-Horror Asteroids game, but I haven’t yet, for fear of having some sharp-tongued rock star developer come along and tear me to pieces.
None of this is to say that you shouldn’t be discerning. I’m as concerned about the distinctions between (and definitions of) good code and bad code as much as anyone else. I’ve literally had nightmares about having to work with a particularly nasty procedure. I’ve just learned to not be so insecure that I have to insult and belittle people over it.
This isn’t just a problem with developers, either. I enjoy reading about design and usability, and I found a
great article about a
particularly mean-spirited Flickr thread in response to a screenshot from an iPhone app. The app itself may not look great, but the developer had done nothing to warrant the vitriol of the responses.
How to make things better:
1. Be kind and respectful, even to inferior coders. When I first read about the Lean Software Development concept of “Respect for People” I read it as “Respect the developers, especially Martin”. But it’s actually omnidirectional. Respect the other developers. Respect the folks in marketing, respect the pointy-haired-bosses (the first step, of course, is to stop calling them pointy-haired-bosses).
2. Think incrementally. If you’re working with a developer who needs to improve, select a few distinct values-based things that need to be changed when you provide feedback. If you try to fix absolutely everything all at once, you’ll fail.
3. Be constructive. Comments like “my eyes bleed” or “you, sir, are too stupid for words” don’t help do anything besides inflate the ego of the insult hurler. Comments like “if you do an extract method refactoring instead of copy-paste, it will be easier to understand and maintain” or “some stronger lines of alignment would make this easier to understand” are helpful.
3a. (update, July-19-08) Realize that reasonable people can have different opinions and pick your battles. I’ve stopped getting hung up on stylistic things such as formatting or casing. I’ve learned to adapt to the consensus of the project. It’s a useful skill.
Also, realize that there’s generally no one right way, most things are tradeoffs. In this de-normalization example, the author is looking into trading one kind of pain (arguably slow joins and more complex queries) for another kind of pain (risk of data anomalies). It’s generally not the tradeoff that I would make, but it surely doesn’t warrant the “you have no business designing databases” hate that he got in the comments.
4. Realize that mistakes are OK and a necessary part of progress. Some developers (including me sometimes) get defensive or insecure when people find bugs in their work. The best developers I’ve worked with never are. It’s not that they never make bugs, but they don’t take their bugs personally.
