You may have heard of minimalism before in all sorts of disciplines and philosophies of life. Some of you might have heard of it as living without many possessions or perhaps in computing to refer to using as least amount of hardware and software resources as possible. I would like to take a small spin on perspective of applying this philosophy of life and apply it to writing code. While I believe the minimalism of computing is a bit more about the resources, I will speak of minimalism more in terms of using less in programming.
“Ok Martyr, why even should I care about any of this code minimalism garbage?” Well, you should always be striving to write better code. No matter how many years you have tucked under your belt writing systems, you can always improve. Many programmers tend to look at a piece of simple chunk of minimal code and think of it as “elegant”. It just makes sense. It has no unneeded statements, no fancy tricks, straight to the point and has ultimate readability. Minimalism, as I think of it, will help with all of these things. The philosophy has a few key ideas…
You may follow some, or all, of these tips already and that is good. I am trying to codify the practice into a way of thinking that will help you realize what it means to have simple code. I think many programmers still don’t know what it all means. They also don’t realize why much of the code they see online is largely bad code. By the way, I think much of this code online is written by people who are new or just writing enough to get a job done… not that they are passionate. Read my article on “Why everyone should NOT learn to code” for my ideas about that.
Programmers are complex thinkers. As engineers we think of a solution and it is often the first one we think of that we go with. It is also the first one we think of that is the most complex. We lean on what we know, we lean on something we just read and want to try out, we also think about the code we might have already written that could help and shoe horn that code into the solution.
Just recently I was in a meeting with other engineers who needed to solve a problem about running some desktop style software from the web. We needed a web interface to feed data into a command line across languages, across systems and across platforms. Of course as soon as the engineers started brain storming they started throwing out ideas like “We could use a file to store some parameters and the software could read this file using a queue, but it would need access to the other server. Oh and what about race conditions and timing and …” I sat back and let the ideas roll a bit and then started throwing out ideas that many people thought at first were counter productive. “We don’t need a file. Heck, the front-end doesn’t even need to store the parameters. On top of that the other server doesn’t even care about the front-end. We don’t need to do that, this or the other thing. That is all too complex.”
The other developers were confused at first but then immediately caught on to what I was doing. I wasn’t talking specifics quite yet, but they saw that I was reducing reducing and simplifying the problem space. As I chopped away at the problem, they saw the code they would write get more minimal and simpler. That is what we want! Simple means clear, concise and often has a lower bug rate. For the developers, it also meant less code writing and more at work doing something else more in line with their passions.
Ok, one of the problems I am finding, particularly with C# (btw C# is my favorite compiled language) is that they keep introducing stupid syntax sugar. We talk about readability yet they take what was simple loops and reduce them to dumb lines that to the untrained reader doesn’t even look like a loop. Yeah simple for experienced users, but horrible for new people. Sure the language lets you do this, but it doesn’t mean you should. Of course we are always excited to use what we just read about from the latest tech magazine, but it may not be the most straight forward way to do it. Often times I see 3 lines of code added just to setup the situation to use the new line of code. I could have just written 1 line of run-of-the-mill code and accomplish the same thing. Use the simplest syntax to get the point across.
People read this principle and think premature optimization. I am not talking about that. Going back to the previous paragraph above, if you find yourself adding code to use other code rather than a simpler non-glamorous way, you are doing it wrong. We can always optimize later, but often times we want code that just looks vanilla and does the task. I rather stare at a simple loop and say “Duh, seen this a 1000 times before” than see a new line of code with a bunch of setup code and be like “What the heck is this?” Don’t write 4 lines to do what 1 line would do easily. I know it is not exciting, but you will be more excited when you have less bugs and things “just work” at the end.
This rule is the top rule of them all. Minimal code doesn’t mean the fewest character variable names and a ton of abbreviations. It is minimal in its ideas and thoughts. If you are making a peanut butter and jelly sandwich, call it a knife, not a “metallic serrated blade used for cutting”. Call your variables what they are, what everyone would know it as, what a 5 year old looking at it would know it as. Simple ideas make for simple code and simple code starts with simple words.
No matter the language, I think if you adopt one, or many, of these principles when thinking about your next class/function/data structure you may find your code “boring” but it would also be highly effective and usable. That project I spoke of earlier, I minimalized the process so much in the end it lead to my work load being reduced from something like a week to 1.5 days. I needed to write a little HTML/CSS/JS and talk to a few REST endpoints using some AJAX. I don’t have to worry about files flying back and forth, I don’t have to worry about a database connection and how the other process would read it. In addition to that, I put more pieces into a preferred partner platform we wanted to show off (for the curious it was Amazon) which would make the bosses happy. All because I apply a few minimal code philosophies to what others thought would be a much more complex project. The major pay off, I won’t have a dev a year down the road coming to me to ask what the code does. They just look at it in all its simple glory! Thanks for reading!
If you liked this article and want to get started with a project, consider my book called “The Programmers Idea Book“. It features 200 project ideas including comments to get started, resource links, difficulty rating and more.
