How to Make Your Colleagues Hate You

What do programming and playing golf have in common?

Obviously, both are enjoyed outdoors, you get to wear awesome pants, and there’s often lots of swearing.

OK, so maybe only that last part is true.

There is something called code golf though, that does have some similarity to “outside golf”. In golf, the idea is to get the ball into the hole in the lowest number of strokes possible.

In code golf, the objective is to write a program using the fewest number of characters.

Take the FizzBuzz problem as an example. The task is to write code that outputs numbers from 1 to n, except output Fizz if the number is divisible by 3, Buzz if it’s divisible by 5, or FizzBuzz if it’s divisible by both. Sounds stupid, but it’s a classic interview question.

The output is something like this (some lines truncated):

1
2
Fizz
4
Buzz
…
13
14
FizzBuzz
…

It could be implemented like this:

for i in range(1, 31):
    if i % 3 == 0 and i % 5 == 0:
        output = "FizzBuzz"
    elif i % 3 == 0:
        output = "Fizz"
    elif i % 5 == 0:
        output = "Buzz"
    else:
        output = i

    print(output)

Alternatively, like this:

print("\n".join([str(i%3//2*"Fizz"+i%5//4*"Buzz" or i+1) for i in range(30)]))

Both of these code segments perform the same function, but even if you don’t know Python (or any programming languages), you can see there’s a marked difference in the amount of code necessary to implement the same thing.

Which is the correct way?

Well, the best approach is probably somewhere between those two, but if I had to pick one that I’d like to see in production code? I’d actually pick the former.

But why? I thought less code was always better.

You might have heard this quote (or something similar) by Steve Jobs from Apple’s 1997 WWDC keynote:

The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.

Jobs was speaking in reference to using code from reusable, widely-available vendor libraries; such libraries exist to prevent developers from having to constantly repeat themselves. And he was right… up to a point.

When you’re writing your own code for your company, less is not always more.

In the first example, it’s really easy to see:

• where the code is branching
• what the branch conditions are
• what the output is going at each step.

It’s also easy to see what happens to output at the end (it gets printed). Not to mention that if you need to debug your code, you can insert test breakpoints on any of those lines. It’s not fun stepping through code in a debugger when the entire function is compressed into the same line.

That’s not to say implementing programs in the shortest way possible can’t be fun. There’s even an entire Stack Exchange site dedicated to Code Golf. It’s just that maybe, just maybe, your work isn’t the best place to flex your coding skills in this exact way.

Still, you know what? Maybe you want to flex! Maybe you want to impress your co-workers by reimplementing one of their algorithms in a fraction of the space that they used. That’ll show them who’s boss!

…actually, do you really want to be that guy?

I want to show off my programming skills!

Sure, you’ll astound the other members of team for a while. But when it comes time for one of them to maintain your clever code, they might not be so amazed.

It might be even worse if you yourself have to come back and maintain it later. Heed the words of seminal computer scientist Brian Kernighan:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Certainly, there are times that I’ve come back to my old code and tried to understand what I was thinking at the time. Sure, once I’ve figured it out, I’ll be impressed at my own cleverness. That never seems to change the fact that I’ve killed an hour or two just trying to reverse-engineer my own work.

It’s great for job security though, isn’t it? Being the only one who can work on a given project?

That’s true, but when you inevitably decide to move on (hopefully to bigger and better projects), you’ll probably have to undergo some kind of handover process to bring your replacement up to speed. This can be painful, especially to you, if you’re having to spend way too long trying to explain your amazing code to others.

Plus, you may have heard the old saying: “If you can’t be replaced, you can’t be promoted”. You may very well end up both locking yourself in place and bringing down a bit of resentment on yourself

So flex on your fellow devs by showing how good you are at writing clean, understandable and maintainable code.

My code’s fine, the other devs keep writing hard-to-understand code!

What if you’re not the dev writing the complex code? What if you’re the other guy, the one who’s always squinting at code reviews, trying to figure out what’s going on in that mysterious line?

Well, keep in mind that everyone has different methods and thought processes. There’s always a possibility that the code you’re reading isn’t something that another coder would consider too complex.

Here’s another example; a way to get a value from a dict, with a default value used if the key doesn’t exist in the session:

try:
    user_logged_in = session["user_logged_in"]
except KeyError:
    user_logged_in = False

This method works, no question. However, there’s also the built-in get method:

user_logged_in = session.get("user_logged_in", False)

Hopefully you’re not looking at that second example and saying, “That’s terrible, who knows about the get function anyway? And why aren’t we handling the KeyError?” The reason why this one-line function is preferable, as opposed to the FizzBuzz one-liner, is that not only has the get function has been used in Python for a very long time, but that this snippet uses a single function to get the same result.

Even though a programmer can’t be expected to know about every function available for a language, a quick check of the documentation should be enough to clear up any confusion.

Take it a step further, though. What if you’ve reviewed a big chunk of code and you keep finding the same principles being frequently applied throughout? Not duplicate methods, but a style of code that just keeps giving you trouble?

Well, the answer might just be to reach out. If you find yourself coming across the same functions being used time and time again, but you’re not sure why they’re being used or what the benefit is, that’s probably something you should raise with the original author or technical lead of your team.

Don’t be afraid of looking stupid. Imposter syndrome is a real thing, and you’re probably more skilled than you think. A good company will want you to grow your skills so they can build an unstoppable team of awesome developers, and that includes you!

Making life easier for your co-programmers

Ideally, you want to write code that can be read and understood without needing extra explanation or clarification. But let’s say that you’ve come up with an incredibly concise and accurate function that you can’t bear to simplify. You really want to include it in your code, but at the same time, you remember all of those times when you were going over someone else’s app and trying to understand how their super-clever functions worked. You’re a considerate sort, and you don’t want to make life harder for the people who’ll work on your code after you. What do you do?

In all honesty, the answer’s both simple and obvious. We all know it, even if we don’t practice what we preach all the time.

Comment your code.

It’s that simple. Leave instructions that detail at the very least the purpose of your function. Maybe include details on the intended inputs and outputs, or at least an indicator that you’ve run the function through a set of unit and/or integration tests. Even the word “Tested” is better than nothing.

That being said, it’s safe to assume that the comments you leave are going to be read by programmers. This means that if you really want to, you can also practice “Code Golf” principles on your comments.

Let’s go back to our original example of the FizzBuzz test for a minute. Say that you used the more concise function and are leaving a comment for your eventual successor. Using our original explanation of the test, you could write out a code comment like:

# Outputs numbers from 1 to *n*, except output `Fizz`
# if the number is divisible by 3, `Buzz` if it's
# divisible by 5, or `FizzBuzz` if it's divisible by both.

It’s accurate and descriptive, but hardly concise. Anyone at any level of experience can understand what the function is supposed to do, but at that length, you might as well have written the longer function instead.

Assuming that this function was to be reviewed by a programmer that’s never heard of the FizzBuzz test, what’s the shortest possible way to summarise the function’s purpose? Here’s a good try at it:

# Takes int *n*, prints joined str 1->*n*.
# %3==0->Fizz, %5==0->Buzz, &&->FizzBuzz.
# Tested.

Obviously, this comment is shorter and should be understandable by most competent programmers, but comes across as gibberish to anyone who doesn’t read code. Still, it at least tells whoever reads it that the code’s been tested to confirm that it does what the comment says it does, and that the problem in the code is more likely to be elsewhere.

As with the original example, the ideal comment writeup lies somewhere between these two extremes, but any sort of comment will make life easier for whoever’s reviewing your code in the future.

A Confession

I have to admit, I’ve been on both sides of the complex-code issue. I believe it’s a bit of impostor-syndrome in either case. Sometimes you feel the need to write really complicated code to prove that you know what you’re doing; likewise, it can be daunting to have to ask for something to be explained, especially if you’re already a “Senior Developer” who should know their stuff.

Nowadays I like to “tone it down” a little bit. Where I previously would have gone all-out to produce those flawless one-line solutions, I instead try to determine if functions can be split into multiple lines. I try to break them down in ways that let me assign meaningful names to variables, and that let me display algorithms in more understandable ways.

I also have enough confidence in my skills and experience by now that when I come across something “weird” I don’t hesitate to ask the original author what’s going on. Who knows? It could be an opportunity for both of us to learn something.

At Tera Shift, we believe in delivering good-quality, well-documented code that can be maintained by (almost) anyone. And more importantly, we leave the golfing (be it inside or out!) for after hours.