Good Programming Practices And New Year’s Resolutions

How many of you have created new year’s resolutions in the past? Come on, be honest with yourself, you know that you have thought about creating a new year’s resolution at least once or twice. And how many times have you succeeded with those new year’s resolutions? If you’re anything like me, you have long ago given up on new year’s resolutions because they are something that you impress upon yourself in the wee hours of January first after having imbibed one too many glasses of champagne.

You see, resolutions don’t really work because people just don’t take them that seriously, and they are something that we do on a whim. If we actually wanted to change, then we wouldn’t wait for January 1st in order to make the decision. Or maybe we don’t want to change? Maybe the problem we have isn’t really causing us that much pain? But is that really the case?

The Real Source of The Problem

The thing is, often our problems aren’t too small to deal with, but instead are too big to deal with. They might feel unchangeable, insurmountable, or just require too much effort in order to accomplish anything. We might recognize the problem, but the thought of tackling it just makes our heads spin. But we know that we need to change, so we make a fleeting resolution, take a half hearted stab at it, and then we simply forget all about it three weeks later. Does that sound familiar? Does this sound like any of the feelings you get as you stare at your IDE with a few hundred thousand lines of your favorite (or least favorite) language sitting inside of it?

Does the code just seem to big? Too daunting to make changes? Not enough tests? Maybe you feel like you can’t get started because you just don’t know where to start. Or you don’t want to change because even though you know deep down that the system you are working with is very painful, you don’t feel like you know how to make it better. Sometimes you don’t think it could be any better. And when we are dealt big problems, humans often want to come up with big solutions, don’t we? But sometimes big solutions aren’t the answer. (How agile of me.)

Where To Start

Alright, so your problems are big, what to do? Well, you do exactly what you do every day as a developer. You take a big problem and you break it down into small ones. At least I hope you are breaking problems down… if you aren’t breaking down problems, then one of these cases applies to you:

1. Someone else is doing it for you.
2. Your software is a nightmare.

Anyways, I digress. So we need to break our problems down into bite sized pieces. Instead of saying, "I want to read 10 books!" it might be better to say "I’m going to read one book by the end of February". You see what I did there? You need to take an overarching goal, turn it into something more achievable, and then give it a time-box. As a consultant, I am exposed to all kinds of interesting (occasionally useful) concepts and whatnot, but one that seems to come up over and over is SMART. SMART is all about creating good goals. It stands for:

• S – Specific
• M – Measurable
• A – Attainable
• R – Relevant
• T – Time-boxed

It sounds silly, but the way in which you define your goals is almost as important as simply creating them. If you create silly goals, then you will:

1. Fail – your goal was too big.
2. Succeed too easily – your goal was too small. This makes you feel like you didn’t accomplish anything, and therefore no drive to push forward.
3. Not have any clue whether you succeeded or failed – your goal was nebulous or wasn’t time-boxed.

But what does all of this have to do with Good Programming Practices?

Well, I’m glad you asked! Good Programming Practices aren’t New Year’s Resolutions, they are real goals that we need to strive for and put effort into. But if we look at the plethora of good programming practices out there, then we will often feel overwhelmed to the point of paralysis. We get too much information and too many directions at once, and we just end up doing nothing.

I mean just think about all of the different design practices there are out there! There are OO design practices. Architecture design practices. Design patterns. Testing practices. Testing patterns. Automation. Deployment. Refactoring. The list could just go on and on. And those are just high level categories with an insane number of items within each! It really is a daunting and career-long task, especially when you consider the new amount of knowledge and work that is being produced on a daily basis. That made it a bit worse, didn’t it? 🙂 Well, I have a bit of advice for you…

The Amazon Curse

Pick one small piece. Let’s say that you decide to start with testing best practices. Your overall goal may be to become a better tester, and that is a laudable goal. But then if you look at that you might say, well, now I have to learn how to write testable software, I need to learn how to write good tests, I need to learn about loose coupling, I need to learn about designing with interfaces, I need to learn about mocking, etc… Before you know it, you have bought a stack of books and they all arrive at your house from Amazon (they make it too freaking easy to buy books). And guess what, they are still sitting there, aren’t they? Why? Because you tackled it all at once. You didn’t break it down! (Hopefully a mental imagine of someone getting funky just popped in your head)

Instead, let’s say that on your journey to becoming a better tester, the first step is to get better at writing unit tests. In which case, you should set a goal for yourself up front. Say something like "I am going to write at least one test every day for 2 months". Some of you may look at that goal and say, that is super easy! Well, if it is, then make it a bit harder. But for some, that is a somewhat difficult goal. Maybe your software is a static spider web and it is a challenge to write even one test! Remember, balance difficulty with the ability to accomplish it. Accomplishing your goal will make you feel good, and will likely lead to larger goals.

Once you have read a few blog posts and written a few tests, maybe you should go grab a book on unit tests. Or maybe there is enough online information to get you started. The whole point is that you are doing something. You are writing tests. You are on your way to becoming a better tester. You are doing something. Doing something to make your world better.

Summary

You know, not too many years ago I was working in a development job that I hated. I felt trapped. I knew that I needed to do something in order to get out. And so I decided that even more important than becoming a better developer was to become a more active part of the developer community. In hindsight, it was the best decision that I ever made. Going out and being around developers who genuinely care about, and are passionate about, what they do empowers you to change more than you’ll ever know.

I made that decision about 4 years ago, left the company I was working for to join a small e-commerce shop, and then about 3 years ago I started this blog. I made the decision that when I started going to the local .NET user group meetings that I was going to show up no matter whether the topic was interesting or not. Doing that helped me forge friendships and network in ways that I would never imagine. I started realizing that I needed to share more with the community, so I started this blog and at the very beginning swore to myself that it would be a labor of love and not a chore. I would commit to only one entry per week, and never force myself to write a single post. And it stuck. Since then I started going to more conferences (I have a goal to attend at least 3 per year), and I help organize my local Code Camps. And you know what, it is a blast! So the moral of the story here is, start small, and take it day by day. As they say, there is no such thing as an overnight success.