I've been working on an idea that a software manager's job is to promote the fundamentals of software design, but I realized it was difficult to discuss the fundamentals with out stating some of them, so I started a list of some of concepts I find important.
In retrospect, I should have noted these a long time ago, as it would have helped focus my work as a full time developer.
So here's the list:
- Respect your profession. Creation is a noble pursuit.
- Impress your users, not other developers. Developers are impossible to impress, so it is futile.
- Most software projects fail: Don't underestimate the 'easy' stuff.
- Use the standard library for your language.
- KISS: Don't make the 'easy' stuff harder than it has to be.
- Likewise, don't solve problems you don't have or create problems needlessly.
- Consider boundary conditions.
- Step through your code in the debugger before you check it in.
- Don't repeat yourself.
- Know your collections. Many languages use non-standard names, so read the docs.
- "Premature optimization is the root of all evil", Donald Knuth, 'nuff said
- Shorter functions are better than long ones.
- Less code is better than more code.
- But don't reduce code at the cost of readability (especially Perl programmers :))
- Use Inversion of Control to reduce dependencies and coupling.
- Class inheritance (not interface inheritance) increases coupling (aka subclass coupling). Prefer aggregation and IOC which decrease coupling.
- Beware of code that doesn't contain actual application or system logic.
- Long variable names are ok.
- Narrow variable scope is preferable to broad variable scope.
- Do not use exceptions to implement application logic. The application should not throw and catch exceptions when it is behaving correctly or as expected.
- Concurrency is almost impossible to get correct. See: When to use threads
- Unless your product is for developers, reduce meta programming.
- Likewise: your language is a tool. It is a means to an end and not an end in and of itself. Nor is it a religion.
- If your tools are your religion, practice at home. Be a professional agnostic.
- In production code, prefer proven (known to be used in production systems over a reasonable amount of time) technology over experimental.
- Maintain a side project for experimentation.