Sprint planning is a collaboration between dev and product. If your devs aren't good at it they'll agree to far too much stuff in a sprint, or they won't spot what things are blocked, or they'll fail to report what happened in a sprint in the retrospective, which impacts everything from planning the next sprint to writing release notes to when the company can do marketing about a major release.
Hiring developers who are amazing at algorithms but terrible at everything else has huge, far-reaching consequences for everything a business does. Being a good developer is about so much more than writing good code.
> If your devs aren't good at it they'll agree to far too much stuff in a sprint, or they won't spot what things are blocked, or they'll fail to report what happened in a sprint in the retrospective, which impacts everything from planning the next sprint to writing release notes to when the company can do marketing about a major release.
You're describing common sense, not sprint planning.
> Hiring developers who are amazing at algorithms but terrible at everything else has huge
I like this argument from every anti-algo advocate. Because if they're good at algos they're certainly bad at everything else, like you need to sacrifice one to get another.
> Being a good developer is about so much more than writing good code.
Indeed, writing good code is a basis. You can't be good without writing good code, and you can't write good code without knowing basics of algorithmic design and thinking.
Hiring developers who are amazing at algorithms but terrible at everything else has huge, far-reaching consequences for everything a business does. Being a good developer is about so much more than writing good code.