You Should Write Bad Code More Often
By: Ygor Rebouças Serpa
Tags: Startup, Software Development, Programming, Productivity

Write Bad Code More Often

All we use is the product of decades of innovations and failed designs.

You can only truly grasp the beauty of a garbage collected language if you dive on some nasty C/C++ code. Until then, all you can do is imagine how painful it was back in the day. The whole hate over singletons can only really be understood by those that got to write one and faced the many issues associated with them (such as writing tests).

Theres a whole world between textbook samples and real-life experience. The former is no more than a hint; the latter really changes how you code.

Most of us, back in our beginner days, coded without Git or Unit Tests. These projects tended to be buggy, and, more often than not, they would stop working at all. Without Git, you couldn’t tell what you might have accidentally changed. Without tests, things would stop working days before you bumped into them again. This experience is what motivates us to use these tools every day.

To truly understand how to write good code, you must write bad code first.

There a couple of ways you can force yourself to write bad code (or to see ugliness in your current snippets). It all boils down to one thing: try coding some other way. This will either show you how much better your solution is or how stupid it was (“was” because you’ll change it, right?)

Here’s a list of things you can do in your spare time:

Learn a Parent Language: Kotlin, for instance, is inspired by Scala. Swift, among other things, tries to solve Objective-C issues. C# superseded Java. Learning parent languages teach you how much of “what you have now” was not present back then (and what it solves). It will teach you to appreciate more a lot of things you might otherwise think are crap. Learn a “Successor” Language: If you are a C++ developer, you should try Rust. Java folks should give Go a go. Python users might try Julia or Nim. JavaScript guys ought to try TypeScript or maybe Dart. Unlike learning a parent language, this will show you how much of what you do now is crap and how it could be better handled. Learn LISP: This is a weird one for many. LISP has no variables. It is a fully functional programming language (that’s easier than Haskell). You don’t need to be any proficient with it, but try writing some algorithms, such as Fibonacci, quick-sort, or Huffman coding. If you take your time to do so, you will realize how variables are, many times, unnecessary. Write a Text Processor in Plain-C: Given a path to a text file, open it, remove all line breaks, and add new breaks after every period ( . ) character. Then, shuffle each word keeping the first and last characters unchanged. Bonus points if you process each line in parallel. This will (quickly) show you how string processing has evolved dramatically. Look for Design Patterns: Take a list of design patterns, such as this one, and open up some project you work or worked on. Take your time to read about each pattern and try finding places that could benefit from one of such patterns. For each one you see, try picturing how much cleaner it would be if you had used it (bonus points if you refactor it). This is the best way to incorporate design patterns into your repertoire.

These tips, in essence, are all trying to either make you code differently or take a second look at what you have already done. Either way, you’ll notice that not everything is as shiny as you might have once thought.

Besides, I am not telling you what’s wrong or what is right, nor how to code. Instead, I invite you to…code. Code in a new language. Try doing the same thing in two different ways. Coding is the way to be a better coder. Not reading some random blog posts on the internet.

Thanks for reading!