Exercise 1: On Process

There's two type of processes in the world of software development. First you have the Team Process, which is things like Scrum, Agile, and eXtreme Programming. These processes are designed to help a team of people coordinate around a large codebase without killing each other. A Team Process is one that dictates how each person will coordinate, standards of code behavior, reporting, and management oversight. Usually these Team Processes boil down to:

• Make a list of things to do.

• Do the things on the list.

• Confirm they are done correctly.

Where many Team Processes go wrong is when they try to control personal processes that are better left to an individual. The eXtreme Programming (XP) process is probably the most abusive in this respect, going so far as to dictate that each programmer have another programmer who observes their work and yells at them whenever the text editor shows some red. I strongly object to processes that force personal process elements onto people when not in some educational context. It insults our professionalism and creates an environment of dictatorial condescension that does not foster creativity or quality. In an educational setting, dictating that students use particular personal process methods is necessary but not in the work environment. For example, the only time I force paired programming on someone is if they are a junior programmer or new to the team and need to learn. After that the team process should be such that everyone is able to work however they need to get the job done at the required quality level.

The other type of process is a Personal Process, and I take this idea from painters, writers, and musicians. Part of developing as a creative individual who focuses on quality is developing a process that helps you produce work in a consistent way. In fact a sign of an amateur painter, musician, or writer is one who has no idea about their process. Usually these people who claim to have no creative process actually do have one; they just aren't aware of it and therefore constantly get it wrong. Most other creative disciplines develop strategies and tactics that help them create finished works from ideas without falling into disaster half-way through. For painters this is a way of breaking the problem of a painting down into logical steps that assure success is more likely. With musicians it's a similar process combined with a balancing act of staying within the structure of their chosen musical style. With writers their process is a way to structure their writing so that it flows naturally and isn't full of plot holes and logical inconsistencies (something most TV writers seem to totally not get).

For software your Personal Process needs to be something that accomplishes the following:

• Identifies viable ideas to work on.

• Gets you started on those ideas to see if they'll work and change them quickly.

• Progressively refines your idea over numerous work sessions in a way that avoids problems or enables you to recover easily.

• Ensures the quality of your implementation of your idea so that you aren't crushed by the weight of bugs later.

• Makes sure you can work with others (if you want).

Notice how I say you don't have to work with others. Since the advent of open source the concept of creating software has included an overbearing demand for community. If you don't want to share or work with others, then you are an insult to their being and considered an anti-social cowboy. The problem is very few creative activities are started in a group, and usually the ones that are started in a group end up not being creative at all. That creative spark is usually the result of one or maybe two people having an idea and then realizing it from nothing. Producing a finished product can require a large team, as with books, movies, and albums. Many other creative activities can be done solo, such as with painting or most visual arts.

You'll never find an art school demanding that painters only work in teams to create a painting. There's also no reason that software can't be a solo creative process similar to painting and writing. Software is a modular discipline, which means you can create something all by yourself and other people can still use it even if they never talk to you and never work on it. You can be a total jerk and people can still use your software. Writing and painting are the same way. There's an ocean of miscreant, abusive writers, painters, and musicians who are still worshiped by millions of people.

If you start working on your personal process and someone tries to tell you that you need to share or you're an anti-social jerk then, they're being abusive. People have the right to keep things private, work alone, and make their own things. The only people who seem to demand that you contribute to larger projects are the people who started those larger projects and seem to make all the money. Trust me on this. I've contributed a huge amount to the world of software, and still I go to conferences and people say I'm not a contributor because I didn't write lines of code into their project (even though they've never ever done a single thing to help me).

Throughout this book, when I say "process" I mean personal process. I rarely cover anything that directly relates to working with others because there's a mountain of books that already cover how you should work with others. There's very few books that help you work on your own process and define what works for you and why. There's absolutely nothing wrong, self-centered, greedy, anti-social, or abusive about wanting to focus on you so you can be better at what you love.