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.

Exercise Challenge

The actual exercise is to just write down what you think your process is and what problems you seem to have. At this stage you might have no idea how you work because you aren't very experienced. To help you I've compiled a list of questions:

• Do you have problems working on projects for long periods of time?

• Do you tend to make defective code with no idea why?

• Do you chase programming languages but never actually implement anything?

• Do you never remember APIs? Yeah me either.

• Do you feel inferior or like a fraud who will get caught?

• Do you worry if you're a "real programmer"?

• Do you have no idea how to take an idea and pop it out of your head into code?

• Do you have problems getting started?

• Do you work in a chaotic environment?

• Do you get past the first implementation of your project and have no idea how to take it further?

• Do you keep piling code on top of code until there's just a huge mess?

Think about these questions, then try to write down what you do when you work on a project. If you don't have experience working on something, then write down what you think you should do on a project.

Study Drills

• Write some more questions like this, then answer them.

• Ask other programmers you may know what their process is. You'll find they probably have no idea.

Further Study

Something to keep in mind is that what people say their process is and what they actually do can be wildly different. We humans have a tendency to remember events in a much more positive, logical way than reality. During this book you're going to break this habit and use externally recorded metrics (and possibly screen recording) to know for sure what you do. This isn't something you should do forever, but it's a big help when you're working on improving your coding skills. But, when you ask some other more successful programmer what their process is just keep in mind that they have not done this and most likely what they tell you is not really what they do. If you can find a more experienced programmer willing to record their screen while they work, then that can be more instructive than asking them what they do. I suggest going to the screencasts of other programmers and simply watching how they tackle problems and take notes.