Pragmatic Programmer

THERE IS NO BLOG; GO AND WRITE CODE

In all seriousness, though, that is the main thesis of the book. If you have not coded anything and picked up the book, you will not leave with anything. Although that might be an exaggeration, I believe it to be true. The authors themselves said that the book contains the lived idiosyncrasies of a software developer. Without any experience writing and maintaining software, any of the tips and topics would be seen as simply information and not wisdom. And that’s okay because that is what the doctrine of pragmatism teaches! To simplify Dewey, learning is doing.

The value of the book, then, is precisely because it functions as a companion book. The topics and tips set-out by the authors are there because that is what software developers do. That is the value of the book, and the writers also recognized that fact. My point being: they don’t have to focus on addressing the “blind-sides” of the book because it is not in the scope of it. Two examples being the topic of “Domain Specific Languages” and “Big-O”. The authors didn’t go into compiler theory for the former or algorithmic theory for the latter; they didn’t have to!

Good companion book, 8/10. It is probably a bit dated; I recommend faithfully doing the exercises.

Reflections on CS Education

I wanted to write this section as a personal reflection on the topics within the book. Particularly the topics covered here that weren’t a part of my CS education. Too my non-surprise, a lot of the software development theory was there. Cohesion, coupling, DRY, SOLID, orthogonality, OOP design principles, “good design,” refactoring, testing, software development, design patterns, TDD, etc., etc., and such “X” concepts. What wasn’t there was the more theoretical side of CS (because it is computer science), which is algorithmic complexity, low-level computation, mathematical logic, and the like.

Now for the controversial section on the topics not covered. One of the most important topics not covered in my education is the importance of tools. Akin to a craftsman, a software developer should have their own tools of the trade. Gathering and understanding those tools is often neglected in CS education. This blind spot is why MIT has made an online course titled “The missing semester of your CS education.” IDEs, CLIs, OSs, scripts, git-foo, and their idiosyncrasies are incredibly important parts of a developer’s toolkit that are heavily neglected.

The second topic, the bane of all CS majors, but arguably just as important as tools, is what I dub software politics. Working with other developers, eliciting requirements from customers, and communicating with stakeholders. These three things are considered to be a Herculean task, an insurmountable mountain even, to current or graduating students of computer things. Even though there are mandatory group projects and things of the such, there remains the all too sad story of a great peerless developer who can’t communicate their ideas or implement them by themselves.

My remedy to the topics above is simply reading books regarding these topics to understand things. I’ll skip the first topic because it is a more “technical” thing, and it’s clear where to find resources to learn those things. The second topic is the more interesting one, right; how do you understand people? The solution colleges do is mandate their students take “humanities” courses, like a semester where I had to read Dante’s Inferno (I hated it)[^1]. My solution is starting with a reflection: the only thing that makes a robot a human is if it demonstrates free will. There are some philosophical first principles or positions that prevent a person from wanting to make progress, whether that be solipsism, naive realism, nihilism or being existentially paralyzed [^2]. Once that desire to understand and connect is recognized, boy, do I have some books for you[^3]!

Book Recommendations:

With these, a person can be a pretty solid developer. As Dave and Andy wrote in the first chapter:

“Keep on reading” - they didn’t actually say this, but they basically did

P.S. Here is the reference guide, although it was from a course ~20 years ago, and they added 30 more tips in the new edition: reference guide