>currently I'm building a distributed collaboration system with event sourced data in Microsoft Orleans
I know it's easy and fun to use frameworks that abstract all the gory low-level details (the equivalent of calling a built-in sort function on a list of numbers), but somebody has to write those frameworks at some point. Don't get me wrong, I'm certainly impressed with the work that the Orleans team did and it would be great to read a write-up on the design of this framework. I suspect a write up on your 'distributed collaboration system with event sourced data in Microsoft Orleans' would be less interesting because the best part would read 'and here I used Orleans to do all the hard parts'.
That's precisely my point. There's a handful of guys at Microsoft building this awesome framework. Anyone else interacting with it needs to understand some details of the framework but it's mostly abstracted away from them. And those developers can be exceptionally well suited to their jobs without understanding the underlying algorithms that make Orleans work. Calling the algorithm design "foundational" is like saying it's foundational to understand how an intake manifold is designed in order to build a car. You could have the best intake manifold designers in the world and still build a shitty car around it. Foundational programming advice and tutorials should focus on making developers the best at building cars well, and leave the "manifold design" to the 1% who need to do it.
I think my issue is an attitude that celebrates ignorance.
>Calling the algorithm design "foundational" is like saying it's foundational to understand how an intake manifold is designed in order to build a car.
Here's a big picture view, the most talented developers I know have a very good mental model of low level details, and also tend to be pretty good at algorithmic questions. I don't think that's a coincidence.
I know that day-to-day programming tends to consist of solving rudimentary problems and worrying more about high-level code organization and architecture rather than micro-optimizations of some function. But it has also been my experience, that even in those cases there will be times when you will run into a problem that will require you to put together an algorithmic solution with a data structure you learned way back in uni that is analogous to the kinds of puzzles you disparage.
As a challenge, why don't you try to do one of those puzzles per day for a month - I guarantee you will find value there.
I know it's easy and fun to use frameworks that abstract all the gory low-level details (the equivalent of calling a built-in sort function on a list of numbers), but somebody has to write those frameworks at some point. Don't get me wrong, I'm certainly impressed with the work that the Orleans team did and it would be great to read a write-up on the design of this framework. I suspect a write up on your 'distributed collaboration system with event sourced data in Microsoft Orleans' would be less interesting because the best part would read 'and here I used Orleans to do all the hard parts'.