Developing like there’s no tomorrow.

The apocryphal story of a large portion of the development team going on a ski trip and the bus careening down a ravine and killing them all is a story which strikes fear into the heart of any business.  Another is the cranky cowboy who writes half of the code-base in a single drunken night and proceeds to quit when he’s offended by an innocent feature request from Marketing.

In both of those cases there’s the dreaded fear of a significant chunk of code that’s been left behind.  Sometimes as developers our instincts are to be the domain expert in a particular area of code.  After all, it’s a certain amount of job security.  I’d like to argue, though, that in the end, everyone on the team benefits if the code is written for others in mind.

Others can help you fix your bugs.

Everyone encounters bugs in her/his code.  Even if you believe you’ve written something completely perfectly, sometimes the specifications change, and what was a feature is now a bug.  If you’ve written code that is understandable and documented, someone else can come and help you fix those problems.  No longer are you chained to your productivity; it’s actually possible to go on a vacation.  While this may seem like a recipe for you being replaceable, it makes you, as a developer, more valuable than some yahoo who might alienate everyone shortly before jetting.

More viewpoints == more opportunities.

If others understand what you’ve written, then it’s rather possible for others to contribute ideas.  Sometimes we become wedded to a particular implementation or path, and while it’s easy to become attached to it, it’s significantly more useful to have a marketplace of ideas to choose from.

You don’t want to be That Asshole.

You know the type; the guy who insists everything be written in a very particular way which no one else understands and he’s not the sharing type.  He might be invaluable now, but if he were ever to encounter you again, you’ll be sure not to recommend him.  After all, you’ve had to deal with his mess after he left for greener pastures.  Don’t be That Asshole.

So, what can you do?

For one, document your code and your changes as comments about why you do certain things.  Sometimes it is possible to be too verbose, but more often than not it’s important to know “yes, we’re doing something that looks totally dumb here, but it’s for a good reason.”  Second, write up a design document for anything more complex than a simple refactor or a bugfix.  If it’s a module or a system, someone will need to know how to use it or make changes to it, and if there’s a document to refer to as canon, then at least the next developer that comes along will have a starting out point.  Third, code reviews (or pair programming, if you’re into the whole “Agile” thing) are your friend.  Having a second, or in some cases, third pair of eyes there when you justify your decisions not only helps someone else understand what you’ve been working on for a few days, but the anticipation that that’s happening just naturally makes you write better code.

The way I like to approach it is to develop code in such a way that I’m always willing to show someone else, or use it as an example for a programming student.  In the cases where that particular statement isn’t true, there by necessity needs to be a good reason; whether it be the need to minimize the change footprint, or the need to maintain the same functionality (even if it’s broken as is).  Otherwise, I’m always developing as though someone’s looking over my shoulder.

Finally, much like the title of this post, I try to develop like there’s no tomorrow.  I have just today, and whatever I get done needs to be in such a state where someone else could sit down at my computer and finish what I’ve done.  Much like those authors of large epic series (*ahem* I’m looking at you, Robert Jordan), it’s important for developers not only to document what they’ve done, but also what they intend to do so that others can pick up where they’ve left off.

Note: this post was previously written by me while I was at a different company.  Still applicable in the general sense, but definitely something we’re a lot better at doing than other places.