How One Google Developer Turned Vague Ideas Into Tangible Goals

A lot of people struggle with this: given a vague idea or project, how do you move towards making something concrete out of it? For Vivek Haldar, a software developer at Google, the solution came 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.

Formulate principles that will guide the solution

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 (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.

Find one concrete idea and build on it

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 criticise and 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.

Make sure it’s growable

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.

Speed of iteration almost always beats quality of iteration

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 criticise and learn from will everyone figure out what right is.

Build, fail, fix — and repeat.

On Vagueness [Vivek Haldar]

Vivek Haldar writes software for Google. Many years ago, he was a PhD student at the University of California, Irvine (and even wrote some papers). Subscribe to his RSS feed and follow him on Twitter.