I might come back and do a more thorough look at each of these differences later, but I wanted to get a rough idea of what were the main changes to each of the chapters in the recently released 20th Anniversary Edition of the classic book, The Pragmatic Programmer.
There’s probably plenty more other changes even in the sections that are common between both editions, but this is a high level overview of the major differences in each chapter, summarized as:
The software development industry is full of best practices and recommendations, many that evolve and change as our technology changes. There are some core concepts that remain beneficial even though programming languages and runtime technology platforms have changed over time.
Here’s a summary of some core principals that can help us develop software systems more effectively:
Unnecessary complexity in code is technical debt that will to cost you at some point in the future – it’s more likely to contain unexpected and hard to find bugs, and complicated code it harder to understand, and therefore harder to maintain. Keep it simple.
DRY – Don’t Repeat Yourself
Avoid duplication in code. Duplicated blocks of code are a maintenance risk. If there is bug in a block of code that exists in multiple places, fixing the issue in only one place means that the issue still remains in those other blocks of code. When other developers are maintaining the code in the future, it may not be obvious that the same code exists elsewhere.
The cost of maintaining a system increases in relation to the more code that is part of your product or solution. Why? Because the more code you have, these’s a higher risk for things to break, go wrong, increased effort for testing, and so on. You won’t have bugs in code you don’t have (you may have missing features but that’s a different problem). It makes sense therefore that you shouldn’t build additional features that you or your customer doesn’t need or want. The YAGNI rule is that if you don’t need it, don’t build it. Don’t make your job harder by increasing the possibility for things to break, or increasing the overhead of maintenance by building unneeded features that need to be fixed, updated, tested in the future. Don’t write code you don’t need.
Design/plan/structure your code to enable easier unit testing
Not everyone agrees whether Test Driven Development (TDD) should be followed as an absolute rule or not, but thinking about your tests first has a benefit that can be taken and used to your advantage even if you don’t subscribe 100% to the TDD approach. If you think about structuring your code in a way that makes it easier for you to test, then it’s immediately easier and takes less effort to write your unit tests, compared to code where there was no effort or thought into how the code could be tested. Simpler code is (usually) easier to test, compared to overly complex code that is usually much harder. Simpler code is easier to understand and maintain.
A while back an xkcd comic on Voting Software attracted a lot of attention on Twitter for it’s alarmist comparison of the attitudes of the software development industry to other engineering disciplines and in particular, this statement:
“our entire field is bad at what we do, and if you rely on us, everyone will die”
From: https://www.xkcd.com/2030/
From: https://www.xkcd.com/2030/
This was widely shared and quoted on Twitter, and even shared by industry leaders such as Grady Booch:
“I fear that perpetual adolscence is our curse and our gift – (we’re) always chasing the next shiny thing”
Joerg Muller-Kindt
This thought that as an industry we’re stuck in “perpetual adolescence” caught my attention. As an industry we struggle to advance. What’s unusual when you think back over the past 20 years and even further back looking at the history of our industry, there are developments and ‘movements’ where groups of individuals come together to champion an idea that at first seems to make a positive improvement to our industry as a whole, and then over a few more years the ideas fade away and seem to be forgotten. Some are even occasionally rediscovered again by another group of like-minded individuals years later.
The ‘perpetual adolescence’ of our industry as I see it is not that we’re stuck at a particular point in our industry’s growth and unable to progress, we do progress and advance. This growth however, appears to be in short cycles where we move forward, but then we go back to what we were doing before, and we’re stuck in a cycle of discovery and rediscovery. It’s not as bad as one step forward, two steps back, but it does appear to be something like one step forward, one step back. We’re never continually advancing, occasionally we move forward but we end up going backwards again. The progress of our industry never seems to be continually moving forward. Maybe this is typical of any industry in its infancy.
The cycle of centralized vs decentralized (distributed) systems
The hype of Functional languages
Strongly typed vs dynamic languages
Platform independence vs platform dependence (of languages and technologies)
Software development as an engineering discipline or an art, and everything in between
Serverless, as the solution to all problems
There’s plenty of other ideas and concepts that could be part of this list, and I’m not highlighting anything in my list to say these ideas good or bad, but when you look back it’s interesting how ideas come and go over time. People come and go too, some noticeably bringing new ideas and passion with them, sometimes rediscovering ideas again from the past. Sometimes as champions leave the industry their ideas no longer have a voice and their ideas disappear with them too.
If our industry is still in its infancy, is this cyclical, repetitive behavior just the industry trying out new ideas to see what sticks? Or is it that the people actively involved in championing ideas come and go too, bringing ideas in and sometimes taking ideas with them when they move on? Does this mean that as an industry as experienced developers leave the industry and new generations of developers come in, are we doomed to continually repeat our mistakes of the past?
