Your code sucks - and that's OK!

Published: Jan 12, 2018, 6:00 am

Opinion

Rant

Your code sucks. In fact, it sucks pretty badly. There, I said it, but at least I didn't tell you it's bad and you should feel bad. Because you shouldn't. Bad code happens to everyone. To you, to me, even to that guy flipping burgers in the cafeteria who never got a good job because he only learned to program in Oberon (seriously, look it up). 

I think to understand where we are coming from, it's pretty important to look at some common causes of bad code:

  1. Bad design. I don't think this one needs much explanation and can come in many flavors. You didn't think things through, maybe you didn't think at all. Or you made a design that didn't match your requirements. In any case, bad designs lead to many changes, APIs that don't really fit what you're trying to do, and in overall bad code
  2. Changing requirements. Even if your design is perfect, there are always things that can throw you off. Maybe instead of async replication you suddenly have to support streaming (Looking at you, Dave). Maybe your small internal tool suddenly needs to be translated into different languages. It's easy to understand that such changes can lead to many changes and decrease the quality of your code.
  3. Programming languages and libraries. This one usually get's a lot of hate, but hey, luckily our blog has comments disabled. So, I'll just say it. There are good languages and bad ones. Same for libraries. If your api call is List.Add, then the opposite should be List.Remove or something similarly logical. If you instead use List.Append and List.Bananarama for the same functions then no program using these functions will be very readable.
  4. You don't know everything. There is simply no way. So if you wrote your own function to do something that the basic libraries you're using already do, other's may raise their eyebrow and point it out as bad, redundant, or not optimized - but how would you know? And you'll be surprised about how many language features and library functions you don't know about - even if you have used the language and library for many years.
  5. IDEs are NOT (always) your friends. Sure they help when refactoring code and built-in documentation telling you the expected parameter types is just awesome. But at the same time, the higher-level the functions in an IDE are, the less clear the generated code is. And while code that is generated in one location may be obvious, once you copy and paste it somewhere else, the original intent can easily get lost.
  6. Fast code is rarely obvious. I love optimizations. There is just nothing more gratifying than when you take code that users have complained about for weeks and turn it into something that executes in the blink of an eye. Don't you like our new remote deployment script? It took a full deploy and audit from about 10 minutes down to less than 15 seconds, but to do so, we had to... well optimize. As a result, where you had previously well structured code with modules and objects, you now have a mess of code that doesn't even do error checking until the end of the program or if something didn't behave like it did in the last run. You can check out the code. It sucks. But boy is it fast!

I could probably add a few more points to the list but I think this is enough to make my point: How many of the issues are under your control? Bad design surely is, but what about the rest. Can you really be blamed for not knowing about promises in your first JavaScript project? For mixing the getElementById you've been used to for a decade with that newfangled $ from jquery? Or that the C++ core of your game server is a 200 line beast of if's but now handles ten times the users it did before?

So don't worry and don't feel bad. While we're far from perfect. I just recently figured out the performance results of /i pattern modifier in PHP after having used PHP for way longer than I'd care to admit.