A few of my favourites; > An organization that treats its programmers as morons will soon have programmers that are willing and able to act like morons only.

A few of my favourites; > An organization that treats its programmers as morons will soon have programmers that are willing and able to act like morons only. In a broader sense what it implies is that companies should not make a Programmer's job onerous (in any dimension) to the point that the "joy" is gone from the doing of the activity itself. Thus Reports/Meetings/Processes/Testing/etc. should all be modulated/balanced based on needs/project and not because it is the latest fad. Managers should really really heed this. > Far too often, 'software engineering' is neither engineering nor about software This is a follow-on from the above. > Any problem in computer science can be solved with another layer of indirection. I have also heard this attributed to Andy Koenig. > My ideal of program design is to represent the concepts of the application domain directly in code. That way, if you understand the application domain, you understand the code and vice versa. This is how i learnt the techniques of designing in C++ from the early days i.e. from "Barton and Nackman's Scientific and Engineering C++" and "James Coplien's Multi-paradigm design for C++". This is fundamental to problem-solving itself and hence in any job it is of utmost importance to understand the domain i.e. Why and What is being done rather than the How. > Legacy code' often differs from its suggested alternative by actually working and scaling. Very very true. This is why i dismiss people who come in and start saying "everything must be rewritten" without spending time studying and learning about the existing system.