Prepare… but don’t get stuck. Start coding.
This is a story of analysis paralysis. You know, every developers antithesis of flow. You’ve been thinking about one feature or bug for so long, you see problems and concerns from every angle. You want to make sure that what you code is correct and accurate. This sounds just like writers block for an author.
If you have been analyzing a problem for awhile, you have probably become somewhat comfortable with the problem domain and the solutions you might try. But you just can’t quite decide which one with its many benefits and drawbacks you should implement.
When I find myself in this state, it is tempting to just keep on delving down the rabbit hole. There surely has to be the correct solution if I just keep looking for it. But you and I both know that that is just a sunk cost fallacy.
Instead, action is the most important step. You’ve thought, planned, and maybe even prepared a little. So just get started.
For me the simplest step, often has the largest impact.
So I like to get started by creating a new test class or adding a test case to an existing test class (especially if I’m just working on a bug). This is a low friction step to take that helps transition my mind from thinking/planning mode to implementation.
After my test is setup I can start in on that new feature or fixing the bug, with the added benefit of nearly instantaneous feedback for my changes. (However this isn’t a post about test driven development that might come later.)
If you’re not following test driven development, just create that class or function. Something small that will get you in your editor is just what you need to get over that developer inertia.
An interesting thing starts to happen
Just by getting started and working through the different implementations that I thought of, I start getting feedback on those ideas. Clarity comes through implementation.
I quickly realize that an implementation won’t work for a reason that I didn’t think of. Or perhaps something that I didn’t think could work actually starts to take shape and with a few small changes is exactly what I needed.
Don’t be afraid to get started
Action is the quickest way to get real world feedback on the ideas that you had during the preparation process.
It is important that you know and follow good design principles though. Take a little time along the way to properly separate concerns in your code.
Jump in and have some fun coding.
Kendell Fabricius is an Android developer at Ancestry, currently working on the Find a Grave app.
If you’re interested in joining Ancestry, we’re hiring! Feel free to check out our careers page for more info.
