---

It is that time of the month where I have an internal crisis of competence regarding my career and ability. Technology is advancing, languages are maturing, frameworks are evolving, and I have been sitting back and stagnating.

I never really make the best use of my time as you can probably tell from this blog. I find it very difficult to read a book the whole way through without getting distracted by a different book. I am not saying I need to spend 18 hours straight absorbing an entire book in one go, but I do need to set aside some time to read. As I work from home I can just fold this into my working day¹.

My bookshelf is pretty stacked. I have a lot of interests spread over a wide variety of subjects, but I can never focus on one topic long enough to gain the knowledge that I want from them.

This time I am going to try something different. I am going to WRITE ABOUT THE BOOK I AM READING. Right here.

For my first attempt I have picked up The Pragmatic Programmer 20th Anniversary Edition:

This book had been recommended to me by various websites and algorithms and LLMs over the years, and in fact I had already bought it:

Maybe after 28 months it’s time to open it up. I’ll have a go at a chapter-by-chapter read, and make some notes, give some thoughts, write some personal anecdotes as I go along.

At the very least it will help me retain the information from the book, and give me some structure and drive to continue with the read.

I have decided² that I will likely stick with the .NET and Azure tech stack, and not branch out into lots of different languages. I would rather have a deeper knowledge of a couple of areas than a shallow knowledge of a broad array of tools and languages. Think more Morrowind than Skyrim.

It's Your Life

This first chapter concerns the mindset of a pragmatic programmer (PP), and I have to admit it makes them out to be a bit full of themselves, taking their work too seriously, and making their career their identity. But maybe that is the point! Perhaps I am the weird one by not taking my career as seriously as I should?

Pragmatic Programmers are distinguished from your run-of-the-mill programmers by an attitude, way of life, philosophy, and thinking beyond the immediate problem.

There are mentions of developers who look on passively as their skills become outdated and complain about their company not training them. I agree with this part entirely. I once had the misfortune to work with someone who said that he "learned the .NET 2.0 framework, so if the company want me to use .NET 4.0 they should train me". I thought this was such as ridiculous statement that it has stayed with me for over a decade now. I wonder if that guy is still waiting for the company to invest in him³.

To contrast this way of thinking, a PP⁴ should make the time to keep up with new technologies in the own time, so they do not feel as though things are passing them by.

I can get behind this idea, it’s what I’ve always had to do.

This chapter also touches on how much flexibilty the software developer has in their roles, such as remote working, but as it was written before the pandemic made remote working a standard benefit I am going to ignore it.

The Cat Ate My Source Code

Another aspect of being a PP is owning up to mistakes, taking responsibility for things, and generally being a trustworthy team-member. The book states that if you accept responsibility for an outcome then you should expect to be held accountable for that outcome.

I’m not sure I agree entirely with this bit. Yes, developers should own up to mistakes and be trustworthy, but many times the option of not accepting responsibility just isn’t there. You are de-facto responsible as nobody else can do the job. For example I worked in a team that needed to write a new integration for the existing product. The requirements were vague. We were asked to estimate how long it would take⁵ to complete the work. We said 14 sprints (28 weeks). The boss shat his pants and said “no, 8 sprints”. The development team took 10 sprints and produced some barely functioning, untested, unmaintainable mess that constantly ran into issues and were criticised for running over time and under-delivering.

Where was the option of not accepting responsibility here? I do not think this is uncommon behaviour either.

I believe all of this “agency” talk that the authors use really means “if you don’t like it, leave”. That is not really a “not accepting responsibility” choice. Not everyone can just get another job whenever they feel like it.

Software Entropy

I like this part as I agree with virtually all of it. It refers to developers allowing rot to set into their code. This rot is also known as technical debt as it sounds more palatable. The concept is that the developers will eventually pay this debt back, but the reality is that it will never happen. You will never pay back your technical debt. If you have a tech-debt backlog then the rot has well and truly set in. Good luck repairing it.

There is a link made between software rot and urban decay with the broken window theory. This states that something small, like a broken window not being fixed in an apartment block, will lead others to think that nobody cares about the building. This leads to another window being smashed, until eventually littering begins, graffiti appears, crime, that kind of thing. The decay spirals beyond repair⁶.

With software, rather than a smashed window, it could be a poorly thought out decision, or bad piece of code, or wrong design. The PP will take steps to show that this is not ok, that this is being actively worked on. Temporarily boarding up that broken window. Maybe comment out the offending code or return some dummy data for now. Do not allow the rot to set in.

I was working on a fairly large, complex legacy codebase a few years ago. There were comments in the code that would say:

// TODO: This is just for demo purposes - remove afterwards!

The trouble was that this demo code was now 18 years old and had formed part of the bedrock of the application.

This sub-chapter ends with an anecdote about firemen putting out a fire in a house, but ensuring they laid down a protective mat over the carpet before rushing in, to prevent ruining the carpet in the process of putting out the fire.

The PP will do the same thing: not cause collateral damage. That is to say that just because there is an urgent need for some piece of functionality for the demo, don’t write terrible code and smash a window in the process.

I have had the misfortune of working for an absolutely terrible software company that only wrote trash-tier software. Their systems were basically a stack of broken windows piled on top of one another. I was asked to look at some shitty code and “fix the problem”. When I said I couldn’t as there were too many problems, I was made out to be incompetent. This is where I made use of that “agency” the authors talk about.

Stone Soup and Boiled Frogs

This is a fairly lengthy story about soldiers in wartime getting the villagers to part with some of the food they have been hoarding by boiling some stones in water to make soup. Eventually a villager will add a tiny part of their own hoard to the pot, then another villager does the same, until eventually there is a nice big pot of soup that everyone can have.

The software parallel is that nobody wants to give you anything to make your ideas happen. They have to be tricked into it by you doing a small part of your Big Idea and then impressing them with it. Once they are impressed you say how it would be even better if they gave something else, like budget, to the project. Eventually your Big Idea will be completed.

The flip side is that sometimes a gradual process can be bad, like the overruns on projects. These happen one day at a time and can easily get out of hand. The adage of the frog slowly boiling alive as the water around it heats up as it is not aware that anything is changing is literally every software project out there. PPs need to be alert to what is going on around them. Practising situational awareness is a good trait to have.

Good-Enough Software

Great software today is better than perfect software in a year.

The idea here is to not over-engineer a piece of software. There will be lots of different constraints on a project and they should not be ignored because you want to craft the greatest application ever.

However this does not mean you should cut corners to meet deadlines.

Your Knowledge Portfolio

Your knowledge and experience are your most important day-to-day assets, but they are expiring assets as technology advances. You need to keep learning all the time to be a PP.

This section likens your knowledge investment to a financial investment. I don’t think I agree with this really, as being an early adopter of a technology will not necessarily mean you get rewarded for it as if you bought a stock that mooned. I’m not sure what the link they are making is, but you should review your knowledge portfolio and drop dead-tech and maybe learn something in an area you are weak in.

There are some more direct goals to become a PP:

1. Learn at least one new language every year
2. Read a technical book each month⁷
3. Read non-technical books
4. Take classes
5. Participate in local user groups and meetups⁸
6. Experiment with different environments
7. Stay current

Communicate!

Having all this knowledge about software is pointless if you can’t communicate with other people.

This final section of chapter one is about presenting your ideas in the right way to the right people. Pick your moments to ask for something from someone.

Frankly, this section reads as the most vague and wooly part of the chapter.

I believe the authors are trying to say don’t bore the tits off of everybody with boring tech-talk when your audience are not interested in that shit.

Write good documentation, don’t overload your code with unnecessary comments etc.

End of Chapter One

Well, that’s chapter one done.

There is some good advice in there that I am either already doing or will start doing.

The main parts that resonate with me are:

• Continually learning, even though I personally find it exhausting to do.
• Ensuring code rot doesn’t set in
• Writing good-enough software that meets requirements and is not over-engineered

The parts that I do not fully agree with are:

• Impressing people with a small part of a larger idea to get their buy-in
• Half of the suggestions about a knowledge portfolio, mainly the social parts
• Taking responsibility for something you cannot fully control

Onwards to chapter two!

Tips from chapter one:

• You have agency
• Provide options, don’t give lame excuses
• Don’t live with broken windows
• Be a catalyst for change
• Remember the big picture
• Make quality a requirements issue
• Invest regularly in your knowledge portfolio
• Critically analyse what you read and hear
• English is just another programming language
• Build documentation in, don’t bolt it on

« Back to Posts | Chapter 1: A Pragmatic Philosophy | » Chapter 2: A Pragmatic Approach

1st October 2024