Pragmatic Programmer Philosophy Part 2

In my last post I wrote about three of the seven key attitudes and skills that comprise the pragmatic programmers philosophy: Fixing broken windows, taking responsibility, and communicating effectively. In this post I'll summarize three more.

1. Be a catalyst for change

Big changes come from group efforts. One of the most valuable skills you can have whether you work for a company or run your own company is the ability to motivate others to work together on important problems.

When you have an idea that you thing has the potential to positively influence the trajectory of your company, words alone will often not be enough to motivate people. Old processes, much like old habits, die hard. You need to show people something - something that gives them a clear sense of what the future looks like. Showing people something means that you need to invest time in building it and the easiest way to do that is to just fucking do it. This doesn't mean you should shoulder the entire project on your own because in many cases that may not be feasible.

It does mean two key things:

1. Don't ask for permission to do it. Asking for permission is believing that someone else has the right to stop you from pursuing your idea. This doesn't mean never ask for permission. It's just that in most cases new ideas are met with staunch resistance that is rarely based on the merit of the idea itself. One common reason for resistance is strictly attachment to old ways of doing things.

2. Build enough of it to sell your idea and for others to build upon. If you build something that does not at all present your idea in the best possible light, you won't be convincing enough to motivate others. If, however, you do build something that gets people excited but theres no clear way for them to contribute to the goal, then you're still stuck by yourself.

2. Don't forget the big picture

Every project has goals. In order to meet those goals efficiently, the team must remember what the goals are and not get sidetracked. It's very easy to get sidetracked gradually by small things than it is by big things. A frog will jump out immediately if you drop it in boiling water. However, it will cook if you put it in cold water and slowly turn up the heat.

As programmers, we experience the rising temperature in many forms: bugs, features, politics. We need to constantly assess whether our decisions are bringing us closer or farther away from our goals to avoid being cooked.

3. Make quality a requirements issue

Time is a limited resource. Projects have deadlines. Projects that have high quality standards tend to take more time. Given these truths, it's nonsensical to not treat quality as part of your user requirements.

In some projects, there's not much negotiating room for quality. However, in the vast majority of projects - especially very new ones that do not operate under high risk environments - quality can be a sliding scale. What that means is that it should be set by conversations you have with the user. What quality do they need? How much time do you have to work with? Would they rather get the product sooner with less quality or later with better quality? In some cases, users would be more than happy to have a feature that works 90% of the time if they can get it earlier than have it be perfect and have to wait for a very long time.

Having quality as part of your process of gathering user requirements means that the user will more likely get what they actually need and not what you think they need. It also means you'll be much better positioned to say when it's time to stop working on something. You can almost always refactor your code to make a feature better, but if it meets the current quality requirements then that's not necessary.

My Thoughts:

• The concept of making quality a requirements issue is very much part of the philosophy behind making minimal viable products (MVP). I think this is an idea that a lot of programmers who take a lot of pride in the code they write will have difficulty swallowing because it's pretty much saying that you should still ship something even if it's incomplete and crappy if that's what people actually want. As software developers, you're not just writing code for the sake of code. You're often solving other peoples problems. Key phrase: other people. Talk to them - what do they need? 
• I don't feel like I have a problem just going for something without asking for permission. I do want do think more critically about how we can improve existing processes at work. What I often do is I would be introduced to an existing process and if I become frustrated with it, rather than thinking about different ways of doing the same thing I instead tolerate the frustration or eliminate it by becoming extremely familiar with the process (doing the same task faster). I feel like I can be very patient but patience only changes your own perception of a process and not the process itself which may still be causing others a lot of pain. 
• I lose sight of the big picture very often. I have a tendency to get really absorbed in solving a problem without considering its relative importance to other problems I could also be solving. When I'm in that state, it's as if time becomes an unlimited resource and the only thing that matters in that moment is solving the problem. This can be great when I'm latched on to an important problem but it is very problematic when I do this with unimportant problems. My time is limited and not managing my time increases the likelihood of delaying the completion of a project. If someone gives me a week do complete four critical features and one non-critical feature but I spend 80% of your time on the unimportant one, I'll end up rushing (and probably screwing up) to complete the four other features that actually matter.