Three golden rules of a software team

Here are my three golden rules/principles/guidelines to building good software as a team:

Good enough

Write code that's good enough. It doesn't have to be blazingly fast or have theoretically perfect optimizations. It just has to work. There's never any other requirement.


It doesn't even really need to be fast except on the frontend. If you can do something in 16 milliseconds then you can maintain 60 frames per second. Computers can do a lot of things in 16 milliseconds these days.

The ideal case for your code is for you to never look at it again as soon as possible.

Finally, be good enough. Chasing ever-higher standards can lead tech teams to make really silly decisions.

Document everything

Write everything down. Somewhere. In whatever form works for you and your team.

The best documentation is right there with the thing you're working on. Comments in code are just great. Type systems and tests too are documentation— one of expected inputs and one of expected outputs.

Using something, anything, to help make your code make more sense in some way benefits the next person who reads the code. Much of the time, that person will be you.

Power sucks

Power games and office politics shouldn't be driving your tech stack.

Everybody loves a good tech rivalry (except Rails guys, the snobs!) but nobody has a good time when tech decisions tear a team apart.

Perhaps even worse than the turf-war style office politics are when one person unilaterally makes technology decisions for the team, with no (or ignored) input.

In short: Power sucks. At least when it starts poisoning a team's choices. We're a profession that, for better or worse, cares deeply about the tools we use.

We also care about the stuff we work on, so this rule ends up applying to product roadmap and even UX decisions.