#principles

Starting over isn’t failure—it’s a powerful development skill.

“Perfection” is time-bound, contextual, and subjective. Don’t chase it, or you will end up wasting your time.

If you can make an unknown situation look like one you already know how to handle, you can apply a well-known solution.

Software is an evolving entity, not a finished product. You need to edit your code to improve.

Don’t be a backseat driver, trying to take over the PR through comments.

The secret of good programming is to strip every statement to its cleanest components.

If you are not in a position to judge the result, consider not using AI, or ask for help.

Challenge yourself to come up with at least three solutions to problems that you encounter.

To build robust tests, each test should verify only what it needs.

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.