This is not a definitive list, just a collection of observations of effective and efficient software engineering teams.

Another excellent list of lessons learned writing software can be found in Things I Learnt The Hard Way (in 30 Years of Software Development).

No waterfalls

Software development can be particularly prone to the waterfall method. Avoid it as much as possible. There is something religious about this method, on the 7th day the engineer created the code.

In nature, the equivalent would be tadpoles laying eggs, millions of years ago, and the next day a fully formed human being walking out of the water. Evolution is an incremental process, almost all engineering is as well. No ‘Divine Coding’.

Code reviews

This can be difficult, for people not accustomed to it, as it can temporarily bruise the ego. Get over yourself.

Having your code reviewed will catch bugs you’ve become blind to, having looked at the problem for too long. It will also validate or test your assumptions.

Most importantly, even if your code is always perfect, it helps other engineers on your team learn; a technique they might not know, how team practices are done (especially for new team members), and stay up to date with how the system is implemented.

Keep changelists small

Every changelist should be concise and manageable. If you’re following the advice above, every changelist will be reviewed by at least one person. Large changelists are exponentially more difficult to review the larger they get. Asking for a review is asking a teammate for their time, be respectful of that.

Don’t break the build

If you can break the product without breaking the build, add more tests, ideally as pre-commits.

Simplest case first

If a teammate suggests replacing your brilliant, never before seen, solution to a problem, with a simple, existing, language native feature/package, they’re right, 99% of the time.

Lint everything

Decide on a code formatting style and always enforce it. Reading a codebase without consistent style is like reading Beowulf, as rewritten by Chaucer, and proofread by Shakespeare.

No martyrs

Working 120 hour weeks to deliver is not heroic. You either failed to plan your time appropriately or wildly misestimated the time to complete the work. In both cases, you’re doing a disservice to your team and risking quality. There’s a reason why truck drivers and pilots aren’t allowed to work more than a consecutive number of hours per day.

Don’t micro manage

Hire smart people you can find, and guide them.

---

Notebook