Keep it Simple

First let’s and acknowledge that syntax and the language is the easy part of coding. Everything else is the hard part. Creating code that is simple, readable, resilient, easy to debug and maintainable is hard. Creating code that is easy to maintain by yourself and others is hard. Designing something that works inside the context of a legacy system and can be easily understood by coworkers is hard. It gets easier with time. To get to a point where things are easy and stays easy and is easy for others, you’ll want to invest in the discipline of keeping things simple.

Overthinking, over engineering, over complicating a problem are enemies of productivity and maintainability, and avoiding burnout. You want to write as little as possible, you want the code to do as little as possible to avoid bugs and side effects and you want to read as little as possible when you or someone else needs to add to it. In this first post, I’ll focus on KIS or Keep it Simple

KIS - Keep It Simple

I’ll acknowledge that the whole term is KISS: Keep it Simple Stupid but maybe we don’t need to insult ourselves as part of a mantra. Also, it’s probably not a good idea to call people you work with or others stupid.

The definition of simple is subjective to project, language and team. Keeping it simple means that you write less code, maintain less code, introduce less opportunity for bugs and make it easier for the next developer to understand your work. Keeping it simple means knowing the problem you are trying to solve and avoiding unneeded complexity when solving that. I’ll try to provide some tips on how to get there.

Take the time to answer the below questions

  1. What exactly does this need to do?
  2. What is the bare minimum to make that happen.
  3. Can I objectively say that the problems I am adding code to solve are relevant?
  4. What tools are my coworkers using and am I introducing a tool with a steep learning curve?
  5. Are the changes I am introducing absolutely needed. Am I refactoring for refactoring sake?

Ask questions, invest time in reading the code or studying infrastructure. If it’s a personal project, know your goals and pay attention when new technologies and complexity are a distraction. I suggest writing out the problem your solving or goals for the change for in plain language. When adding complexity or changes, you can ask yourself if that action solves the problem you are currently solving.

Don’t be afraid to take notes while reading through code to understand the problem. I feel it’s common to see developers taking notes when gathering business requirements, but when they need to read through complex code, they just try to absorb it all. We all have limits. There is no rule that you need to keep all the understanding of code/infrastructure in your head!

Sometimes you find out the solution that you need is very simple after a large investment of time and writing code. It might be a single if statement or a tiny config change. For many, it isn’t satisfying to solve a problem without a larger contribution. A simple solution might unjustly get labeled a band-aid or a hack. I think band-aids are wonderful inventions that don’t get enough credit for most minor injuries, they are the exact thing you need. Knowing the problem in depth means you understand the root cause and if it needs to be solved or not. You’ll know if a band-aid is appropriate if you’ve invested time in understanding the issue. Have confidence in the solution. If you know the problem, you’ll know if your solution is a hack or not. Ignore comments or the feeling that something is a hack if the word “hack” is code for “too simple” or “boring”. Have confidence in the solution.

It’s tempting to keep a more complex solution to feel that satisfaction of contribution. For that, I’ll say there is always more code to write. Defining maintenance as a problem means that refactoring or large changes can be done it’s own scope. Don’t attach yourself to lines of code. Celebrate simple solutions, celebrate boring code, celebrate removal of complexity. Spread this feeling to your team. A few nice words on a pull request or celebrating someone in a slack message will go a long way.

Hopefully this helps you. Keeping it simple is a discipline and it gets easier with experience. My experience is that developers can have a hard time getting over the desire to add complexity. Keep working on it. It’s worth it, I promise. It might even help outside of programming.

Advertisement