Coaches: Whence Confidence?

coaches, we all know that confidence is key, yes? it’s not the only key, but it’s key, especially in the beginning.

people look to you for ideas, then. and they’re lookinig to you for a number of reasons, but one of those reasons is because they think you’ll have some. and early on, there’s very little reason for them to think that. they don’t know you, they are guessing. and that perceived confidence in them is matched by an internal confidence in you. it takes a lot of nerve to stand up on your hind legs and offer an idea to a group you don’t know well.

so where’s that confidence come from?

well, you could just know all the things. if you knew all the things, you’d always be right and could always be confident as a result. you could also just pretend to know all the things, of course. that’ll help with their sense of your confidence, but it won’t help all that much with yours. i know some of the things pretty well, and some of the things kinda, and a whole lot of the things not very much at all.

where’s my confidence come from?

one place it comes from is my past successes and failures, which are plentiful. both have lent me a great deal of confidence.

  • successes in the past give me a little confidence because they were successes, but they also lend confidence at a higher level because, frankly, they amounted to very little in the grand scheme of things. they are relatively unimportant.
  • and failures might seem to subtract confidence, which they do, but again, in the grand scheme of things, they just don’t matter that much. i’ve failed more than i’ve succeeded, and i’m still here. still hungry. still beloved by some. still at it.

it’s strange to say that my confidence comes in part from the relative insignificance of my choices. but strange doesn’t make it untrue.

another place my confidence is rooted is in my extreme capacity for doubt. again, rather strange. but i gain tremendous strength from knowing in advance most of what’s wrong with my ideas. by the time my idea gets out, it’s already been hit and hit hard by my very own doubt-magic. to a remarkable extent, i already know what’s wrong with it or what might be wrong with it. this means i’m very rarely surprised or troubled when others critique it.

i also get my confidence from two kinds of “meta-“. essentially, the confidence is inherited from my process. it’s not that i have so much confidence in the value of my idea as that i have so much confidence in the value of my idea-valuation process.

i call the first meta- “do to know”. once i get an idea past a rudimentary scratch & sniff test, once i establish that it’s not definitely wrong or evil. i turn my attention to splitting it into steps that attempt to reap partial value from it. i do one of those steps, and i get to see if i got the partial value i was hoping for. i am doing the thing — in steps — to know whether it is valuable or not to do the thing. “do to know”.

the second meta- ? i have nearly complete confidence that the people i share my ideas with will take the idea, lose the fat, and cash in on the protein with tremendous vigor and enthusiasm. this gives me confidence because i don’t have to be that smart. even if i’m the smartest person in the room, *we* are smarter than *i* am, if we’re just given the chance to be.

as long as my process gives us the chance to be, we’re as good to go as we’re gonna get. “as we’re gonna get” is an important clause. i’m not saying our ideas always work, or that even if they work they’re the best. i’m saying, we live in the heideggerian “thrown”, and inaction is an action, and being right in advance just is not within our reach.

we have no choice but to share ideas and try the ones that aren’t definitely wrong or evil.

so that’s where i get my confidence. it comes from insignificance, doubt, do-to-know, and community. it doesn’t always work, because nothing always works. but it works often enough.

where do *you* get *your* confidence?

The Rigorous Playpen

i’m bettin’ u already got some code. if yer a geek in a substantial code base in an org w/more than a half-dozen other geeks, i’m bettin’ u already got a *lot* of code.

in your team’s head, if not somewhere on an out-of-date piece of paper, there is a picture of “our code”. i want to draw a box somewhere where there’s room in that picture, and i want to label it “rigorous”.

let’s call it the rigorous playpen. and what we want to put in that area of our codebase, is only file-pairs about which we can make this statement:

this code (T) tests that code (P). if u can break our app in that code w/o this code telling u u broke it, call us, any time day or night, and we will come running.

i have some questions & comments about this idea. do you get it? that is, does it seem pretty clear what we’re asking to go in the rigorous playpen?

under what circumstances might you move one of your file-pairs in to that category? it would seem to require a substantial amount of judgment & experience to designate some file-pair as being in the rigorous playpen.

if we had a rigorous playpen with some code in it, what might change about how we do things now?

i’d imagine several things would change.

  1. we would be far less likely to go there first in a brushfire. this is like our doubt that the String class from our library is fundamentally broken, rather than the index we passed to ‘substring()’. nobody *starts* by debugging String.
  2. we would onboard newbs by finding work to do in the rigorous playpen. both, changing code P and changing code T, both with our assistance & support of course.
  3. we would orient ourselves *outside* the playpen to buidling code that was readily playpen-suitable from the very beginning. this is the steering premise of TDD.
  4. as we brought more and more of our code to the playpen, we’d get better & faster at doing it.
  5. as we brought more and more of our code to the playpen, we would fear deployment less and less.

a question emerges almost immediately: how much is this going to cost?

the answer: a good deal less than you think, because the payback comes at you high and fast. a good deal more than you think, because you have to change how you think — how you *feel* — about building software.

No One Way: GeePaw On Method

when i was geek-young, not quite forty years ago, i worked in a tiny two-person shop, and we were entirely without “method”. we just wrote code. at that time, there were plenty of analysts of geekery, and they were certainly writing about how to geek, but 1) their ideas were seen as more of a bazaar than a cathedral, and 2) most of the trade did exactly what we did at good ol’ MIS.

(chris martz, or jan, if you’re out there somewhere, i would love to make contact. i have never properly expressed my profound gratitude. i internet-stalk you from time to time, but no luck so far.)

in the period from about ’85 to ’95, a lot of proto-brands of methods started to emerge. most of these were tightly tied to direct geekery rather than the larger trade. as ideas about how to write code got stronger, they widened their scope, and became ideas about how to run the whole trade. i myself used the Booch method, later unified with jacobson & rumbaugh to create the Rational Unified Process[tm]. [no, literally, tm.]

it’s not actually clear to me that most geeks use any method more formalized or nameable than what i started with back in 1980. and even those whose orgs *claim* to use one, seemingly very often don’t.

there is a plethora of methods these days. in the circus called “agile” they seem to multiply like bunnies. proto-brands have become full-on brands. flames abound, and much gnashing of teeth, tho i’ve hung with various leaders in this scene for many years, and a lot of what might seem to a noob as internecine conflict is actually just joyful intramurals. (ex: london & chicago school TDD).

y’all know i abhor hashtags for any purpose other than to create temporary news channels for breaking events. i’m especially resistant to those tags that reek of sloganeering. i don’t find myself in need of threads whose intent is to unify but whose result is to divide.

but if i were to stake out a hashtag it would be # NoOneWay.

when i was first learning to teach, my constant debriefer was my beloved wife virginia, a master teacher. every day i’d tell her about the day and throw out something that “went wrong”. at this point, she would suggest — i am not exaggerating for effect — anywhere from 5 to 15 things to try in class that were different from what i had tried. for her as a master teacher, it somehow never entered her head that there could or would be One Best Way to trigger the light bulbs in a class of students.

this was a revelation to me, building a slow tire-fire in the dump of what passes for my consciousness. and over a very long period of time — apologies to my many intervening victims — the message got through. and once i got it, with teaching. i began to see it much more with geekery, conceived both narrowly with “writing code” and broadly with “shipping value based in software”.

i don’t want you to think — heh, how could anyone possibly think this of me of all people — that i don’t have opinions, and strong ones, about what things have worked and not worked, for me, for the teams i work with, and even for the larger trade. i certainly do.

but consider some method X. maybe it’s a method for writing a line, or for dividing software into efficient arrangements for mental scope, maybe it’s for obtaining viable working definitions of “shipping” or “value”.

and consider method X’, which is just method X with some small change.

here’s the thing. there is no One Best Way to write a line of code, or divide software in chunks, or find out what people would like software to do. there is no Method X that is the One Best Way. Maybe there never will be one, or maybe the world will change, but for now, we are without a Method X that is a Method One Best Way for any of these things.

so, what’s a girl like us to do?

take whatever you’re doing now and label it method X. if it’s working great, great, make an X’ method out of it and try that and see if it gets even better. if it’s working not-great, find something different, method Y, and try *that* for a while. the geek trade is absolutely surfeited with ideas for both method Y you haven’t tried and method X’ you haven’t tried.

read widely. try things. don’t be afraid to try X’ and decide you still like X better or decide to try X” or even a different ‘. and please, don’t *stop* doing X’ methods just cuz you haven’t found one yet that’s really better than your X. not only is it extremely likely that your situation is only local in time, but it’s extremely *un*-likely that you have discovered the X that is the One Best Way.

the road to hell is lined with great parking spaces. don’t park.

last thought for this muse: isn’t geekery just about the *best* thing?

h/t my friend @onealexharms for the morning tweet that started me down this one.

The First Metric: How Are You Feeling?

of all the routine requests i get from clients, the one i find most difficult to deal with is this: “help us choose a metric so we can tell if things are going well.”

the problem is that “numbers as health indicators” is *so* deeply embedded in our worldviews, *so* deeply correct on paper, and *so* deeply counter-productive in every case i’ve seen in practice.

think about your own health for a minute. is it a 9 or a 3? while you sputter away trying to answer that, let me point out some of the difficulties in making such an assessment.

  • difficulty: my “health” rests in a huge variety of factors, some easily measured and some not so easily so. in order to come up with one number, or even five numbers, we will have to do make some pretty sophisticated judgments after some pretty sophisticated analysis.
  • difficulty: my “health” varies temporally due to externalities like recent injury, the flu, the six straight weeks i’ve spent in a hotel, and so on. we’ll have to make sophisticated judgments after sophisticated analysis.
  • difficulty: my “health” includes factors not one person on earth knows how to assess objectively, like whether i’m nearing the borderlands of churchill’s black dog, or whether my mom just died. hmm. we need some sophisticated judgment after sophisticated analysis.
  • difficulty: *my* “health” has key indicators that are not the same key indicators as *your* “health”. if we’re to compare these, dagnabbit, sophisticated judgment & analysis will be required.
  • difficulty: for a 100 years, several times in the last twenty years, a variety of expert-consensed health indicators have been challenged, overturned, abandoned, and replaced. parsing that turmoil to settle on figures would need, you know, sophisticated judgment after analysis.

anyway, if you’re done sputtering, just give us the number. is it a 3 or is it a 9? is it 3.782 or 3.105? c’mon, c’mon, kid, i don’t got all day here, i have powerpoint to edit.

  • difficulty: knowing my “health” is 6.322 tells neither me nor you what we want, could, or should, actually do about it.
  • difficulty: the relevance of a health metric depends entirely on the relationship between me, my health, and the origin of your interest in it. you guessed, sophisticated judgment after analysis.

if you’re reasonably good at assessing trends, you might have noticed a trend in all these difficulties. (if you’re not, then why did u even ask me for these numbers?) that trend is towards sophisticated analysis followed by sophisticated judgment.

well, is *anyone* good at assessing health? yes. i can think of two groups that are quite good at assessing health: medical professionals and health insurance companies. (neither is perfect, both are quite good at it.)

how do doctors & nurses assess health? well. they build relationships with their patients, and make delicate subtle judgments using 1) experience & preference, 2) your reports, and 3) some extraordinarily expensive & complex local detailed tests.

insurance companies do it differently. they use huge aggregates and monte carlo analysis and data-mining and *staggeringly* complex mathematical models to do it.

these differences make sense. insurance companies care about your health because doing so lets them maximize their gambling profits across a huge range of bets. doctors & nurses care about your health because of other reasons.

still sputtering? lord help me, it’s a simple question. WHAT IS THE NUMBER OF YOUR HEALTH!??

let me ask a question. when you “don’t feel good”, are you more likely to see a medical professional, or more likely to see a health insurance company?

i thought so.

notice two things about going to your medical advisor.

first, your medical advisor is a full-time expert on health who invests heavily in an actual ongoing relationship with you, and that costs money. (if you’re an american, it normally costs more money than you have.) second, your medical advisor begins virtually every interaction in one simple & straightforward way, by asking a question: “how are you feeling?”

so. i have a client right now who is asking me — all clients with more than three geeks ask me this sooner or later, sooner at the vbca’s, later at the smaller outfits — how can i get a number to tell me our health?

“how are you feeling?”

Coaching? The First Pre-Requisite Is To Like People

do you know what the absolute first pre-requisite for being a software development coach is? you have to like people.

sometimes we get so involved and committed to method, or technique, or whatever current flamewar rages around the building, it can be really easy to lose track of this fundamental requirement.

  • i am not talking about being an endless fount of loving kindness, a rainbow-farting unicorn drifting amongst the few fluffy clouds that just serve to highlight the great beauty of every day.
  • and i am not talking about being an extrovert — one who gains energy more than loses it by being around other people.

anyone who knows me knows i am neither of those two things.

i’m talking about *liking* *humans*. their quirks and tics, their style, their hopes, their worries, all the stuff that make us people and not machines. i’m a pro. i never work with a team without finding something nice to say about them. and i admit, sometimes that’s something like, “gosh, you folks just have the *best* shoes!”

but i actually really enjoy the people i work with. i like learning about their weird-assed hobbies, their night-coding project, the path that led them to geekery, how they met their SO, and on and on. i just like people. we’re such a mess, and we try so hard.

so let me ask you this: do you play favorites? Good. Play more of them.

remember what it’s like to be attended to, smiled at, to get help and to give it, to be asked, to be regarded kindly. remember how *strong* you feel when those things are happening? dig it. do more of that.

TDD & The Geek-Young: Is Tdd Right For Noobs?

possible causal point for a failure to value TDD: geeks thinking the main source of bugs in professional software is not handling the main case successfully.

in any feature in any app, there are one or more primary cases. a given story is likely to be concerned with one of these at a time. when you’re geek-young, the great challenge is just to close out the primary case. hell, you barely learned the syntax, you’re just learning the library-set. just getting that primary case running is a big deal.

it takes a while, but with some practice, these primary case problems get easier and easier. you learn the syntax for real. you’ve used enough of the library to suspect or increasingly know how it was intended to be used. you are getting stronger, and that’s great. you find yourself making solutions in your head before you’ve even heard all the problem. and altho that has its own risks, you generally are making headway all the time.

when you go pro, tho, three factors emerge, all of them based on size.

because your app is larger, there are more people changing it, more cases to grasp, more things to remember.

  1. more people means more worldviews. assumptions you’ve made in your code are quite likely not the assumptions made in theirs.
  2. more cases to grasp means more possible code-paths. assumptions you’ve made about when and where and why your functionality is being called are far more difficult to make.
  3. more things to remember means slower and slower thinking. human brains are optimized for a very narrow bandwidth. no matter how much you resemble an encyclopedia, sooner or later you become nearly paralyzed.

and somewhere in this not-quite-so-geek-young phase, you will hopefully begin noticing that standing up the isolated main case really just isn’t that hard, comparatively. you bone up on design, which isn’t mostly about solving isolated main cases anymore. it’s about a new level of the game. (like when you finally realize potting simple pool shots isn’t the hard part of pool, or that bouncing between knit and purl isn’t the hard part of knitting. there are lots and lots of games-for-a-lifetime, and geekery is one.)

after a while spent learning the patterns and their beautiful variations, experiencing the joy and despair of walking around chanting “it’s really just an X. *everything* is just an X. it’s X’s all the way down!” you reach yet another game. you begin to understand how much time and energy you are spending on problems caused by assumption mismatch and tacit knowledge and trivial one-liner flaws.

TDD — really a shorthand for me for “the modern synthesis of software development” — offers a variety of ways to mitigate or even eliminate that pain. and as you adopt it, your successes increase, and your failures decline. and blammo, you’re a pro. this isn’t a switch, it’s a process, and it takes time. fortunately, you have time, cuz it pays back almost immediately.

and now you’re in a place where you can look back on those other periods and ask, would TDD have helped me even then?

my answer: yes, oh hell yeah. because those assumption mismatches, tacit knowledge failures, and one-liner flaws, THEY WERE COSTING ME THE WHOLE TIME. i just couldn’t see it. “just make the isolated main case actually run, please lord please,” was all i could attend to. tho i felt like the isolated main cases were the hard part, i was wrong. the hard part was *still* what it is now: assumption mismatch, tacit knwoedge failure, one-liner flaws.

i’m old enough to have climbed many mount stupids, and the odds are good that i’m climbing one just now. but at my current stage in the game-for-a-lifetime called geekery, i believe that TDD would have walked me through all the earlier stages far faster.

TDD is so powerful because it lets you kill off so many distractions from “just get the next main case working.”

Sync Points Reduce Our Trade’s Effectiveness

companies spend a great deal of time and energy seeking to get their teams synchronized. several forces motivate these efforts. it’s worth taking a second to look at these.

  • one force: the belief that synchronization provides steering points. the notion here is that since we’ve just synchronized, now is a good time to react to the market and adjust the direction in which the project is headed.
  • second: the belief that no given team is able to do all the “vertical” work needed to accomplish some business goal, to go from silicon to screen and back again, with reasonable optimality, e.g. turnaround time, excellence, safety, and so on. (this belief is often buttressed by actual organizational barriers. most notably the horizontal layering of teams to resemble whatever horizontal layers exist in the app or its technologies.)
  • third: synchronization points give us an evaluation opportunity for the market, but they also give us one for the teams. it’s a convenient time for us to reward, spank, and re-org our team layouts.
  • fourth: sync points let us view longer term plans as composed of little segments that we morph into “work buckets”, which we can then “fill” and produce some sane estimate of when a large-scale deliverable might ship.

these beliefs, and some related others, seem to lend tremendous support to the idea of building software development teams around the central idea of synchronization mechanisms. the synchronization schemes form a widespread mainstream in the trade. they’re especially prevalent in vbca’s. there, they tend to go hand in hand with a variety of “standardization” efforts.

i contend that these synchronization ideas — writ especially large in the vbca world — create a tremendous net-negative impact on software development all over the world. they are not just not needed, but are actively counter-productive. i think they are wrong or wrong-headed.

i spend large amounts of time embedded in various “agile” organizations. most of these are “scrum”. these orgs almost uniformly introduce sync points at 1) 1-2 weeks, 2) 12-16 weeks, and 3) 52 weeks.

(note: those quotes are expressly an anti-invitation to discuss the myriad ways those orgs are not actually doing “real X” for any value of X in vicinity of the movement we share. i am bored of that conversation, and will require free scotch to bother to pretend otherwise.)

let me offer a few points about this synchronization concept & its implementation in these orgs. before i do, tho, i will make a statement that may trouble some listeners. that’s okay, it troubles me a little, too. but i’ll tell you now and u can decide whether storm off early. (1/2): i’ve spent 40 years in professional s/d, and 20 years embedded in the agile movement as a leader. i’ve worked in dozens of orgs, from ma & pa to fortune 10 companies, on every kind of s/w there is. i am coming from actual practice & experience.  (2/2): and maybe that’s all there is to say. i cop to my well-known arrogance. please don’t come at me with a textbook or a well-designed slide, your week-long class or your scant years doing the same thing in the same org. i just don’t have it in me today.

okay, some points, for those of you tolerant enough to hang in this long.

point: synchronization mechanisms are never free. by its nature — by its very definition — synchronization breaks flow. it introduces wait states and restart costs. wait states are periods where we stop working because there’s not enough time left before synchronization for us to squeeze anything else in. restarts are periods right after synchronization where we re-gather our focus and seek to re-find flow. if the syncing mechanism itself is expensive: i routinely see 1.5 days given over to syncing at 2 week intervals, one is easily giving 20, sometimes 25 percent of one’s productivity over to the mechanism. this is a staggering cost. we should make sure the benefit is worth it.

point: the ideal site for steering a small team is any time they’ve finished one small piece of work, before they start another. one does this in a hierarchy by giving your direct reports larger-scale direction and leaving them to decide how/when to intervene inside their teams. this is not easy, which is why you are well-paid to do it. it requires trust in your directs, and patience in achieving whole-hierarchy change. but the thing is: steering isn’t *actually* achieved any other way. a syncing mechanism provides an “as if” model of steering, and if it were free and equally effective, that’d be fine. see the first point: it’s not just not free it’s quite expensive. you are paying a very great deal for the illusion of control. is it worth it?

point: verticality in team range, their free ability to operate in different technologies all up and down your code base, is wildly risky & inefficient only because we set things up that way.

  • first, the geeks on your teams already wrestle with at least a dozen advanced technologies every day. they are hardly incapable of navigating across these. it is in fact their whole job.
  • second, there are far cheaper ways to protect yourself against a noob breaking what has gone before than banning them from changing it. what if u had very high certainty that this could almost never happen? you can. it’s called TDD. and in no way coincidentally, in addition to the defensive benefit of TDD, there are *huge* advantages provided by it to your more experienced geeks AND to your noobs, entirely aside from risk-mitigation.

point: the whole reward/punish justification for sync points is foolish on a number of counts.

  • first: reward/punish? you are ignoring the last 100 years of research into human motivation, likely quite disastrously so.
  • second: if u seek to reward/punish team on grounds other than their productive health, you can do that any time you like anyway.
  • third: there is no reason whatsoever to believe that measuring sync-to-sync productivity can be in any standardized or made viable for cross-team comparison. we have a ton of info that suggests otherwise, and almost none that backs this notion.
  • fourth, same-team different sync-period comparisons by numbers are almost as bad. different teams wrestle with widely different degrees of difficulty from one sync period to the next. dead-ends abound in our trade, as do false starts, as do even key individuals’ lives.
  • fifth: interrupting flow is itself usually a punishment, as is evaluation from people who are so far above you they have to evaluate you based on numbers that don’t capture your state.

i’ll say this again, please memorize it now: there are only two ways to assess the health of a software team just two: live with the team. trust someone who lives with the team. that’s it. that’s all you got. if you can’t do one of those two things, you can’t assess their health.

point: your longer term plans don’t work very well at all now, with all those sync points. how much worse could they actually be? remember, you are *paying* for that sync, heavily.

further point: using sync-periods as buckets is a whole category of foolishness separate from all the rest. it ignores every single thing we’ve learned about the real world of software development for fifty years. it is just a staggeringly costly and hurtful practical joke.

so? lose it. forget about sync points. they cost a fortune, they help little, they often hurt a lot. focus on building unsynced systems that free intelligent trustworthy motivated people to do their best work. oddly enough, they will.

Desiderata: On Motives

so. this is hard for me to approach. the circumstance of my radicalism began when i was but 5 years old.

at age seven, under pressure, i became aware that some adults were dumb-asses. by the sixth grade, age twelve, i saw most things around me lies. i encountered people i thot were good and just behaving not good and not just. i was fully radicalized then.

around that time i stumbled upon the poem “desiderata”. it was a popular poster, and i papered my walls with posters. and, in poster form, it was claimed to be some ancient anonymous text, cited to some boston church — coincidentally i’m in boston tonight, but not at a church. in fact, it was written in 1927 by max ehrmann. i know nought of ehrmann other than the poem.

in conversation just now the line i regard as central came up. and — this is my 58th birthday, so some 40+ years on — i went back to the original. and i read it. and. and, it entirely recapitulates every good day of my life. i say this frankly embarrassed.

what, seriously, this long-forgotten poem, written by an unknown, printed on a poster by some hooker, pinned to my twelve-year-old’s wall with pins i bought myself from mowing lawns, 75 a year, ten bucks for me, the rest for the family kitty?

inebriation being what it is, and me being what i am… yes. yes, this poem still captures almost entirely what i do and who i am. i recite it to you now. further tweets are the poem, until i advise otherwise.

Go placidly amid the noise and haste, and remember what peace there may be in silence. As far as possible without surrender be on good terms with all persons.

Speak your truth quietly and clearly; and listen to others, even the dull and the ignorant; they too have their story.

Avoid loud and aggressive persons, they are vexations to the spirit. If you compare yourself with others,

you may become vain and bitter; for always there will be greater and lesser persons than yourself. Enjoy your achievements as well as your plans.

Keep interested in your own career, however humble; it is a real possession in the changing fortunes of time.

Exercise caution in your business affairs; for the world is full of trickery. But let this not blind you to what virtue there is; many persons strive for high ideals; and everywhere life is full of heroism.

Be yourself. Especially, do not feign affection. Neither be cynical about love; for in the face of all aridity and disenchantment it is as perennial as the grass.

Take kindly the counsel of the years, gracefully surrendering the things of youth. Nurture strength of spirit to shield you in sudden misfortune. But do not distress yourself with dark imaginings.

Many fears are born of fatigue and loneliness. Beyond a wholesome discipline, be gentle with yourself.

You are a child of the universe, no less than the trees and the stars; you have a right to be here. And whether or not it is clear to you, no doubt the universe is unfolding as it should.

Therefore be at peace with God, whatever you conceive Him to be, and whatever your labors and aspirations, in the noisy confusion of life keep peace with your soul.

With all its sham, drudgery, and broken dreams, it is still a beautiful world. Be cheerful. Strive to be happy.

(me again).

what i have tweeted is very possibly a copyright violation. i’m sure, in that case, to receive stern letters. yeah yeah. i’ve been kicked outta better bars than this, believe me. when some angry person tells me they have to read the poem on the ad-riddled site, i will forward it on to you.

meanwhile, tho. meanwhile. u know i was just 12, right?

alex harms and i have an expression, we use it to express our sympathy for people who are fucking up. “well, she’s just a boy, right?” it’s our way to remind us that we all got here without knowing what to do, and formulate what we can. cc @onealexharms

i stand before you fairly astonished. there is no part of max ehrmann’s poem i would wish to demure. i have spent my life on it i am glad to have done so.

The “Software For Money” Game

so, apropos the earlier muse that was fairly muddled about the hardest problem in the geek trades today…

i can’t think of a better way to describe what i do as a geek than to speak as if we were playing one of those wild modern world-building games. lately, i’ve been playing Oxygen Not Included, but there are lots of them. The most famous are probably the Civilization and Age Of franchises.

in these games, whether smooth and real-time or turn-based, one is confronted with an undeveloped world and asked to create within it some sort of ongoing/sustainable enterprise within it. if you *are* a gamer, u know what i’m talking about. if not, well, poke around a little, and you can find out easily what i’m talking about.

the gist of these games is that one makes multi-threaded/tasked gestures to alter and respond to an environment of some kind. “go build a woodshop”. “run like hell to that dam and plug that hole”. even “take a break”. it’s not done using text, but those texts are illustrative. (there’s also “kill that fucker”, “dig a hole to poop in”, and so on and so forth.

the environment (“anything not mine”) these games are played out against isn’t just a passive recipient of your activity. on the contrary, as you affect it, so does it affect you. some of those effects are broad & generalized: in Oxygen Not Included (ONI), you gotta have food, water, and of course oxygen, and they all decay over time as you use them. others are more “event-like”: enemies arrive, most typically, of one sort or another, and you must defend your little colony against them.

when i play these games, they greatly resemble the software development game in several respects.

1) time passes as you develop, with dreadful or benign, obvious or unpredictable, consequences.

2) at any given time, there are literally dozens or hundreds of orders you might give, and many of them have complex & interrelated parameters associated with them.

3) ongoing sustainability trumps virtually every other concern. the game is long, and you have to develop your ability to claim the prize at the end very slowly compared to how fast you can execute moves.

4) a nasty little meta-complexity is present in the best of these: the issuable orders change over time, in response to some subset of the orders you’ve already given. (can’t make a hydrogen generator until you’ve learned how, for instance.)

5) there is no one answer, no fixed repetitive algorithmic mechanical newtonian recipe for success.

6) the only way to get good at it is to do it. you could study the math and code of ONI all day long, and you still wouldn’t know how to win.

7) there *are* patterns. they’re not precise or identical in application, but the more games you play the more familiar you become with certain problem/solution variations.

8) in order to get where you win more often than you lose, you have to lose one helluva lotta times.

9) it all comes down to me choosing from a bewildering variety of actions, applying them in multi-threaded value-producing sequences and trees, and keeping my eyes generally on everything all the time.

10) it produces a delightful buzz.

so. here’s the thing. i could easily map every one of these ten numbered items directly on to making software for a living. i mean, really, almost word for word.

shipping software for money is a temporal enterprise. at any given time there are myriad moves. there are multiple threads of activity. there are active and passive environmental effects. there is sequencing, anticipation, and stochastic/heuristic prediction. and it can be fun.

to restate the problem that initiated all of this: how do we build an effective culture of transmission, where we be more effective in expressing the possible moves, their interactions, their necessary and optional sequencing, and their consequences short-term and long?

pro-tip: it will be at least as hard as playing the game in the first place.

The Hardest Problem In The Geek Trades

software development is a *temporal* activity: it takes place over time.

any temporal activity can be shown as a series of snapshots. this is a way of “speeding them up”, usually for the purposes of analysis or instruction. it’s a kind of “as if” thing. for some kinds of thinking, we can just elide, ignore, or lightly annotate the face that the activity takes time to happen.

there’s nothing inherently sinful about these “as if” visions, but sometimes, when their conclusions are ramified into prescription, especially rule-centric process, they can produce unexpectedly unpleasant results. the whole snapshotting conversation is really about the framerate we choose in which to talk about our way of making software.

how often do i take a snapshot of “my way” to make it valuable to onlookers? and the answer depends almost entirely on who those onlookers are and what they want to do with the resulting sequence of images.

the most common answers in development pedagogy seem to be 1) just show the final result and explain it. 2) one second = one second, and, the most common 3) snapshot once an interesting change has occurred.

at different times, i’ve used all these methods as consumer and producer both. i generally prefer the third when i’m learning something brand new, and the first when i’m out there looking for “how i implemented X?” type answers. i want to hone in on the third, because i think it’s most useful for the largest part of the trade. if we double the population of working geeks every five years, that means that any given time half of the trade is composed of — no offense — noobs.

what noobs — often including me, depending on domain — seem to benefit the most from is sequential frames where each frame has an “interesting” change from the frame before it.

didja ever do something dumb that got your mom mad at you? and she said, “oh, child, what were you *thinking*!?!?” as a noob forging my way into a new domain, that is the question i most often want to get the answers to. “what were you thinking?”

geekery is the sociotechnical act of integrating high levels of creativity with high levels of rigorous technique.

a rewrite: geekery is the sociotechnical act of integrating high levels of creativity with high levels of rigorous technique over susbtantial periods of time to make artifacts that please.(i added that rewrite cuz it mentions or implies all the muddinesses present in this very muse.)

if we are to learn, do, analyze, teach, or give advice about geekery, we have to incorporate *all* of this into our vision.we have to address the artifacts, the pleasing, the creativity, the technique, the sociotechnicality, the humanity, and temporal flow of the enterprise. honestly, nothing else will do.

perhaps my biggest whine — this is not a rant today — about these branded prescriptive processes i encounter every day everywhere all the time: it is the extent to which they seem so often to leave out one of these key aspects.

what i am after is a description of software development that is formulated to include all of it.i don’t know that i have such a thing inside me, or that any of the geeks i love and respect have it in them, either.

at the end of the nineteenth century, david hilbert produced a famous list of “problems we must solve” in mathematics. i guess i believe the most pressing problem we must solve, as an industry, a trade, a discipline, a way of being and living and working, is just this: how can those of us who are successful at this express what we do to those of us who are less successful at it?