• Daniel Kephart

Actually, Please Do Reinvent the Wheel - Lessons From a Computer Programmer

Our article today is written by guest author Matthew Kaufman, a computer programmer with additional interests in philosophy, theology, and creative writing.


Programmers try to write the smartest code daily, but all are fallible and fall short of programming perfection.

Writing any kind of program or application can be extremely tough. Beyond the starting hurdles of developing a mindset for writing code, knowledge of the tool set you have available can be one of your biggest limiting factors. I often liken writing code to building something with Legos just from looking at the picture. The difference being that you have an unlimited amount of pieces you can use, so long as you know how to use them all properly. In this fashion, many programmers find themselves falling into habits. Why push the boundaries and learn new tricks as an old dog when the old ones still work? Well...

Why limit the variety of pieces at your disposal?

Out of all programming languages that exist out there, one of the most agonizing is a little language called JavaScript. You've probably heard of it, but you probably don't know just how dependent you are on it. It's everywhere. Unfortunately, it is also clunky, weird, and problematic. Due to this, many people treat it like a leper. They don't want to touch it. In fact, they'd prefer it was stuffed in a closet with some saltines for the rest of its miserable little programming language life. Not me. Instead, I say that we, as programmers, should charge bravely into the unknown night in hopes of finding a new dawn. A new dawn where all our programs run efficiently and are easy to read (nerdy, I know).

If you don't quite get this...feel free to skip ahead :)

Let’s start with an easy (cough) to follow and simple (cough) example. Many programmers have most likely used something along these lines before. It seems comfy and familiar to programmers. Sure, to you it looks like Greek had a baby with Gaelic, but that's okay. Honestly, Greek can have a baby with whoever it wants so chill out. Anyway, for programmers this is "see Spot run!" We’re making sure that we made the variables and that the user entered some text. It's as comfy as a Sunday spent reclining in front of NFL football. It's nice. But is this the best way?

Well, the shortest answer is quite simply, no. This is a perfect example of a programmer limiting themselves by only using the tools they know well. As someone who knows JavaScript a bit more than most, allow me to show you a better solution and why it works.

This is much better. (Brace yourself, jargon incoming) We are computationally better, only executing one single check instead of three. We have cleaner and easier to read code because we took a very long ‘if statement’ into one short chunk. But why does this work? Well, it is because we are leveraging the ‘weird’ nature of JavaScript to our advantage.

You see JavaScript, unlike most other computer languages, will happily convert anything to anything, even when programmers think it shouldn’t or don’t want it to. But in this case, we’re that same wierdness programmers don’t like, and making it our friend. You see, by using a special operator, ‘!’, at the beginning of the statement, we’re telling JavaScript to treat the following as a statement that will be converted to either true or false. A good mind of JavaScript will reveal the fact that ‘undefined’, ‘null’, and the empty string all resolve to false when converted. So if we want to make sure our variable isn’t any of those three, why not just convert it and check all three at once instead of checking each one step by step? Better yet, why would we stop here?

We can lose the if-else, too.

Looks weird, huh (okay, I get that it all looks weird)? But it works, trust me.

You see, JavaScript, like many languages, will check each part of a boolean expression one step at a time. So with this example, we’re using even that to our advantage. The ‘foobar()’ won’t even be ran by the computer if it knows that what the user put in was empty or if the variable is ‘undefined’ or ‘null’. Conversely, we can just invert this operation with our ‘!’ operator and use the same trick to run ‘boofar()’. While we are sacrificing a bit of code readability here, we are limiting our lines of code down and we are also creating a bit of style into our code.


But why does any of this matter? To anyone who isn’t a Software Engineer, this all may seem stupid, boring, or just plain confusing. Well it’s a life perspective matter. As humans, we tend to approach problems from the same direction over time. We slam our heads into walls till they fall. Not ideal. Sometimes exploring the new and unfamiliar is a better option. Sure, sometimes you’ll find out the new approach you tried doesn’t work, but that doesn't matter. You're looking for new oddly shaped Legos that may not be necessarily be useful today. Tomorrow, though, that piece may be exactly what you need.

That's not programming. That's life.

The problem solving tricks we programmers use can actually help society as a whole. After all, they're pretty universal. Like you, programmers are always learning these weird strategies and approaches. Facing these problems makes us smarter people, better people. Learning new ways to program, even if you’re not a programmer can help you develop a better set of problem solving skills.

First off, don't try to check everything individually when you can check them all at the same time without any detriments for doing so. If you’ve ever cut up vegetables, this is why we try to cut all the chunks at the same time rather than separating them and cutting each chunk into a smaller piece and then moving on to the next. It seems stupid, but so many people forget about approaching problems in this manner.

Secondly, prioritize your attention. What you focus on--and the order you do it in--matters. After all, if you’re inspecting a car for safety, you’re not going to bother testing the emissions if the car has a windshield missing, are you? It sounds simple, but it can be more confusing than a page of code. Too often we become ingrained into our rigid processes.We forget to try to break up the monotony. We treat ourselves like the computers instead of people writing innovative solutions. We forget to try new things, and that can cost us time, money, and effort. Or all three, for that matter.

Does that demand reinventing the wheel? Maybe. Occasionally questioning the effectiveness of the wheel can be a good and healthy practice. We know this deep down. We know electric lighting is better than candles today--but halogen bulbs didn't spring up over night. They were the result of an investigation. The candle needed reinventing. So go out there and question the design of the wheel. Who knows, maybe your question and idea might actually provide humanity with a better wheel.

Thanks to today's guest author, Matthew Kaufman, for contributing his expertise.

Recent Posts

See All