Break the Code to Set Yourself Free

Have you ever been assigned to work on someone else’s code? Isn’t this kind of like an artist to be given the Mona Lisa and asked to improve on it.  Well that’s assuming you’ve been given some sweet code.  More often what we are given is just typical code — some good, some bad.

Yet, writing code from a blank canvas is much more fun isn’t it.  You can use whatever “brushes” you want and the fun pastel color paints, too. If you want to paint a nude, you’re free to do so. Oh wait. I thought I was talking about code. I let my mind wander when I mentioned nudes … ex-squeeze me.

But when we code, that blank file MyNewFile.c is heaven. And seeing someone else’s code is a complete bummer — kind of like seeing your plumber’s plumber’s crack.  First you have to make something of the mess of code you’ve been given, because at some level all code is just a big mess when you first look at it.

Maybe it’s even written in a crappy language, too — in other words, anything other than C, right?  (I’m a bit of a C purist, sue me.) So here you are, PHP (barf), and your gun has no bullets.

Besides you couldn’t leave your manager with this mess. Or have to have the emergency first responders need to take your fat dead body out on a stretcher — huge mess, too. Too much work… We can spare them.   Let’s figure this out because at some level we have our eyes set on a rock star lifestyle.  And rock stars don’t quit — they just OD!

But we are artists, right? You’ve coded naked at home on the weekend, right? Maybe even thought of slicing off your ear when you couldn’t find that one bug. But, how can that bloody manager ask us to work on some else’s art? How rude. Oh, I guess if you want to keep getting that darn paycheck, we better fix our attitude. I imagine Linus Torvalds even gets patch requests that look like sh*t and makes him want to swallow a gun muzzle, too.

But he managed to push through the pain and so can we. I’ll slip into my big boy pants now, but I’m going commando when I get back home, OK.  (Right now my gay male readership — if I have any — is doing backflips.) Let me drop some quisi-senior citizen wisdom on you.

There are two major approaches to working on someone else’s code: first approach, you change only what you absolutely have to and then run for the hills, and, second approach, you make it yours, own it, and change it to your heart’s content.  The latter often involves going on your blog and slandering the piss out of the original author as well. (Ha ha.)

First, many times the former is the way to go. Sure, sometimes you would be a fool to do anymore. Yet if you expect to have to make a lot of changes to the code going forward, I say own it. Make it yours.  Put a ring on it.

So often we don’t do this though.  Instead, we tread lightly, not wanting to break the code … or make any noise as we approach the deer in the woods.  The slightest noise and they flee.  (Where my tribe is from deer hunting is popular among “real” men (and women, too).  I tried it but flopped.  Too much of a sensitive intellectual perhaps.)

If you own it, you will care about the code. Caring about the code is the most important thing there is. If you care about the code, you will make sure your customers are delighted; you will make sure to produce high quality software. It will now be your art — your masterpiece.

The fear of breaking a codebase can cause concern though.  If the codebase is large or poorly written, it gets even more scary.  And if your boss is a jerk, you might be less inclined to take chances.  Other issues might be the codebase is poorly documented.  We all know how common that problem is.  Or the codebase has docs but they haven’t been kept up to date — another common problem.

So sometimes you need to just spend time documenting the code before you jump in.  Do a high-level flowchart of the code.  You could use Visio or just do it in a notebook for starters.  By charting out the software and various interactions, you will have a great head start.

Next make sure you understand all use-cases.  Do your homework.  Figure out what the heck the code does and how it does it.  Be patient.  This can take some time depending on the size of the code, your familiarity with the language and your knowledge of the problem domain.

But get in there and don’t be afraid to break the code.  You will learn by breaking code.  Of course, try to break the code without it going live and messing up your customers.  But definitely get in there and mess around, discover, break, and create your genius.  Leave your mark.  Own it.

Your confidence will grow as a developer.  When you face fears, you will inevitably conquer them.  You will quickly become the go-to person for the codebase.  Your manager will see you’ve got gumption and are self-led.  Both traits highly valued in any profession.

The worst case scenario is you’ll break the code really bad and spend a few hours reversing changes from your source control tool until you get back to a working version.  Now, if you don’t use version control software, you’ll have a bigger problem!

So the next time you are assigned to work on someone else’s code, own it. Make it yours. The best code is that which is produced by someone who really owns it and takes pride in their code. Sign every header file with your name like it’s your art. Because it now is!