That’s an insightful take, and completely un-obvious, at least to me.
The idea of a company having its engineers livestream all their production work kind of terrifies me, but might also be kind of an interesting way to do business.
I wonder though if being able to write code and explain it at the same time is a skill like singing and playing guitar at the same time. I’ve never live-streamed though so couldn’t say. Any tips for trying it out, good reasons to do it or reasons not to?
We don’t do that, but we did a lot of pair programming when I started and my productivity was through the roof.
The equivalent in commercial settings should be pair programming. I was on the headset with another programmer who would realize some concepts only as he put them in words and explained them to me.
But the same thing was the case in academic settings. I could tackle some problems only in dialogue (again over headsets) and only in mutual we would even be able to come up with many solutions. I found that it only works in a pair settings and it breaks down in a setting of three.
I think once we engage the speaking part of our brain we unlock something that makes us find solutions instead of take ambiguous shortcuts.
This is why this seems like a strategy that is much more suited to an academic setting. If you're studying algorithm proofs, it sounds like you're often reading something like LP.
Advocating for LP in commercial product development sounds like dreaming. No way would someone who has to meet deadlines write these long, qualitative descriptions of what the code was doing. Martin's suggestion of building the 'narrative' into the code itself sounds much better in those cases.
And it has its merits: you see how a problem is tackled.
I believe this should be obvious.