The Pragmatic Programmer: From Journeyman to Master (Pragmatic programmer) (Category Engineering)

I got another ancient book from the shelf here to remember the past and tell me how IT began for me in the early 2000s. This time we will talk about the influential book of the time, written by Andrew Hunt and David Thomas. 1999. The main idea of the book was that the programmer should be a pragmatic professional who is constantly improving, thinking critically and treating his work responsibly. Now I would say that the authors advocate a healthy engineering approach, not just programming. I wonder if I'm already. told I was talking about the book, but then focused on his records from the 2000s, and now I decided to talk about the pragmatic programmer, the key character described by the authors and who is the author of the book. Cares about the quality of its code and takes responsibility for its decisions (care about your craft) This is a reference to craft rather than engineering, there were different schools of thought at the time as to whether programming was an engineering activity or a craftmanship. (He even appeared. craftmanship manifesto software)

• Apply the DRY principle (don't repeat yourself)avoiding duplication of code Uses automation to improve development efficiency (automation) Regularly tests code and applies approaches like TDD (test-driven development) Constantly learning and adapting to changes in technology (afterward 25 For years, I would put that first.)
• Uses version control systems (Version Control) as a mandatory part of the work process Aims to write clear, easily maintained code.
• Uses debugging techniques. (debugging)such as talking to a duck (rubber duck debugging)
• Follow the principles of YAGNI. ("You aren't gonna need it")avoiding unnecessary complexity Apply refactoring approaches to improve code structure The book has funny stories about the theory of broken windows. ("broken windows theory")about stone soup ("stone soup") or axe soup in Russian fairy tales, as well as the method of debugging "rubber duck" ("rubber duck debugging").

The book was published a little more. 25 years ago and at that time, it was extremely progressive and innovative - from the above it introduced or popularized. DRY Principles, Principles of Orthogonality (orthogonality) Decomposition of the system into independent components (decoupling)The importance of refactoring Focused on automating development and testing processes long before CI/CD was widely available. (Continuous Integration/Continuous Delivery) systems. For example, at the time, many companies didn't even use VCS, let alone write tests. Emphasized the personal responsibility of the programmer for the quality of his product, which was an innovative approach against the background of the then more formalized methodologies. Developed the concept of continuous learning and adaptation as an integral part of a developer’s professional development long before it became a standard.

P.S. It is interesting to compare what interested me. 20Years ago, when reading a book and how I look at it from a height of experience:)

#SelfDevelopment #Engineering #Software #SoftwareDevelopment #Management #Leadership