I read the first two chapters of The Pragmatic Programmer: From Journeyman to Master, which are entitled "A Pragmatic Philosophy" and "A Pragmatic Approach," respectively. I'll go through and summarize my thoughts "A Pragmatic Philosophy" first:
The preface of The Pragmatic Programmer begins by explaining the meaning of the word 'pragmatic,' which comes from the greek word pragmaticus, or "skilled in business." I get the feeling that this is the central pivot point around which the rest of the book hinges. Skill and craftsmanship are emphasized from the get-go.
Business needs are also a key element, though I get the feeling that it has less in terms of doing whatever the "business person" says and more to do with contextualizing the job of programming within the context of the greater problem at hand.
The sections in the chapter were broken down as seen below. These are the guiding principles behind the rest of the book.
"The Cat Ate My Source Code" is about taking responsibility for your code and the task at hand. This is possibly the most important lesson I learned from my coworker at Aggrego, Dave Willkomm. He was always doggedly determined to find out not only a solution, but also the fundamental reasons why that solution worked.
He not only took responsibility for his code, but he was also very conservative about what the team took on and whether or not it was possible. As a lead developer, he was the moral compass for the team, instilling us with a sense of discipline (tests must pass! Single responsibility principle!) and well thought out conservative policies with regards to everything from account management to deployment to version control. Dave is the epitome of responsibility.
"Software Entropy" makes a comparison between the physics principle of entropy that describes the tendency of the universe to gradually decline into disorder. One of the ideas that impressed me later in the book was the idea that code is knowledge. If you take that to heart, it becomes much easier to imagine how code, once written, declines into disorder. Familiarity with the code degrades even if you are the original author of that code. Now imagine an engineering team's net familiarity with a large application over time. Familiarity with any existing code is bound to decline, and if someone leaves the project, that familiarity drops precipitously. Entropy is unavoidable.
The authors evoke the broken window theory, which postulates that a single broken window in a city leads to a free-for-all environment that quickly accelerates the aforementioned entropy. In order to deal with entropy, care must be taken to fix any "broken window," or to be careful with existing code and practices and to maintain a careful eye on the small details, lest they snowball into big problems, even when dealing with putting out fires.
"Stone Soup and Boiled Frogs" was a bit more nuanced, and my recollection is fading a bit, but it comes down to being an agent of change by getting buy-in from project stakeholders. The soldiers in the story of "Stone Soup" got buy-in by providing something intriguing ("Are you making soup out of rocks?") and then, one by one, getting villagers to join their side and make contributions.
Boiled Frogs, on the other hand, evokes the moral of the frog who will jump out of a pot of boiling water, but will sit there complacently if you bring it to a boil slowly enough. The lesson here was to always keep an eye on the bigger picture - is this project slowly going to hell? How do you know? Is your frog boiling?
"Good-Enough Software" is basically about shipping product. My friend Daniel Kim told me that the joke in the gaming industry was, "Critical bug discovered...deadline tomorrow...ship it!" Of course, that's not what this chapter says you should do, but rather advocates against perfection.
"Perfect is the enemy of good."
As is illustrated in the next chapter under "Tracer Bullets," good-enough software often opens up possibilities for iterative development that responds to the evolving needs of the project.
An interesting note at the end of the chapter is "Know when to stop." Just like you can ruin a piece of art by overdoing it, you can ruin a program by adding too much to it. I think this is related to the fact that the easiest code to maintain is less code to begin with.
"Your Knowledge Portfolio" simply refers to the fact that you should constantly be actively gathering and assessing new information about your craft. And in my opinion, capturing everything, a la Getting Things Done. There's something about the act of capturing it (as I am doing now in writing this) that reemphasizes the learning, even if you end up discarding the idea. It brings it into sharp focus, which lets you evaluate it all the more effectively.
This chapter runs through basic communication skills. Calling it 'basic' is by no means intended to demean the topic. Communication is, surprisingly to the layman, a crucial part of being a good developer. It has also been a core component of movements like Agile and DevOps. It is probably the part that I am best at, unfortunately for my technical skills.
Other good resources for communication are Just Listen and Strunk & White's Elements of Style for communication and written communication, respectively.
~
This summary makes me realize how much I took in yesterday. I haven't even gotten to the second chapter I read, "A Pragmatic Approach," which feels like it contained more content. It looks like I have a ridiculous amount to learn from this book if this is the first chapter.