Skip to content

Note

This is an unfinished draft post.

get it down. get it right. get it good.

I have a simple workflow that I use to build something new. Others would use crawl, walk, run.

get it down

Step one is just getting it down. It doesn't have to be right. It won't be right, even if you spent 10x the time on it.

Just get it down. Pseudo-code, going analog, wireframes. Whatever. Just get it down.

get it right

Getting it right means getting the output correct. Not just is it working but is it generating the correct output?

This will take quite a bit of time. What are the problem boundaries? What are the limits on input? How can you reasonably account for variance, or updates, on them?

get it good

This is the fun part. Tinker and tweak. Can you get it working faster? More completely? More tightly couple outputs from one method to inputs of another?

This is part of learning your craft. Understanding the tradeoffs of building for the sake of building, versus honing your skillset. Get it good enough for its intended purpose, honing your skillset along the way.

But don't get it good for its own sake. There are other problems to solve, and other methods to learn.