When I think about a good developer tool, I think about the work it lets someone do. The tool is there to help you understand a codebase, test an idea, or make a change. It should not become the main thing you have to manage.
That sounds obvious, but tools can quietly ask for a lot of attention. A setting has to be found. A warning appears without enough context. A background task changes what you are looking at. Each interruption is small, but the person using the tool has to stop, interpret it, and decide what to do.
Help has to arrive at the right time
An editor can catch a mistake before it reaches production. It can also distract you while you are still forming an idea. A warning is useful when it tells you what happened and gives you a sensible next step. It is noise when it makes you stop without helping you decide.
I do not think every tool should be quiet all the time. Some problems need immediate attention. The question is whether the tool can tell the difference between something that blocks the work and something that can wait.
Good defaults help. So does making a tool's actions visible and predictable. When it changes a file, runs a command, or stores information, the person using it should be able to understand what happened.
Approachability is part of the design
Making programming easier to approach does not mean hiding every detail. It means giving people a way to understand the detail when they need it.
A beginner might need a clear explanation of an error. An experienced developer might want the exact output from the compiler. Both are better served when the tool gives enough context and lets the person choose how far to go.
This is the kind of question I want to keep asking as I work on software: does this help someone move forward, or does it make them learn the tool before they can do the work?
The answer is not always obvious. It is still a useful question to ask.