Experts have it easy (2024)

Keying off that, I caught myself while reading this section:

> The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. Often there’s an underlying pattern that the novice can pick up through careful observation, even if neither the expert nor the novice can properly articulate this pattern.

I'm 20 years into my programming career at this point and for a long time I really believed this was true and in a sense the "final" stage of mastery. However, I think there is a stage (possibly stages?) of mastery beyond the level of expertness where most answers come quickly through intuition.

I think it boils down to "practitioner vs educator" -- some people are amazing practitioners and unquestionably expert at what they do. But, when you ask them to explain themselves, they run into that "I know it's right, but I don't know how" situation. I think the reason for this is that the person is not a great educator, which is a separate skill. Similarly, I've met many great educators who didn't perform well when asked to execute under real-world conditions.

This has led me to believe that the combination of "great practitioner and great educator" is one of the rarest breeds out there. The few people I've met with this ability I would not call even 10x engineers but 100x or even 1000x.

You've outed yourself as a young person here, because young people have this social fear of messaging senior engineers. Messaging at work doesn't need to be synchronous like in personal communication. Messaging at work matures into optional asynchronous communication for efficiency. See the No Hello (https://nohello.net) protocol.

There is actually a lower bar for quickly bugging a colleague over messaging than walking over to their desk. It's actually impolite to shoulder surf and skim your colleague's email inbox to determine if what they're doing is important. For senior and above levels, reading emails can be more urgent than having an IDE open. There can be production issues, environment issues, vendor tickets, and emails from senior management that are communicated over email. Or they can be submitting an HR form that has their personal details.

Before 2020, software developers in open office environments naturally gravitated to messaging over talking in person, because having no office or cubicle walls means if you're talking out loud at someone's desk, you're bothering others sitting nearby. Sometimes this happens anyway, and it can be hard for some people to read code or emails while listening to colleagues talking right next to them.

> There are other, tangential, reasons to prefer remote work over in-person, but I don't think there's any reason why remote work would be better at educating novices.

There is minor degradation in educating novices, like maybe it's 2% to 5% worse, but in open office work environments, the majority of communication is messaging and emails anyway due to lack of privacy and sound-proofing. Screensharing is easier to see than huddling at someone's desk, and quieter for your colleagues next to you who wouldn't hear all sides of the conversation when you're using headphones.

There might be some situations and some people for whom this would be immensely irritating, but for the moment as far as I can tell, it's going ok with my novices. But your essay opened up a reflection in me about how people perceive this and if I need to tone it down. Thanks!

Crazy how much CPU/GPU performance and storage speed have improved while other things haven't changed at all in decades.