Article summary
The hardest part is always getting started. That’s equally true with blog posts (like this one!) and code, and most of life, really. I recently struggled with this on a project.
The feature was to allow users to mark up a chart, and I didn’t know what specific interactions we wanted to create. How should the user create new annotations? What chart interactions does our charting library expose, anyway? Not knowing what the chart could do made it hard to design the feature, but not knowing how the feature was going to work made it hard to decide what to include in the chart.
Fake the Data
I was able to break that unfortunately circular loop by just hardcoding some data to start with. In this case, I just stubbed in a simple, plain-old C# class. I made it return some starting values so that I had something to put on the chart.
Another way to do this is to insert records directly into your database. I’ve found this approach very helpful in the past. The big win here is that you can jump into the middle of the user workflow.
I find it’s often useful to understand how the data is displayed and how people interact with it before I write the forms to add it. Often, once I can see the data, I discover that I’ve structured things wrong. By being able to play with the data early, I was able to avoid spending a lot of time building an incorrect creation workflow.
Use a Spike
The above is really a special case of just writing a spike. A “spike” is a quick prototype you write to help learn. These are usually written without tests or investing in high-quality code, intended as a throwaway.
It serves the same purpose: let’s just try something so that we can learn about how our tools work better. After that we’ll have a better idea of what we can do and how to structure things.
Draw a Picture
If you’re not yet ready to write code, try drawing a picture. Of course, what picture you draw depends on the problem you’re trying to solve, but I suggest that you start off with something vague. Pencils and paper are cheap, so starting at a high level and then either refining or making new drawings is easy.
And after that, get more specific. This doesn’t have to be code, but you probably should be able to point to some bubble on your digram and say, “This goes in the XYZ class.” This way, your diagram can become a guide to how to implement your new feature.
“Draw a picture” seems fairly trivial, but I wanted to mention it explicitly because, in the time of COVID work-from-home, I’ve found that I don’t reach for sketching nearly as much because it’s harder to share the diagram with my coworkers. I think it’s well worth pushing through that anyway and making good use of webcams or collaborative tools like Miro.
“Rubber Duck” It
Or alternatively, try talking to yourself. I’ve found that it’s very useful to try to put the problem into words. Why are you having a hard time getting started? Just start talking. I suggest getting away from the computer, or paper, or anything at all. Just talk. I find that the formality of typing makes it much harder to start when I could begin to describe the problem easily out loud.
How do you find a place to start when things are unclear or ambiguous?