I want to keep these, and elaborate on them, but they were cluttering up my personal README, so I now want to create separate issues (and eventually blog posts or similar) for each or them.
Other Ideas
These aren't "principles", per se, at least not yet, but worth thinking about how they fit into the principles above
Favor Outcomes over Output
Detail TBD - Still working on this one.
Crawl, Walk, Run
This is almost certainly a big part of "Slow is Smooth and Smooth is Fast", but it's also bigger than that and deserves some detail. Somewhere. Problably not in this README.
See One, Do One, Teach One.
Similar in nature to "Crawl, Walk, Run" this one is possibly a PART of "Slow is Smooth and Smooth is Fast", but probably not as closely related. I get a lot of mileage out of it as a learning technique, so I should probably write about it and link to it from here.
Planning is Essential; Plans are Not
- Failing to plan is planning to fail - Alan Lakein
- A goal without a plan is just a wish - Antoine de Saint-Exupéry
- Plans are useless, but planning is essential - Dwight D. Eisenhower
- Everybody has a plan 'till they get punched in the mouth - Mike Tyson
- No plan survives first contact with the enemy - Helmuth von Moltke the Elder
- Counterpoint? Or related but orthognal concept?: A good plan violently executed now is better than a perfect plan executed next week.
Don't Put it Down, Put it Away
This saying is really the bare minimum, or a prerequisite of "Clean As You Go" - where "Clean As You Go" would be applied to gradually reduce tech debt, "Don't Put it Down, Put it Away" is intended to avoid certain kinds of tech debt and other waste in the first place - when you're done with something (even if it's imperfect), don't expect to pick it up again in the near term.
Stop Starting and Start Finishing
Essentially the same idea as "Don't Put it Down, Put it Away" - and the trick in both cases is not to let perfectionism and scope creep get in the way of declaring victory, finishing, and putting it away.
Demos and Dogfood
Note: Does this roll up into "Build in Public"?
The most relevant work product artifact is working code in production. Everything else is overhead. Some overhead in the form of other deliverables and written artifacts may be necessary for principle, legal, or other reasons, and may indeed be necessary to GET working code into production, but if there's no eventual working code in production: those turn to waste. By demoing frequently and broadly, and by eating our down dogfood, we emphasize this intent to go to production, tighten feedback loops, and reduce wasted overhead.
Other Management-Specific Ideas
This is the wrong document for these, and I'll move them when I find a better place. Clearly these are also a work in progress.
Catch Them Doing Something Right
Never miss an opporunity to celebrate a win. I don't know what the right ratio is between celebratory feedback and course-correcting feedback, but make it higher. Relatedly, celebrate in public, but keep corrective feedback and discussions private. Use judgement to decide public or private setting for puzzling or neutral feedback and related discussions. But PUBLICLY CELEBRATE ALL THE WINS.
Mitigate Risks. But Take Them
Risk exists to some degree in nearly every decision, action, or inaction, and by itself is not a reason to avoid making decisions and taking action -- but it also can't be ignored. Identify and communicate risks, weigh the potential downside agains the potential upside, control what is economically feasible, communicate more, and then go for it.
I want to keep these, and elaborate on them, but they were cluttering up my personal README, so I now want to create separate issues (and eventually blog posts or similar) for each or them.
Other Ideas
These aren't "principles", per se, at least not yet, but worth thinking about how they fit into the principles above
Favor Outcomes over Output
Detail TBD - Still working on this one.
Crawl, Walk, Run
This is almost certainly a big part of "Slow is Smooth and Smooth is Fast", but it's also bigger than that and deserves some detail. Somewhere. Problably not in this README.
See One, Do One, Teach One.
Similar in nature to "Crawl, Walk, Run" this one is possibly a PART of "Slow is Smooth and Smooth is Fast", but probably not as closely related. I get a lot of mileage out of it as a learning technique, so I should probably write about it and link to it from here.
Planning is Essential; Plans are Not
Don't Put it Down, Put it Away
This saying is really the bare minimum, or a prerequisite of "Clean As You Go" - where "Clean As You Go" would be applied to gradually reduce tech debt, "Don't Put it Down, Put it Away" is intended to avoid certain kinds of tech debt and other waste in the first place - when you're done with something (even if it's imperfect), don't expect to pick it up again in the near term.
Stop Starting and Start Finishing
Essentially the same idea as "Don't Put it Down, Put it Away" - and the trick in both cases is not to let perfectionism and scope creep get in the way of declaring victory, finishing, and putting it away.
Demos and Dogfood
Note: Does this roll up into "Build in Public"?
The most relevant work product artifact is working code in production. Everything else is overhead. Some overhead in the form of other deliverables and written artifacts may be necessary for principle, legal, or other reasons, and may indeed be necessary to GET working code into production, but if there's no eventual working code in production: those turn to waste. By demoing frequently and broadly, and by eating our down dogfood, we emphasize this intent to go to production, tighten feedback loops, and reduce wasted overhead.
Other Management-Specific Ideas
This is the wrong document for these, and I'll move them when I find a better place. Clearly these are also a work in progress.
Catch Them Doing Something Right
Never miss an opporunity to celebrate a win. I don't know what the right ratio is between celebratory feedback and course-correcting feedback, but make it higher. Relatedly, celebrate in public, but keep corrective feedback and discussions private. Use judgement to decide public or private setting for puzzling or neutral feedback and related discussions. But PUBLICLY CELEBRATE ALL THE WINS.
Mitigate Risks. But Take Them
Risk exists to some degree in nearly every decision, action, or inaction, and by itself is not a reason to avoid making decisions and taking action -- but it also can't be ignored. Identify and communicate risks, weigh the potential downside agains the potential upside, control what is economically feasible, communicate more, and then go for it.