Expertise: success in a domain

So, in my last post I defined expertise as the set of acquired factors that contribute to success in a domain, and waved my hands at refining that (to, for instance, something about “mental” factors). Let’s dig in a little bit on the latter part — “success in a domain.” What counts as “success in a domain?” Some researchers (Fernand Gobet, for instance) look at expertise as getting “results that are vastly superior to those obtained by the majority of the population,” but that raises the question of which results we care about.

Expertise (n.)

If we’re talking about “expertise” instead of “experts,” it’s only natural to wonder what “expertise” actually is. Hold on to your butts, here comes the (light, I promise) conceptual analysis. In simplest terms, expertise is just being good at something. That’s not the whole story, though — there are lots of ways to be good at something, but we don’t want to call all of them expertise. Let’s look at basketball as a concrete example, and playing one-on-one, specifically.

Expert (n.)

I’m doing a deep dive into the research on expertise (or, maybe more accurately, continuing to dive into that research — it’s been something I’ve been watching for several years now), and one conclusion I’m coming to is that “expert” as a noun is not actually that useful. My biggest concern is that calling people experts instead of talking about their expertise — the knowledge and skills and whatnot that help them get better results in their domain than others do (though stay tuned for a future blog post about what-expertise-is) — reinforces an air of mystery and of otherness.

Attention, please

I’m flying back from Nordic Ruby (my first conference talk in three years; my last one was at Nordic Ruby, too, which made for a lovely continuity). The talk I gave was about the lessons I’ve learned while trying to become a better artist over the past year and a half, and focused on attention as the key concept. At this point, my thought (still early in my practice, but hopefully valid for all that) is that many mistakes in drawing are mistakes of attention — we draw what we think we see, which is very often not what we actually see.

My 2014 in Reading

I had a lot of fun writing up my year in reading last year, so I thought I’d do it again for 2014. Goals I mentioned in last year’s post that committing upfront to read an average of 3 books a week took a bit of the fun out of reading. As a result, I reoriented my goals this year. On Goodreads, I committed to reading two books a week (which I figured, correctly, would be relatively easy).

Wanting to be, not to do

It’s about a month and a half until my 10th wedding anniversary, and I’ve been reflecting on how I was feeling before I got married. I distinctly remember telling my now-wife several times during the wedding planning that I wanted to be married, but I didn’t at all want to get married. During a long cab ride to an airport this morning, I was thinking about that, and I realized that it’s one instance of a more general truth that a lot of people are realizing or discovering in other contexts.

Predictions for Comixology+Amazon

Note: I don’t have any special insight into the business arrangements here; I haven’t been paying as much attention to the comics industry over the past few years as I once did. These are just minimally-educated guesses based. When the news that Amazon had acquired Comixology broke, several of my friends — knowing my long-time interest in comics in general and digital comics in particular — asked my opinion. I didn’t have a ton to say at the time, other than the general statement that I didn’t think much would change on the Comixology side (citing Goodreads as an example).

Postmortems: trust and confidence

I am a strong believer in the value of a good postmortem after a customer-affecting incident — and after internal incidents, and after unusual projects and efforts, and pretty much all the time. I really want to talk about one of the purposes of a postmortem, however: building trust and confidence. Trust and confidence I’ve been thinking about trust and confidence in the context of software development since early November:

Two problems with antifragility

I’m no fan of Nassim Taleb (of black swan, antifragility, and needing-an-editor fame), but I forced myself to finish his last book Antifragile in spite of all the problems I had with his presentation and writing. If you haven’t heard of it, the gist is: fragile systems suffer harm when stressed, but there are systems that instead benefit when stressed. Taleb calls these systems “antifragile.” Near as I can tell, Taleb thinks his identification of this concept is hugely revolutionary, and he goes out of his way to name all of his favorite things antifragile and all of his least favorite things fragile.

My 2013 in reading

I’ve been using Goodreads reliably this year to track my reading (well, the book and graphic novel portions of my reading). Over the last month, I’ve been exploring that data – mostly for my own personal enjoyment, but also to see if there were any useful, gleanable insights into how I read. We’re not quite out of 2013 yet, but I thought it might be interesting to record what I’ve found so far in one place.