I started reading Kent Beck’s “Smalltalk Best Practice Patterns” today. This book could be considered ancient in Internet time (it was published in 1996). But I’ve found it to be one the better programming books I’ve ever read.
Unlike most modern tech books, Smalltak Best Practive Patterns gets straight to business with ideas for good design by page 6.
These are the properties I strive for in my code … Once and only once -If I only have one minute to describe good style, I reduce it to a simple rule: In a program written with good style, everything is said once and only once….
Lots of little pieces –Good code invariably has small methods and small objects … no one thing I do to systems provides as much help as breaking it into more pieces
The video is just under 30 minutes and worth the watch if just for nostalgia alone. For the the TL;DR crowd, the first four minutes sum up the exact same problems we still have today. The kicker starts at the 3:15, mark where they describe how to build systems:
Another way is to write many, many small modules of code.
Kent’s same advice, this time from 1982.
1996 was my first year of computer science in college and sadly I was never taught this. Throughout my professional career, I only worked with one programmer who actually practiced this pattern. The talent spectrum of programmers is wide and definitely subjective, but I would wager the majority of developers still do not follow this advice.
We are still dealing with the same problems that the great minds of computer science (and by great, I mean Dennis Ritchie and Ken Thompson) were solving 30 years ago. I love being part of an industry that is constantly in forward motion, but we do have a tendency to drop ‘tried and true’ for ‘new and shiny’. We manage to divide ourselves into small communities and focus on tools, but do little to collectively move our industry forward, solving the issues we all experience in practicing our craft.
“Most of the problems being dealt with by programmers are caused by programmers.”
Perhaps we should start our own “Slow Food Movement” in technology. When the next new hotness emerges, we spend less time on build tools and package managers, and more on how to build maintainable software.
We gain nothing by dismissing the effort of those who have already done the heavy lifting for us.