This is at the root of it all – most of what follows are just different ways of reducing complexity. But why is reducing complexity important? It’s actually pretty obvious because its everywhere – we are human and humans are fallible. We make mistakes. We tend to make mistakes more when things are harder to do, ie more complex. Computers don’t make mistakes, they just do what we tell them. So it is upon us to correctly tell computers what to do and for us to do that reliably we need to make things nice and simple for ourselves.
There is no real skill needed to place a ball on the floor, but to balance a ball on your nose… that takes lots of skill, balance and practice. If you were set a task that could only be achieved by balancing a ball it would be a wise decision to balance it on the floor rather than your nose. Less complex. Less can go wrong.
Writing software is never going to be as easy as placing a ball on the floor, but the process will be made up of many small decisions where you can choose to simplify things, or not. Often the most obvious choice will be the one that eventually becomes complex, so you need to consciously choose the route of simplicity and you need to do that over and over and often it may seem like more work. Some complexity will end up living somewhere so its best that you choose where and try to reduce it as much as possible.
I was going to put this much further down the list but, like reducing complexity, it is at the heart of so much of what will follow.
Computers move data around as a series of zeros and ones. Languages like C# were not created for a computer’s benefit. They exist for us humans, to help us write code that we can understand. We are making an immediate mistake if the code that we write is not easily readable.
Is readable code just about the use of comments? No! Comments can be useful for setting context, but if the code itself is readable – by using function names, parameters, variables etc that are self-explanatory – then the need for comments mostly goes away.
The structure of the code is just as important. Breaking code down into small easy to understand chunks helps to make it readable. How do you do that? Well, you use techniques like…
All of that is a big ask right? Code evolves as you write it and before you know it you have painted yourself into a corner. So how do you avoid that?
Firstly, ask yourself this question – what is the primary role of a software engineer? Is it to write code? When you stop to think about it, software engineers are here to resolve a problem and that involves figuring out how you are going to solve the problem.
A best-selling author creates a story in their head. Writing it down is just the way that they share the story. A good software engineer creates the solution to the problem they are working on in their head. Writing lines of code just communicates that to the computer.
The way to ensure that you are using the techniques described above is that you plan to use them. You design and plan your solutions to make use of the techniques before to start to write any lines of code. And you constantly refactor your code, forcing yourself to adhere to the rules of simplicity. Has a method grown in size? Break it down! Ended up re-using a chunk of code three times? Move it into its own function!