I am going to admit right now that I only wrote this article because I thought of a clever title. I have figured out that any piece of coding wisdom to be handed down must come with a catchy title or an easily rememberable acronym, else it risks being ignored. This I say to you. Coding in a vacuum sucks! CIAVS, as the kids say these days.

Okay, maybe the kids don’t say that. Maybe the kids are too busy playing video games and they’d rather call people “fag” on XBox Live. However, I would like to imagine a few cowboy coders sitting in mom’s basement reading programming blogs and trying to create the game of their dreams. To them I say, “Coding in a vacuum sucks!” What do I mean by coding in a vacuum, though?

I mean a few different things. First of all, coding alone. Being the only coder on a project. Yes, it is nice every now and then. You don’t have anyone mucking around in your code. You have the liberty to program as you please. (Hey, maybe that’s another blog title right there!) With reckless abandon, you can ignore warnings, write single letter variable names, and sweep exceptions under the rug. Yes, sir. You can ignore all forms of good practice and really crank out some code of terrible design. Not to post again about the power of a good code review, but every once in a while you should have someone review your code. It is incredibly hard to catch bad habits that you formed as a self-taught C Programmer ten years ago.

The buck doesn’t stop there. Just as beneficial as having someone else read the code that you have written, I would argue that it can be mutually beneficial to read the code that someone else has written. You might pick up on something. The other day my friend made a post about something he did in his own code and a very informative comment let him know about the Resource Acquisition Is Initialization idiom. I did not know the acronym, but it is a cool pattern that I had seen utilized at work before. Had I been programming off by my lonesome, I never would have known about this type of pattern. (But I would still hate the goto keyword.)

You may be asking yourself, “But Chad, how can I avoid it?” Here are a few surefire tips to avoid separating yourself from coding society.

Don’t code in your own branch! It’s true, partitioning your changes off so that only you see them is fine sometimes. That is, as long as you integrate often. When you spend a few weeks in the chad_monkey_work branch, however, you cut yourself off. It is easy enough to duplicate changes that someone else is making, introduce subtle bugs in another system that you are not testing, and set yourself up for a painful merge.

Get involved in open source! Open source projects are kind of a bear. Anyone can contribute, so usually there are some pretty decent projects out there with style guidelines that are simply dreamy. Getting involved with an open source project is a good way to start familiarizing yourself with new paradigms, patterns, and coding styles. With any luck you can get some feedback on your own stuff, too.

Join a forum! Go on! Give it a shot! There are communities out there willing to talk shop. You can visit StackOverflow.com or DreamInCode.net, just to name a few. You can also look for a community focused a bit more strongly in your preferred language or area of interest. Are the XNA forums more your flavor? Give it a whirl. Who knows what kind of niche advice, tips, or tricks you’ll discover?

Now go out there and be as social as awkwardly possible! Don’t make me break out more bad puns. You won’t like the title of the next post. Trust me.

  • Share/Bookmark