I am the manager of a small team of developers (5 engineers, including me).

A few months ago, on the suggestion of another colleague we introduced mandatory code formatting in the code base, for our main project. Our project is in Python and the formatting tool is black (not relevant, I guess).

I find value in having the same 'appearance' of the code in all the project files, for me it is part of the Quality Assurance for the whole project. Code merge requests have to be formatted with the tool otherwise they cannot be added to the software.

Since then, a colleague is always complaining and expressing disagreement about this decision whenever the occasion happens.

How would you deal with such situation ?

What would you answer to "code formatting is totally bullshit", "it's like colors, some people like it red some other blue that's it", "it reduces my freedom", "it makes code more complicated to read with no added value" etc. ?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. Commented May 19, 2019 at 18:38
  • 1
    You may want to edit to clarify that there is no actual time consuming problems with editing the code or checking in (I do have issues with formatting that can't be sensibly set to default in my IDE - I'm not really fan of adding spaces manually to make formatter/style checker happy). Clearly answers show that you are looking at inter-personal issue and not actual pain point you've introduced. Commented May 19, 2019 at 20:14
  • 1
    One things which might help us understand your situation a little better is whether you discussed this decision with your team before it was implemented. When you say "we introduced mandatory code formatting" do you mean "we the team decided to..." or "as the team manager, I decided our team would..."? Did you have constructive discussions with your team before implementing the reformatting, if so, did your 'lead developer' raise any objections at that time? If so, were their objections listened to? Or did they do a pull one day only to find everything had been reformatted under them?
    – Mark Booth
    Commented May 20, 2019 at 16:50
  • 1
    @puck OP's using Black, which is a very sensible way of formatting code. The employee is being terribly unreasonable when complaining about that style.
    – T. Sar
    Commented Nov 22, 2019 at 16:02
  • 1
    @puck in particular, it guarantees that you don't see commits of bazilions of lines just because someone ran a different formater on the entire project and feels entitled to their opinion about it
    – njzk2
    Commented Apr 12, 2021 at 20:48

26 Answers 26


Honestly, my reaction would be the following:

Bob, I appreciate the feedback, but as a team we've decided that we're using Black as our mandatory code formatting tool, and that decision is final. I understand it's not your personal preference, but I'm afraid that you're going to need to learn to work with it.

But if I wanted to engage in a discussion?

"code formatting is totally bullshit"

That's not very constructive feedback, could you be more specific?

"it's like colors, some people like it red some other blue that's it"

Of course, but standardising on those "colors" is very helpful, and we had to choose one!

"it reduces my freedom"

So does agreeing to write code in the same language and version of that language, but can you imagine the chaos if we didn't?

"it makes code more complicated to read with no added value"

That's not true. After a while reading code in this format then it won't be more complicated to read at all - in fact it'll be simpler to read (added value there) because you'll only have to learn one style across the whole project. It also then means that diffs are much more readable for PRs, we can onboard other devs and get them up to speed quicker, and devs won't get hung up about what kind of formatting might look a bit prettier in a given sitaution.

To be clear, if his feedback was constructive - say of the format "I don't think Black is helpful to us for x, y and z reasons, since much of our code follows a, b c coding style which Black deals with poorly, have you considered (another tool) instead", then that's a very different scenario. That's when you should make every effort to engage in a discussion to validate his concerns, and work with him in addressing them.

  • 67
    but I'm afraid that if you want to stay in this team In my head I might be thinking that but I would definitely not state it in that way, at least at the start. This guy seems like someone that might escalate quickly and that wording will probably make him escalate faster. I would use something more like, "I understand it's not your personal preference, but I had to make a choice for the team and this is it." I think the overall goal is to help everyone understand the benefits and join the fold. If he continues to revolt, then you turn up the language.
    – JeffC
    Commented May 17, 2019 at 13:39
  • 12
    @JeffC Yeah, that's a fair point. I meant that it's a non-negotioable while he's working there, but reading it back, that comes across a lot more confrontational than I intended it to sound...!
    – berry120
    Commented May 17, 2019 at 16:04
  • 14
    but as a team we've decided that we're using Black as our mandatory code formatting tool, the OP never stated that was a team decision.
    – Akavall
    Commented May 17, 2019 at 19:17
  • 14
    "We introduced" does not mean that decision to introduce it was made by the team, it could have been, but it didn't have to be. I would be careful with claiming that something was a team decision, when it really wasn't.
    – Akavall
    Commented May 17, 2019 at 20:51
  • 10
    Re the code formatting, it does entirely depend on exactly how it's being reformatted. If it's automatically changing function definitions back to K&R-style, for instance, he may have a point. Or doing horrible things to fit into 80-char limits, or truncating variable names. Trying to find what he doesn't like about the standardised format might be useful for the OP.
    – Graham
    Commented May 17, 2019 at 21:24

How would you deal with such situation ?

After nicely comforting him, which you have already done, it's time to firmly tell them to deal with it. It is not an individual's code, but the company's. As a manager, you need the code to be as maintainable as possible by your team and new additions you make to the team in the future.

"code formatting is totally b***$hit"

As a coder myself, in the companies I have contributed to, some standards of formatting are enforced. As a lead developer, I would actually expect them to be a fan.

"it's like colors, some people like it red some other blue that's it"

As your manager I like red, deal with it.

"it reduces my freedom"

Code formatting does not impact freedom of creating a elegant solution. I call B.S. on this, and you should too.

"it makes code more complicated to read with no added value"

Ummmm nope. This actually makes me wonder if your lead developer is actually a lead at all....

To reiterate -- you have set a standard, as a manager or a team it matters not. The lead needs to get on board with it or perhaps move on.

  • 77
    @Eyal - Sometimes being an rear end of a donkey, is the only way to talk to an employee, who is being the entire donkey. (In other words an ass for an ass).
    – Donald
    Commented May 17, 2019 at 19:36
  • 6
    To me, if there aren't specific criticisms about the formatting style that the employee doesn't like (tabs vs. spaces, number of spaces per tabulation [which, as an aside, is really only an issue when spaces are selected over tabs], bracket placement, line continuation practices, etc.) then they are just being difficult for difficulty's sake. OP didn't indicate that employee had any specific criticism about the current tool, just formatting in general.
    – LJ2
    Commented May 17, 2019 at 21:25
  • 12
    An opinionated person is extremely useful once converted and can become useless when forced. There are times when the latter is necessary, but it is a great way to destroy productivity and motivation. The former is usually more constructive - a good investment for the team and manager in the medium-term if done right. It is possible to drive away someone that could be converted with the right finesse and understanding and who would be a potent asset. So I am sympathetic to what this answer is getting at, but -1 for not even acknowledging the other side of this trade-off.
    – mtraceur
    Commented May 17, 2019 at 21:53
  • 5
    The lead is not a team player. We always find ourselves in situations where we have disagreements. If you can't adapt to the team's or management's wishes you are always free to leave. Commented May 18, 2019 at 2:29
  • 2
    First of all, code formatting and syntax highlighting are different things and should be addressed separately. In USA, syntax highlighting can be covered under ADA accommodations for high contrast display needs. Second all modern IDEs can be personalized to reformat and highlight on the fly and can reformat code to company standard at commit. Best answer should have been adopt company standard AND provide support & permission for programmers to personalize code display to enhance readability on their workstations. Sometimes a Boss needs to an ass but not this time.
    – Melioratus
    Commented May 18, 2019 at 23:00

I would try to convince him of the positive effects of uniform code formatting. Git diffs become much easier to digest when commit n and commit n+1 have the same formatting. Maintainability becomes easier, assuming the formatter enforces good practices. In the end, corporate software development is a team sport.

If your code formatter allows defining rules, ask him if there are certain rules that he dislikes and consider discussing them with your team.

  • The biggest benefit of easier to digest diffs is that now you are only concentrating on the actual code differences, and not having to use up your limited cognitive attention on irrelevant formatting changes. Or, given the question is about Python, formatting changes that may or may not be irrelevant. Our team has started to do formatting-only commits followed by the actual code change commit to avoid this very issue. Commented May 17, 2019 at 12:45
  • 23
    +1, I would work with you. This answer is the only one that doesn't try to convince the employee that the implementation is the right way, but that the goal is the thing to keep in mind. By offering his input, he gets to contribute to the best solution. The answers like Tell him to suck it up or leave are trash. That's not leadership. Commented May 17, 2019 at 14:13
  • 5
    "Git diffs become much easier to digest when commit n and commit n+1 have the same formatting." on the other hand they become much harder to digest when you are forced to change the indentation of a large block of code just to add or remove a conditional. Commented May 17, 2019 at 16:26
  • 12
    I feel as though this is the more emotionally intelligent answer. My tech lead has fought our manager on certain process standards, but they can usually agree to try it out for a quarter and continue the conversation. "Suck it up and deal with it" approach isn't my cup of tea even if the employee is the one with the bad attitude. As a manager you have to rise above and not stoop to that level.
    – jcmack
    Commented May 17, 2019 at 18:24
  • 1
    @PeterGreen, one of the beautiful things one can do with git is rewrite history, such that everything is in Blackened form ever since initial commit. Do that and add ongoing enforcement, and you have no changes without semantic meaning in history... ever. Commented May 19, 2019 at 3:04

How would you deal with such situation ?

I would try to understand the recalcitrant developers point of view. They may have good points to make that I'm ignoring.

Background and supporting experience

We implemented auto formatting on our codebase a few years ago and it caused no end of problems, partially due to the way it was introduced, but mostly due to the way it impacted our workflow. It caused so much extra work fixing merge conflicts that in the end, we turned off many aspects of the auto formatting, so it only auto-corrected things which didn't cause more problems than they solved. We also went through every setting and included only those that everyone agreed on.

One problem with auto formatting is not only does it 'standardise away' bad formatting, it also 'standardises away' good formatting.

An auto formatter can't tell the difference between a double space accidentally added, and a double space added to make an element on one line, align with an element of another line. This visual association can make it much easier to read the code, as it can be far more obvious that two things on two lines are related.

If you are going to implement auto formatting, you need the whole team to buy into it.

You need to apply the formatting globally, in a branch, and only merge in that branch once everyone has had a chance to review the effect is it has on their workflow, raise their objections and agree a way forward.

Most people would buy into automatically stripping whitespace from the ends of line, few people would want their careful manual line splits for readability to be mindlessly re-split into the incoherent mess many auto-formatting tools produce.

My suspicion is that this developer is upset because they take pride in their work, have spent a lot of time making their code as readable and maintainable as possible, and this auto reformat has destroyed all of their carefully crafted formatting.

Even though the syntax of Python already places a number of requirements on formatting, it still leaves a great deal of latitude for the individual developer.

In short. Listen to your developers objections, you may be able to improve the code base for everyone. As PEP 8 — the Style Guide for Python Code says

A Foolish Consistency is the Hobgoblin of Little Minds

It is right there at the top of the guide for a very good reason.

Condidering jrhs comment, occasionally people who describe programming as "more an art than a science" get laughed at, but I disagree when it comes to the soft skill aspects of coding. Programs aren't just speaking to the compiler/interpreter, they are speaking to programmers who may have to fix, enhance or maintain that code in the future.

To address VGRs comment, I don't think this is a good place to critique black. I haven't used this tool, but reading through the description I can see mostly good things there, especially for long term maintenance and diffability (the bane of complex merges).

That doesn't help if the whole team doesn't buy into using such a strict and uncompromising auto-formatting however.

  • 4
    That seems to be the only part of PEP 8 that people ignore (ok, ok, that, and a lot of people have figured out that 80 characters is a ridiculous anachronism). Vertically aligned similar-parts-of-lines are superior. Fight me.
    – msouth
    Commented May 19, 2019 at 5:14
  • 4
    80-char limits are popular not because 30-year-old terminals had them, but because this way it's much more comfortable to see at a glance what the code is doing when you're just scanning it with your eyes. Long lines kill readability. Typographic guides for text usually recommend 45-70 characters per line. I often format my comment blocks to a width of about 60 lines because I find it to be a sweet spot in readability.
    – detuur
    Commented May 19, 2019 at 11:28
  • 3
    This answer touches on some important issues with auto-formatters that rarely get addressed; I'd consider careful use of non-standard whitespace that doesn't effect functionality to be a "hidden feature" of programming, and it can really help at times. The only counter-arguments I've ever heard against that are more or less "well then you spend more time making your layout than you do formatting", but I've never found this kind of work to be a waste, nor do I spend hours upon hours doing it...
    – jrh
    Commented May 19, 2019 at 17:11
  • 4
    ... and I guess to give a specific example, 1) Would anyone make the claim that indented, bulleted lists in Stack Exchange aren't useful? 2) Would everyone prefer it if they removed that for the sake of "standardization"? 3) Here's a sample of what that would look like. I guess I'd rather programmers be given all the same resources as a writer would have (when practical, I know font sizes and bold / italic would be problematic); remove whitespace at the end of the line and enforce tabs vs spaces indentation, sure, but I'm not a fan of taking tools away for presenting ideas well.
    – jrh
    Commented May 19, 2019 at 17:13
  • 4
    While you make some good points, I didn’t see any mention of automatic formatting in the question. I am strongly in favor of coding standards, but I despise automatic formatting, as the result is usually poor. How and where to conform to standards (such as the best way to break up a line) is a task best left to humans. mguijarr can enforce coding standards without the use of automatic formatting.
    – VGR
    Commented May 20, 2019 at 5:59

If I owned a bakery, I may want my bakers to use a standard size of loaf. It makes it easier to buy bags for the bread, for instance. I can have a consistent price on the loaves I make.

My bakers may feel that this restricts their creativity. Some may like to make very small, or very tall loaves of bread.

Other bakers may feel that they prefer a much bigger loaf.

This doesn't mean that there aren't valid reasons for setting a standard.

However some bakers may want to point out that the loaf size I have requested will not fit in the oven. I'd be a very sensible bakery owner if I listened to those bakers.

Your team member is already conforming to a wide range of standards which may restrict their creativity and contradict their preferences. This comes with working on a team. This doesn't mean that you shouldn't set standards, but it's probably wise to allow and encourage constructive, non-disruptive feedback.

  • 6
    I like the analogy. Consider it stolen for future use!
    – PeteCon
    Commented May 17, 2019 at 16:19
  • 11
    The analogy loses me a bit because unformatted code functions the same as formatted, which can't be said for bread. A small loaf will not do the job of a large loaf. It's really hard to compare this concept to a tangible, physical good.
    – Geobits
    Commented May 17, 2019 at 18:13
  • 2
    @Geobits A round loaf functions the same as a rectangular loaf, but they definitely require different bags. Commented May 17, 2019 at 19:09
  • 4
    @Geobits - There was a major SSL bug a few years ago within some Apple software that was caused a glitch in code formatting (i.e. writing two lines of code under an if statement). The example might be off the mark, I forget the exact detail, but It was a pretty silly coding error. The point is code standards serve a purpose.
    – Donald
    Commented May 17, 2019 at 19:40
  • 4
    This analogy falls apart in that programmers' output is expected to have a high degree of originality, whereas bread is expected to be uniform. There is room for debating whether a code-formatting program should always override the judgement of a human programmer (assuming that the human-produced code is reasonably conformant to the style guide, and that variances have their justifications). Commented May 17, 2019 at 23:37

"code formatting is totally bullshit"

Even if this had a point (and it does not), black/white statements like this often hint at a very immature understanding of:

  • how to deal with developer tools and discuss about their pros and cons in a balanced and context-rich manner (a.k.a. professionally)
  • how to deal with teamwork

We need professional and constructive opinions, not fanatic axioms.

"it's like colors, some people like it red some other blue that's it" / "it reduces my freedom"

No, it's not like colors. It's about readability, and about shared standards.

People doing this complaint are going towards the selfish path and do not realize the added value of common standards in dealing with code and, most of all, understanding other people's code and making them understand yours.

The fact that everyone has his/her own preferences, on the contrary, is exactly the reason why you should have coding standards, from comments, to naming, to formatting.

Sacrificing your "personal preferences" has to be done often for a greater good, good teamwork is all about compromise for the best result.

Imagine if:

  • developer A has his standard
  • developer B uses other formatting standards
  • new "C" developer would have to read code in two different styles
  • D in three... and so on.

It gets confusing and tiring because your brain has to adapt to different styles and constantly switch between them. With one shared standard, you just have to adapt once. In shared projects, even so if open sourced, you enforce standards for very good reasons.

And what if they edit the same file/class? Will it end up with different coding styles?

"it makes code more complicated to read with no added value"

I think what I stated above suffices as an answer to this utter nonsense.

Edit: please do look also at @nitarshs's answer, it gives another interesting angle from a group-psychology point of view that I found interesting.

  • @NathanHughes no, maybe bad wording, I'm not a native English speaker. I intended to say "people who bash tools with such ease".
    – Czar
    Commented May 17, 2019 at 19:21

Perhaps the root cause of the problem is not related to Code-formatting, but something else?

In my experience, this situation clearly shows that the dissenting individual has not expressed himself/herself in a mature and rational manner, immaterial of whether they are right or wrong.

I am not sure how long the individual in question has been with you and the team, but I really think you should know the person's disposition better to know how to handle situations like this

I have noticed that even rational people behave in irrational ways when they are not happy about something. Even they might be unaware of the true cause of their irritations.

Or its just possible that the person is immature by nature, in which case you can then choose to ignore them as long as they do their share of the work properly.

Maybe take them out for drinks/dinner and give them some care and attention. You should open up to them and let them open up to you. Try to know your teammates better and let them know you and the rest of the team better.

  • 2
    They may have a very clear idea what the other problem is and feel it is not up to them to bring it up. Commented May 17, 2019 at 15:55
  • Possible. In such cases, just ignore their comments.
    – nitarshs
    Commented May 18, 2019 at 7:34

This isn’t about code formatting at all. It’s about the worst form of micromanagement possible. Whenever a commit is made, a stupid mindless micro-manager changes the code in a stupid micromanaging way. And this developer is pissed off. (It seems some people didn't get this - when I say "micro-manager" I'm talking about the code formatting tool).

Your gain, and your teams gain, from all of this is indistinguishable from zero. Your loss is that you had arguments, wasted your time, and you pissed off someone who so far has been a decent developer. Best case you will lose his support and engagement. Worst case you lose a valuable team member completely.

Just turn the tool off and be done with it. It has caused and will cause more damage than it’s worth. Just decide: Do you want to show that you have the biggest xxxx to wave around, or do you want a team that is happy and gets work done?

  • 19
    Consistent code formatting makes working with other people's code a lot easier, and makes diff easier. In my opinion this is about professionalism and team work, not micromanagement. Nowhere does it say that the manager makes the code change, it's the developer that should make the code change before the commit. Commented May 17, 2019 at 18:36
  • 6
    I think you're making several unwarranted assumptions: that the gain is zero and that the person in question has been a decent developer whose lost engagement is due to being required to work more efficiently with the rest of the team. I don't think either is correct: most projects see efficiency wins (e.g. code review requires less deciphering of someone's “creative” style), and from the sounds of it this person already has issues working on a team and this is a manifestation of that rather than the cause. Commented May 17, 2019 at 20:34
  • 14
    The point of the code formatting tool is to eliminate all the nit-picking that goes on in code reviews. There is no micro-manager involvement here; the code formatter does its work, and that's that. Commented May 17, 2019 at 20:39
  • 7
    @DanielRoseman If you have code reviewers nitpicking at code formatting, then you have a real problem. And I don't know if I didn't express that clear enough - the code formatting tool is the micro-manager.
    – gnasher729
    Commented May 17, 2019 at 21:37
  • 2
    @gnasher729 nah, it's a crutch for those colleagues who cannot be bothered to provide cleanly formated code. If he got it "right" himself the tool would do zero changes. He obviously doesn't. So this is a way to prevent any discussion when someone else sees the changes undoing all the nice formating and dirtying up the code review. Commented May 18, 2019 at 3:05

A few months ago, on the suggestion of another colleague we introduced mandatory code formatting in the code base

Since then, a colleague is always complaining and expressing disagreement about this decision

The core problem sounds not with the decision per se but with the fact that this colleague's opinion wasn't taken into account when making a decision that heavily affects them. Was this properly discussed, with all the pros and cons carefully evaluated (that goes for the automatic part of the enforcement, too), or you just made the decision unilaterally "because I personally like it"? Practice shows that a person is extremely more likely to defend a group decision if they feel that their opinion was heard and taken into account, even if it didn't make it to the decision in the end.


This isn't about code formatting. It's about being a good and effective manager and enforcing a decision you've taken on how the team does work - which as you've said is considered and is likely to the benefit of the team, overall.

I think the problem is best illustrated by removing the specifics from your question:

I am the manager of a small team of developers

-- I made a decision on a detail of how we do work --

Since then, a colleague is always complaining and expressing disagreement about this decision

It's a people problem - the hard part of being a manager. It's tempting to try to address the content of the complaints because they're familiar, comfortable territory and can be argued sort-of objectively.

But resist that temptation, because what you really have to do is tell this team member, directly and unambiguously, that they must accept the decision and stop discussing it.

It's personal, it's uncomfortable, but doing so is part of the job and is what the rest of the team wants and expects you to do, I can assure you.

  • 4
    What is more, the cause is probably a people problem as well. While this colleague is protesting the result of the change, he may actually be objecting to the way in which the change was made, or some other aspect of the change. In which case the formatting is just a red herring, the real issue is something else, and the resolution is to discuss things with him, figure out what the real problem is, and address that. Commented May 17, 2019 at 15:50
  • If you are a good and effective manager then enforcing a decision you've taken should never be necessary.
    – Mark Booth
    Commented May 20, 2019 at 9:53
  • Authoritarian management may be effective in some environments, but for knowledge workers it rarely is. If you take pride in your work, then being micro-managed, having your decisions overruled or having your opinions ignored can be a serious impediment to productivity and creativity. When the shit hits the fan, your manager should be the one holding the umbrella while you fix it.
    – Mark Booth
    Commented May 20, 2019 at 10:18
  • @MarkBooth completely agree with this. My assumption here is that it's a decision that's been taken with the opinions of the majority of the team in mind - obviously if more than just this individual are against it, or if after trying it in practice his objections make sense and he changes your / other team members' minds, then of course you should re-evaluate the decision.
    – davnicwil
    Commented May 20, 2019 at 12:51
  • 3
    I'm not so sure. Given the "on the suggestion of another colleague" and "I find value" elsewhere, my assumption was that "we introduced" was using the Royal we. It is a common trait of authoritarian management for the dictats of an individual manager to be cloaked in a false or gaslit consensus. "Don't you remember, we all agreed to this at the last meeting?", "No, you suggested it, I explained why that wouldn't work and you said we'd discuss it later". Maybe I'm just getting cynical in my old age. *8')
    – Mark Booth
    Commented May 20, 2019 at 14:43

Realistically, people leave teams. Using stylers like these make it easier for another person to pick up the project in the future, and understand the actual content instead of speaking time understanding the formatting of it.

Try responding with a positive of using them. For example, "code formatters are bs", "well, it can be easier to find simple mistakes in code when you know how it should look" etc. Even better if they can be relevant to your project/team directly.

If it was more than one team member, I would have suggested holding a meeting explaining why this formatting tool is being used, the benefit it brings, and why it is so important that your developers use it. People don't like change when they don't understand the reasons behind it.

  • 3
    I agree. Right code should look right, and wrong code should look wrong. And the power in this is that the human brain, being a pattern-finding and meaning-making machine, will analyze the patterns of code it sees over and over and then build up a "sense" when something doesn't look right, with all this happening without conscious effort. Eventually, bugs are caught, or not even written, because "wrong code looks wrong." When a team is not consistent, each different member will experience false "warnings" about wrong code, only to discover it's just a formatting difference. That's bad.
    – CodeSeeker
    Commented May 17, 2019 at 16:31
  • 1
    @CodeSeeker: well said. Commented May 18, 2019 at 19:22

Far from a complete answer, but there is one point in here that sticks out to me. The code formatting in your commits in no way needs to be the same code formatting as is used in a developer's IDE while they work on a local copy of the repo. I don't know that I've ever worked on a collaborative project where every developer didn't have their code formatted just how they wanted it. Applying the formatting upon commit is easy enough to set up through git hooks.

  • 3
    Wholly agree with this response. pre-commit hooks are the answer. Other VC tool have similar controls. The most basic use for this is to ensure consistent line endings in mixed development environments. Developer is free to do whatever he likes, but the commit hook ensures "clean" commits.
    – Ian W
    Commented May 17, 2019 at 19:43
  • This is exactly what I was thinking, how I format code, is very different from how the other developers in my group format theirs. When they open my code in their IDE (we generally use VS Code for web stuff, and VS Studio for desktop), it shows up in their format. Admittedly we're not writing Python, which requires rigorous indenting handling, but there's no reason how a given dev has their code formatted should make any difference to how others format theirs.
    – delliottg
    Commented May 17, 2019 at 22:11
  • @delliottg: Yes, and using such an auto-formatter might solve the python problem, where code written by someone who uses literal tabs for indentation falls apart in an editor with different tab spacing.
    – jamesqf
    Commented May 18, 2019 at 17:16
  • And we have exactly that, one of our senior devs likes to use spaces for indents, I prefer tabs, but I don't reformat his code to remove the spaces, and he doesn't change my tabs to spaces. (Remember we don't use Python or other indent formatted languages). We argue about it occasionally, but it's not a big enough deal to any of us that we want to enforce it with a linter or some other tool.
    – delliottg
    Commented May 18, 2019 at 19:28
  • I am not sure that people who suggests this actually are developers working with code. Automatic reformatting makes merges, linenumbers and diffs a nightmare.
    – eckes
    Commented May 20, 2019 at 7:11

Ultimately, as other answers have said, as a manager you have the authority to simply enforce a code style, and if someone doesn't like it, they can quit. However, this probably isn't great for morale or engagement, and an employee who begrudgingly forces their round code into a square style probably isn't happy or productive.

To that end, your best course of action would likely be to convince them that having a consistent style in a codebase is beneficial. Some answers have presented some points already, but there are articles and in fact entire books arguing in favor. They're right that it's like colors - everyone does have a favorite, but if every UI developer working on a project simply chose their favorite color to design with, the final product wouldn't look good at all.

A couple good articles I've just found with a quick search:


I find a big difference between insisting on well formatted code and an auto-formatter being imposed on checkin.

At my job we have a code-formatting mandate of sorts, which is loaded into the IDE, but when it goes really bad there's really something we can do about it because nothing will try to re-apply it at commit time.

I'm willing to believe you have a real problem of a lead developer deliberately doing things so that they're harder to pick up, but it's entirely possible that what's really going on here is the autoformatter is messing up hand-formatted blocks where the language has been bent into something else and so needs a different format matching the structure it actually has rather than what the parser believes it has.

These cases are not distinguishable from your post. Depending on what is going on, you may or may not be able to talk to your other developers and find out which it is. Beware of the attitude of "I believe its better because the boss does" though; it won't be spoken to you but I've seen it fall like that before.

It's actually possible everybody has a problem with it, and they're all letting this guy be the spokesman. Maybe you can find out.

But on doing your due diligence, if you find he's on a power trip, it's time to get rid of him.

  • 3
    And if you find you are the one on a power trip, you may want to think about how that is going to affect the performance of your team in the future.
    – Mark Booth
    Commented May 20, 2019 at 10:05

You have a frank conversation about what the word "professionalism" means.

Your "lead developer" is acting like a pouting child. He/she may have the technical skills of a lead but is obviously lacking the professional skills of a lead. It's about more than just writing code: technical skills are a necessary but not sufficient prerequisite of that position. Being a lead means, at least to me, understanding that it isn't about you. That doesn't mean that you don't negotiate and advocate for yourself, it does mean that you don't throw a fit about things that are industry best-practices even if you privately think they are bullshit (lookin' at you, JIRA).

I would start by saying that he/she needs to get over it diplomatically, then move on to saying it undiplomatically, then move on to a PIP. You've already wasted too much of your valuable time on someone else's temper tantrum.

EDIT based on conversation in the comments

One commenter correctly points out that the tech lead's authority may have been unfairly undermined thus causing disgruntlement. While I certainly agree that might be the case, grumbling about the tool in public is an unprofessional and unacceptable response to the situation. Being undermined should be addressed directly, and in private.

  • 8
    I've known a few programmers who couldn't understand the need for consistent coding standards. If they can't understand that, I guarantee there will be other important things about programming that they can't understand. There's no cure for it. Commented May 17, 2019 at 18:11
  • 3
    @jamesqf “Consistent” in the sense that the whole team does it the same way, preferably a way (PEP3 in OP’s case) that’s common in the industry and easily understood by new team members. In C#, on my team, we use the VS defaults. Not my personal favorite, but very clear and very close to universal — which is much better than just meeting my private aesthetic standards. Commented May 18, 2019 at 17:21
  • 2
    My suspicion is that the 'hissy fit' was only after the lead developer had already had their authority unreasonably undermined. Remember we are only hearing this from the OP's point of view, so the best we can do is read between the lines. Now it's about damage control, and that means listening, not dictating to them what 'professionalism' is or talking about disciplinary action, as this answer seems to be doing. Speaking of which, you may want to define what you mean by "move on to a PIP". I presume you mean "Professional Improvement Plan", but I can't be sure.
    – Mark Booth
    Commented May 20, 2019 at 16:04
  • 1
    @MarkBooth yeah, performance improvement plan. And no, I realize now that I do disagree with you: even if authority was unreasonably undermined (and you're right, it may well have been), you call that out directly, and in private. You don't do it by grumbling about the tool in public. I call shenanigans. Commented May 20, 2019 at 16:10
  • 1
    @EdPlunkett Including the section of PEP 8 (I assume you meant 8) that says "A Foolish Consistency is the Hobgoblin of Little Minds"? Commented May 22, 2019 at 21:47

I'm going to assume your representations of your lead developer's comments are accurate.

These are not the comments of a competent lead developer. I say that as an experienced software and manager of software engineers myself.

The feedback is unconstructive and highly inaccurate. A lead developer who does not understand the value of formatting standards is a lead developer who doesn't understand the dynamics of collaborative engineering.

It's quite possible that they do have legitimate and actionable concerns and I would start from this perspective. You're their manager; help them do their job well.

First, privately call them out on their crappy feedback to you. They are doing their job poorly, if they're just kvetching.

Next, demonstrate that you are open to actionable feedback on how to improve the implementation of coding standards if your developer has any. If they need time to figure out how best to articulate this, give it to them.

If they have nothing specific, then tell them to get with the program and stop bitching. It's not just unproductive. It's detrimental to the team.

You should also start paying attention to their performance as a leader on the team in general. Are they actually providing leadership to the other team members or are they simply the person who has been around the longest? Folks like this can really undermine a team's productivity if they are just acting as a gatekeeper to growth (which is what this individual is doing right now).

  • I would suggest the most likely explanation is a manager on a power trip, representing what the team leader says in the most negative light possible. For example I find it highly unlikely that any developer says “code formatting is nonsense” because you don’t actually have any choice but formatting it somehow, but that someone says “code formatting tools are nonsense”, that I can believe.
    – gnasher729
    Commented Jul 5, 2019 at 10:20
  • Certainly possible, but I have definitely heard senior engineers say the most asinine things about "their freedom being restricted" when what they really mean is "I can't be bothered to consider the other people who will be looking at this code"
    – Dancrumb
    Commented Jul 5, 2019 at 15:15

From a pragmatic point of view, I love code formatting simply because it makes diffing code so much easier. It will also make pushes much easier since if everybody is using the same code formatter, then in principle, adding a dumb inconsequential change to a file won't result in git thinking that the code has changed.

Personally I am not crazy about how the code looks, but the benefits outlined above more than help me overlook this.

  • -1 This doesn't answer the question. Yes, code formatting is nice, but OP already knows that.
    – Chris
    Commented May 21, 2019 at 5:53

Many other answers discuss if code formatting is worth it or not. That is entirely irrelevant to this question.

This is about communication, not about convincing him that standardized code formatting is great. Take a step back. What you need to communicate is:

  • What you're trying to achieve.*
  • How you're planning to measure success.

That extra bit of information will allow them to see things from your point of view, which is oftentimes enough to pacify them. The second part (measuring success) is necessary to demonstrate that you actually put some thought into it and makes it easier for them to trust you. It also allows them to find alternatives or modifications to the policy which satisfy your requests as well as theirs.

If that fails, there are 2 major ways to deal with employees who disagree with a policy change:

  • Listen to them. They are paid professionals and their concerns may be more valid than you think.
  • Shut them up. "This is the decision. I know you don't like it, and I have heard your concerns, but now I need you to accept it and work with the team."

*This is not about a list of benefits, it's about your motivation to implement the change. Maybe you want to empower the team and that's why you had the team decide on code standards and formatting. Maybe you just implemented a suggestion from higher up. Maybe you're planning multiple automation and/or analysis changes down the line that will benefit from standardized formatting. Maybe you want to use standardized formatting to better sell your team to the higher ups. Maybe you pushed standardized formatting simply because you like it.


I think that in this case it would be maybe possible to add a git hook that changes the code format to the one desired by the team on commit, and another one (used only by them) that changes the code format to the one desired by the team member on update.

If the team member feels so strongly about this, it may also be a good occasion to learn more about the code formatter and the git tooling, all knowledge that may handy later on.

  • 9
    A big no. It's prone to inconsistencies and there's no way the whole team must adapt to groundless whinings of a single.
    – Czar
    Commented May 17, 2019 at 13:27
  • 3
    I kind of like your idea, but there's just too many things the tooling can't fix (e.g. anything in comments like example code in autodoc annotations, any newer syntax it hasn't been patched for, etc.). It's not worth having to constantly double-check the offenders code and go through multiple code review fails on every pull request. Commented May 17, 2019 at 14:32
  • I don't know how relevant is is to python, but we used to have a tool (more limited to diffing/merging) that was aware of the language syntax, and did syntactically aware diffs.
    – Cinderhaze
    Commented May 17, 2019 at 15:09
  • This sounds ridiculously error-prone, and the type of colleague strikes me as someone, who would oppose any codestyle or autocorrection (i.e. he is not consistent in his own style). This is not feasible.
    – Chieron
    Commented May 17, 2019 at 18:25

code formatting is totally bullshit

This can easily be disproven by taking some example code (unknown to the developer), removing all newlines, tabs, and reducing multiple spaces to single spaces, and asking the employee to tell you what the code accomplishes.

it's like colors, some people like it red some other blue that's it

Yep. This is the case for pretty much any programming dispute. Tabs vs spaces, C-style brackets or egyptian brackets, ... But the answer is always the same: Some people like to drive on the left, some people like to drive on the right. Either is fine, but allowing both at the same time leads to madness.

Or, if you really want to use his analogy against him: but using blue and red together makes purple, which means that no one gets what they want.

An executive decision has been made to pick this format. Your employee does not have the authority to override that discussion. End of story. I would not endulge this line of questioning any further.
I'm always open to constructive feedback but your employee's argument is one of hardheadedness, it's not constructive. Don't let them turn it into a competition of being the most stubborn. Even if you win, you're signaling to your staff that being stubborn is an acceptable way of expressing disagreement.

That doesn't mean you can't help him if it's simply a matter of inexperience. Maybe you can find an automated formatter so he can type in his own format and have it converted.

I've told the people I managed that I don't care about the readability of their code before they check it in. I'm not expecting them to fully uphold the style guide at every second. As long as the code gets cleaned up before it's merged into the branch, that's acceptable. I often start from quick and dirty code and only clean it up once I got it working. Some people work this way, and that's okay, as long as they don't skip the required cleanup in the end.

it reduces my freedom

No one has the freedom to do whatever they want. Having to pay the employees reduces the company's freedom too.

The effort required to format the code from the get go will pay back dividends when someone else has to read their code.

Given this employee's remarks, I suspect it's likely that he's complained about other people's code formatting or naming conventions. Point out that others will feel the same about his formatting and naming. Uniformity means that everyone can read everyone's code, regardless of whether it's everyone's personal preference.

it makes code more complicated to read with no added value

It's harder to read for him now because he's not used to it. The more he resists the change, the longer he's going to struggle with it. The decision has been made, it is happening, end of story.

I would focus on the point that the employee has been informed of the new format, and is expected to now uphold it. If they don't comply (or don't put in genuine effort), any delays caused by their pull requests being rejected falls squarely on their shoulders.

Code merge requests have to be formatted with the tool otherwise they cannot be added to the software.

When you say "cannot", do you mean that it's not allowed, or that it's not possible (e.g. a reviewer will always reject the request)?

If it's the latter, that's the stick you need. If the developer does not follow the formatting rules, their requests do not get accepted and any delays incurred from this are their responsibility, which will result in a bad performance review.

If it's the former, then you're really relying on everyone to willfuly partake in the system, which only works if everyone does so. You're currently dealing with someone who's holding out. It's possible that he's holding out specifically because he knows that you don't enforce it but only ask.

  • So you blindly believe what OP told you. He’s clearly failing as a manager, and wants support here, so I wouldn’t believe that any of his quotes are accurate.
    – gnasher729
    Commented Jul 5, 2019 at 10:26
  • @gnasher729: It's not a matter of belief. SE does not have a format which allows for the counterparty to tell their side and then lets us arbitrate between two opposing parties. The Q&A format inherently ties us to the content of the question as asked. I can only answer the question as asked, its applicability in real life is wholly dependent on how much the question itself is grounded in real life. Though commonly expected, there is no true safeguard for fictitious or misrepresented situations.
    – Flater
    Commented Jul 5, 2019 at 10:30
  • @gnasher729: Secondly, by what measure do you grade OP to be "failing as a manager"? They are unsure how to approach an employee who, to OP's experience, is resisting a team convention with no real reason other than the unwilligness to adapt. How does trying to solve the problem and acquiring additional insight equate to failing as a manager? Do you go around to all posted questions on SO/SE and point out the incompetence of every OP because they don't know the answer to their question?
    – Flater
    Commented Jul 5, 2019 at 10:33

You're a manager, so let's try to manage him (and this), don't just tell him off or view him as a problem:

"John, my responsibility is to make this as easy as possible for everyone, and for future employees, not just some of the people here today."

"When most developers looks over code, its faster if they can take some things for granted, like the way the code will be done, and the way some things are standardised. If there is ever a need for anyone to scrutinise the code [External code audit? Liability? Due diligence?], its better if it is standardised. You're right that some like blue and some like red, and outside work, you and I can both code in any way we like. But while we're writing code that a team has to maintain, and future engineers have to quickly and accurately understand, my belief is that standardisation will help, and I'm leading the team - not you, not Bob, not Alice, so I have to make those kinds of calls if I feel the need - and I do."

"When you find yourself managing projects like this in future, you can make the call you like, and expect others to follow your directions. But I hope when you do - and you're good so you probably will [a compliment never hurts if it's true, if not leave out] - that you'll reconsider and see the benefits it gives, even if it imposes a discipline that you don't see any point in, right now."

"I believe it will save small amounts of time in every days work, when code is redone, I believe it will reduce errors, and I believe it is professional. I'd like you to respect that even if you don't agree with it."

  • 1
    Keep in mind that the lead developer likely knows better than the manager how to develop code successfully.
    – gnasher729
    Commented Jul 5, 2019 at 10:24

Whitespace is actually part of the python syntax. Readability is already designed in the language. In fact, python has it's own recommendations on how to format your code. Best Practices, naming conventions, etc. it's called PEP (more specifically PEP8). Start there! Knowing PEP is something they can add to their resume!

How would you deal with such situation ?

I think the four other developers are on the right side of this argument and you may be in the wrong here. Honestly take in the feedback of your employees and take it to heart. Put yourself in their shoes. If there paycheck is based on performance, and this tool reduces that, you're essentially taking money from them in their mind.

I think a good next step is to decide whether or not to continue using the tool. If you deem it beneficial, explain why. For example, if the End-User/Client gives you better reviews or future projects because the code is beautiful - tell that to your employees! That means more money in their pocket!

Remember, your KPIs for Quality Assurance may not be what is in the job description for your team members. Make your team have buy-in on their projects. Make it something they are proud to own. When a strong sense of ownership is a workplace norm - quaility assurance comes naturally.

  • 9
    Only one developer on the team objects to consistent formatting, not four. The tool OP mentioned, black, enforces PEP8. It is not realistic to claim that consistent code formatting reduces anybody's performance. Quite the reverse: The value of consistent coding habits (including formatting) is in ease of maintenance. The job performance of a programmer is not a function of how many if statements he can type in a given hour. Commented May 17, 2019 at 17:18
  • 2
    @EdPlunkett It's funny that you say "it enforces PEP8" because one section of PEP8 says that it should not be enforced. Therefore enforcing PEP8 is not actually conformant to PEP8. Commented May 22, 2019 at 22:45
  • 1
    @immibis You’re a gift, my friend. An absolute gift. I never knew sovereign citizenship had been ported to Python. Commented May 22, 2019 at 22:50
  • @EdPlunkett I nominate this for the most nonsensical comment of the month. Commented May 22, 2019 at 22:58
  • Right at the top of PEP8: A Foolish Consistency is the Hobgoblin of Little Minds!
    – Mark Booth
    Commented May 24, 2019 at 14:31

Two additional points may be worth considering.

  1. You're asking for a black/white answer for a grayscale problem. Your code formatting rules could be reasonable, could be relaxed, could be nitpicking. I have seen all kinds of rules. So first, of all, check if the code format rules you demand are actually reasonable or not.
  2. Was the code formatting and all the code standard rules just imposed from above, or agreed by the developers in the team - those who actually write the code and who read / use the code from others? It might be a good practice to decide on a set of coding standard rules by committee - once only, and then these rules are enforced. If most of the devs agree to them, then you have a high chance of these rules being reasonable, and if anyone complains, chances are, he is the problem. If the rules were simply imposed by decree of one person... well then you might have a problem there.
  3. An alternative is to find a code inspection / formatting tool that's more or less the industry standard for the language you use. For example, for C# I use Resharper. Then the decision will be unbiased, and the formatting can more or less be done automatically in the editor, as the code is written. If Resharper is happy, I'm happy. Find something of that sort for Python.

My personal rule of thumb when I lead a team is to only insist of strict rules when someone's code looks really ugly... and if that happened, we could be looking at a deeper problem than just code formatting. A problem that starts from HR and hiring the wrong person. Otherwise, if the code looks more or less clear and organized, and its architecture / design is good, nitpicking about formatting often causes more trouble than it's worth.


Consistency is a weak argument. For a person who doesn't agree with a particular formatting rule, it might feel like there's a problem with micromanagement or with a power-hungry architect. Formatting almost never matters - "it's like colors, some people like it red some other blue".

The real benefit of automated formatting rules is that programmers don't waste time discussing stuff that doesn't matter. Too much time is spent in code reviews on comments about indentation. Much more brain power should be focused on real problems with the code.

Introduce the developer to the term Bikeshedding. Make it clear that you consider his comments a great contribution to bike shed design. He wastes time of others. He is a bad team player. It will be used against him during evaluation.


In addition to the other responses which covered The Talk pretty well already - a methodology to introduce formatting in your process whether Bob likes it or not:

Do code reviews using the four eyes principle on each and every merge request. Your master should only be modified with accepted merge request, no other way. All merge requests must be subjected to quality assurance, i.e. a different team member must look over the code. Enforce formatting and let Bob's MRs be rejected due to wrong code formatting.

If Bob refuses to comply, then his merge requests will be stuck in limbo. When asked, "why is feature XY not done, despite the deadline having long passed?", Bob may respond, "this has been done for a while, but got rejected by colleague Y". You can argue that it is then not done. This is what quality control is for. Coworkes must reject such requests and reassign Bob, it is then Bob's job to deal with it.

There are various degrees of agressive if acting this way, so if you want the tone to stay as friendly as possible, be careful about how you implement this. Nevertheless - you should do code reviews anyway.

On a personal note - Bob's supposed statements about usefulness of formatting incline me to think they are possibly not suited for a lead role or simply lack some specific education in certain areas. Maybe they know the codebase in and out, but due to lack of best practices helped turning it into a giant mess and only they know a path through the chaos. This kind of thing is dangerous, because you may become very dependent on one single person as your codebase grows less and less maintainable.


There are a lot of answers here which focus on good technical arguments. To summarize: the team made a sound decision on how to proceed, and one individual rejects the team decision and the manager directions.

The conversation which I would have is more along the lines of: did you just call my instructions and the team decision "bullshit"? Did you really complain that being paid for working "restricts your freedom"? I strongly suggest you check in your code nicely formatted right now, and I will arrange a meeting with HR to discuss respect toward your employer, manager and team.

  • 5
    So you're saying a decision is the right decision because it comes from above and respect should be there? I would say no, that's exactly not how tech companies should work, coders should be convinced of what they do and how, not forced. That would be very unproductive up to dangerous.
    – Mayou36
    Commented May 18, 2019 at 10:06
  • 1
    @Mayou36 No what i am saying is: calling team tools "b******t" is out of the range of professional communication, especially if you have no solid arguments. And stating that guidelines at work "restrict your freedom" is kind of a weird understanding of a working contract. Especially for something which actually is a team topic.
    – Sascha
    Commented May 18, 2019 at 10:16
  • 3
    Re "the team made a sound decision on how to proceed", I get the impression that is wasn't the team as a whole which made this decision but rather the manager which made the decision and wants our advice on how he/she can impose it on their team. Hence the problem.
    – A E
    Commented May 18, 2019 at 12:35
  • 1
    No. you might want to think it isn't. Do that kind of thing routinely and your staff will tell a different story when they go home from work. And that's the story that counts, you don't get to do a GWB redefinition that waterboarding isn't torture really, or making those kind of threats (which is what they are) as your basic response isn't bullying really. They'll see it as such, and your team will be the loser. Don't do bullying behaviours, even if you don't consider that the right word for it.
    – Stilez
    Commented May 18, 2019 at 17:08
  • 3
    The question is, who is the bully in this situation? The lead developer whose authority on the project has just been undermined, and (somewhat) understandably reacted adversely to the news, or the manager who is now looking for ways to get their developer to fall in line with their pronouncements? Only having access to one side of the story makes this difficult to call. For all we know, the comments quoted by the OP may have been made by the lead developer off the record, in private, in bar after work. Context is all, and we just don't know.
    – Mark Booth
    Commented May 20, 2019 at 16:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .