Axioms

There are a few convenient mental tools that have improved the things I make. Software Engineering truly is a mental task, and maintaining your mental process is as important as any other process. Here I'll collect the axioms I find most helpful and important.

Occam's Razor

Entities must not be multiplied beyond necessity.

Build it 3 times

When I make something new, I often learn enough building the first iteration that I can significantly improve by building the thing again. This is true for the second iteration as well, and can bring to light more long term concerns than the unstable first iteration. The 3rd iteration is often when things really start to take shape; I keep more from the 2nd than I do from the 1st, and can be more confident that I have a good foundation.

Make it work then make it right

Sometimes in software engineering I feel there's a want to make sure everything is perfect before development starts, to address every possible concern so that there are absolutely no unknowns, and implementation follows instruction from design. In reality, it's very difficult to make the thing perfect in one attempt, and software is quite malleable. It's true that there are concerns and requirements that can't be ignored, but most things can be improved after initial implementation. If you spend your time mired in the design stage, you may find your opportunity to build something has passed you by.

Prototype minima

When prototyping, make sure to build the smallest possible experiment to avoid wasting your time making something that might not pan out.

IKEA Effect, not invented here, escalation of commitment

All three of these involve making sure you're not too attached to your own work. Sometimes it's just not that great, or needs new direction, or would be better replaced by someone else's solution. I've seen so many pieces of software (my own projects included) that become unmaintainable because of either unnecessarily bespoke code, or insistence on a particular solution.

The IKEA Effect

The tendency to place higher value in things one had a hand in creating.

Not invented here

The tendency to avoid things you didn't have a hand in creating, or is outside your cultural norm.

Escalation of commitment

The tendency for people to continually invest time, effort and resources in something that may not ever produce good outcomes, partly motivated by anxiety about return on what has already been invested.

Coupling is a property of the problem not the solution

There's a lot of talk in the software industry about what methodology to use when structuring large software projects, and it often revolves around coupling style. Do you make a monolith or use microservices? Do you use MVC or something else? In reality it's usually a mix, and this is because organization isn't some universal rule, it's defined by the problem being solved.

Better tools make better work

Often, taking the time to find or make the right tool for the job can improve your workflow dramatically, and keep you happy and sane. We shouldn't put up with subpar tooling.