I had an informal expertise extraction conversation yesterday, with a senior software engineer I respect. The preliminary takeaway for software design expertise is that experts *attempt to predict the direction of change* for their software requirements, and design accordingly.
Conversation
Replying to
They do this intuitively. By feel.
So the expert novice difference here is that experts get it right more than they get it wrong.
And one measure this engineer gave me is: if their commits on a new feature are all green, not yellow, it means they predicted correctly.
1
1
28
(The implication being that the initial structure was the right one, and the changes in the requirements fit into the design, without too much restructuring.)
My god. This explains a LOT of what I’ve seen.
1
1
11
Of course, the main caveat here (again, from the engineer), is that below a certain level of skill, novices don’t realise that the initial structure they chose was wrong, and would keep patching the mistaken design.
That is, the green-yellow heuristic is just a heuristic.
1
13
“Look, everything is a tradeoff, right? And if you design your code this way, it becomes harder to change that way. (Illustrates) So the question is, can you make the right tradeoffs? The senior engineer is aware of the tradeoffs. The novice engineers can’t even see them.”
1
10
“The junior engineer just thinks about the low level implementation details. They don’t even realise that the hard bit is when you uncover new information and the design or requirements change. The senior is always thinking about where the change is mostly likely to come from.”
2
2
21
If anyone wants to use the interviewing technique, it’s Applied Cognitive Task Analysis:
2
12
But I didn’t have the time to use the full technique, so I did this informal shortcut instead:
Quote Tweet
1/ Let's say that you have access to an expert, and you want to get at their expertise because you want to learn it.
You don't have time to do a full skill extraction. (These take hours).
What's one question you can ask that generates the most useful information for you?
Show this thread
1
12
You know, this explains a whole bunch of behaviours I’ve seen. (Speculating here, this is not part of the extraction):
- I’ve noticed senior coders tend to spike by doing throwaway prototypes.
- They also tend to start on a brand new feature by writing everything in one file.
1
11
I used to think they spiked prototypes to quickly generate information about the feature. But now I wonder if they’re also looking for ‘direction of change’.
2
7
And writing everything in one file, with hard coded variables and very little structure makes sense if you have high uncertainty about a new feature: the best structure to use when you don’t know where the change is going to come from is to have no initial structure at all.
2
1
14
(And of course keeping everything in one file makes the cognitive overhead really low, which means the inevitable restructuring — once the engineer knows where change is coming from/what tradeoffs to pick — is easier to do).
2
10
I suppose I should add: I’m going to circle back and do a proper ACTA extraction sometime in the next few months. So follow if you’d like updates — though no promises on the timeline.
Figuring out what programming expertise ACTUALLY is is one thread I just keep pulling on.
2
8