10 Things from Pragmatic Programmer (almost) 25 years later

As someone who has been in the programming space for quite some time now, I have heard the title of this book many times. Upon reading it, I even realized that I knew many of the concepts that were either started or propagated by it.

Just recently, I had a talk with a more experienced colleague (let's say a senior software engineer for convenience) about various topics, including the principles of programming. We discussed how many people only know the library and not the language (hello Prime) and other similar topics.

My colleague mentioned that among the many books he had read, this particular book had a really big impact on him, and he still follows many of the rules set forth by the book to this day. This made me realize that I had not yet read the book. So, I got a copy of it, sat down, and tried to understand this 25-year-old programming knowledge.

10 Most impactful things that i got from reading

• Always use a version control system - Nowadays, Git solutions are common; however, in 1999, this was groundbreaking.
• Learn a new programming language or technology every year - Learning a new language every year may be demanding. Instead, consider learning a new framework or any new technology. Keep learning and trying new things, even if you won't use them. This will improve your skills overall, especially in the JavaScript world.
• Practice good code hygiene - This means writing code that is easy to read, test, and maintain. Many books cover this, and it's hard to say what exactly is easy to read code, but we all know it when we see it, right?
• Don't repeat yourself (DRY) - Avoid duplicating code or logic in your programs. Of course, repeating the same logic in code is bad. However, nowadays, some programmers try to abstract everything in ways that may be hurtful. So, don't write the same function logic five times, but if you only use it twice, don't build a whole module for it that will take 10 hours to understand.
• Use automation to your advantage - Automate repetitive tasks to save time and reduce errors. In the prime DevOps era, use CI/CD. One of my favorite books is "Modern Software Engineering: Doing What Works to Build Better Software Faster." Maybe I will write 10 things from it later?
• Keep it simple, stupid (KISS) - Strive for simplicity in your code and design.
• Write tests for your code - This will help you catch bugs early and ensure that your code works as expected.
• Refactor your code regularly - This means improving the design of your code without changing its behavior. Do not put tasks like "REFACTORING USER PAGE" in your backlog. Refactoring is a constant process. If you are adding a feature and see some part of code you would like to rewrite, just do it. If you are constantly doing this, you will never have to "waste" time for a big refactor.
• Use patterns and idioms wisely - These are proven solutions to common programming problems, but they should not be applied blindly.
• Continuously learn and improve - Never stop learning and experimenting with new technologies and techniques. This is the best advice not only for programming but for life in general.

So how it is holding up?

First of all, it's worth noting that this book was published in 1999, so some of the specific technologies and tools mentioned in the book may be outdated. However, the general principles and practices outlined in the book are still highly relevant today and are considered timeless.

For example, the book emphasizes the importance of writing code that is easy to read, test, and maintain, as well as the value of continuous learning and improvement. These principles are still highly relevant and are widely embraced by software developers today.

Additionally, the book emphasizes the importance of using version control, which is still a fundamental practice in software development. The book also introduces the concept of "DRY" (Don't Repeat Yourself), which is still a guiding principle for many developers.

One aspect of the book that some may consider outdated is the emphasis on object-oriented programming (OOP) and design patterns. While OOP is still widely used, there has been a growing trend towards functional programming in recent years, and some developers may view OOP as less relevant today. Similarly, while design patterns are still used, some developers may view them as overused and may prefer to focus on simpler, more flexible designs.

Overall, while some of the specific technologies and tools mentioned in "The Pragmatic Programmer" may be outdated, the book's principles and practices are still highly relevant today and are widely embraced by software developers.

If you are interested in this kind of knowledge here are books that great

1. "Clean Code" and "The Clean Coder" by Robert C. Martin - These books were published in 2008 and 2011 respectively, making them newer. "Clean Code" focuses on the importance of writing clean, readable, and maintainable code. It covers topics like naming, formatting, and code structure, and emphasizes the importance of writing code that is easy to understand and modify. "The Clean Coder" focuses more on you as a programmer, with topics like communication, teamwork, and ethical behavior. It offers practical advice on how to be an effective and responsible software developer.
2. "Domain-Driven Design" by Eric Evans - This book, first published in 2003, offers a comprehensive approach to software development that emphasizes the importance of understanding the business domain and designing software around it. It covers topics like bounded contexts, aggregates, and domain events, and provides practical guidance on how to implement domain-driven design principles in your projects.
3. "Refactoring: Improving the Design of Existing Code" by Martin Fowler - This book, first published in 1999, focuses on the importance of improving the design of existing code through a process called refactoring. It provides practical guidance on how to identify code smells and apply refactorings to improve the structure, readability, and maintainability of your code.

If you want to read more from me visit my blog

Comments

[Richard Griffiths]

The one I find most impractical for me is learn a new language every year. To learn one, you need context, not just tutorials. A reason to absorb the language and get a feel for it's idioms. Without such purpose it doesn't stick.

[Szymon Sadowski]

Agree, that's why I would take this rule more universally "to always keep learning". No matter if it's new language / framework / library. Just never stop and your skills will progress.

[Bill C]

Yeah, I think keep learning is a much better statement of things. I think the extent of surrounding tooling and technologies just wasn't there to learn 25 years ago.

[Jean-Philippe Leloup]

At the end of my studies, my supervisor recommended that I produce a piece of work based on a real case and not something made up