by Michael O'Hearn on January 4, 2009
Using exceptions to control program flow is a hotly debated subject. Wherever you stand, remember that there are performance implications. It doesn’t hurt to be aware of when exceptions are being thrown. Sometimes they can sneak right by without you ever having seen it.
Have you ever come across an empty catch block? Or one that does nothing useful with the exception and does not rethrow? Luckily, Visual Studio has a setting that can help ensure these don’t slip by. In the Debug->Exceptions menu item is the following dialog:
After checking the Thrown column for Common Language Runtime Exceptions, your debugger will break for any exception, even if it has been handled.
by Michael O'Hearn on January 2, 2009
We all know the type. They often go around shouting stuff like “tables are for tabular data” and “you should never use that library!” They storm off and pout if you don’t listen to them. They read about the newest trend and want to go back and fix all of the work that was done the wrong way.
I am this guy. I read A List Apart, Martin Fowler, Joel Spolsky, and Stevey’s Blog Rants. In my library I have Code Complete, Patterns of Enterprise Application Architecture, Framework Design Guidelines, and The Pragmatic Programmer. I take what I learn, market them to others as facts, and get upset if they don’t jump and go about doing things differently. Why won’t they listen? Do they not get it?
I’ve worked with this guy too. A friend of mine used to lament, “Whoever wrote this code should be shot.” He was referring to my code. For a while after that I would cringe whenever he came to discuss something “neat and cool.” Even if code belongs on The Daily WTF, what good can come of being mean to the author?
“I wish he would quit!”
Dealing with the angry coder can ruin your day, but if you step back to look at his motivation, you might realize that he’s not such a bad guy after all. He’s not thinking negative things about you. He’s really not even thinking negative things about your code. He is just thinking about potential improvements. All he sees is a dirty carpet that needs a vacuum cleaner.
- Don’t take it personally: Try to remember that no matter how animated he may be, it’s not because of you. If you get defensive — which is a very natural and ingrained response — things will almost certainly escalate into frustration. Don’t feel the need to defend your code or your decisions.
- Just say no: Don’t beat around the bush. If you don’t want to hear it, declare that you are not interested in this right now.
- Be grateful: I know this one could be hard at first, but once you get into the habit, it feels and works great. Fake it until you make it. Eventually you will realize that he truly is trying to help you and it could likely change your relationship.
- Take some space: If your discussion turns heated, don’t be afraid to put off the entire discussion until later. There is a very good chance that after waking up the next day, at least one of you can look at things from a different perspective.
“But standards and best practices need to be followed!”
When you are the angry coder, it seems like people who don’t listen or automatically intuit new ideas are lazy or apathetic. Sometimes they are, but more often change is hard. It is a never ending process in this profession, one from which even you are growing. Take a look at some of your older code and consider: How do you rate against your high standards?
- Show them the money: If you can show someone the benefits of what you are suggesting instead of the downsides of the way things are currently done, they may be much more receptive to change.
- Accept no for an answer: Sometimes it may seem like the sky is falling, but it probably isn’t. Try to forget the worst case scenario, and focus on the most likely scenario. Your company will still sell its widgets, even if you have a few deprecated HTML tags.
- Don’t be critical: There is one thing criticizing your coworker is guaranteed to do: ensure they have their defenses up the next time. Instead, invite your coworkers to be co-conspirators in promoting the next big thing.
- Choose your battles: Just because you know how to better something doesn’t mean you should. You don’t want to stretch yourself too thin.
- Listen: No one will listen to you if they know you won’t listen to them. When they are excited about something, hear them out fully. Think carefully before adding to their idea because they may view it as you taking over.
- Apologize: If you realize later that you were too harsh, fess up. Your coworker is probably still upset about it, and, even if they are not, what can it hurt? It might make you feel better too.
I hope you find some of these tips helpful and I would be very grateful if you would share your own insights in the comments. Hopefully, if we put a little extra effort into understanding each other, we just might catch ourselves occasionally smiling on our commute home.
To anyone I have offended while in angry coder mode: I am sorry.
To my angry coders: Thank you. I have learned a lot from you and appreciate your passions. Even if I sometimes wish you’d just quit.