Category Archives: Specialization Is For Insects

Anything Interesting Is Educational, or, Abstraction Is For Experts

It takes me a few days to work through a concept sometimes. I have an essay about the central metaphor of gaming groups, for instance, that I had planned to put up last week – I’d say I understand about eighty percent of what I am trying to say, and the text still needs some reworking. Fortunately, I have a mini-insight, a shorter-order idea I can put up in the mean time.

I collect a lot of important concepts in my daily life. Some times, I notice it more than others. Recently, I was digging around in the blog of the game designer behind the recent kickstarter project about a lego-robot tabletop war game, Mobile Frame Zero, and I happened across an entry on trying to sell genre-appropriate roleplaying games at a horror convention, without success.

You can read the entry I’m talking about here, on Vincent Baker’s blog. It’s an interesting read, and I learned about some games I’d like to play – but the real treasure, for me, came in a followup post linking to another blog’s take on what might be done to improve the salability of such games to the horror-convention set. You can find this insightful post here.

The key insight, the thing I’m most glad I learned, is this:

It’s not just that specific situations are more engaging – they’re also much more useful for people to learn from.

Abstraction works for experts, because experts already have the mental framework to interpret and understand the abstract ideas being presented. They also have a mental bank of examples to draw from, so the abstract ideas very quickly get fleshed out in their minds. Novices have neither a mental framework nor a rich set of prior experiences, so the abstractions remain just that.

Friends, I have been struggling with an abstraction is for experts problem for a few months, both at work and in the consulting I’ve been doing for Alpine Valley School. If you have been involved in either of these settings – or if you are one of the people I vent my frustration on this topic to – you may be able to guess what I am talking about.

There is a vital distinction that underlies some important thinking about elements of an organization that are not working, and it is my tendency to communicate this distinction as an abstraction in the hopes of being able to use it immediately in discussion. When I do this, I say something like, “There’s a difference between process and procedure, you know. A process is what actually happens – a procedure is what we write down, or what we say happens.” This comes up because while one can “follow” a procedure, if you say someone is “following” a process, I believe it means follow as in “he follows politics closely” or “follows what I’m saying” – or doesn’t, as most often seems to be the case when I bring this distinction up.

A process includes elements you can’t control or maybe even perceive, or at least haven’t yet. A process is something you can study, observe, model in your mind, design and then attempt to implement – but it is not something you can “follow” in the rote sense of doing the proscribed steps. Digestion is a process. Construction is a process. Learning is a process. Following a standard set of steps in a standard or expected situation is something else. Standard Operating Procedure covers it – this is something I abbreviate to just “procedure.” You can be following procedure, or not. These are valid constructions that invariably mean what people think they mean. Procedures are part of, and describe and influence, some processes. But they are not the same.

The reaction I typically get when I bring this up is, “Oh, that’s just semantics.” People resent being distracted from what they’re trying to fix or plan, want to get right to do the doing, and are more than happy to dismiss the distinction I’m trying to introduce as a waste of time. This can be incredibly frustrating; here I am, working with smart, interested people, and I need to make some important points about what we’re discussing – points that I believe they will find useful – and I can’t, because they are uninterested in the distinction that enables understanding of the points I want to make.

For instance, changing the procedure doesn’t necessarily create the change you want in the process, and in fact the process as it happens right now may not even closely match the procedure you are trying to assess and modify. These are ideas that can lead directly to stronger understanding of a situation, and to a better grasp of where processes are breaking down, especially when people are using the same word – “process” – to refer to both what we say we do and what actually happens. Ideas forced to live together under the same title tend to merge and become difficult to extract, to come to have reduced distinction in the mind of the individual co-titling them.

Here is where the insight that abstraction is for experts comes in. It’s not that the people I’m working with don’t want the point, necessarily; it’s that the abstraction is, at best, interesting but unrelated when I introduce it in this way, and the “just semantics” reflex closes off further exploration with a wave of exasperation. People don’t want to waste time in meetings, and most people identify semantic discussions as a waste of time. I don’t happen to share that particular valuation, but that doesn’t mean I can get an exemption from it.

In discussing this problem with Aubrey (a damn fine software tester/quality analyst who happens to be my sister), I found that while she recognized my irritation, she steadfastly refused to validate my frustration. I wanted very badly simply to complain – perhaps because I saw the problem as tragic but inevitable. Aubrey knew better – she understood that it wasn’t that the idea was impossible to communicate, it was that it wasn’t concretely connected to the discussion in the minds of the people I was trying to help, and so felt like a distraction.

I bristled. I tried to prove her wrong in a brief role-play in which I took the role of the (I was sure) unassailably uninterested party. Aubrey was right, and I was wrong; she was able to communicate the points I had wanted to make without having to present the abstract semantic distinction up front. By sticking to specific, concrete points that edged around the semantic issue and using alternative language like “what we have written down” and “what we are actually doing,” she presented her ideas in a way that left no opening for my prepared rejection of semantics to even enter the conversation. By maintaining the distinction between process and procedure in her own speech without calling explicit attention to it, she laid the groundwork for introducing the abstraction of the semantic points to people who would already have specific, concrete ideas to attach the floating abstraction to – if, points having been made, it was necessary to bring the abstraction back into it at all.

I was the one who introduced her to the idea of the distinction between process and procedure in the first place. (To be fair, she was the one who introduced me to the work of James Bach, which is where I got it from.) When I introduced it to her, I simply gave her the abstraction. I wanted to tell myself that the reason that worked with her and it didn’t work with my colleagues was that she was an Alford, and Alfords are better at this stuff – but of course, it doesn’t work that way. She just happened to be an “expert” in semantics and testing, areas rich with experience and mental frameworks directly related to the concept I was communicating – so the abstraction worked for her. The other people I was trying to communicate the abstraction to were not experts in related areas, and lacked these resources – so my attempt to communicate an idea that I understood so vividly collapsed, because they simply couldn’t see the relevance.

This was my fault, which is the conclusion I did not want to reach. Had I considered or intuited the idea that abstractions are for experts, perhaps I would not have needed to consult Aubrey’s hard-earned expertise in communicating these sorts of concepts.

Aubrey had solved my immediate problem, but I didn’t understand why I had the problem in the first place until I happened on that passage in a post by an author I’d never read before about selling horror roleplaying games to non-gamers.

This is how a great deal of learning happens: by accident in the specific instance, but by design in the general habits. I did not intend to learn this particular thing (how could I have?) but my habits of analyzing my problems, discussing them with smart people I respect, and deeply pursuing any subject that catches my interest allowed me to make a mental connection that I hope will be of great utility to me in the future.


Tags: ,


writeSomething(“a heuristic for writing when it feels like I’m not able to, expressed as a function”, “10:00 PM”, unspecified);

I have a lot more ideas for posts and essays than I have posts and essays. I suppose this shouldn’t surprise me, and it is certainly not necessarily a bad thing. What is a bad thing, however, is that I often neglect the opportunity to turn an idea into an accomplishment, even when I want to. Too often, I go eat a sandwich or fuss with the internet instead. Today, I am going to try to give myself a tool to help combat this problem, and to continue a theme from my last post, I am going to use the programming idea of a function to do it.

Here is my function, expressed in the approximate syntax of JavaScript:

function writeSomething(topic, doneBy, length) {

your.status = "Writing using a computer keyboard";
your.thinkingAbout = topic;
your.allowDistractions = false;
	topic: topic
	status: "Conceived of but unexpressed"
	text: ""

while(something.status != "Expressed"){

var newText = Create.sentenceAbout(topic);
something.text = something.text+newText;
var completion = Evaluate.forFullExpression(something);
if (completion === true){
	something.status = "Expressed"

	if (ideaStatus = "Expressed"){
		return something.text
		your.writingGraveYard[wGraveNextPosition] = something
		var wsDebIns = ""
		var wsDebrief = ""
		while(wsDebIns = false){
			var newDBText = Create.sentenceAbout
			("Why I didn't writeSomething");
			var wsDebrief = wsDebrief + newDBText 
			csDebIns = Evaluate.forInsight(wsDebrief);
		return wsDebrief
	return something.text


Now, you may not learn much reading that, especially if you’re not familiar with JavaScript in particular or programming in general. That’s not really the point, though I hope you read on, because there may be value for you in this yet. (And if you are familiar with JavaScript, you might notice that I called functions and changed variables not defined in the snippet. Assume this is in the context of a working program, and that the methods I call somehow accomplish what it sounds like they ought to. Or you might notice a problem with the syntax that I didn’t, in which case I invite you to point it out to me.)

I learned a lot writing it, though. I learned some things about programming (for instance, I was able to cut a bunch of stuff involving previous status and setting status when I was done that made the code really hard to read once I realized that stuff belonged in another function), and I learned some things about posting code on WordPress (it’s not easy to work around the visual text editor, which is inclined to collapse indentation and ruin the formatting, even if you know how to format your post in HTML, and it works well to write the code in a program like Notepad++ or TextWrangler, but even so, just to get the code to display in the narrow text column, I had to compress the indentation a couple levels).

But more importantly, I learned something about how to structure and express even a simple idea, and I learned that my initial understanding of that idea was so incomplete that I had to redesign it a few times before I could really express it in psudo-programming language. I learned that I didn’t understand my idea, and I came to understand it better by writing it out like that, even if I’m not all that satisfied with the way it turned out.

That, by the way, is the purpose of writeSomething() in the first place: to understand the topic better, to find out what I don’t know about it – to give myself permission to write about something I don’t yet know how to write about, without evaluating its correctness or value to anyone besides myself. To let me make mistakes so I can learn from them. writeSomething(), only asks one question as it writes: am I done saying this?

An idea expressed in the style of a computer language can be as significant in what it omits as what it includes. My normal writing process would have lots of things that aren’t in this one. It would constantly be checking what I was doing for originality, for truth, for value. These checks can be important for good writing, but I believe fear of coming up short of my own standards, and the standards of others (and more explicitly, the pain I experience when that happens), is one of the things that leads to missed opportunities to accomplish something valuable.

To return to the programming metaphor, writeSomethingGreat() is broken; sometimes it doesn’t return anything at all, much less something great. To help me figure out how to fix it, I’ll use writeSomething() instead (for now) when I find writeSomethingGreat() === undefined.

So far, it seems to be working, though it sure did return something strange.



CodeCademy and Code Year

A couple of months ago, a friend of mine shared an article about Code Year on Google+. The idea of learning to code with a year of straightforward online lessons was appealing, and so I signed up – and I am exceedingly glad I did. It has changed the way I look at computer programming, and the world. The timing was just right, for me – I had just finished reading Jerry Weinberg’s excellent An Introduction To General Systems Thinking, which I did not realize had prepared my mind to eagerly grasp the potential benefits of learning to code – even in a relatively simple, limited language like JavaScript, which is what Code Year is currently teaching. I couldn’t wait for the lessons to arriving by email – so I jumped ahead to what the people putting on Code Year, Codecademy, had going on already.

I discovered one of the most friendly and inviting self-education tools I have ever seen. It gave me an achievement! I love achievements. I want someone to give me achievements for writing fiction! Well, maybe not. At any rate, I swept through the lessons they already had available, enjoying each lesson more than I ever would have suspected. And then. When the first email arrived, with a link to that week’s lesson, I though I’d already done everything they had; I was wrong. Each week they are putting out a significant amount of accessible, quality educational content, and they’re doing it gratis.

I also learned something about programming. Writing computer code is not an exotic behavior, or a specialized talent that only a few can even comprehend. It is a basic, accessible human skill. I should have known; Heinlein told us as much in Time Enough For Love:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

I will admit that I have not put much practice into dying gallantly, though I hope I would be up the task if that’s what was called for. I have been putting a fair amount of attention into learning programming though, and it has been enormously rewarding. If you are reading this paragraph, it would probably be rewarding for you, too.

I don’t intend to work as a programmer for a living, though it might be nice to have the option some day. I don’t intend to write my own software for daily use. I am learning programming for essentially three reasons:

1: It is surprisingly easy to learn.

2: Working on programming problems helps me exercise the analytic parts of my brain that I rely on to live a good life.

3: It may help me solve a problem in some other endeavor later in my life, either directly (giving me insight into what’s may be happening under the surface of software I’m testing, for example, or allowing me to write a quick script to help me accomplish a rote task) or indirectly (software design and the behavior of computers, as with so many other apparently narrow disciplines, are enormously useful sources of metaphor that can be applied to many other areas of life).

If you are not convinced, the home page of Codecademy may yet convince you. I accidentally completed a lesson and was awarded an achievement within minutes of landing there, and was hooked. You can track – and publicize – your progress with a public profile page. Mine’s

If you sign up, or if you’re doing it already, drop your profile page in the comments and let me know what you think of Code Year!


Review: Secrets of a Buccaneer-Scholar

I could say that this book changed my life – but that’s something that every book worth finishing will do, and so that is not especially notable.
I could say that anyone interested in education, either for themselves or for their children or friends, will find a lot of very important thoughts that I think they need to hear in this book – but that’s too general and lacks specificity, and I wouldn’t respect a recommendation so vague without knowing the reviewer.
I could continue the “I could say” format – but I don’t think it will help me finish what I’m trying to say.

What I might say, then, if I were forced at gunpoint to provide a negative review of this book, is that the buccaneer theme and analogies found throughout the first half of this book were perhaps a little taxed as an organizing concept. I would explain that it feels a bit pedantic, almost like it’s trying too hard to take very useful advice and interesting concepts and dress them in the sort of rugged pirate garb that the author hopes will make them appealing to youthful readers. I hope he’s right – because the “young adult” set can get a much out of this book as anyone else.

Since no one is coercing me, what I will talk about instead is the intense, concentrated value of this book for me, an adult trying to thrive in the working world.

When I discover a field of endeavor, one thing that’s very important if I am to sustain my interest is the discovery of a philosopher, someone who understands not only what we’re doing, but why. When I got into writing, it was Ayn Rand and John Gardner. When I got into shooting, it was Jeff Cooper. I discovered in these people not so much a new way of thinking, but a developed understanding of much in myself that I had not yet integrated and understood. In each case, it was like finding a new grandparent, a patron saint, a mentor – that stood for that part of myself that I had yet to truly delve into.

James Bach has done this for me for self-education and professional thinking. (I suspect that Jerry Weinberg did something similar for him, and his recommendation that you read everything Jerry has ever written is worth the price of the book. I’ll review some of Jerry’s books soon.) Like the other members of my personal pantheon of author-mentors, James Bach can do more than give advice – he can help you understand how he came to know and believe the things he does, and how you might come to do something similar.

You can and arguably should get a taste of Bach’s work on one of his two blogs, about software testing and education, which can be found at and respectively. (I am adding both of these to the Blogroll, so this post is something of an Introduction, too.)

I suggest this post as a starting point for Satisfice:

Likewise, might be a good point to start on the blog about education.

Now, you may not care about software testing at all. That’s fine – but still go look at that link up there. If, as I suspect, the post you read is smart, useful and thought-provoking even through you don’t care about software testing, poke around a little, see if you can find something else of value in those archives. I know I did – and that I came to care about software testing. That’s something else a philosopher is good for – making a particular field of endeavor interesting even to the non-specialist, giving someone approaching as an initially disinterested generalist the view they need to understand why they should care about something they would have never thought twice about before, something that can provide them enormous insight and value, even if they never design a software test strategy, or shoot to protect what they love, or write a novel – as the case may be.

I should also note, for any Sudbury or AVS type people who might come through here, that this book is now my habitual answer when it is suggested that graduates of a Sudbury education have mysterious powers of intelligence and insight, and that no one knows how they do it. Well, maybe some people don’t know how they do it, and maybe some of them do it differently – but this book can help anyone get a handle on understanding how I do it, and I suspect anyone either at AVS presently or having come up in such a place can get just as much value from this book in explaining their own processes and abilities as they can learning new heuristics and taking comfort in the tale of a man who was successful at self-education.

For AVS people in Colorado, I have purchased a few copies of Secrets of a Buccaneer Scholar and donated them to the school for PR and training purposes, and of course to make them available to the students. They are available as loaners – but I suspect you’ll want your own copy, when all is said and done.


Tags: , ,

Introductions: Jeff Cooper’s Commentaries

Progress is being made on The Novel, but I thought I’d take a quick break from that to remedy a grave wrong – I had failed to link to Jeff Cooper’s Commentaries. Now, it’s not really a blog – and it’s certainly not updating anymore. Unfortunately, Jeff Cooper died in 2006, and I never had the pleasure of making his acquaintance.

He is my hero.

I do not necessarily agree with everything Jeff Cooper said, taught or did, but that’s hardly the point. The point is that the man revolutionized the way pistol shooting was taught and the way firearms training was thought of, had a keen understanding of history and the mind of man, and expressed himself with force and elegance. His training saved some of his students’ lives, and continues to save lives today. His ideas – many of which, by the way, I do agree with most emphatically – are not only interesting, insightful and powerfully put, they are entertainingly written. Jeff Cooper’s books shouldn’t be missed, either. The Principles of Personal Defense in particular is invaluable, but if you read anything the man ever published, you will come away better for it.

Jeff Cooper mentored me as surely as anyone could on the subjects of firearms, hunting, training, and personal defense – and he was dead by the time I took up the subjects. Jeff Cooper proved that mysticism and Jedi ghost powers are unnecessary in order to teach your students from beyond the grave – one needs merely to have written it down and left those behind who can teach what one has learned.

Back to the Novel Mines of Moria, for me – but you should go visit the ghost of the late, great Lt. Colonel John Dean Cooper.




Get every new post delivered to your Inbox.

Join 205 other followers