#principles

Mocks encode our assumptions, which might differ from reality.

Treat every support issue as a bug. Then fix that bug!

Follow the original task for as long as it takes to complete it. Keep a list of everything else.

The more you add, the harder it becomes to understand.

Remove everything that has no relevance to the design.

The best design does what it needs to, and no more.

I believe smaller solutions lead to faster completion and higher quality.

Is customer satisfaction or commercial success the ultimate measurement of the outcome of my work? Not for me.

Check code committed to version control for quality, and the code base will thank you.

To make something easy to understand, its parts should be at the same level of abstraction.

If you don’t know what message to write, it was too long since you last committed.

Has the backlog become longer than you can finish within a reasonable time frame?

Only successful software becomes legacy, the rest is abandoned.

Developers sometimes underestimate the importance of doing things just for fun.

I put stuff with too much uncertainty in a box and don’t think about it until I know more.

It’s easy to think that large results require large changes. That is not necessarily true.

How come people never worry about whether technology scales down to a low number?

Even though you feel completely confident, there is always a slight chance you are wrong.

A question which can help you both prioritize more effectively and design better systems.

While it may sound counter-intuitive, creativity often benefits from constraints.

Teaching is a great way to determine if you truly understand a subject.

Whenever you feel smart, take a step back and think about why.

When you make an exception from a rule, you make the whole system harder to learn.

In technology choices, sometimes “boring” can be better than “interesting”.

For every bug you fix there should be an automated test which will fail if the bug reappears.