A remarkable amount of geekery-advice comes in the form of rules & slogans accompanied by appealing. intuitively correct, theoretical reasoning using simple logic applied to pre-existing abstractions.
I’m gonna pull a GeePaw-ism here and relabel “appealing, intuitively correct, theoretical reasoning using simple logic applied to pre-existing abstractions”. I’m gonna shorthand these to “Preasons”.
So. We get a lot of preasons in our trade. And they’re applied at every level, including but not limited to Coding, Designing, Tool-Using, Planning, Teaming, and Managing.
If I don’t know how to do a thing I have to make a guess about how to do it. If I am remotely interested in success, I have to have get some preasons, choose among them, and give my favorite a try. There are lots of ways to gather preasons, including making them up myself. (There are even preasons about the best way to do this.)
The only possible fix for that is to always only do things one knows how to do already.
But doing only things you already know how to do is a losing proposition. It will lose in business. It will lose in geekery. It will lose in management, and so on and so forth.
We have to change to win, and that means we have to have preasons to guess which change will work.
It’s true I have only a passing familiarity with most other trades, so I could be wrong. But in my experience, preasons dominate the geek trade like no other. I see this every day in my work with teams all around the world. I see it in my RSS feed and I see it in twitter. I see it extensively in hucksters and third-rate thinkers.
I have come to believe there are a variety of factors that cause this huge reliance on preasoning in geekery in particular. But if I lump all of these factors under a single rubric, it would be this one:
Ignorance-Discomfort: we don’t know how geekery works yet and we really don’t like that.
Regardless of whether any given preason has merit, there is one thing that every preason lacks, by definition. Preasons are always “pre-”. Pre-experience. Pre-results. Pre-data. Pre-implementation. Pre-local.
Preasons don’t account – can never account even in theory – for the actual experience of the actual team that is actually acting on them.
Now, this isn’t the fault of the preason. We absolutely have to have preasons when we don’t know what to do. There is simply no way around them. We cannot know with certainty the result of applying a given preason to our given situation until we apply it.
The sin isn’t in using a preason. It’s in not reviewing the result from using it.
What I am aiming at with that theme is a failure pattern I see again and again. We grab for a preason, use it to justify an action, then grab another and do the same, ad infinitum, ad nauseum, ad legacy, ad enterprise, ad ass-hattery on an intergalactic scale.
In the act-then-listen pattern, the listening has equal value with the action. In the preason-act-preason-act-preason-act pattern, the listening is what’s missing.
This missing step, the part where we listen to see what effects our action has, is how we can convert preasons in reasons. If we don’t listen to our own results, preasons never become legitimate reasons.
If we fail to do that conversion, in a world in which there’s so much we don’t already know, we’ll create something as awful, useless, demoralizing, and largely ineffective as – well – the geek trades.
Suspect all systems for developing software. All of them. Suspect anyone claiming to have a drop-in system for you or your team. Anyone. We do not know how to geek, still less can we tell people how to geek using abstractions applied from a great distance.
Suspect “try harder” answers to negative experiences. I am not saying here that you don’t have to try, or that you don’t have to practice. I’m saying at some point, a long sequence of “try harder” has to be replaced with “try different”. How long? It depends on context, but my generalized advice to the mode of the bell curve: shorter than that.
Suspect large resource commitments to preasons. Large resources include millions of dollars, your entire software development enterprise, any step that takes longer than a breadbox. Even if your current preason-experience with a project or a sub-team is positive, roll it out one step at a time.