David Heinemeier-Hansson has recently created a few videos on “writing software well”, where he shows some examples of his workflow and reasoning behind how and why code was written in a particular way. I do like that he shows real production code in his videos, instead of some obscure fake example.
It’s partly a reaction to the endless debates we tend involve ourselves in as software writers without looking at real code. When you debate without code, you’re likely to get sucked into illusions of disagreement. You argue from your experiences with codebase A, I argue from my experiences with codebase B, and we clash because A isn’t B. That’s just silly.
Yet somehow arguments grounded in production code are rare. Few people seem willing to lift the curtain on such codebases, which is a damn shame. Because that’s where the real wisdom is buried. That’s where people have been forced to make actual trade-offs between competing patterns and practices. It’s those trade-offs and the circumstances around them that are valuable.
Source: DHH on writing software well
Writing software well is an art in itself, and you can discuss ages with others regarding how you solved a specific problem. It depends on various factors that you’ve taken into account, such as the framework used, the value of a specific problem, and craftsmanship. Robert C. Martin also wrote a book about writing clean code (“Clean Code: A Handbook of Agile Software Craftsmanship”) and what in his eyes are the necessities of clean code. This book is deemed a very good read, and I can’t but agree after having read it a few times.
Though, sometimes the best way to write software is by not writing any software at all for a problem, you might be able to solve a problem outside software in a more simple way. I know, as developers you want to write software to fix a problem, so that is a harder thing to do. And if you need to solve it with software, you can ship a solution in iterations. Preventing you from creating overly complex solutions for a problem, and it allows you to test your assumptions. I’d like to stick to an approach that takes out unknowns and clarifies assumptions, which I later discovered to be quite similar to first principles thinking.
The following four rules are for me important when writing software:
- the boyscout rule of leaving the campground cleaner than you found it; leave the code in a better state than I found it. This could mean clarify variable names, or even refactoring functions to make them easier to understand.
- have an idea of where you’re going with your solution; explicitly know your assumptions and know what you want as a result, this keeps me from making a solution overly complex.
- stick to a good code convention; adhering to team code formatting and naming conventions, these keeps the codebase having a sense of togetherness.
- don’t repeat yourself (DRY); I try to avoid code duplication, in order to have one place of truth. A future colleague that will maintain your code will thank you.
Sure, it doesn’t cover the full spectrum of writing software, though for me it makes it easier to grasp the concepts of writing software well.
P.S. If you’ve enjoyed this article or found it helpful, please share it, or check out my other articles. I’m on Instagram and Twitter too if you’d like to follow along on my adventures and other writings, or comment on the article.
Buffer
Tweet
Share