This article originally appeared on Medium and is being republished here for easier, free access.
In the tech industry, I hear a lot of great developers claim to know absolutely nothing about design. They treat it like a mystical world, something beyond the more absolute world of programming. They feel they could never “do” design because they simply don’t have the apparently innate ability for it.
I however, couldn’t disagree with them more. Good programming is good design. That is to say, good code is code that is well designed code. Any programmer who writes good code is simply writing well designed code. The principles that define what is good code are strikingly similar to those of good design.
Look at any of Dieter Rams’ Ten Principles of Good Design, you’ll notice in almost all cases you can replace the word “design” with “code” and “product” with “software” and you have a principle of writing good code.
This is obvious, when you’re writing code, you’re trying to solve a problem in the best way possible.
If you’re writing code that has no use in the software, and doesn’t contribute to something useful, you’re likely writing unnecessary code, and unnecessary code is always bad code.
Good code is easy to read code, and good programmers know it’s worth the time crafting explicit names, separating functionality and generally working on the readability of the code. Good code looks good on the screen. It’s well executed, well planned and well organized.
Again, separating functionality and choosing meaningful method and variable names is essential to good code, and makes discerning what the code does and understanding it easy. Code that is hard to understand is bad code.
Good code doesn’t intrude on other code, keeping code SOLID is very important for creating good, maintainable code. When a method intrudes on another method, it makes managing the code difficult. It should stand by itself, making it easier to manage and easier to reuse.
Making sure your code does exactly what its name and purpose would suggest, and separating those concerns is important in code. If your method is a naming function, it should do naming and nothing else. It should not also save, update, rename, erase or anything else it’s not explicitly defined as doing.
Creating manageable, maintainable code is incredibly important. Some of your code could still be being used ten years from now, and if you’ve created a mess of bad code and mixed up concerns, it’s going to be trouble for you (or your replacement) down the road.
Good code is a thoroughly thought out solution to a problem, it leaves nothing to chance. This includes thoroughly testing different cases and making it as accurate a solution as possible.
This might be a bit of a stretch, but good code is environmentally friendly in a different way from physical objects. Good code is friendly to the software environment, it doesn’t repeat itself, it does what it’s supposed to and separates concerns. Bad code is bad for the software environment and creates code pollution and makes the project “ugly” (like real pollution).
This pulls it all together, creating elegant solutions that do exactly what they’re supposed to, don’t repeat themselves and are well organized. The biggest project bloat is always caused by repeating methods, poor orgnization and intermixed concerns that break things down. Keeping things “less-but better”, simple and down to their core functionality, then stringing them together to create a piece of software is good code.
It’s easy to see that programmers who write good code are really designers, they work to create the best solutions to problems following virtually the same principles as the best designers. Good code is simply code that is well designed, thoughtfully crafted to be unobtrusive, long lasting, easy to work with, easy to read, manageable and useful. Good code works in the same ways the best UIs or finest furniture does, a lot of people just don’t realize it.
If you liked this you can also follow me on Twitter, check out my GitHub, and take a look at my other blog posts.