Various notes to myself, about being effective.
1. allow for some slop in the machinery.
Being intolerant of error or imprecision in others (or in one's self) lowers effectiveness. To err is human.
2. strive for rightness, but don't beat people over the head with it
Related - being right doesn't always mean you're effective. And being right in a way that pisses off people around you (e.g. right in a pedantic sense) lowers your effectiveness when people disengage from you. Often as geeks we assume that our individual contribution is really all that matters; but on most projects, our contribution as a member of a larger hive is as important (maybe more so, on some projects).
3. furious activity is not a substitute for genuine progress.
Charging full speed down the wrong road, doesn't lead to being effective. The cure (if there is one) is to understand the project's goals well.
4. but at some point you need to stop staring at your navel.
The flip side of [3], is that you also must to realize when you need to actually deliver something (as opposed to spending more time in "understanding the problem" better).
5. consistently avoiding risk is a net loss.
If you're in a position where covering your ass (reducing project risks that you could be blamed for) is more important than delivering running code on time, it's probably a good time to find a different project to work on.
6. listen to customers.
It's a good thing to listen to customers. To listen, of course, implies you have a relationship with customers in the first place. "I don't do customer facing stuff" is a good way to tell everybody "I'm obsolete."
7. ideas are good. implementable ideas are vastly better.
No one will pay me to come up with ideas that I have little or no chance of implementing. Work out a rough sense of what can actually be built, or demo'd, and find customers who would be willing to build on that.
