Simplicity is brilliance.

Code should not be clever without good reason. If there is a simple way to accomplish something, use it.

Imagine that the future maintainer of your code is exhausted at the end of a long day and just wants to fix a bug and go home. This ternary operator saves two lines, but what if one of the values needs to be expanded?

Run tests before you commit.

If there are tests in your codebase, even if you don’t believe in them, you hurt your teammates if you break tests without good reason.

Software development is a craft. Would a cabinet maker replace a hinge without checking if the cabinet still opens?

Beware the process trap.

Not every failure requires a change in process. It should be acceptable to say, “I made a mistake. I didn’t communicate properly when scope crept, I didn’t ask for help early enough, I didn’t write tests, I didn’t understand exactly what the customer was asking for. I will do better next time.”

Not every failure can be fixed with a process change. You can lead a horse to water, but you can’t make a developer write a proper unit test. Even if you require 100% coverage.

Beware the metrics trap

100% unit test coverage can be useless. The tests can exercise every line of code without actually testing anything except implementation details. I have seen unit tests that exercise every method in a class and never check return values.

Removing the support phone number from the main site will reduce support requests by 90%. Congratulations. Now we’ve lost 20% of our business.