Wherein I lay out a manifesto I’ve been working on for a few months.

A Developer’s Articles of Faith

  • The computer is never wrong. If something is amiss, it’s because you caused it to be so. Seek understanding through iterative simplification, and rigorous delineation of scope. DO ONLY WHAT YOU CAN UNDERSTAND IN ONE SITTING, IN ONE SITTING
  • When in doubt, your computer is better at a given, well defined, repeatable task than you are. Embrace repeatability, consistency, and automation in your tooling and testing. CLEANLINESS IS NEXT TO GODLINESS
  • The marginal cost of CPU cycles is zero. The marginal cost of a developer’s time and sanity is quite a bit more. Err on the side of making your life easier at the expense of the computer’s. UNDERSTAND COMPUTERS, BUT DESIGN FOR PEOPLE (corollary: PREMATURE OPTIMIZATION IS THE ROOT OF ALL EVIL)
  • If you know what you’re doing, you will probably never understand what you’re doing right now better than you do right now. The cognitive context lost when you come back to a task at a later date is large, and can easily turn into your deepest effort drain. Where possible, leave your work at a natural conclusion, with as many low level ends tied up as possible. Where loose ends exist, track them mercilessly. LOOSE ENDS, LEFT UNADDRESSED, WILL SINK YOU
  • The counter-case: if you don’t know what you’re doing right now, give yourself time (or seek out help) to let the context sink in; nobody fires on all cylinders all the time. An important decision made early and wrongly is usually vastly more expensive than one made late but correctly (within reason, of course). IT’S OK (HEALTHY, EVEN) TO BE BEATEN, BUT ONLY IF YOU ADMIT IT

Organizational Maxims (an addendum)

  • Give developers the tools and environment they need. If anything; IT, HR, your office layout etc, aren’t helping, then they’re a liability. Full stop. A GREAT WORK ENVIRONMENT MAY NOT LEAD TO TEH AWESOME, BUT A SHITTY ONE WILL CERTAINLY LEAD TO FAILURE
  • Accept that you’ll be wrong a good portion of the time, and build your processes around that. Shamelessly solicit feedback from the bottom to the top; make nobody too ashamed or scared to say anything to anyone (aside: if your people aren’t willing to step up to that, you’ve got the wrong people). DO NOT STRATEGIZE / LEAD / DECIDE IN A BUBBLE (secondary lesson: EXPECT HINDSIGHT TO KICK YOUR ASS)
  • Do not tolerate the thin end of the wedge. Good developers are fickle beasts, and have an exceedingly low tolerance for anything that isn’t on their terms (aside: if your people roll over and take obvious crap, then – again – you’ve got the wrong people). BULLSHIT IS THE KRYPTONITE OF GETTING COOL THINGS DONE