Best Practices

http://eatingbees.brokentoys.org/2008/06/30/best-practices-part-2/

I’m sure some of these will seem naive or cookie-obvious. Maybe a different few to each reader.

Read books. The Pragmatic Programmer, Mythical Man Month, Refactoring. Learn a new language, methodology or framework every quarter.

Cycle people, don’t let them overspecialise or silo. You’ll get broader more useful employees. Their CVs will look nice, which should compensate for the extra challenge. Maintainability will be closer to the hearts of every developer. Consider how resilient your schedule is to a double-decker (”bus impedance”).

Overtime takes a toll. After eight hours you are not doing your best work. An overtime culture will cause employee throughput, fragmented design and many bugs reaching production. I bet Tseric put a lot of hours in. Having said that, a release push won’t kill you. Just not constantly.

Users are great at describing problems, not always so great at picking solutions (not that you should ignore those). Listen, bring in requirements, write usecases, iterate, run the tests, release, reexamine. Anyone should envy Blizzard the Elitist Jerks forum.

Admit mistakes. Confirmation bias is the root of evil. Identify the drivers and facts, don’t allow elegance as a driver but do allow maintainability and flexibiliity.
Tackle risk early, do design carefully but don’t gold plate. Identify the most likely causes of change and allow for those, instead of making the most general solution possible.

Keep people motivate through attention and constructive feedback. Bored/frustrated people cause problems, responsibility can transform them.
Keep visibility through the management chain, ensure those you lead understand your drivers clearly.
When appropriate, praise employees cc your manager. Help overcome challenges privately.
Ask employees to mail you about their successes or those who especially helped them and keep a record.

Don’t use stack ranking for more than two years.