With 2016 wrapping up, I have my traditional end-of-year review planned for next week. In that post, I’ll go over all of the articles from this year. This week, I’m reviewing a more specific topic.

If you have been following along for the last couple of years, you know that I write a lot about competitive programming, but that I also explore topics related to productivity and learning techniques.

Mastering a subject requires learning some domain-specific topics. For competitive programming, these topics include language advice and editorials on specific programming puzzles. But that knowledge isn’t very useful if you just read about it. You also need a plan to use it.

When you’re learning a technical subject like an algorithm, you can’t just read about it once and remember it. You have to try it out, often many times. If you don’t keep using it, it’s easy to forget it, which often means you have to re-learn it later. Similarly, learning about a productivity or learning technique doesn’t help much unless you try it out repeatedly in real working or learning situations. And if you stop using it, it may take some time to get back into it later.

With that in mind, I have collected a set of reminders that I find useful when working on difficult projects. I’m planning to keep this list handy in 2017 as a checklist to make sure I don’t forget to use these techniques for my programming and learning projects.

Here’s the checklist:

• Work on important problems, or on problems that will lead to important problems.
• Use time goals to make sure you’re showing up.
• Schedule blocks of time so you don’t have to decide when to work.
• Track focused time to make sure you’re using your work time efficiently.

« Continue »

If you want to get better at something, you need a plan. Improvement doesn’t happen on its own. But once you have that plan, a bigger challenge is executing on it along with your other responsibilities.

One way to increase your chances of following through on changes is not to try to make big changes all at once. Instead, make small changes, but make them regularly. Let’s see how that works.

« Continue »

A few weeks ago, K. Anders Ericsson of deliberate practice fame released a new book (which I haven’t yet read) called Peak: Secrets from the New Science of Expertise. The main challenge with reading these types of popular science/psychology books is taking action. They are written to be enjoyed, but there’s nothing forcing you to make any life changes once you finish the last page.

One way to avoid the passive reader trap is to maintain an idea list. Advice books are packed with words and stories, but are usually built around a few core ideas. Many of these ideas come up repeatedly in different books and articles. So as you come across them in your reading, maintain a master list of ideas that seem useful. The purpose of this list is to serve as a reminder of practices that you find effective. Try them out one at a time, and adjust as necessary to fit your work style.

Items on this list should be more actionable than guiding philosophies like “You don’t have to live your life the way others expect.” But they shouldn’t be too specific, or your list will get unwieldy. This isn’t the place for tiny life hacks about secret Gmail features. The goal is to make a list that will remind you to follow principles that you have found to be effective.

With that in mind, here’s my list:

« Continue »

Software developers spend a lot of time in front of computers, obviously. It’s also a modern truism that a networked computer is both a productivity enhancer and the greatest time waster humanity has ever invented. The same devices that we use to make a living are also perfect for delivering endless cat videos.

But we can’t just stop using our computer and go back to the abacus. Even turning off the network is problematic, now that Stack Overflow is the de facto source of documentation for anything useful. (Turning off email while you work is recommended though).

So what’s the solution? One thing about computers, especially those that run desktop operating systems, is that they’re designed to be customized. So let’s try to solve a problem that technology has created (Internet distraction) by applying a technological solution: a time tracking app, customized for self-tracking developers.

« Continue »

Earlier this year, I wrote a survey of the Productivity Habits that I’m using to keep my project moving along. This week, I’m going to focus on one habit, which I’m calling Time Bank. I’ll also share a handy spreadsheet that makes it easy to try out this system.

« Continue »

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)