What should the engineering team of an early-stage startup care about?

The obvious answer: making the startup succeed. Making something people want, growing revenue, landing that big customer or the next funding round. But everyone in a startup cares about those things. What should engineering, specifically, care about, in order to make the startup succeed?

There’s loads of advice online about how to be effective founders, how to refine your business plan, how to validate your product thesis. But I haven’t found much written about effective engineering for early-stage startups. This is a shame, because for most startups, engineering is pretty important. It’s how you build your product - not to mention probably the majority of your headcount - so the way you go about it will affect the kind of product you build, and even the way your company operates.

When you do find advice about startup engineering, it tends to be limited to cursory admonishments to “move fast” and “get shit done”. These slogans aren’t wrong, but they are overly dismissive and reductive. They suggest that the way you do things doesn’t matter at all: anything which doesn’t look like immediate, visible progress must be a waste of time. This all but rules out introspection and improvement. It offers no help with answering questions like:

• Should we do code review?
• How do we prioritise maintenance work versus developing new features?
• Is it worth it to host our own infrastructure rather than using a cloud platform?

I’d like to suggest a more constructive theory of what an early-stage startup engineering team should care about, to help answer those kinds of questions.

As well as software, I also make cocktails. I got into it a few years ago, and by now it’s become a fully grown hobby, as evidenced by the entire kitchen shelf given over to bottles, and the ongoing invasion of my fridge by Mason jars of syrups and infused spirits. (Luckily my roommate considers that an acceptable price to pay for having an onsite bartender!) One question I often get asked is: “How do I get started making drinks at home?”

Home bartending is a very satisfying hobby, not least because you’re working with booze. It offers much of the creativity and sensuality of cooking, but with a fraction of the prep and cleanup work. And there’s a thrill to making a tasty, classy drink at home, for around $4 instead of $8 plus tip. And it doesn’t take much to get started. Your average kitchen is probably only missing four cheap pieces of equipment to make a wide variety of cocktails.

If you want to get started for yourself, the following are my recommendations for what to get. They also make a nice gift package: buy someone these, wrap them up as a set, and they’ve got four fewer excuses not to start mixing their own drinks.

If you work on a software product team, you’ve probably heard, or said, things like this:

• “The deadline is unreasonable, I can’t do a quality job in that time.”
• “Just ship it already, it doesn’t need to be perfect.”
• “Shipping quickly is the priority, so we don’t have time for testing and code review.”
• “We’ve been moving too fast recently and breaking too many things. We need to slow down and be more careful.”

These sorts of statements often come up when discussing schedule or scope. They frame the decision being made as a choice between two approaches: you can do it fast or do it well, but not both.

I believe that “speed vs quality” is a false choice. Each time we naïvely frame a decision this way, we do a disservice to ourselves and to our users. Sometimes the best way to run fast is to be confident in your footing.

Ever been in a conversation like this?

Engineer: “We’re going to have to cut feature X if we want to launch on time. It’ll take two months to build, but the deadline’s in a month.”

Product manager: “That’s a shame - our competitors have that feature. I thought you demoed it last week?”

Engineer: “That was just a prototype. We can’t ship it to users.”

Product manager: “Why not? It looks awesome, and it worked fine in the demo.”

Engineer: “Sure, it basically works, but the code is a mess, and we haven’t done any testing. It’s not ready to ship.”

Product manager: “It doesn’t have to be perfect. We need to move fast now - we can always fix it later.”

Engineer: “That’s what you said last time. Fine, we’ll ship the prototype… again. Don’t blame me when it breaks.”

Each person is trying to manage the risks they know about, and do what’s best for the business. Despite the best of intentions, these conversations can feel frustrating for both parties. It’s easy to feel like the other person doesn’t understand your concerns, or is stubbornly clinging to their own principles. The optimal decision is probably somewhere in the middle, but this kind of discussion rarely gets there.

I previously argued that we should stop using the word “quality” because it tends to polarise conversations. Now I want to offer an alternative. I propose that most conversations about schedule or scope would go better if they were framed instead around confidence.

I don’t like discussions about quality in software.

Don’t get me wrong. I want to build software I can be proud of. I want to be part of teams that build great products. I aspire to craftsmanship. What I dislike is the word “quality”, and how it tends to polarise conversations.

Quality is subjective

A lot of factors go into software quality. Good software is fast. Good software is maintainable, readable, scalable, and well tested. Good software has attractive UI and intuitive interactions. Good software has no bugs, or at least no serious bugs, or at least no bugs that our customer support team can’t work around.

In practice, quality means whatever you want it to mean. To a fan of unit testing, quality means investing in unit testing. To a designer, quality means beautiful screens and careful interaction design. To a customer support manager, quality means all bugs are documented and the serious ones have an ETA.

If you tell people that your estimates are higher than expected because you want to do a quality job, some of them will think you’re spending time refactoring and writing tests, and some will think you’re going pixel-by-pixel in Photoshop. Some of them will end up disappointed.

When people who program want to convey to others the joy and satisfaction we find in our craft, we often liken it to doing magic. The analogy evokes a sense of empowerment, possibility and freedom. But I think comparing programming to magic actually does unintended harm, because it has another connotation: that programming is a mystical ability, something you are born with, not something you can learn.

I want to get a lot more people programming, and I think we need a better analogy to get there.

What is programming like?

We in the software profession have done a terrible job of explaining to the public what it is that we do. Everyone has interacted with a teacher or a doctor. There are TV shows about lawyers, cops, even government officials. However warped our impression of their day-to-day, we can relate to these professions. TV depicts programmers as modern-day wizards, socially aloof, hacking into systems or bringing the new algorithm online just in time to stop the cyberterrorists — totally disconnected from people’s experience of the software they use every day. Software remains mysterious.

This isn’t just a problem for awkward “so, what do you do?” conversations at parties. I believe one reason why so many demographics are underrepresented in software is that unless you grew up with it, you’re unlikely to have the faintest idea what making software is actually like. Why would you strive — particularly against economic obstacles and systemic biases — to enter a profession you know nothing about?

Programming sucks

Inspired by a friend who couldn’t see what was so hard about programming, Peter Welch wrote a hilarious, heartfelt and all-too-true rant about what writing software is like. His title, and answer: “Programming Sucks”. The whole, long post is enjoyable reading, but here’s a representative excerpt:

Imagine joining an engineering team […] for a bridge in a major metropolitan area. […] The bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. […]

Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.

Rainbow uplighting.

This is an insightful analysis of Inception, but I think it doesn’t go far enough.

Spoilers below

(I wrote this as a response to an Ask Hacker News post about learning Vim, but I thought it deserved a life of its own.)

This is one of my favourite Vim features. Say you have the following code:

do_something_with(some + long * complicated * expression)
                           ^

Say your cursor is where the caret indicates. Typing ci) (“change inside parens”) in normal mode will:

• delete all the text between the two matching parens
• place you in insert mode with the cursor between the two (now adjacent) parens
• put the deleted text in the yank buffer so that p will paste it.

The use case here is obviously so you can assign a name to that long complicated expression. ci) is much easier than selecting it with the mouse, and keeps your hands on the keyboard where they belong ;)