In the 2014 film Whiplash, controversial music instructor Terence Fletcher aggressively questions his jazz drummer student Andrew Neiman during a band rehearsal. "Were you rushing or were you dragging?" he asks Neiman.
I'm a developer, and I often think about this scene. Every time I evaluate the code I'm working on, I ask myself in Fletcher's voice: Did I deliver this feature too quickly? Or am I taking too long to fix this bug? Am I rushing or am I dragging?
I believe many developers share this line of thinking. We think this way because of how developers deal with estimates in software development. An estimate is a relatively rough guess at how long it should take to code a feature or fix a bug. An estimate is not a deadline, and managers should consider that when using production metrics like Throughput or Takt Time.
Additionally, developers with different backgrounds and experiences will design and build solutions in different ways, with different levels of depth and detail.
Still, data and metrics dictate the pace of today's world. Developers work for companies that have to turn a profit, and that's linked to the time it takes for their products to be released or updated. Inevitably, companies lean more on the when than they do on the how.
Because there's no metronome to measure developer tempo while programming, I came up with a few non-obvious heuristics that help me understand whether I am rushing or dragging. I hope these will help you too.
It's completely normal that code reviews ask for small adjustments. But if they're pointing out unmet, partially met, or non-functional requirements, you're probably rushing development without a proper understanding of the task at hand.
Every task gives you the opportunity to get better at your craft. Even for tasks that seem similar, you can improve during pair or code reviews. Don't let your work turn into a production line, because that will stagnate your career in the long run. Just ask yourself: Is there a more effective way to solve this same problem?
I believe all software developers enjoy finding the solution to a bug or seeing their code working in production. But if you don't feel those small doses of dopamine, you're probably stressed. Reevaluate your day and talk to your manager or team, because you may end up rushing things to reduce your workload.
While you must seek to improve your technique and learn about new tools or practices, you shouldn't let that turn into an excuse for procrastination. First focus on solving the problem at hand, ask peers for feedback, and only then consider how you could refactor your code in a better way.
Always discuss, define, and evaluate the scope of a task before starting it. Every developer must understand that not everything that's part of a task is vital for the solution to be delivered. Scope grows like grass. Align with your team to determine what's paramount in a task and what's not.
Humans are inherently prone to procrastination. There's little point fighting it. But you can use it to your advantage: Deliver something functional, get some feedback, and then include a break after these small development cycles. Don't stop randomly. And, if you're as anxious a developer as I am, turn off email and message notifications while programming.
Much of life is about balance, and it's no different here. It's a cliche, I know, but it's a cliche because it's true. Find the right balance by taking some time after each delivery to ask yourself: Did I learn something new? Am I feeling okay? Did I receive feedback that I'm on the right track?
Do this frequently and you'll be able to find the perfect tempo. You won't be rushing and you won't be dragging. You'll be able to calm your inner Fletcher voice.