Conversation

Cedric Chin
@ejames_c
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.
6
87
Cedric Chin
@ejames_c
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
28
Cedric Chin
@ejames_c
(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
11
Cedric Chin
@ejames_c
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
Cedric Chin
@ejames_c
“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
Cedric Chin
@ejames_c
“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
21
paul weidinger
@fpweidinger
Replying to
@ejames_c
Was a senior engineer. I always think about designing around areas of "volatility." ie how should I structure code to encapsulate the axis of change, as opposed to encapsulating the behavior. This principle is called "information hiding." Components should hide their requirements
1
3