“…slow is smooth, smooth is fast.” My trainer repeats the mantra as I make jerky, inefficient movements with the basketball. I decide he should sit next to me and repeat this while I code, do customer support, cook, and look for my keys.
Ever feel pressure to code quickly? Fear you won’t accomplish enough in the sprint? Run into an unexpected snag and dread explaining that you’re still working on the same task at standup the next day?
How do you think that pressure affects your behavior and performance? Does it lead you to make the best decisions for the long-term?
These sorts of anxieties have been a frequent companion in my career. Even when not pressured, I find myself jumping into tasks at an almost frenetic pace. Sometimes it feels great to knock out tickets at breakneck speed. Other times, it results in costly mistakes. It almost always leads to a refactory period where focus is more difficult.
 I once urgently needed to change data in my production db, and the app console takes more than a minute to load. I decided to make the simple change in psql instead, saving that precious minute. Instead of modifying the three records I needed, I changed every. damn. record. in the table. Fortunately I was able to use backups to restore the data, but you get the point…
I’ve recognized three triggers of this manic coding behavior in myself:
- Excitement. I’m just excited about the task and ready to blast off. This causes me to underestimate the work involved, and my quickness soon becomes unsustainable after encountering hidden complexity. My hasty assumptions about the task turn out to be wrong and rework is required.
- “Agile.” Much has been written about “Agile” and micromanagement that I won’t rehash here. Personally, I tend to be a collaborative worker. I enjoy helping people with Heisenbugs, architecture considerations, etc. Unfortunately, cargo-cult “Agile” discourages anything that can’t be immediately tracked in Pivotal points or claimed as your own. Even mentioning that you helped someone in standup can be an encroachment on your coworker’s need to appear productive and self-sufficient. Some work environments are more toxic than others (often correlating with the amount of funding left), but I’ve found even the best environments introduce unwarranted developer stress this way. This stress often manifests as feeling rushed while coding.
- Fatigue. It’s late at night, I’ve been working without breaks for many hours, or I am just plain tired. Perhaps I’ve simply been working at an unsustainable pace for the past few weeks. My fatigue makes me less patient, more likely to commit errors and take shortcuts. In Zen and the Art of Motorcycle Maintenance, Pirsig calls this the most important feeling to recognize as it often precedes “the Big Mistake.”
 Rich Hickey famously pointed out that “sprinters” only run short distances and “Agile” solves this by firing the starting gun every 100 meters.
Slow is smooth. Smooth is fast. If you can’t convince yourself to slow down for fear of lost productivity, try an experiment: for the next medium-sized task you have, don’t jump in immediately. First, gather all of the information and resources you’ll need to complete the task. Pretend you’ll be working on a plane (without WiFi) and you must finish the task before you land. Figure out which files you’ll need; plan your attack. Then, calmly proceed with your plan, noticing when you start to feel rushed and then purposefully slowing down. Even force yourself to type slowly, sending your brain the message that there is no hurry.
At the end of this experiment, ask yourself these questions:
- How do you feel?
- Was there hidden complexity you might have missed had you been rushed?
- How much time do you think you gained/lost by taking things slowly?
- Does this feel more sustainable than your usual pace?
Let me know what your experience is! I think you’ll find that development can become consistently energizing again, rather than tiring. I have personally been able to increase my productivity severalfold by not only slowing down while I’m working, but also drastically reducing the amount of time I allow myself to work.
I highly suggest Cal Newport’s Deep Work for more insights into increasing your productivity while reducing stress.
I'm Garrett Lancaster. I co-founded and developed a moderately successful SaaS app you've never heard of. I mainly work on projects using Ruby on Rails, Ember, React, and "VanillaJS". If you liked this article and want to hear about the next one, click below. I don't spam and I respect your privacy.