Get Off the Tightrope

by Tom Stuart

In his presentation at RubyConf 2017 titled "Get Off the Tightrope," Tom Stuart discusses the common struggle programmers face when trying to manage large tasks, a mental habit he describes as akin to walking a precarious tightrope. He explains how this approach leads to stress, inefficiency, and a host of secondary issues in software development. Stuart shares various symptoms of this problem, including the difficulty in maintaining focus amid potential interruptions, the overwhelming nature of large tasks, and the time-consuming nature of switching gears when distractions occur.

Stuart highlights several causes of 'tightrope walking':
- Eagerness for Progress: Developers frequently dive into tasks without a clear understanding of their complexity.
- Cultural Influence: The tech industry often perpetuates the idea that programmers need uninterrupted focus, which can lead to isolation.

To combat this issue, Stuart suggests practical remedies:
- Break Down Tasks: Encourage planning and breaking large projects into manageable parts using techniques like story mapping.
- Utilize Version Control: Using Git effectively for tracking changes, maintaining a clean commit history, and collaborating can improve workflow.
- Practice Test-Driven Development (TDD): This approach enhances focus by cycling through phases of development, ensuring quality and keeping progress clear.
- Leverage Conversations: Engaging with colleagues and sharing ideas can clarify thinking and foster teamwork.

Stuart concludes by emphasizing the importance of recognizing when programmers are overextending themselves and encourages using tools and strategies to simplify complex problems. By actively avoiding the all-or-nothing tightrope mentality, developers can lower stress and enhance their productivity, ultimately leading to better software outcomes.

00:00:10.670 Hello everyone, my name is Tom, thank you very much for choosing to watch this talk. I'm very grateful for your time and attention.

00:00:15.719 This is going to be about 40 minutes of your life that you'll never get back, so I'm going to do my best to make it worthwhile. I'm here to talk to you about a particular problem that I see a lot.

00:00:30.660 For most of the last decade, I've made a living as a consultant helping people to make better software. That has involved working with many different companies that employ lots of different developers. This was by far the most common problem that I had to help people with.

00:00:42.180 In almost every case, it was the root cause of many secondary problems and it usually ended up costing time, money, and emotional stress. A year ago, I was fortunate enough to join an online learning company called FutureLearn as their CTO.

00:01:00.180 This means I'm now responsible for a team of brilliant developers who are all fantastic at their jobs, but I still see them wrestle with this problem from time to time.

00:01:12.390 This issue affects everyone at all levels of experience. It certainly affects me whenever I sit down to write code. It’s not even a programmer-specific problem, but I'm addressing an audience of programmers today, so I will discuss the problem from a programming perspective.

00:01:24.990 Although this is a serious problem with serious consequences, it’s one that you can actually fix, partly just by being aware of it—which is half the battle with any problem. However, you can also learn tools and coping strategies that can make it much less likely to affect you.

00:01:43.380 I'm going to talk about some of those tools and strategies in a bit. Actually, here’s the overall plan for what I’ll be telling you: I’m going to start by describing the problem and then tell you about some of its symptoms and causes.

00:02:01.409 I'll suggest a few example remedies for the problem based on my experiences, and then I’ll wrap up by explaining why I think this is an important issue to discuss. So first, here's the actual problem: trying to do a big thing all at once, all in one go.

00:02:21.989 That might not sound like a big deal, but as I said, it’s a surprisingly destructive tendency that leads to all sorts of other problems. I'm sure you recognize the situation: you have a large task, like adding a feature to some software, investigating a difficult bug, or making a major upgrade.

00:02:40.379 To make progress, you need to think about all the large and small details, all the moving parts, and all the interdependent problems. You need to keep everything in your head simultaneously to think about all of them at different levels of detail while you do the actual work.

00:03:03.030 Working on this big monolithic task can feel like a precarious walk across a tightrope. You start out standing on safe ground, but once you step out and begin, you won't feel safe again until you complete it and reach the other end—which could be far off in the distance.

00:03:21.660 Every step you take has increasingly high stakes. If you fall off, you’ll have to start over, losing your context, ruining your flow, and forgetting what you were doing. You might end up having to go all the way back to safety and try again from the beginning.

00:03:49.100 Now, here are some symptoms of this problem. When you're experiencing it, the large task feels constantly stressful. It’s difficult to get things right because so much depends on it, and you’re constantly aware of the risk of falling off and having to start over.

00:04:07.290 Since you're expecting the problem to be large and messy, it can be hard to see where the edges of the problem are. This makes it easy to accidentally get stuck investigating some buggy third-party library or unpicking questionable design decisions from years ago.

00:04:24.530 Before you know it, you’ve spent days down a rabbit hole chasing a dead-end issue that isn’t even part of the original task you were trying to accomplish. Once you get past the halfway point, your energy tends to wane, and you just want the whole thing to be over with.

00:04:37.430 This decreasing willingness to revisit your original assumptions or question your earlier decisions can be problematic, especially when new information comes to light. It’s almost certain that as you work, you’ll discover more valuable information that may reveal earlier mistakes.

00:04:56.100 However, if you’re desperate to just finish the big project, you're less likely to want to go back and address those decisions, leading to lasting mistakes. Additionally, interruptions or distractions can be particularly painful because they disrupt the meticulously constructed mental context you’ve built up.

00:05:13.160 As an aside, a particular strain of tech industry culture reinforces the view that programmers shouldn’t be interrupted due to the complexity of our work. There’s a popular comic illustrating the immediate loss of focus that occurs when a programmer is interrupted.

00:05:39.470 Now I'm a programmer, but I also manage a team, and I enjoy coffee—so maybe I'm the problem here. Regardless, it’s important to be cautious of the narrative that programmers deserve to be uninterrupted because of the nature of our work.

00:05:56.810 You may have seen this image circulating on Twitter that emphasizes the extensive time needed to transition mentally in and out of meetings. It suggests that if you have a meeting for 30 minutes, you might need 45 minutes of downtime before and after just to prepare and recover.

00:06:20.780 Similarly, there’s a chart illustrating how much time it takes for so-called 'geek productivity' to recover from interruptions. Regular small interruptions can lead to substantial loss of productive time throughout the day.

00:06:41.840 Images like this reinforce the cultural belief that interruptions and distractions are inherently detrimental to meaningful work. Another symptom of this problem is how long it takes to pick up your thread again when you get back to work.

00:07:00.660 If you’re always in the middle of something massive—even without interruptions—it can still take you ages to get back into the flow. If you find that it takes a long time to ramp up on a Monday morning or after lunch, you might be suffering from this issue.

00:07:12.900 There are other symptoms that I won't delve into in detail, like feeling irritable about questions and meetings, or worrying that you might forget what to do next. You might also notice that you've modified many files but can't remember what you were trying to accomplish.

00:07:36.660 Those are some symptoms of the problem I'm discussing, but why does this happen? I believe one reason is simply eagerness to make progress. You see a significant task ahead of you and want to dive right in, seeking the psychological reward of completion.

00:08:06.340 This eagerness comes from a good place, but it may lead you to overshoot your capacity. Additionally, being unsure of how big a job will be can also contribute to the issue. When you first start working on something, it’s easy to underestimate its complexity.

00:08:32.649 Even if you have a decent sense of the task’s size, you might lack visibility on how far along you are as you go. This uncertainty feeds anxiety and worry about pausing your work, which only exacerbates the problem.

00:08:54.640 As previously mentioned, there’s a prevalent idea in tech culture that programmers possess a unique role among knowledge workers. This notion is flattering to programmers since it endorses our work as intricate and demanding of special attention.

00:09:09.590 Programmers tend to believe that those around us must make space for us to focus, and that we require consideration in how we work, treating interruptions as intolerable. However, this perception is misguided for several reasons.

00:09:36.710 Most significantly, interruptions and distractions aren't exclusive to programmers; all knowledge workers need uninterrupted time to focus, and interruptions can present collaborative opportunities. While we might wish to minimize distractions, we must also acknowledge that they can spark empathy and foster collaboration.

00:10:06.780 Addressing the reality of our work involves accepting that interruptions and distractions are tough to eliminate entirely. If we ignore them, we risk missing out on valuable insights from others.

00:10:19.240 For instance, if someone wants to speak with you, engaging with them might actually offer helpful perspectives. Endless focus without any engagement might isolate you from others’ experiences and the broader context of your work, hindering your growth as a developer.

00:10:54.540 New programmers often associate programming primarily with typing out the correct solution. While that is initially true, to grow as a developer, you must widen your skill set to include understanding and caring about others' perspectives.

00:11:17.090 Now that I've explained the problem, let’s discuss some remedies. I don’t have a magic solution to eradicate this issue, but over the years, I've gathered various strategies for coping with it that I’d like to share.

00:11:30.900 These strategies are based on my observations of other developers and I hope you might find them helpful or think of your own. Each of these examples could warrant an entire talk in its own right, so I appreciate your understanding as I briefly outline them.

00:12:03.990 The first remedy is planning ahead. It’s essential to break down large tasks into smaller, manageable components. While you don’t need to accomplish everything immediately, having a plan will help guide you in breaking down your work over time.

00:12:21.030 Story mapping is a great way to visualize how smaller tasks contribute to a larger goal. This technique, developed by Jeff Patton, can help you organize and categorize tasks that need to be accomplished to achieve a specific outcome.

00:12:58.089 For example, let’s say you’re building an e-commerce website. You’d start by gathering a group of people to brainstorm individual small tasks that might occur during the process, like viewing a product, adding it to the basket, and making payment.

00:13:30.480 As more tasks come to mind, you write them down and arrange them chronologically on a wall, categorizing them into groups. This exercise offers a comprehensive view of the overall story, allowing you to identify gaps in certain areas that may need addressing.

00:13:49.280 Once you have a complete set of tasks, you can select a minimal number to form the initial version of the project—this is called 'slicing' the story map. By breaking tasks into smaller components, you gain a clearer sense of the overall progress you’re making towards your goal.

00:14:21.230 Another useful remedy is maintaining a clean and coherent history of your work using version control systems like Git. Making small, focused commits allows for better organization and understanding of what you’ve accomplished.

00:14:37.910 By avoiding large, indiscriminate changes and instead opting to commit self-contained changes, you clarify the relationship among your modifications and reduce confusion when reviewing your work later.

00:14:59.680 Writing detailed commit messages improves context as you document your thought process at the time of a change. When revisiting work later, these insights enhance recollection about why specific changes were made.

00:15:21.240 Always strive to maintain a healthy branch state while you’re working on a long task. This means regularly reviewing your work, incorporating upstream changes, and ensuring your branch is coherent and presentable.

00:15:44.060 Additionally, look for opportunities to integrate small, beneficial changes into the main branch during your work. This encourages a consistent workflow and gives you a chance to contribute improvements actively.

00:16:07.270 Become comfortable with reviewing your Git history regularly. Using interactive rebasing to organize your commits improves clarity, helping you maintain a linear trajectory in your work.

00:16:37.030 You can merge edits more seamlessly and illustrate the flow of your work, which facilitates easier understanding for those looking at the code in the future. This technique also aids others in following your logic without getting bogged down in excessive details.

00:17:06.210 In addition, practice switching away from tasks periodically. Working exclusively on one branch for extended periods can cloud your perspective. Taking breaks and then revisiting your work helps you assess it more critically.

00:17:37.700 Additionally, try to work in short bursts to keep your focus sharp. This will help you cultivate a better sense of whether your current work makes sense and help you understand where you need to make adjustments.

00:18:03.660 Test-driven development (TDD) is another powerful tool that assists in managing complex tasks. It encourages switching between different mental phases: red, green, and refactor. This approach helps keep your focus on the task at hand while ensuring solid code quality.

00:18:29.870 Within TDD, you start by thinking about what your code should do (red). Then, you work on getting it to pass (green), and finally, you refine the code to enhance its quality (refactor). This cycling keeps you grounded and allows for ongoing improvement.

00:18:56.360 Developers often overlook the invaluable focus this strategy provides. It is important to actively think about your current phase and not let distractions draw you away from progressing through your work.

00:19:24.530 Additionally, consider working outside-in with acceptance tests or end-to-end tests. This method gives you a larger view of your tasks, clarifying what features need development and how close you are to completion.

00:19:51.440 Whenever you encounter a failing test, it serves as a useful indication of the next area to focus on. Always being aware of your current standing in relation to your end goals helps maintain progress.

00:20:19.480 If you have no idea what I'm talking about regarding this acceptance test idea, I will link some resources later for better understanding. For example, one of my colleagues recommends never stepping away from your computer without a failing test, as it helps you seamlessly return to your task.

00:20:45.750 Tests should focus on checking what you genuinely care about rather than being a box-ticking exercise after implementation. They are a crucial tool to clarify your focus and priorities.

00:21:12.270 Remember, code that’s hard to test will also cause challenges in usability and maintainability later. If a code structure requires effort to test, take the time to enhance its design now, rather than deferring problems for the future.

00:21:34.760 Lastly, leverage notes and conversations—these powerful tools are often overlooked. Practice jotting down questions, insights, and distractions that arise while you’re focusing on a task, which can help you avoid losing your focus.

00:21:57.160 Make it a habit to share your thoughts with others; verbalizing them can help clarify your thinking. Pair programming can enhance this process, as will conversations with colleagues.

00:22:29.790 Finally, I want to recap a few key methods that can help you avoid the tightrope feeling. You can make plans to navigate tasks effectively, use Git to keep your history clean, and leverage conversations for guidance.

00:22:56.470 These tools will keep you grounded as you tackle complex projects and make your work less stressful. The main strategy is to be aware of when you're taking on too much at once, keeping a pulse on your feelings while working.

00:23:23.560 If you notice yourself moving onto that dangerous tightrope, it’s crucial to step back and rethink your approach, breaking down tasks into smaller, manageable steps, rather than seeking to leap across all at once.

00:23:51.080 In terms of resources, Jeff Patton’s user story mapping page links to a book, as well as helpful blog posts. There are also other useful resources about using Git to articulate and document your work.

00:24:25.320 Additionally, various talks from RubyConf, including one on Git-driven refactoring, cover useful techniques that can help visualize ownership of your work.

00:24:40.780 In conclusion, I’ve spent considerable time discussing the tightrope-walking issue. I chose to come all the way here from London to communicate the importance of getting off the tightrope.

00:25:09.200 Based on my experiences, I believe that recognizing this problem is essential for becoming a great developer. When you start your journey, you learn how to write code, but as you progress, the challenge is to cope with complexities of larger problems.

00:25:32.920 Ultimately, learning how to break down complex issues, using the right tools and strategies, is what differentiates good developers from great ones.

00:25:58.880 As you become more experienced, mastering strategies for addressing the intrinsic complexities of your tasks becomes crucial. With persistence in breaking down larger questions into smaller tasks, you can methodically approach your work.

00:26:21.530 Though this might seem obvious to some, the realization came as a surprise to me. I still find it necessary to remind people not to stress by taking on too much at once.

00:26:44.370 Ultimately, mitigating stress while enhancing your coding abilities hinges on embracing these strategies and allowing them to become second nature. Don’t wait for improvement to happen by accident.

00:27:10.180 When you return to work after this talk, think deliberately about honing these skills and make time to develop strategies that resonate with you. Learning to recognize when you're treading on the dangerous tightrope will empower you to step back to calmer ground.

00:27:34.310 By methodically progressing through your tasks, you will not only produce better software but also experience less stress and frustration in the process. Thank you very much.