It's not THAT bad... ¯\_(ツ)_/¯

Alright, you've had enough. You've decided that English is just too inefficient for your tastes because you just HATE repeating the same word more than once. It doesn't matter if the repeated words are right next to each other ("I bet you had had no idea where this was going when you started") or are a distance apart ("Had I told you where this was going, you would have had no reason to believe me!"), you just can't stand the repetition! So you decide to do the only logical thing: replace every repeated word with a period, thereby completely removing the inefficiency! As you stop to pat yourself on your back for a problem well solved, you pause and realize that this would be a rather difficult task to do by hand... Of course! You can just write a computer program to do it for you!

Such was one of the problems that a bunch of our software engineers worked on in our most recent monthly Programming Contest.

Hard at work, with food!

Everyone, well fed, and hard at work

Each month, for the past few months, I've organized a series of inter-departmental Programming Contests for engineers of all skill levels. Each contest consists of a collection of problems (such as the one I described above) each of which is of the general form: given some input, operate on it in some way such that the resulting output matches what is expected. However, you are not given access to all of the input: you are only given a few example inputs and outputs, but you must write the program so that it can take any input (of a specified format) and produce the correct output. Your goal is to correctly solve as many of the given problems as rapidly as you can: mistakes result in score penalties, and whomever can solve the most problems the fastest wins!

Now, I know what you're thinking: "Why in the world would someone, whose very job it is to write code all day, want to participate in a programming contest where they have to write even MORE code, but with the added "fun" of having to do it under a time limit, and against other, possibly more senior, engineers?!" To which I have three responses:

First, because the winner(s) of our contest always get a prize, such as the brand new Amazon Echo Dots given out at the last two contests. And I mean, who doesn't love free stuff?

Amazon Echo Dot

Our last two contests' prize: the Amazon Echo Dot

Our winners from the last contest: Saravanan Kathiresan and Kapil Londhe

Our winners from the last contest, Saravanan Kathiresan and Kapil Londhe, holding their hard-won and gift-wrapped prizes

Second, because we always provide a bunch of delicious New York food for everyone participating (see the previous point about free stuff)!

And third, because the type of coding that is best suited for programming contests is very different from the type of coding best suited for software development.

This last point I would really like to expand upon, and I think the best way to do so would be with an example. Let's return to the problem that started off this blog post: Engineering English, and take a look at the code I used to (correctly) solve this problem in Python 2.7:

d = {}  
while True:  
    try:
        l = raw_input().split(' ')
        nl = []
        for w in l:
            nw = w.lower()
            if d.has_key(nw):
                nl.append('.')
            else:
                nl.append(w)
                d[nw] = 1
        print " ".join(nl)

    except EOFError:
        break

Now, those of you who have spent years working on production-quality code probably saw that example, dry-heaved a little, and thought something along the lines of: "That monster! There are no comments anywhere! There's an infinite loop! None of the variables make sense, and the longest variable name is 'nl', which isn't even a word!" To be honest, I can't argue with any of those points: this code would never make it past a code review, and I would never even dare submit it for one!

But, it is exactly for these reasons that engineers are willing to take a break from coding for work, to go and code for a programming contest: in a programming contest the code itself doesn't matter, the only thing that does matter is that it solves the problem. Programming contests aren't about writing well-documented code that can be understood and maintained for years by people you might have never met. They're about writing working code as quickly as possible, which you will probably never look at again once it works (it even took me a few minutes just to find that code I had submitted). They wholly emphasize solving the problem by any means.

That's one of the reasons why, I think, programming contests are so appealing: they give engineers a chance to forget (or at least ignore) all of the (necessary) formality of production coding, and instead focus on the essence of coding itself, to solve problems. Taking a break, once in a while, to go back and just focus on the core of computer science helps keep it all fresh in your mind, especially concepts and constructs you might not use in day-to-day work, which can only help to make you a stronger programmer.

Now that you've heard me talk about why I love programming contests, why not try one and find out for yourself! Our contests are always open registration so anyone, whether you work at Viacom or not, can join in! Our next contest will be on Thursday, March 2nd, at 12:45 EST, so if you're interested, click here to join! (Note: in order to receive a prize, you must be physically present at our New York site!)

Trevor Masters

Read more posts by this author.