Latency numbers are written with three significant digits (4.21 ms). I'm curious about the accuracy of the measurement device. If it can measure tens of microseconds, I'm impressed. If it can't, the conclusions in this article should be taken more coarsely.
I prefer «reduces uncertainty» to «reduces ambiguity». The problem isn't ambiguous specifications, it's simply that there are too many unknowns to just do the work at this point.
The author talks about the shaping of the work, so I guess this is implicit.
I agree that mentoring is hard, and I want to read your take.
I wonder if we agree on expert aesthetics or not. You write:
> Experts tend to have an aesthetic preference towards technically challenging work rather than simple-but-interesting work, and I’ve written more about this phenomenon here: expert aesthetics.
When I read the passage the first time, I thought you meant "experts prefer to work on hard problems in order to arrive at simple solutions". But that's not what you're saying!
> I would love a language that has this gradual evolutional abstracting as a core concern. That makes it easy. Where you can start from simplest imperative code and easily abstract it as the need for this arises.
This is about how I write Clojure.
I start out with some code that does the thing I want. Either effectfull code that "does the thing" or functions from data to data.
After a while, I feel like I'm missing a domain operation or two. At that point I've got an idea about what kind of abstraction I'm missing.
Rafael Dittwald describes the process of looking for domain operations and domain entities nicely here:
Consider sending him an E-mail, he responded when I thanked him for exactly this book a few years ago! There's an "E-mail me" link on the left sidebar at http://www.catb.org/~esr/.