There's two reasons, to me, why formatters make a lot of sense. First, working in large teams, not everyone will agree on a formatting convention and it's very

There's two reasons, to me, why formatters make a lot of sense. First, working in large teams, not everyone will agree on a formatting convention and it's very difficult for people to internalize the convention and stick to it. This leads to, at best, inconsistencies in the code and, at worst, bike shedding discussions on which conventions to use that distract from shipping actual features. When HBO's Silicon Valley had its lead character lose out on a promising relationship because of a spaces vs tabs argument, it hit dangerously close for those of us that have had to endure a months-long meetingfest to arrive at a company standard for code formatting. Once you've been through that hell, you can appreciate the simplicity of just invoking a tool during the build process. Second, there's what I'd call the "Mark Zuckerberg clothing" reason. When asked why he always wears the same style clothes, he said, "I really want to clear my life to make it so that I have to make as few decisions as possible about anything except how to best serve this community." Similarly, code formatting doesn't deliver value to customers/users. The more you can ignore it, the more you can focus on other things. When I first started using code formatters, they irked me greatly. But once you get used to them as a part of your process and start to feel comfortable reading the code they spit out, they transition to being liberating. The formatting fades into the background and all you see is the logic in the code. And I didn't realize just how much time I was spending getting indentation levels correct and aligning things until I entirely stopped doing those things. Now I write code that looks really ugly until I hit save and then it looks exactly the way that the rest of my code looks.