On Starting Over

I used to have a bad habit when working alone: I’d start a feature, begin doubting my approach, throw away my work, and start over from scratch. Sometimes more than once. The result? Wasted energy, abandoned code, confusion about what I had and hadn’t implemented, and repetitive rework. This post is a collection of thoughts on this practice.

They are:

• It’s okay to start over, for the right reasons
• Prioritize getting it working
• Save your work
• When getting help, don’t show up empty-handed

It’s Okay to Start Over

Code Retreats is a programming community that encourages throwing away first drafts. Starting over can be helpful when you’re learning a new technique or trying to improve.

If something doesn’t feel right, you can throw it away! You don’t have to keep trying something that isn’t working. Persistent not-working is often a valuable indicator that an approach is flawed.

Get It Working

Conversely, I’ve argued that when building, the best thing you can do is get it working, then make it pretty and well-factored.

For me, this means getting the interactions working, and then applying the design and cleaning up.

Save Your Work

When I’m building something tenuous, and I get any part of it working, I try to commit. Get it under version control, push it to a remote, and start working on the next piece of the puzzle. Committing regularly gives me a feeling of momentum that’s encouraging and addictive.

When you’re feeling the urge to start over, this could save you a lot of work: create a well-named branch, atomically commit your changes, and push to the remote. Make sure the branch has a memorable name, like spike/postgres-port-v1 or stuck-installing-graphql. So you can remember it!

Then, break down your changes into small, understandable commits like: “Widen button container” or “Add new route.” Finally, push to your remote.

Many times, when I succeed at building something on my second or third attempt, I realize some of those commits from a previous attempt would be useful to have again. When I’ve saved them, and they’re well-named and small, I can cherry-pick them onto my current branch.

$ git cherry-pick <sha-of-useful-commit>

Don’t Show Up Empty-Handed

When you’re stuck and ask for help, it’s always better to bring something to work with. Senior people who are helping love to critique but have less patience being asked to start from scratch.

Even if they start your pairing session with “this is bad: let’s start over”, you’re showing that you’ve done some work and aren’t waiting to be rescued.

And with an existing implementation, your pair might be able to teach you something or more quickly arrive at the right answer by seeing your wrong one. As they say, “the fastest way to get the right answer to a question is to post the wrong answer on the internet.”

Summary

Follow these tips and ship more software:

• It’s okay to start over, for the right reasons
• Prioritize getting it working
• Save your work
• When getting help, don’t show up empty-handed

• Ideas