> I open a draft PR the moment I make my first commit on a branch, for visibility. If the people responsible for reviewing your work don't want to see your wor

> I open a draft PR the moment I make my first commit on a branch, for visibility. If the people responsible for reviewing your work don't want to see your work in progress, just wait to open the PR. Consider that they may be inundated with all kinds of notifications and trying to silence things that are not immediate action items. Don't take it personally. If your director prefers it, just wait to open the PRs. > I commit a lot. There is nothing wrong with this. But consider that your commits ought to be easy for others on your team to use. They should be discreet units of work. This is useful for debugging if someone needs to use `git blame` or `git bisect` to figure out why a piece of code does what it does or when and why it was introduced. You can rewrite your commit history into discreet units of work by using `git rebase -i` and squashing some (or all) of the commits in your branch together before you open your PR. > The director expects senior engineers to have very little chatter on their PRs. They should be ready to merge with little discussion. In general, communication about your work as an engineer is important. It's one of my pet peeves when team leads complain about too much communication. That being said, there are at least two legitimate reasons for the director's position: first, as I mentioned before, they may have too many messages coming in and be trying to cut back on some unnecessary noise. Help them out with this by avoiding unactionable comments and things that you can take care of yourself. > Rather than linting before pushing, I enjoy waiting for Hound's comments and fixing them afterward. I suggest installing local linting tools in your IDE. There's no reason to burden your team with extra messages that you could have taken care of on your own machine. > The director went through my commits and saw some commit messages like "uncomment code", "remove commented block" While it's not a good practice to commit commented code, sometimes mistakes happen. You can squash these commits into the previous ones so they don't pollute your git history. Remember, half the point of git commits is to understand how and why your code got to it's current state. If you have to pass a bunch of accidental, cleanup, or whitespace commits to get to the information you are looking for, it can make it really hard to work with the code base in the future. In general, I don't really see anything wrong with this feedback, though I understand that it can be annoying to have to change your preferred working style. My advice, never escalate something like this. If you can't come to an agreement about it with your director, you have two options, either suck it up and deal with it, or start looking for a new job.