Photo by Isaac Benhesed on Unsplash
Keep It Simple, Stupid is the mantra by which I strive to develop solutions. But it wasn’t always like this. I have evolved as a developer as my skills and knowledge have gained the experience needed to make solid choices.
“If you can’t explain it, you don’t understand it well enough” -- Albert Einstein
When I first started to write code, I had no idea what I was doing. I Just threw stuff together until it worked. Mind you this was well before the internet or the devil magic that is Stack Overflow. As I learned things, I applied them. It felt great! That is until I went back and tried to read things or worse yet explain them to another developer.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” -- Brian Kernighan
It took me far too long to realize that clever code is usually bad code. Now, that isn’t to say it won’t solve the problem. It can solve the original problem. But if the solution is something that needs to be maintained or enhanced, clever code is not the best solution.
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” -- Robert C. Martin
The code I write now is hopefully understandable by all developers regardless of their individual experience level. At the very least, I can walk people through the code easier. Now I choose to write code that is more simple instead of landing there by accident.
This doesn’t mean the fewest lines of code to solve the problem, nor does it mean that I am writing the same code I would have when I was just starting out. It means I am trying to keep things simple. Less to read, while still easy to understand.
Here are some common tropes that I incorporate into my day-to-day development practices:
Using static analysis and coding standards is a great way to keep a code base readable by all. I try not to customize the linting too much, just take what comes with it and deal. That way the decisions are made for us, and there is no arguing over what should be used where and when.
Don’t Repeat Yourself, is a simple concept, but in code can be tricky. How much should you reduce duplication? Sometimes, it is better to duplicate parts in order to keep readability high. Like if you have to make dynamic class names in order for things to work… that might not be highly readable/traceable.
Variables, constants, methods, functions, attributes, parameters, yes… all of it. Why? Because that is how our brains are wired. Sure it may make sense to group things into logical pieces of domain when writing them, but come back 2 months later and all that context is gone! Finding things when alphabetical is WAY easier!
While this may seem minor, having a random string inside your code can become very ambiguous over time. Worse, it can make changes and tracking hard. Put those strings (and numbers for that matter) into variables that explain what they are for.
It really is one of the hardest things we do. I need to name things so the person after me (which could even be me) will understand the intent of what I am trying to relay. Because of this I have four rules.
Writing easy to comprehend code is extremely freeing. It helps everyone on the team level up and maintain a high performing solution. If you don’t believe me there are a ton of great resources out there to learn how to KISS. Read Clean Code by Robert C. Martin, The Art of Readable Code by Dustin Boswell and Trevor Foucher, or The Pragmatic Programmer by Andy Hunt and Dave Thomas.
Are you ready to build something brilliant? We're ready to help.
.jpg)
