Just some thoughts on the term 'Pragmatic'

Earlier this week, I started training for the RubyConf 5k. Based on the general suggestions, I'm doing the Couch25k training program, and I found the podrunner podcast that will help with the interval training. So, after the first run, I was feeling pretty good. I mean, the last couple intervals had me breathing pretty heavily, heart pumping, but I thought I handled it all pretty well. So, I was talking to Sarah and said, "Wow! I feel great. I know the program says to take a day off, but I think I might run tomorrow, as well." After all, I've been walking and using my legs for quite a while now; I know and understand the way my body works when moving. She just looked at me and asked if the program said I should take a day off. "Yeah, it does." As expected, she advised me to listen to the instructions; the people who developed the program have a lot more experience than I do with these things. I thought for a second, smiled, and said, "But, I'm pragmatic with my running. Don't hassle me with your 'program dogma.'" Well, we had a great laugh about it. I felt fine the next day, wondered if I should have run, and then, the second day after the run, oh the ache started. My legs definitely were burning, and I was glad that I hadn't over-worked them by running the next day. I guess it is true that it is often the second day after a workout when you feel the effects.

This is a common thing that I hear from software developers: they have a little bit of experience, think that they understand something to the point where they can make their own decisions on what it means to 'be pragmatic.' Often times, people use the term 'pragmatic' as a way to hide a lack of skill and experience. Or, sometimes, it is used in ignorance: someone doesn't realize that they don't understand something well enough. Usually, though, it is brought to play when someone is justifying cutting corners on something. Just like the second day pain I felt with running, this can come back later to bite you in the ass. Think your 9 months of trying TDD makes you an expert, someone who can suddenly decide when it is 'pragmatic' to not design your system with TDD. Or, don't even worry about designing your system with TDD, just talk about automated testing. Are you being 'pragmatic' about automated testing, skipping it things you don't know how to do or are hard? I wrote a blog post about being pragmatic with Uncle Bob around TDD-ing javascript.

It is pretty common knowledge that I'm not a big fan these days of those terms, 'pragmatic' and 'dogmatic.' (I even included a bit of my dislike in a talk I gave to the Chicago Software Craftsmanship group). Do they have value as terms? Yeah, they used to. Nowadays, though, they seem to be used more often as justification for decisions that are based on lack of skill or a desire to cut corners. Next time you are tempted to make a decision based on being 'pragmatic,' take a moment to pause, try not to use that term. Instead, ask yourself why you are making that decision to cut a corner. And be honest with yourself. It isn't shameful to explain that you are not doing something because you don't know how. After all, admitting you don't know how to do something is the first step to learning how to do it, no?