Red-Green-Code

Deliberate practice techniques for software developers

  • Home
  • About
  • Contact
  • Project 462
  • CP FAQ
  • Newsletter

Deep Work and Collaboration in Software Development

By Duncan Smith Mar 30 0

Collaborate

“The relationship between deep work and collaboration is tricky,” writes Cal Newport in his recent book on focused productivity. That’s for sure. The goal of deep work is to expand your cognitive abilities in a distraction-free working environment. But many people don’t work alone. And as anyone who has worked on a team can attest, co-workers can be a source of distraction. How can we reconcile deep work goals with the need for collaboration?

Hubs, Spokes, and the Whiteboard Effect

In Deep Work, Cal suggests two ways to achieve the benefits of deep work without giving up on collaboration:

Find a hub and spoke workplace

Workplace trends favor open workspaces. In theory, those promote collaboration by encouraging people to bump into each other and exchange ideas. Cal instead recommends a hub and spoke workplace architecture. This type of workplace combines private offices with common areas. Workers spend most of their time concentrating in their offices, but emerge periodically to encounter their colleagues in spaces like hallways and break rooms.

You can’t always control the design of your workplace, but you can create a virtual hub and spoke model even in less ideal circumstances. For example, you can wear headphones to indicate that you’re concentrating (and for blocking out background noise), or work some of your day during early or late hours when you’re less likely to be interrupted. These are workarounds, not perfect solutions, but they may be preferable to changing jobs, especially as more employers move to the open workplace model.

Take advantage of the whiteboard effect

Deep work doesn’t have to be individual work. Cal gives the example of Walter Brattain and John Bardeen, who built the first transistor and later shared (along with William Shockley) the Nobel Prize in Physics. Brattain and Bardeen’s result clearly meets the criteria for deep work, but they accomplished it by working as a team of two, not as one individual deep thinker.

The whiteboard effect doesn’t automatically turn any group discussion into deep work. The larger the group gets, the harder it is for every individual in the group to avoid the distractions that prevent deep work from happening.

The Technology We Love to Hate

For knowledge workers, the quintessential example of shallow work is reading and writing email messages. The subject of last week’s Study Hacks post is a recent article Cal wrote in the Harvard Business Review, in which he suggests that we all give up email. That would be great, but email seems to be really hard to kill (and companies have tried). Cal’s suggested replacement is interesting though.

In the email workflow, knowledge worker #1 needs something, so she sends a request to knowledge worker #2. The request shows up in KW2’s inbox. Cultural norms dictate that KW2 take action on the request in a reasonable period of time. Meanwhile, KW1 is dealing with her own inbox requests from other colleagues. For many knowledge workers, the email workflow sets the agenda for the day’s activities. Cal compares the process to routing packets on a network, but instead of specialized hardware, the routers are human beings who should be doing something more valuable with their time.

As an alternative to the email workflow, Cal suggests office hours: each knowledge worker selects a few times during the day when they are willing to be interrupted. During these times, they use old-fashioned communication techniques like meeting in person or speaking by phone, or newish technology like instant messaging. But no email.

Collaboration in Software Development

While we wait for someone to kill email, let’s consider how deep work fits into the workflow of a software development team.

The hub and spoke arrangement and the whiteboard effect represent ideals of deep work/collaboration coexistence. In the first setup, workers spend most of the day in an ideal deep work environment. In the second, two well-matched peers push each other to get the most out of their abilities.

The office hours proposal covers another aspect of deep work and collaboration: sometimes we just need a colleague to do something or provide information. Traditionally this is handled through email, but regardless of the communication mechanism, there’s an asymmetric relationship between two workers. One person needs something, and the other has the means to provide it. In software development, one developer might own a component that needs a bug fix or enhancement in order for other work to proceed. Or they might simply know how to work around a problem.

If we combine the whiteboard and office hours scenarios, we get another scenario: collaborating with someone who knows more or less than you about a topic. Let’s call it asymmetric collaboration. This scenario differs from the whiteboard scenario, which is a collaboration of equals. And it’s different from office hours, which are for quick or one-time conversations, not ongoing collaboration.

In asymmetric collaboration, the goal is to spread knowledge around an organization. The challenge for the more knowledgeable person is to explain their specialty in a way that the less knowledgeable person can understand. The challenge for the less knowledgeable person is to concentrate and keep up. The “teacher” and “student” may later switch roles.

Asymmetric collaboration can be compatible with deep work. The person in the teacher role has the chance to solidify their understanding of a topic. The person in the student role gets to learn something new. There is deep work potential in both opportunities. However, there are pitfalls for both teacher and student.

  • For the teacher, there’s a danger of becoming the expert that everyone goes to with problems, leaving them with no time to learn new things.
  • For the student, the teacher may be eager to get back to their own work, which may tempt them to simply solve the problem rather than helping the student learn how to solve it.

In these situations, neither the teacher nor the student is stretching themselves, which means deep work isn’t happening.

Combining Deep Work with Collaboration

Deliberate practice researchers have determined that elite performers spend no more than 4-5 hours per day in concentrated practice. Deep work, which has a lot in common with deliberate practice, has a similar limitation. You can’t spend the whole work day focusing at maximum intensity. So the goal of using deep work on the job is not to eliminate all shallow work. Just half a day’s worth.

In a programming job, there’s always something new to learn. If there isn’t, it may be time to move to something new. Sometimes you can find the information you need on Stack Overflow, and spend your deep work time internalizing and practicing it. But that isn’t always possible. You may be working with a system that is internal to your company and has no documentation. In that case, the best approach may be to find someone nearby who can explain things to you.

When you get stuck on that type of problem, should you seek help, or try to puzzle through it on your own? The answer to that question depends on which of these statements best describes you:

  1. I usually work on a problem for too long, rather than asking for help when I get stuck.
  2. I usually ask for help on a problem too soon, without spending enough time trying to figure out the solution on my own.

There is some value in banging your head against a tough problem. But it’s best to practice that discipline on programming puzzles or your own projects, not on problems that you’re being paid to solve. If you’re on the clock, decide if you’re closer to group 1 or group 2, and work to get closer to the other group. Group 1 people need to learn to look for help once they have made a diligent attempt. Group 2 people need to become more self-sufficient before they give up.

Good Interruptions

For the reasons explained in the book, a deep work habit is worth cultivating. But for most software developers, it’s not necessary or desirable to spend all of your work time alone in front of a computer.

When you’re learning something new, the best choice is often to interrupt someone who knows more about that topic and can get you through a challenging spot. And when you’re the expert in an area, the best interests of the group dictate that you allow yourself to be interrupted in order to spread your knowledge around. If you reserve half your day for deep work and use that time effectively, this type of collaboration won’t prevent you from making progress on your own learning goals.

(Image credit: Ron Mader)

Categories: Career

Prev
Next

Stay in the Know

I'm trying out the latest learning techniques on software development concepts, and writing about what works best. Sound interesting? Subscribe to my free newsletter to keep up to date. Learn More
Unsubscribing is easy, and I'll keep your email address private.

Getting Started

Are you new here? Check out my review posts for a tour of the archives:

  • Lessons from the 2020 LeetCode Monthly Challenges
  • 2019 in Review
  • Competitive Programming Frequently Asked Questions: 2018 In Review
  • What I Learned Working On Time Tortoise in 2017
  • 2016 in Review
  • 2015 in Review
  • 2015 Summer Review

Archives

Recent Posts

  • LeetCode 227: Basic Calculator II January 13, 2021
  • A Project for 2021 January 6, 2021
  • Lessons from the 2020 LeetCode Monthly Challenges December 30, 2020
  • Quora: Are Math Courses Useful for Competitive Programming? December 23, 2020
  • Quora: Are Take-Home Assignments a Good Interview Technique? December 17, 2020
  • Quora: Why Don’t Coding Interviews Test Job Skills? December 9, 2020
  • Quora: How Much Time Should it Take to Solve a LeetCode Hard Problem? December 2, 2020
  • Quora: Quantity vs. Quality on LeetCode November 25, 2020
  • Quora: LeetCode Research November 18, 2020
  • Quora: Optimal LeetCoding November 11, 2020
Red-Green-Code
  • Home
  • About
  • Contact
  • Project 462
  • CP FAQ
  • Newsletter
Copyright © 2021 Duncan Smith