Making is More Important Than How You Make It

We get hung up on how we make something when we could just be making it.

Creations Shipped

What's really important is what you shipped. How you accomplished this feat is influential in getting the thing shipped, sure. But the "how" can also get in the way.

When taught silver-smithing by his mom, Richard Garriott wasn't phased that he didn't know how to make a clasp to complete a necklace. He finished the silver snake pendant anyway, and he's worn it since age 11. He said:

It is permanently attached because, since it was the first thing I ever made, I didn't know how to make a clasp. A clasp is actually a fairly advanced item. I've still never made one.

He's now 56, and the silver snake is a prized possession. It's worked well so far, right?

Doing Nothing

New developers get stuck doing nothing. We want someone to show us the "right" way to do it. We fret that until this is revealed, the code we ship will not be worthy.

Old developers get stuck doing nothing. We wax poetic about patterns. We discuss at length the best or most appropriate methods, endlessly weighing pros and cons.

This is meta work. It's easy to get stuck here. It's easy to procrastinate here. I deal with this every morning.

Getting There

Just start! Through moving, you'll find -- you'll make! -- a way to enjoy the journey.

Don't be a Bilbo. If you too stay home, stewing with your ring, you too may soon be scraped over too much bread.

We Have Preferences

It's no surprise that developers are fraught with opinions. These opinions are useful to us at times. We should allow them and follow them inasmuch as they enable our productivity. We should distance ourselves from them inasmuch as they prevent us from acting.

When using our opinions to categorize languages, conventions, frameworks patterns and other preferences to our liking and supposed betterment, we need not impose them on others, thus slowing their momentum.

Sharing? Yes, when appropriate. Imposing? Who would actually do that? But shared opinions can start to feel like impositions given the degree of force, length, or type of attitude used in the sharing.

I recently attended a conference where callback hell, a name given to nested callbacks in JavaScript code, was mentioned. The speaker mused he wished he could put this code in a "cone of shame". In my opinion, there's nothing inherently shameful about this code shape. It only becomes a problem when the developer or user feels some bad effect. Then you can refactor it away into a better construct. Why stigmatize it inherently?

Making and Doing

We could spend more time making things. We can stop bikeshedding with ourselves or others and get to work.

What do you do to get out of analysis paralysis and make the thing you want?