The book “The Pragmatic Programmer” by David Thomas and Andrew Hunt is one of the “must-read” for a developer. Co-author Andrew Hunt took part in the creation of the Agile Manifesto back in 2001.
This book can give you a lot of practical advice on how to write flexible, dynamic, and adaptable software. I’ve found this book super interesting, so I want to tell you 5 of the many lessons that this book gave me. I hope to pique your curiosity, in this case, here the link where you can buy the book. Let’s start with the first lesson:
1. Fix the problem, Not the blame:
It is possible that during a debug session you find a problem with a piece of code that someone else wrote, some developers just say “I didn’t write this code so I’ll not fix it”.
Pragmatic programmers fix the code, not the blame, it doesn’t matter whether the bug is your fault or someone else’s. It’s still your problem. Remember to communicate with your team so you can create a common healthy culture. The authors strongly encourage to have robust respectfully debate about code, this is an important way to share knowledge and ideas.
2. You can’t write perfect software:
Let me say it straight: perfect software doesn’t exist, so accept it as a fact and don’t waste your time trying to chasing an impossible goal. But pragmatic programmers can get benefits from this thing: code in defensive mode, don’t trust no one including (and especially) yourself code. Continuously search the room for improvement in your code.
The authors introduced common techniques that help us fix up existing code continuously as we go. Write code that works and prove it by writing tests and after that make sure that they are executed often and automatically.
Record every change of your codebase using a version control software, shared the code in a directory is not acceptable as a version control system. This kind of system lets you go back to a previous version of your code, so if you made a mess you can just back to a previous version and start again. In addition, you can always know who made a modification on a specific line of code or which files were modified in a specific version. This information is invaluable for bug tracking, performance, and quality purpose.
3. Don’t depend on what can change:
To really make your code adaptable and flexible you should keep external to your app all those values that can change when your software will run in a different environment or for different customers.
Common things you probably want to externalize are credentials, license keys, formatting details, validation parameters, and so on. You can choose to put these values in a file, database table, or behind an API but keep external this kind of data. Remember that those who don’t adapt fall behind.
4. Take small steps:
The future is uncertain especially when we talk about software. Clients don’t know exactly what they want, that’s where developers can help. Our job is to help people understand what they really want. Some think that the “requirements gathering” is an early phase of the project, but it is not.
Requirements are learned in a feedback loop.
This is the main reason why pragmatic programmers prefer to work in short iterations, to get feedback from the client in a loop. So, to reduce the risks of wasting effort it is important to design and write maintainable code that better suits what it is currently requested.
Take small steps, write code that it is easy to change, gather feedback from the client, and adjust requirements, this is what a pragmatic programmer does. This kind of advice is similar to what the Agile Development says, I wrote an article about this topic, you can find it here.
#software #code #software-development #pragmatic-programming #tips
