What I Learnt From The Pragmatic Programmer 2nd Edition - Reading Time: 3 Mins

Introduction

Ever since I heard about the book "The Pragmatic Programmer", I immediately borrowed it from my local library. It had shaped my thinking as a developer, due to its choke-full of common sense and practicality. Which was not apparently present in my studies on software engineering. Not in the realms of algorithm or architecture but instead comes directly from experience in working the industry.

Despite I was a broke student. I made a promise myself to buy it one day as part of my personal library. Imagine my surprise when I heard about it in an episode of Test & Code that a revisited version is out. I rushed to keep it and was able to get a copy by sharing the cost of delivery with 3 others to have it shipped to Singapore.

Continous Learning Regardless If It is Technical or Soft Skills

I believe the key focus on the book is on the need for self-education and taking charge of your own education as a developer. Regardless if it is your own technical skills or soft skills as you grow in your development journey.

You should commit to yourself to read a technical book once a month and do not skimp on non-technical books as a lot of software development depends on these soft skills. Which sadly does not cover in the full depth of the importance of it. Despite it may not be technical in nature like teaching, mentoring, leadership, ethics, business knowledge and communication.

Learn about it will prove useful as you grow to solve problems that may not require this same technical prowess. Therefore it is not an excuse to slack off, in not adopting or learning new methodology or technology. Just put it as part of your own toolkit for different situations when the need arises.

Documentation Should Grow With You Not Bolt-On

One should treat documentation as a living document that grows with you from the start to the end. Instead, treat writing as another programming languages with style guides and ways to present knowledge & technical information that is a digestible format for anyone besides you.

Do not go through the motion in your documentation, instead write it as a chef would do. It serves as both marketing tool as well as reducing the number of support hours for your software.

Everything You Do is a Prototype

Whatever is developed should be treated as a mockup/prototype even if it is finally delivered to users. As there will be times that you have to make radical changes to software that will perform differently.

Therefore all software design must follow the concept that it has to be flexible and breakable to adapt to the changes of environment, use cases, the business objective. So that it is easily replaceable without affecting the overall structure of your software system.

Design by Contract is useful for API development which is applied as OpenAPI. This is why testing is easy for design by contract. Which tests the assumption of your contract with a combination of the unit & property-based testing.

Property-based testing performs variations of tests based upon the input to test the limits of the system. The downside for property-based testing is the randomness that occurs when a bug is founded. Due to the random nature of the tests. Creating a unit test cases which tests for that same bug helps to solve the problem and tighten the net.

Conclusion

I would advise anyone who is developing software to get The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition). Regardless you are a junior or senior developer, there is gold for you to mine. It offers common sense and mental models for you to build on and learn in your developer journey.

It will be part of my own personal library equal in terms of contribution & complimentary to what Uncle Bob has talked about over the years. Which help you gain the perspective of being a pragmatic programmer to operate on a higher standard than you are now.

Reference