Best Practice Exhaustion

I’m sure everyone has days like this – you feel a little worn out physically and exhausted mentally. I always know I’m extra fatigued mentally when I lose all interest in my work. Just like when I was racing mountain bikes, some days your mind refuses to go out and train. It’s too much. The idea of shirking your responsibility and doing anything except what you are supposed to do is irresistable.

While considering how I came to this point of fatigue, a new thought came to me in regards to development.

From time to time I believe I experience best practice exhaustion.

Work is filled with people that know best practices, but any idiot can read and remember rules. Most best practices start with the words “always” and “never”. Some examples:

1. Always check in your code to version control.
2. Always write unit tests.
3. Always do code reviews.
4. Never let an unanswered email fester.
5. Never let someone else drop the ball on a project.
6. Never use XYZ data structure, ABC pattern.

In software, it’s easy to compile a long list of best practices. Things that every good developer will always do.

Here are some implications of best practices:

1. You are responsible for any and all problems with a project.
2. If other people are lazy/non-responsive/not professional, that’s your fault too.
3. If a bug appears, and you could have prevented it, you’re guilty. Why didn’t you follow best practices?
4. If you’re exhausted at your desk and decide to stare aimlessly people wonder, why aren’t you working?
5. Not only are you responsible for coding, but you are responsible for project management, people management, specifications, deployments, etc.
6. Your velocity is always measured by code only and not these other factors.

So I find myself sometimes stuck in a bit of a rut. I take a task at work, I think about it, start developing and this laundry list of do’s and dont’s floods my thought process.

“Have I checked in every piece of code I’ve ever written? Even one off scripts? Even trivial database scripts?”
“Did I release something without a code review?”
“Did I log my time perfectly in XYZ tool?”
“Does everyone always know what I’m doing at all times? Did I send enough emails?”
“Have I thought about every possible boundary/use case no matter how obscure?”

I could go on and on and on.

The bottom line that summarizes this post is the statement: You never have any excuse for not doing something perfectly.

At least that’s how software engineering feels at times. I have found little grace and forgiveness amongst co-workers for simple human error.

We’ll see if there are solutions to the “no excuses” problem going forward.

Best Practice Exhaustion

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s