If all you concentrate on is short term improvements then... sort of?

Making iteration faster let’s you see the results of changes you make faster, that’s the benefit. If you’re iterating faster than you can make meaningful changes then you won’t see any change by definition.

Iteration length is also context dependent. For a multiplayer game I really like being able to see my changes immediately when working on it, I love being able to iterate with other devs on some idea where each iteration is in minutes and we’re chatting about it together but we only test the game itself “as it’s meant to be played” with anyone outside the team once a week. That’s part logistical and partly anything shorter than a week doesn’t usually show enough progress. If there’s some bigger change we’ll also keep our work iterations but pause the larger play tests until it is done.

Short as possible is good advice but you’ve got to look at your own context and make sensible decisions. You can also look at it like following a gradient, if you’re unable to make bigger changes then you’ll just be optimising towards some local maximum.

Micromanagement itself is more about the amount of agency to decide what to do at each iteration.

Even worse it means you are always reacting to the latest or "loudest" issue (like the CEO wanting a feature implemented that no one will use but will impose a maintenance burden) and never standing back to evaluate what is valuable for the majority of customers or product.

It doesn't necessarily mean that management is giving the feedback.

It could be coming from tests, from CI, from the QA team, from customers, from other engineers in your team, or, failing all that, then yes from management.

But if management is giving feedback that is hard to reconcile with everything else, at this point you can point to CI, the previous tests that were added based on other requirements, feedback you got from customers etc. as justification for your existing actions. It means you're operating with a lot less assumptions because you get data validating what you're doing (and where you should fix things) every step of the way.

I would like to interpret “feedback” in the parent comment as communication. And I think we should distinguish between frequent communication and micromanagement. One may report to their manager frequently. Doing so has the benefit of letting manager communicate back any context they might have regarding the current status. Perhaps, that problem has already been solved in some other situation. Or, the manager has experience in a similar domain and can give direction. Unless the manager dictates a direction, doesn't leave enough room for decision autonomy, or begins working on a solution rather than leaving it to the engineer, I wouldn't call it micromanagement.

In my experience, if the management, processes and teams aren’t trusted then it can turn into unwelcome micromanagement.

Engaging with people, who have different motivations and reasons for being in a job, and stripping away often unhelpful implied titles of rockstar programmer to QA robot, can help everyone to see the big picture and in turn to see how their contributions, their cogs, fit into that picture.

Production-line programming can be left to new automated systems, whilst we can embrace and capitalize on people exercising their intellect for productive, feedback-oriented work.