Let’s Read: The Pragmatic Programmer | Ch.1
There are a lot of books I just have to read. “You gotta read this man.” I say no to a lot, but when one just doesn’t go away and keeps popping up in front of me I eventually give it a go. The Pragmatic Programmer is that book in the dev community. Blog posts, tech articles, stackoverflow — I see it everywhere.
In case you don’t know I will save you a google search:
prag·mat·ic
adjective
dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations.
I just started it and as I make my way through it I wanted to document the shiniest gems that rise to the top.
But what kind of book is it?
- It is not a technical book
- It is not about coding today in 2018
- It is about programming as a discipline
- It is full of aphorisms about what makes good code and good programmers
Ch.1 A Pragmatic Philosophy
One thing we can all agree on is that programmers are problem-solvers. However programmers focus most of their time on the problems themselves and less on thinking about the best way to effectively solving those problems. Who has time for that? The problems need to be solved, not thought about! The opening chapter is the first foray into the realm of how.
[Pragmatic Programmers] think beyond the immediate problem, always trying to place it in its larger context, always trying to be aware of the bigger picture.
I’m sure you have found yourself working hard on a problem, hour after hour, until you finally peep back over at the original problem you were attempting to solve and realize that you have veered off into different territory. Your solution has grown a second head! You probably need to take a step back and refocus/reorganize.
But maybe you have gone too far and you made a mistake, you wrote bad code, it’s affecting the code that others have written.
take responsibility
When you make a mistake (as we all do) or an error in judgment, admit it honestly and try to offer options.
Good advice for life, too! This book has a lot of advice not just for pragmatic programming, but for pragmatic living as well. Remember, we want to deal with things in a sensible and realistic manner. Trying to hide your faults only prolongs the problem. We need to suck it up, eat humble pie (it’s delicious) and move on to finding solutions. This is really hard to do, but no doubt will be a benefit to you. It’s something we all want others to do, but when it’s our turn it can be so hard to do the right thing. That’s why we need to be able to step back, look at the big picture, and get over ourselves.
entropy
Disorder. Software rot. We all have written code that we are not proud of, and usually we say to ourselves “I’ll go back and fix that later.” Before you know it, you haven’t, and instead you have taken that approach for an entire project!
Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.
If there is never enough time, maybe it’s time to take a step back and think about the timeline of a project and what effect cheap solutions will have long term.
Have you been a part of team that writes beautiful code? You know what I love about it? It’s contagious. The same goes for ugly, poorly written code. Don’t leave broken windows behind you, leave stain glass masterpieces.
good enough software (or, knowing when to stop)
In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them. You sketch out an overall shape, paint the underlying environment, then fill in the details. You constantly step back with a critical eye to view what you’ve done. Every now and then you’ll throw a canvas away and start again.
I love this quote because it is a great description of programming and why I am drawn to it. But I often forget about that part of a creative endeavor where sometimes you make mistakes, you followed a bad design or bite off more than you can chew. My tendency is to get depressed about it and give it up or deny it, believing that I can still make it work. Failure is a part of the creative process and as programmers we have to take that into account as we build. Knowing when to stop is also important. We want to build great products, but they do not (and will not) be perfect.
your knowledge portfolio
Your knowledge and experience are your most important professional assets. Unfortunately, they are expiring assets.
This section gives some helpful tips on how to continue to grow your knowledge portfolio. This is not a nice-to-have but a necessity. We all need to have a plan of how we are expanding our knowledge and expertise.
This is just a few things that I got out of the first chapter. What I love about it is I get to be investing in my craft without having to always be looking at code. Focusing on the how of programming is just as important as the what. Ya know? Maybe?
On to chapter 2!
