Sage introduced me to this saying.  I think he actually butchered it a little but I like his version better. Looks like the source was the Unix programmer Kent Beck.

This is the simplified mantra for getting some code done. It is easy enough to remember and yet still helps as a guiding principal.

For me the reason this is so powerful is that there are a lot of competing philosophies. We are working with a medium that can do anything. By that I mean software. Given a little bit of time and some code you can make virtual worlds, control cars, control phone, or you can just keep writing todo lists in every programming language imaginable.  It is quite an overwhelming experience really. If you have all this power at your fingertips then what stops you from doing something amazing? What comes out is that it is your own personal limitations that keep you from being amazing.

I don’t think this is entirely fair since the ability to create has been amplified by technology. So don’t underestimate the effect that has on a person. It is probably like that of an author with writer's block staring at his typewriter thinking, “I can create any world on this white paper, so what is wrong with me, think, think, think, think….”

In software land you get that “analysis paralysis” and that bubbles into the imposter syndrome. As a developer it is easy to get caught up in the epic amounts of code, languages, and philosophies. A simple mantra like this is almost a beacon of light that helps you cut through the fog and get on with something.

Start with what will work. Ask yourself the questions “What is the simplest thing you could do that could possibly work?” then time box that and do it. Maybe try out the Pomodoro Technique which is just a fancy way of saying set an oven timer. That will help you focus past the first part.

After that make a test and prove that what you wrote works.  Yes, yes, yes, I know in true TDD you should write the test first. But, when you need to feel like you are moving forward I would advise you write from your heart. If you feel a boost of encouragement from seeing code work do that first. Of course you are a good developer and you will switch to the TDD approach but at the beginning of the project when nothing is written it is more important to feel joy because that is the only thing that is going to push you forward. Apathy is your biggest enemy so build what excites you first.

Once you get that bit of code and it has a way for a user to interact, look at it as a designer and try to figure out what you can remove from the UI you just created. Go reductionist and question everything. Show it to people and see how they use it. This is the “make it pretty phase”.

Finally, you are going to need to make it work fast and that is when the real puzzle solving engineering brain kicks in. Build your services, your load balancers, use map reduce. Just don’t try to do this first. Donald Knuth said “Preemptive Optimization is the root of all evil”, I agree with this so do it last if you ever do it at all.