Developers Shouldn’t Play Golf

One of the many horrible consequences of the whiteboard coding interview process has been Code Golf.

Developers aspiring to snag a coveted FAANG job spend endless hours on sites like Leetcode. Solutions are ranked on performance, and one of the ways to cheat a little on performance is to write code which is as lean as possible.

Wikipedia defines code golf as:

…a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that solves a certain problem.

Code golf has been around for as long as I can remember, but as a curiosity and recreational activity. It has the benefit of allowing a developer to stretch the limits of their understanding of a programming language.

Let’s take an example of solving FizzBuzz in Python.

A simple solution is:

def fizzbuzz3(n):
 output = []
 for num in range(1, n+1):
    string = ""
    if num % 3 == 0:
      string = "Fizz"
    if num % 5 == 0:
      string = string + "Buzz"
    if num % 5 != 0 and num % 3 != 0:
      string = str(num)
    output.append(string)
 return output

The performance on this won’t be great, but it is extremely easy to read and understand what is going on. If I saw this in a code review I might suggest that a better implementation would be to stay with the conditional approach, but utilize the ternary operators to clean it up:

def fizzbuzz2(n):
 output = []
 for i in range(1, n+1):
    fizz = 'Fizz' if i % 3 == 0 else ''
    buzz = 'Buzz' if i % 5 == 0 else ''
    output.append((fizz + buzz) or i)
 return output

This is nice and succinct, and the cognitive load isn’t very high. It also has fairly decent performance. If we are really at the top of our game we might solve this with a list comprehension:

def fizzbuzz(n):
 return ['Fizz' * (not i % 3) + 'Buzz' * (not i % 5) or i for i in range(1, n+1)]

This one has faster performance, but it pushes the readability envelope. If this was code that was going to be the subject of millions of iterations then I’d be fine with it because the performance really matters. But if it’s only going to be run once in a blue moon I’d ask to refactor it to something more readable.

Each of these are reasonable answers. But what would a code golfer do?

Def fizzbuzz(i):
   while i:=i-1:o.append('FizzBuzz'[i%-3&4:12&8-i%5]or i)
   return o;

Yikes!

And this is the problem with code golfing and the whiteboard coding interview. We’re encouraging developers to sacrifice readability over performance and showing off their capabilities with a language. Hopefully during an interview a golfed response would be criticized, but all of that time spent practicing Leetcode trying to get to the highest performing answer encourages this sort of thing.

What are the least expensive resources in software development these days? Processors and disk. Virtual servers can be rented for $2.50/month, and that includes 10GB of disk. What is the most expensive resource? Developer time. It’s going to be extremely rare where we want to trade developer time for a little less disk or processor usage.

A lot of this falls into the trap of premature optimization. As Kent Beck said, “Make it work, make it right, make it fast.” The make it fast part must also answer the question “Do we need it to be fast?” If our code is going to be a bottleneck then we might opt for speed in the optimization process, but in most cases we’re going to try to optimize readability.

Don’t golf your code. Except for exceedingly rare occasions, it won’t be worth it. Six months from now you’re going to look at that code and wonder what the heck you were thinking.

If you found this story interesting, please consider a clap and a follow to keep me writing them. It’d be even better if you shared it on social media.