Archives for September 2015

In Linchpin, Seth Godin has this to say about giving advice:

Telling people leadership is important is one thing. Showing them step by step precisely how to be a leader is impossible. “Tell me what to do” is a nonsensical statement in this context.

There is no map. No map to be a leader, no map to be an artist. I’ve read hundreds of books about art (in all its forms) and how to do it, and not one has a clue about the map, because there isn’t one.

Godin has a broad definition of art, which he returns to throughout the book. In “The Guild of Frustrated Artists,” the section this quote comes from, he defines art as “the act of navigating without a map.” In our field, the most famous book on the topic of algorithms is called The Art of Computer Programming. I’m sure Godin would agree that the creative process of software development qualifies as art.

What does he mean when he says, “There is no map”? In Linchpin, Godin’s message is that people make themselves indispensible (“linchpins”) not by following a process devised by someone else, but by inventing their own. In the section before this one, “Scientists Are Mapmakers,” he explains this idea as follows: “Lab assistants do what they’re told. Scientists figure out what to do next.” That makes sense.

But does this mean that it’s impossible to come up with a step by step process for how to be a leader or an artist, or that it’s “nonsensical” to ask for one? I don’t think so. In fact, when approached with the right attitude, a process can provide the conditions you need for making art.

Daily Rituals

Cal Newport of Study Hacks writes a lot about processes that facilitate creative work, which he calls “deep work.” Over the past couple of years, a few Study Hacks posts have cited Mason Currey’s Daily Rituals. For example: Cal’s post about planning every minute of your work day.

For some people, planning every minute of a work day sounds like a rigid system that would stifle creativity. But it has the opposite effect for Cal and the notable artists profiled in Currey’s book. By setting up structure around the mundane parts of their work, like when to do something, these artists free up their energy for more important tasks, like what they’re going to write or create during each time interval. This is the paradox of using a process for creative work.

Checklists

Just as some artists set up a structured schedule into which they can pour their creative energies, practitioners in other challenging fields find it helpful to use a combination of structure and creativity. This is a theme of physician Atul Gawande’s book, The Checklist Manifesto. In one of Gawande’s examples, which you can read about on James Clear’s blog, a checklist system for physicians resulted in hundreds of saved lives and millions of dollars in reduced healthcare expenses.

Why did the checklist approach provide so much benefit? Professions that require a high degree of skill generally also involve work that is simple but important. Physicians have to wash their hands and maintain a sterile environment. Pilots have to make sure their airplane is safe to fly. Programmers should review source code diffs before submitting new code to a shared branch. It’s rare to find a job where someone else takes care of the details and your only responsibility is to come up with deep thoughts. Maybe Chief Executive Officer. For the rest of us, checklists can keep that routine work on track. And even if you are the CEO, your assistants probably use checklists. In the study from The Checklist Manifesto, nurses were the ones keeping the doctors out of trouble by making sure they didn’t skip any steps.

Feedback Systems

The company I work for has a number of feedback systems. There’s a website that employees can use to send virtual thank-you notes to co-workers who help them out. There’s a quarterly discussion, which includes written feedback from both peers and managers. There’s an annual discussion of changes to salary and other compensation. And each employee has an informal weekly meeting with their manager.

A weekly meeting with your manager is a good time to ask for advice about things you’re having trouble with. You probably wouldn’t phrase it as bluntly as Seth Godin’s “Tell me what to do.” But it’s perfectly reasonable to say you’re having trouble with some aspect of your job, and ask, “Do you have any suggestions?”

Your manager’s responsibility is then to draw on their experience advising people in similar situations, and come up an idea to try out. It’s unlikely that the first idea will solve your problem, but a good manager will start by pointing you in the right direction. The following week, you can return to discuss how things went, and your manager can help adjust your course. (If you’re not in the corporate world, replace “manager” with mentor or adviser). Using a combination of advice and experimentation, you can gradually build a map of where you want to go.

Teach Yourself Programming in Ten Years

Peter Norvig’s Teach Yourself Programming in Ten Years is a frequently-cited response to the popular books that promise to teach a programming language in 24 hours. But although Norvig (co-author of the standard college AI textbook and other books) advises against relying too much on “book learning,” his main disagreement is with the timeline of these “teach yourself” books, not the idea that a book can be a useful guide. In this article, he proposes his own “recipe for programming success,” a collection of advice such as:

• Learn multiple programming languages that emphasize different programming styles;
• Read code by other programmers; and
• Make sure that you’re having enough fun that you’ll keep learning.

Norvig’s article won’t help someone who is trying to solve an immediate problem. (We have Stack Overflow for that). But although each step in his recipe could take months or years, it is a step-by-step process for learning programming from the ground up. A motivated beginner could take these steps to heart and find themselves years later with a good understanding of the field.

How to Attack a Programming Puzzle

I have written before about the benefits of using a process for solving programming puzzles. The process doesn’t just give you the solution. That would be pointless. But it does provide a roadmap for getting as much learning benefit as possible out of each problem that you solve on your own. This is the goal, since puzzle solutions don’t have any inherent value. The purpose of solving them is to learn something about programming and problem-solving. The process is a reminder to look for lessons at each step, and not just forge ahead.

Processes and Tools

In 2001, a group of software developers published the Manifesto for Agile Software Development, a response to mainstream software development methodologies. At the start of the manifesto, the authors declare that they value

Individuals and interactions over processes and tools.

One criticism of processes is that they cause people to surrender responsibility. For example, consider a software project team made up of a group of engineers who are responsible for building a product, and a group of subject matter experts who are responsible for defining requirements. Imagine that the team is using a process that requires the SMEs to approve requirements early in the schedule, before any code has been written. The engineers can then point to these requirements whenever the SMEs request a change, and say they need additional time or money. This sets up an antagonistic relationship between the people building the software and the people who represent the customer. It can also lead to both groups surrendering responsibility for building a product that will best meet the customer’s needs, and instead just building the product that was documented at the beginning of the project.

The software methodology debate is a big topic that I won’t go into here. However, I will point out one difference between a team process and an individual process. A team process is often imposed from above on team members who are required to follow it. With an individual process, like the ones discussed in this post, an individual decides to follow a process for his or her own benefit. There is one person enforcing compliance to the process, namely the person who benefits from it. This setup is unlikely to result in surrendering responsibility or process for the sake of process, which was the real target of the “Individuals and interactions” declaration in the Agile Manifesto.

Servants to the Process?

In discussions of process, it’s common to hear statements like these from the comment section of a John Sonmez post about the Pomodoro Technique:

• “[T]his article does a great job of explaining how to make Pomodoro Technique work for you instead of being a servant to the Pomodoro Technique.”
• “Things like the Pomodoro Technique and every other productivity technique and tool are just that – tools, for us to use to get better results. We should not be a slave to them.”

These seem like reasonable points. But the paradox of using process for creative work is that producing something unexpected often requires a process that is exactly the opposite. The human mind seems to resist creating something out of nothing, which is what is required to make something valuable. Creating the right process (through experimentation and adjustment) and then voluntarily adhering to it can be the way to accomplish this.

It’s easy to say that the process is just a tool, and we need to make it work for us. And of course that’s true. But it’s not that simple. After all, if we always did the right thing at the right time, there would be no need for a ritual, or a checklist, or a process. The Sonmez post is a response to questions that people sent him about how strictly they should adhere to the Pomodoro technique. Now the whole point of Pomodoro is that we modern computer users are easily distracted and prone to multitasking. Pomodoro says: pick one task and focus on it for 25 minutes without interruption. When people hear strict rules like that, they tend to jump to the exceptions: What happens if I have to wait for my computer to complete a task? What happens if I have to use the bathroom?

Sonmez’s answer is basically: be pragmatic without sacrificing the essence of the process. You’re using Pomodoro to combat your natural impulses. When you allow an exception, you’re giving your technology-addled brain an excuse to jump over to something other than the task you’re trying to complete. So take those exceptions seriously. Yes, be pragmatic and make the process, or the ritual, or the checklist work for you, but also keep in mind why you started using it in the first place. There may not be a process or roadmap that guarantees success, but often a rule that tells you what to do next is what frees you to concentrate on your goal.

(Image credit: rosario fiore)