Here is something a lot of people struggle with: given a vague idea or project, how do you move towards shaping something concrete out of it? For Vivek Haldar, a software developer at Google, the solution comes in four parts.

All projects start with a big blob of vagueness. Folks who create the most concreteness out of that are the ones who have the biggest impact. I'm learning how to approach this, but I still feel like a non-swimmer in the shallow end with lifesavers. I've learned a little, by personal experience, and by observation.

This is not design yet. These are high-level ideas that put constraints on the design space. For example, GMail chose the principle that search should be the primary email navigation mechanism. Think long and hard about these, because these principles will be baked into your code and your system in a way that can't be "refactored" away later. This is where wizards (i.e. very senior battle-hardened engineers) can help. Often, choosing these is a matter of taste and design and conceptual integrity. It might sound wishy-washy but it's hard. Document these well. This is your manifesto.

Once you've got a spine, you've got to add a few more bones.

This usually takes the form of a prototype, or a walking skeleton. It might have huge swaths of functionality missing. It might have serious shortcomings. It might be ugly. It might be slow. But that's OK. Think of this as the spec of sand around which a pearl is formed. What is important is that it be concrete, and growable.

It needs to be concrete and tangible. Something you can show and demo and people can play with and talk about and criticize get excited about. People rarely get excited about design documents. They frequently get excited about working prototypes, even when they come with massive this-will-break-on-you disclaimers.

Your prototype should not be a dead end. You should be able to put work into it and make it incrementally better. Adding something new or changing it should not require you to build a new one from scratch. In other words, it should support iteration. There may come a point when you have to throw one (or more away), but ideally that happens only when the prototype has brought you to a major insight that invalidates some of your basic assumptions. Even then, it would have served its purpose. And even then, you need something that will get you to that point quickly.

In other words, focus on learning and fixing, continuously and quickly. Don't sweat too much about getting it right. Chances are, your idea of right won't be the right one. Chances are that most other peoples' idea of right won't be either. Only by having something real to criticize and learn from will everyone figure out what right is.

Build, fail, fixand repeat.

On Vagueness | Vivek Haldar

Read more from the original source:
How I Turn Vague Ideas Into Tangible Goals [Success]