Wes Baker

Someone Else's Code

October 21, 2011

Head down, fingers tapping and teeth gnashing, that’s how you’d find me if I was working on someone else’s code. I want to rewrite it. I mean, it’s awful just look at it. There are no comments and there are ternary operators where they shouldn’t be and they aren’t used where they should be. And to make it all worse, the code is littered with tons of inane variables like temp and iter.

At some point in every programmer’s rich and illustrious career, we find ourselves in someone else’s code. And, inevitably, we start finding problems, things we would never have done. Ever. However, if you took one look at your code from a year ago, I’d bet you’d start finding problems too. So why, then, do we think that someone else’s code is awful and only worthy of a rewrite? Because understanding other people is hard.

The act of reading someone else’s code is hard, slogging through classes, methods and variables to try and understand what they were thinking. But that takes time, time I don’t believe I have. This needs to be finished this week and if I start rewriting it now, I might have time to finish it, but given my track record of estimation, probably not. But how long would it take if I took the time to understand what was happening in the code? What would it take to document it such that I understand the names and the flow? Realistically? Not that long, and it would save me from rewriting code that—for the most part—works.

Additionally, taking the time to understand what someone else was thinking could result in the ‘why’. That ‘why’ pushes you from just knowing what the code does to understanding it almost as well as the original programmer did. Sure, you aren’t them, you don’t think the same and it’s a different time and place, but this new viewpoint can answer why they used a ternary when they did and why that variable’s name is what it is. With that understanding, it’s no longer someone else’s code, it’s now our code. And the more code you read, the more understanding you gather. With that understanding you now see a whole slew of solutions when your next problem comes up.

So how often do you work with someone else’s code? I work with it on a weekly basis. Yes, it’s usually from a co-worker and because I’ve read their code a few times I’m starting to understand how they think. But even if it wasn’t, it’s not really that bad. It might seem like an interruption in productive work, but reading someone else’s code could be far more useful for the amount of time you put into it. Think about it, you’re gathering some of the understanding that it took to originally write the code in far less time than it took to write it. If that’s not productive, I don’t know what is.


Wes Baker

I’m a programmer who lives in Fredericksburg, VA. I enjoy board games, puzzles, and making things work. When I’m not in front of a screen of some sort, I’m probably spending time with my wife, my son, my animals, my board games, or my books. Check out what I'm up to now or see what tools I'm currently using.