The Pragmatic Programmer Philosophy
August 04, 2020 (5 min read)
I started reading The Pragmatic Programmer and it’s been a very thought provoking read so far. I already wrote another article unpacking some of my thoughts on Software Entropy but I wanted to share some thoughts I had on other highlights from the first chapter too!
Chapter 1 is about the pragmatic philosophy. Focused on the characteristics and practices of a pragmatic programmer and some ways of thinking about software development.
This chapter took a long time to read because I found it very thought provoking. I kept catching myself just staring off after reading a paragraph lost in my thoughts. It’s difficult not to give my introspection on every paragraph to be honest, but then I’d just be plagiarizing the book and also you might get bored. So here’s what made me think the most.
Taking responsibility.
Taking responsibility is about accepting accountability for your mistakes. I’ve always felt like I’ve been pretty good at this, except when I’m blamed for things going wrong and I feel like it wasn’t my fault. But we also have the right to not take on the responsibility for an impossible situation. When we don’t speak up for ourselves and push back against things that we know will fail, it is our fault when they do go wrong and not the fault of the people who asked us to do it.
This is hard though. A lot of managers or clients can be overly assertive or very persuasive talkers. You can give sound reasoning for why something won’t work, and even offer alternative suggestions. But they just don’t want to hear it and they want it done.
I’ve been in this tough spot more than a few times. And every time it goes wrong and a part of the post-mortem with my team or even just my own reflection is that we should have just pushed back and said no. At the end of the day when we break and just do what’s asked of us even though we don’t agree, we’re responsible for the outcome.
However I agree with the point the authors made, and that’s to never just say “no” without providing a reason and options. The customer doesn’t want excuses for why something can’t be done they want solutions to their problem. Again, sometimes even providing the options doesn’t pan out, but it’s our responsibility to do it anyway.
Knowledge Portfolio
The knowledge portfolio was the other section that was really interesting. They draw an analogy between the collection of experiences, skills and knowledge we have to an investment portfolio. After all, our knowledge and experiences are our greatest professional assets. So they’re worth investing in right?
Unfortunately unlike an investment portfolio our knowledge and experiences depreciate over time rather than accumulate interest. Technology moves quickly and it’s easy to fall behind in this industry. That’s why they recommend you invest in your knowledge portfolio often.
And what I thought was really interesting is that they seem to prefer your portfolio is diverse. Like a real portfolio you wouldn’t put all your money into sunscreen companies. Because than if there’s a rainy summer you’re losing money. So you should mix it up with some money in sunscreen, and some in umbrellas. That’s just basic investing strategy; don’t put all your eggs in one basket. Have a balanced portfolio.
I’ve been very fortunate to be forced to have a balanced knowledge portfolio just from my career trajectory and spending a good portion of my career in consulting. But it’s something I think I can still improve on. It’s been a while since I’ve stretched too far outside the languages and frameworks I come across at work. Something I want to do more.
Anyway, I thought that section was really cool and it’s going to be bookmarked so I can keep looking back to. Thinking of my learning trajectory as a knowledge portfolio is going to change the way I learn and this idea is probably going to stay with me for the rest of my career!
Communication
This last point wasn’t so much thought provoking as just reassuring. I still have a lot of personal development to do in this area but during my development career one thing I’ve been able to impress employers, clients and colleagues with has been my long-form communication.
Basically all the tips in the book are things that I consider and have practiced. Most of this came from blogging. My last blog, (danfletcherblog.ca) has over 100 published articles and dozens more in draft. I learned a lot along the way to 100 articles and it’s helped me so much in my career.
The book goes into just the right amount of detail but the suggestions are; knowing your audience, knowing what you want to say, choosing your moment, choosing your style, and more.
There’s a lot to know about effective communication and long-form text is only one style. But it can be an incredible tool for conveying your thoughts or ideas. As the book elegantly states, you’re not communicating if you’re not conveying what you mean to convey—that’s just talking.
And that’s it! Thanks for reading!
Cheers,
Dan
