Pragmatic Programmer Philosophy

Andy and Dave define pragmatic programmers as programmers that are effective problem solvers and in the first chapter they lay out a set of skills that form the foundation for being a pragmatic programmer. The attitude that these skills are valuable and essential to being a pragmatic programmer is described as a philosophy because those beliefs serve as guiding principles for how to behave as a programmer both in and out of the context of writing code.

Here's my summary of a few of those skills:

Take responsibility

When you commit to delivering something, know what your responsibilities are and what factors in fulfilling those responsibilities are within your control. If unexpected failures arise and those failures are caused by your own negligence, take responsibility for it. Own up to your mistakes.

However, don't just stop there or else it's just an excuse. Nobody wants excuses. If your dentist accidentally removes the wrong tooth, is an excuse going to replace that tooth? No. Move on from the setback and provide solutions because part of owning up to something is doing your best to correct it.

Communicate effectively

As a programmer, your job is to communicate. You communicate in meetings about software design. You communicate to the users of your software about requirements. You communicate to your co-workers or boss about better work processes. You communicate to the computer about your how-to knowledge.

Learning to communicate is learning how to present your ideas. Presentation matters. In fact, one could go as far as to say that presentation is everything that communication is. If you have an idea but you don't communicate it, it doesn't exist for others. And if you do communicate it but you do it in a way that is difficult for others to understand (maybe you use really big words) then it's not likely to spread.

The type of language that's used and its contents are the presentation of your ideas. They vary by situation but the measure of how effective any presentation is based on the same thing: how effective was it in getting what you want? People who can communicate effectively are able to get what they want. Maybe it's convincing teammates to adopt a new tool or to ditch an existing process. Or maybe it's just getting people to understand you better. They're all just changes, whether small or large, that are brought about by your communication. So the better your communication, the more influential you are.

Fix what's broken ASAP

Whether it's a bad system design decision or an inefficient algorithm, if it's causing you pain or if you know it's going to cause you pain, go fix it. Don't let it stay around for too long or else according to the broken window theory it will cause others who see it to treat the overall system with neglect.

The broken window theory is a psychological theory put forth by researchers of crime and urban decay which states that it only takes a single broken window for a new building to deteriorate into a shit hole. Why? Because broken windows instill a sense of abandonment. That nobody is home and even if they were home they didn't give a crap because there's a damn broken window. So maybe it's okay to litter a little here and there and soon the accumulation of trash accelerates.

This theory can be generalized to apply to others systems including software systems. If you leave parts of the program in a shitty condition, other programmers that work on it will likely also treat it like shit. It's broken anyway and it doesn't look like anyone is bothering to fix it - why bother? That's not the attitude you want to have - no matter how screwed a system is - because all that does is make things worse. Much worse.


I completely agree with the authors about the importance of these skills from my own experience working as a software engineer.

• I've contributed to poor code that resulted in hot fixes and had to decide between making an excuse or owning up. When I own up, I take responsibility and eventually fix the mistake. If nobody takes responsibility, nothing gets fixed. Or someone else will be generous enough to fix it for you but deep down they'll start to resent you.
• Each and every day I'm in situations where I have to communicate effectively. During our morning stand ups I have to communicate the status of what I'm working on and what I'll continue to work on. If I'm not clear, others will start asking questions and the meeting gets prolonged. Also, when I'm driving during our pair programming sessions I have to constantly communicate to my partner my thinking process so they understand my intention and thus are better equipped to evaluate the code that I write.
• We maintain a few legacy systems and there are parts of it that are pretty ugly. If I need to modify it, I usually do my best to leave it in a better condition than I found it. Sometimes, however, the mess is so terrible that I don't even try to make it better. I just want to get it to work and then GTFO. I don't think that's a good attitude even when we're dealing with parts of a system we deem hopeless because you're more likely to be careless and introduce new bugs.

In addition to these three skills, there are four more skills in the chapter that I'll summarize later.

• Invest regularly in a knowledge portfolio
• Make quality a requirements issue
• Be a catalyst for change
• Remember the big picture

Messages: The Communication Skills Book by Matthew McKay, Martha David, and Patrick Fanning

I picked up this book in college because I wanted to understand others better. Just kidding. I just wanted to get better at expressing how wrong other people were because I was involved in a lot of arguments. Back then, effective communication to me mostly mean't being able to clearly articulate my opinions so that others can understand where I'm coming from. My opinions. My feelings. Now had I taken the time to read the book or maybe just learn to have some compassion for others I would've realized that communication involves a whole lot more than just the words that come out of my mouth.

It's been over two years since I've graduated and a few weeks ago I decided to crack open this book again because I really did want to understand others better in order to have better relationships. I had the feeling that in most conversations, whether it's at home or at work, I wasn't fully engaged with what others had to say. I wasn't really listening. This isn't the case all the time, but it happens often enough with people I really care about such as my girlfriend (who rarely passes up an opportunity to point out when I'm not really "there") and close friends to make me feel like I needed to do something about it.

I'm digesting a bit of this book each day and what I really like about it so far is that it really emphasizes skills. It doesn't just present theory on what good communication is, it also offers exercises for me to apply in life so that I can actually have better communication. For example, in the first chapter of the book the authors introduces the difference between pseudo-listening and real-listening. One instance of pseudo-listening is when someone is only listening for a specific piece of information and ignores the rest. Real-listening involves complete engagement. However, the authors don't just stop there! They follow up the theory with strategies for engaging in more real-listening such as applying active listening techniques like paraphrasing as well as ways to apply those techniques in life.

I'll be sharing a lot of what I learn in the next few posts, starting with ... chapter one!