As programmers we are ingrained to look further than the problem at hand. We try to see the bigger picture, solve problems in holistic ways if possible.<p>Often this can lead to over-engineering, creating more corner cases and ambiguity in requirements and reduction of test coverage. That is a trap to lok out for.<p>On the other hand it also can lead to better understanding of the problem space, increase understandability, and less need for later refactoring.<p>Just stating, 'don't look further than the problem you are required to solve' is not an excellent general rule.
The list of rules covered can be found in the book description on the purchase links, like: <a href="https://bookshop.org/p/books/the-rules-of-programming-how-to-write-better-code-chris-zimmerman/18606206?ean=9781098133115" rel="nofollow">https://bookshop.org/p/books/the-rules-of-programming-how-to...</a>
When I worked at Bloomberg their first coding guideline was "Don't sweat the small stuff." I was mystified by that when I first read it. Then I sat in meetings where someone would drone on about how clever they thought their code was until someone asked "Is this small stuff?" It would shut them up so we could move on to more important matters.
There are several books that commonly get recommended for all around general programming knowledge (Pragmatic Programmer, A Philosophy Of Software Design, etc) Curious how this is any different!
I believe this is the type of book that I'd like to skim to see what it has to offer rather than just blindly buy it. This is how interpret some of those points:<p>* As simple as possible, but no simpler -> Don't get into fancy stuff like e.g: design patterns just because you learnt or know them? Same for other techniques depending your language and facilities? Don't use things just for using them.<p>* Let your code tell its own story -> Use verbs for functions and methods, nouns for variables and classes so code is understood with minimum effort as is being read?<p>* Generalization takes three examples -> Sure, first you write a solution, then copy paste it if needed elsewhere as you didn't expect to be reused, third time make an abstraction (function(s), method(s), etc) as it popped up once again?<p>* A good name is the best documentation -> Picking reasonably good names for all kind of identifiers will make code self-document and understand?<p>* Sometimes you just need to hammer the nails -> Sometimes you need to be pragmatic and get a thing done, maybe not in the best possible way?<p>* Code that isn't running doesn't work -> Remove all commented/dead code from a codebase as not only running but might also generate confusion to other people?<p>I do not want to diminish the content of the book in any way nor sound arrogant, but in the past I've seen similar titles and they weren't offering that much to what I already knew at the time.
Any modern software design has to meet these 3-4 key aspects:<p>1. Make the software scalable w.r.t machines.<p>2. Make the software scalable w.r.t humans.<p>3. Make the software maintainable over time.<p>4. Make the software reusable to reduce startup costs.<p>Motivated by these, we make a lot of choices:<p>1. decompose a large complex problem into smaller, isolated, modular problems that can be worked on by different small teams, and run on different servers with inter-server communication.<p>2. organize code along with its documentation for easy understanding, readability and modifiability over time by same developers and different developers.<p>3. organize reusable and independently upgradable parts of the code for ease of upgrade with stable interfaces and stable test suites.<p>4. maintain the build/package/deploy toolchains for ease of underlying hardware and operating systems upgrades without affecting all of the code.<p>5. reuse is the only way to reduce costs – both time and effort – for anything. thinking carefully and setting up for reuse of services, systems, libraries, toolchains, processes, practices etc are critical to any large successful software project.<p>These are general rules for normal times. But there are inflection points when it is profitable to violate these rules.<p>Things that distort the cost/benefit tradeoffs and make it profitable to violate these rules:<p>1. When tech ecosystem is rapidly evolving and toolchains and libraries ecosystem isn't mature.<p>2. When time to market is super critical and if successful we will have more than enough money to deal with these problems later, and if we are late even with good software we would have failed and shut shop.<p>3. When we can't hire talented skilled engineers and still it is worthwhile to win in the short-term.<p>With these rules and violations, you can get stuck in an early local optima. A culture of continuous safe refactors is a super-power that can make you immune to it. Ossification of any kind is bad.