The One with a Pragmatic Philosophy

I have started reading The Pragamatic Programmer again when the 20th anniversary edition came out. I had tried reading the initial version about two years ago but struggled with understanding what most of the chapters meant. When I talked about this with my coworkers, they suggested I should wait a bit until I have some more programming experience. Two years later seems like a good time to start again. So here is a short summary and my notes and thoughts on the first chapter, A Pragmatic Philosophy.

It’s Your Life talks about taking responsibility for changing things you are not happy with and for investing in yourself by learning in your own time when you feel like technology is passing you by.

The Cat Ate My Source Code is about team trust and taking responsibility for your project and not blaming mistakes on somebody else. When mistakes happen, one should provide options instead of lame excuses by thinking about what to say before going in a difficult conversation. It also suggests following up an “I don’t know” with “but Ill find out”. I personally wonder how to increase team trust and trust in one’s self because that is what’s necessary to be able to react like that.

In Software Entropy, Dave Thomas und Andy Hunt talk about the broken windows theory and First, Do No Harm. They suggest finding the time to talk about possible broken windows in a team and thinking about what can be done to prevent these from happening. I find this particularly difficult to balance against requirements and the need to push out features, but I guess that is what product development is mostly about. And I personally struggle with seeing these. I sometimes find pieces of code where e.g. two implementations of very similar function are vastly difficult. That’s easy to see that there is something broken that will annoy the person who needs to work on this next. But for the bigger things? I can hardly find my way through some of our smaller applications, how could I find broken windows in the bigger picture? Something that comes with learning, I guess.

Stone Soup and Boiled Frogs uses the Stone Soup story and the Boiling Frog story to advocate being a catalyst for change while remembering the bigger picture and trying to be objective about it: Will this change really benefit the users/product or is this my personal goal that won’t be good for others?

In Good Enough Software they talk about involving users in the trade-off between quality and quantity and making quality a requirements issue. But they also tell their readers to know where to stop. Again, this feels difficult for me right now. I can’t really see the broken windows so how could I know where to stop? Again, probably something that will come later.

Your Knowledge Portfolio has some practical tips on how to invest in yourself: balancing your knowledge portfolio (investing regularly, diversifying what you learn, learning something new early), developing a routine for learning (I struggle with that right now), practicing critical thinking (5 Whys, Follow the Money) and some suggestions for goals: learning a new language every year (I wonder if this applies to everyone and what they mean by language because I struggle to get on with our stack at work, so how could I learn something new right now?), reading a new technical book each month (I try to do that), reading non-technical books (I definitely do that), taking classes (yeah no, no time for that), participating in local user groups and meetups (yep), experimenting with different environments (Atom -> VS Code?) and staying current (I think I could do more in that area).

I can definitely improve on the whole Knowledge Portfolio part. I think I would benefit from a routine but I struggle with establishing one because my weeks are so irregular. And I am not really following any path anymore, but I can’t find a way to change that right now. And I think that instead of reading more, I need to actively practice coding more.

Communicate! talks about how to communicate better, in a team or with a boss or with users, both face-to-face and via text, by knowing your audience, choosing the right moment and style and by involving the audience. The authors also suggest keeping code and documentation together which we do a bit by writing feature tests via scenarios. There are several books they recommend reading that I have all heard about before but never started reading, so these are going to the top of my to-read list.

All in all, this chapter is a very gentle introduction to this book, I think. As far as I remember, the following chapters go a bit more into details and are a bit more difficult to understand and summarise. But there is definitely some food for thought in this first chapter, as well, especially in the part about learning.