Since we’re two people who create things professionally, my husband and I like talking about the process of creating things almost more than anything else.

If we worked in the same discipline, this might be a recipe for disaster, but because he’s a programmer and I’m a writer, we both have enough ignorance to nod dumbly when the other has a strong opinion about a religious debate in our respective fields.

Functional languages are more elegant? Fine.
Oxford commas are nonnegotiable? Okay.
Company X’s API is too corrupt for the deepest layer of hell? Right on.

Recently, over breakfast he shared with me a post from Programming in the 21st Century.  The post is succinct enough that it’s worth reading the entire thing, but the gist of what that we were concerned with is this: 

I may be looking down my snooty language dilettante nose at them, yes, but from a get-things-done productivity point of view I’m seriously impressed. There’s a continuous stream of games written in BlitzMax, games that are more than just retro-remakes of 8-bit relics, from people with very little programming experience. … I’ve written before about how you can count the number of games written in a purely functional style on one hand. Is it that language tinkerers are less concerned about writing real applications? That they know you can solve any problem with focused grunt work, but it’s not interesting to them? That the spark and newness of a different language is its own reward? Either way, the BASIC programmers win when it comes down to getting projects finished.

After describing the situation to me, my husband asked, “Is there anything like that in your field?” I thought of the never ending war between genre fiction and literary fiction, and it was all I could do not to burst out laughing and disturb the stranger woman who’d decided to share our table with us. (Long story.)

The thing that these two controversies share is a debate over how much attention to craft is necessary.

Of course, there are extremes. If a book is illegible or code doesn’t run, it obviously needs more craft, and overly particular creators need to let go eventually or end up like Emily Dickinson. But there’s a lot of room between those two extremes.

Both my husband and I fall into the never ship category—at least, as far as we can get away with it, so the question for us is how neurotic we can be and still get away with it.

What we figured out is that each project requires balancing obligations to three groups of people.**

The three groups of people who matter.

1. Users/Readers: Be nice to your users. This sounds incredibly basic, but I’ve lost track of how many Android apps have made me tip my head sideways because they don’t rotate when I slide out my keyboard. Making your customers suffer is bad.

2. Co-workers/Editors: For writers, there is no division between the book and the words that make up the book. Bad prose will at best give a copy editor a nervous breakdown, but programmers often write code that their users will never see. Sometimes, no one but the programmer who wrote it will ever see it, so the quality of the code doesn’t matter (as much. See below.) but if other programmers are involved, you don’t want to write code that will make someone (or the spouse that’s sleeping in an empty bed while the poor sap untangles your spaghetti code) want to light your hair on fire.

3. Future self: Part of growing as a creator is transcending old work, so it’s impossible to really be kind to your future self, but there are obvious things you can do to avoid your own future suffering. Recently, I made the mistake of writing out a novella by hand in a notebook. It didn’t feel like a mistake at the time because I was only writing a page or two a day, but I am now forced to decipher about 50,000 words of my horrific handwriting and type out a really crummy first draft before I can even start revising. Bad. Bad idea.

Making our work a pleasant experience for all three groups of people is the ideal, but there’s also the matter of time. Often this question is settled by someone else imposing a deadline (or an empty wallet imposing a deadline), but when there is no outside influence, it’s up to the creator to answer the question: How much time can you justify spending on this work?

*Which of these is most important depends entirely on the project. The order I have written isn’t intended to indicate priority.