The Art Of Unix Programming by Eric Raymond:

This book will attempt to capture the engineering wisdom and philosophy of the Unix community as it's applied today -- not merely as it has been written down in the past, but as a living "special transmission, outside the scriptures" passed from guru to guru. Accordingly, the book doesn't focus so much on "what" as on "why", showing the connection between Unix philosophy and practice through case studies in widely available open-source software.

...

My ambitions for this book are not small. With the assistance of the community, I hope to create a true classic here, a book that will speak with authority of and for for the Unix tradition -- and convey the essence of that tradition to the new generation of programmers who have grown up with Linux and the Web.

I thought this quote from Chapter 1: Philosophy Matters succinctly summarised my own philosophy to programming:

Rob Pike, one of the great early masters of C programming, offers a slightly different angle in [NoPiC]:

Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. (See Brooks p. 102.)

Rule 6. There is no Rule 6.