Closely related to tests are monitoring the production environment. Every time there was an incident and it wasn't visible at the source (whether it was found due to customers complaining or conversion rates dropping), no matter how unlikely it seems for it to happen again (we made a unit test so we should be safe now, right?), always monitor for it.

This might be my ops side speaking, but often undesired behavior aren't outright bugs (a value not being set is expected, but that empty value led to an empty template which led to the frontend framework not reading an event might not be), the same class of issues can be monitored for. This is a combination of logging and monitoring, of both events (where the application checks for unexpected results) and of state (where something external to the application reacts to for example things like active users without login sessions).

> Test features, not units (the time spent vs time saved is meh).

Might I add that testing for security should be a priority. Some agile shops move so fast because they aren’t worried about small bugs. All security issues are bugs and often they are ones that aren’t along normal feature usage.

> Keep the poor soul in mind that has to go through your code in 3 years time. That could be you yourself ;-)

Isn't that why people move company every few years :D

Complaining about crap legacy code is easier when it hasn't got your name at the top

Well said, I'm a big fan of the pragmatic approach as well. But, for some reason we (people generally, including myself often) need to overcomplicate.

> Never go over-fancy with inheritance and whatnot.

So much this.

Personally, I've grown to prefer object composition for bucketing and sharing reusable functionality across classes over the years. Testing with mocks becomes far easier, and it really seems to simplify the mental model.

Nowadays, I only use inheritance when working with generics and generalizable interfaces.