The pragmatic programmer | Insights, and thoughts
Hello reader, in today's article I'm going to talk about a book I finish reading recently: “The pragmatic programmer” written by Andy Hunt and Davy Thomas in 1999 the book survived the test of time and become a must-read book for programmers, and I'm going to share a few insights and thoughts I got while reading it.
No broken windows
The authors mention a research they read about a curious fact about what can turn a decent and organized neighborhood into a messy, and dangerous neighborhood with a high crime rate, and it's just a broken window because when a fence is broken, a window is broken it passes a sensation of not caring about the neighborhood or not caring about the properties and people that live there and soon the neighborhood gets more broken windows, dirty and dark streets what ends up attracting crimes and accidents
And the idea here is that our code or our project is the neighborhood and every time we left a broken window(messy code, variables with bad names, etc.) we are increasing our frustration rates, and increasing the number of bugs that are hard to solve and detect in the system, so similar to the scout rule in clean code a way to avoid broken windows is, of course, have a proper time and knowledge to implement a feature, but that option is not always available so refactoring and turning your code a little bit cleaner whenever you go there to implement a feature needs to be used. For example, if I need to implement a new feature in module “xpto” and I see that module “xpto” has long functions or a lot of lines of code that would be better placed in another module or duplicated knowledge etc. I should refactor that part before implementing my feature in module “xpto”, which will help us guarantee that we'll not have broken windows in our code.
Knowledge Portfolio == Investment Portfolio
As programmers our value is based on our knowledge it is what makes our profit grows throughout the years and as in every profession, in the world, we sell hours of our time in exchange for money, and we want to get the highest price for our precious hours of life and a way to do it is managing your knowledge portfolio as an investment portfolio by making strategies, diversifying, speculating, etc. to get the most out of our portfolio. And the pragmatic tips from the authors are:
— Learn a new programming language every year
When the necessities of the market change we’ll not want to be limited to languages and tools that are only being used in now legacy systems, and we don't want to be limited to only one platform or language because once that language dies in popularity or receives a lot of programmers to their ecosystems our salaries(portfolio) will tend to decrease its profit
— Read a technical book every quarter
Keeping updated with the changes of the market(Kubernetes, cloud, microservices) as well as getting that knowledge that survived the test of time(clean code, clean architecture, pragmatic programmer, operational systems, etc.) is essential to keep our portfolios with some of the best assets in the market
— Read non technical books too
Pragmatic programmers know that our technical knowledge is essential but also know that being a great human being is necessary to be a great programmer, so read the classic books of humanity, read fiction, communication, philosophy, anything but read and try to evolve as a human being in the process of reading it
DRY
Don't repeat yourself the solid principle appeared for the first time in the pragmatic programmer book, and It's worth talking more about it
The dry principle is all about not having duplicated knowledge in your code, but a duplicated knowledge can be easily hidden in a source code that is messy and poor designed(a code with broken windows) or when the team is afraid of breaking the system when migrating duplicated code into a separate module
example of a code without the dry principle:
const saveUser = (user) => {
if(user.enable) {
return db.save(user)
} throw new Error("Enable not active")}const savePost = (user, post) => {
if(!user.enable) {
throw new Error("Enable not active")
} if(post.public) {
return db.save(post)
} throw new Error("Post not public")}
The knowledge user.enable is duplicated in two different functions if I make changes in the user structure I will need to fix two functions instead of only one. Now let's see the code without duplicated knowledge:
example of a code with the dry principle:
const userEnabled = (user) => {
if(user.enable) {
return True
} throw new Error("Enable not active")}const saveUser = (user) => {
userEnabled(user) db.save(user)
}const savePost = (user, post) => { userEnabled(user) if(post.public) {
return db.save(post)
} throw new Error("Post not public")}
Now my code has no duplicated knowledge and if in the future the user structure changes I only need to refactor the userEnabled function, even the legibility was increased because we removed two if statements and added only two function calls. Also notice that we didn't add a function postPublic to the code, why? Because we don't have duplicated knowledge, post.public is only being used once in the code
Tips for a more DRY code:
— Source code under version control:
An obvious one, but if you have a time machine for your code you can refactor how much you want and if you break the source code you can always rollback
— A good test suite
This one is for the hidden bugs or for the bugs that attack the business rules, if you have a good suite of tests your assertions of success and failure are well-defined, and whenever you finish your refactor process you can run your tests and check for hidden bugs in the business rules.
— Good communication with the team
Essential for the future of the source code, the communication between the members of the team responsible for the project is great to put everyone on the same page with what folder contains what layer of the project, common writing style, and the most important good, accessible and meaningful documentation
For this article to not get very long that no one will ever come back to read it again I'm going to finish this one here, and these three points that I mentioned are just a few of the huge amount of insights this book gave me, and it certainly owns its place in the bookshelf of a programmer.