“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.”
Conversation
“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
Replying to
Definitely true. Another way of framing this same observation:
Good software engineering is building for sustained velocity: moving as quickly as possible while also not getting stuck later.
1
2
Less senior engineers tend to under engineer (go fast then get stuck as scope or requirements evolve) or over engineer (build too much, too slowly without validation of approach or requirements or value to customer).
Related is the sense for when to incur tech debt.
Quote Tweet
So how would you explain tech debt to junior engineers—or anyone who cares about engineers?
Here's my attempt, in one sketch. Good software engineering usually boils down to tough trade-offs... 
Show this thread
1
2
Replying to
While we’re at it, yet one more way to think about it:
Good engineers strive to add possibilities (make every future feature easy).
Good designers strive to limit possibilities (offer only features that have real value).
1
1
This is in contrast with the static idea that designers just give engineers requirements.
I suspect this tension is a key reason for challenges around communication between designers and engineers. Each side not quite realizing the other has a very different mindset.
1
1
Show replies