Quotes from Andrew Hunt

The greatest of all weaknesses is the fear of appearing weak.

Don't be a slave to history. Don't let existing code dictate future code. All code can be replaced if it is no longer appropriate. Even within one program, don't let what you've already done constrain what you do next -- be ready to refactor... This decision may impact the project schedule. The assumption is that the impact will be less than the cost of /not/ making the change.

You Can't Write Perfect Software. Did that hurt? It shouldn't. Accept it as an axiom of life. Embrace it. Celebrate it. Because perfect software doesn't exist. No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first. And unless you accept this as a fact, you'll end up wasting time and energy chasing an impossible dream.

An investment in knowledge always pays the best interest.

Great software today is often preferable to perfect software tomorrow.

Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.

Kaizen" is a Japanese term that captures the concept of continuously making many small improvements.

The editor will be an extension of your hand; the keys will sing as they slice their way through text and thought.

Names are deeply meaningful to your brain, and misleading names add chaos to your code.

Don't gloss over a routine or piece of code involved in the bug because you "know" it works. Prove it. Prove it in this context, with this data, with these boundary conditions.

A good idea is an orphan without effective communication.

Every day, work to refine the skills you have and to add new tools to your repertoire.

We who cut mere stones must always be envisioning cathedrals. —Quarry worker's creed

Programmers are constantly in maintenance mode.

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

All software you write will be tested—if not by you and your team, then by the eventual users—so you might as well plan on testing it thoroughly.

The amount of surprise you feel when something goes wrong is directly proportional to the amount of trust and faith you have in the code being run.

If you work closely with your users, sharing their expectations and communicating what you're doing, then there will be few surprises when the project gets delivered. This is a BAD THING. Try to surprise your users. Not scare them, mind you, but /delight/ them.

One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today's civil engineers, while our craftsmanship will still be honored.

Just as in financial investing, you must invest in your knowledge portfolio regularly.

In addition, build dependencies may not be the same as test dependencies, and you may need separate hierarchies.

By coding at a higher level of abstraction, you are free to concentrate on solving domain problems, and can ignore petty implementation details.

maintaining good regression tests is the key to refactoring with confidence.

In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them.