Does scrum ruin great engineers or are you doing it wrong?

If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this is not the purpose of the stand-up but instead to highlight obstructions and opportunities for collaboration, then I don't see what more there is to say than "you're doing it wrong" - because you are doing it wrong, in letter and in spirit. It may not be your fault that you're doing it wrong (it's my guess that the widespread perception that scrum is management-heavy is a function of scrum's market penetration combined with the inherently dicatorial culture of corporate governance). But doing it wrong you most certainly are.

This is not one of your complaints of course, but you do complain about estimation, which - as a sibling comment mentions - is simply 'out of scope' for Scrum, which is a smaller package than people think. (Plenty of scrum thought-leadery types are part of the 'No Estimates' thing, for example.) It does, however, mandate that you occasionally meet for the explicit purpose of working out how to improve processes that are not working properly (such as estimation) - in other words, that the team takes seriously as a collective all the things that scrum does not talk about in itself.

These days I sometimes decide not to work on the top priority issue right now, because I suspect it'll take a few hours of uninterrupted log file reading / debugging / thinking to fix, but the day already has three different meetings scheduled.

If that's the last issue in the open sprint, choosing to add another issue to the sprint while there's still an open one tends to be a no-go, or at least causes some discussion, especially if the sprint closes without the issue being closed.

Or sometimes I simply I don't feel like working on a particular issue right now. Maybe there's no rational reason for that. I have no problem overriding that impulse if I know somebody else (either a colleague or a customer) is blocked by the issue, but if it's a case of "we have happened to include issue A in the sprint, but not issue B", having to work on A instead of B against my preference causes unnecessary resentment.

"Another note on breaking down tasks into chunks"

This is the management trick of "divide and conquer".

But for real good dev, that is not a good development process.

Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned:

If you were in an agile/scrum setup, it would be asked to do that file by file, function by function, problem/code change type by type code change. And possibly not break the rest so that there is something 'runnable' at least every week or some other people can work on another file/function.

But that does not make any sense for a great dev. What you would do if you were experienced is to know the overall direction but rework the code line by line progressively, fixing side things on the way and maybe regularly fixing in other files/functions pattern that are similars. And maybe at some point decide to change again something you did until the point where you achieve your goal.

In my mind, it works more like a path searching algorithm in action.

The scrum concept is probably good for the devops/web script kiddy devs, where you just change hundreds of individual small items without too much interdependance. For example, change the style of button, reorder blocks on a page, change the icons, increase the font size.

Also, something that makes great dev become average is this concept that every dev should be exchangeable and a commodity. Dev become workers on a factory production line where they have no value than to follow process and apply patterns.

They say "what if something happen to your autonomous great dev?" but this argument is not used for the rest of the intellectual society: you don't see 2 doctors at a time, 2 lawyers for your case, 2 CEO in the company, 2 main architects. This thinking is just applied to low level replaceable workers.

Normally, if you lose a great dev and you find another great dev, the new one should be able to understand the problem and the code in a short time and be operational quite fast.

One example we can easily see of efficient dev are the great open source projects. Most of them were not created and led by an army of dev clones but by a few efficient ones: linux, python, php ... In these cases, most of the time we don't consider people to be interchangeable. Some people are keys to topics/code/features and that leads to great dev. But in case of problem, there is almost always someone smart capable to take over after a short time.