How to work with new employee who questions everything with unrelenting dogmatic standards from past job

Question

I have worked for an existing small, tech/dev company as a senior employee since the companies inception 2 years ago. A month ago we hired a new junior employee. He's a good worker so far, but I've realized he's got a lot of dogmatic standards about his programming style. We've got a well established code base, and at first he was making blanket changes to code styles without asking, leading to further discussion as to why. The blanket changes have stopped, but the aggressive discussions and pushing has not.

We've had a few good discussions on how to improve the quality of the code base, and some of his suggestions have been implemented to improve things after discussing. However, he is quite dogmatic, and seems to refuse to accept that any of his ideas could be declined. In some cases, as the senior project lead, I've not agreed to accept a major project wide ruleset.

My reasoning is often that I don't agree that his changes improve things for the better, and having such a strict ruleset doesn't create positive results for the team. It creates a level of unneeded code management. Usually I suggest adding it to a list to be regularly reviewed later. Some examples of his suggestions are removing every bit of commented code (code that needs comments is poorly written?), removing line breaks he deems unneeded, as well as curly brace positioning.

What I get back from this new employee is aggression as to why I wouldn't accept this. His reasons are past projects that implemented them, or reference to some Google standard that may suggest them. He points to a book he respects. I do not believe every piece of code needs full regulation if well written. I've got plenty of architecture goals for the project, but less have to do with spacing, line breaks or removing code comments.

My question is how to work with this new junior employee as an existing senior employee? It's a small company and everyone is mostly a peer, but I'm his advisor to the project, and have been leading it for 2 years. I've brought it up to the CEO who has suggested a group meeting-- but I feel like this is becoming a matter of whoever speaks loudest the longest wins. More regulation is not necessarily better.

Answer 1

This shouldn't be about coding standards, this should be about the workplace.

This young man seems to see only two ways - his way or the high way. It seems to be the kind of person who drains the life out of you, and destroys any fun that you can have at work. Give him a chance to find a place where he can fulfil all his dreams of complete control - somewhere else.

Seriously, someone who involves you in a long discussion about positioning of braces is not someone you want in your team. (There is only one proper positioning of braces, and that is by doing it consistent with the existing codebase).

Answer 2

I hope you make notes on his objections along with your position on why you do the things you do so you prepare the next employee. Under no circumstances should he have had any notion that he could come into an existing team and project and do everything his way. He should have been told, these are the things we're going to do until I'm convinced otherwise. He should have known what he was getting into. This has nothing to do with being harsh, abusive or unwilling to change. Everyone who is in charge at some point has to have their decisions respectfully followed.

Establish some structure for people to voice concerns and a time-frame for coming to a decision. If you are in charge, he makes recommendations, but you make decisions. Feel free to allow him to have a rebuttal or involve other members of the team and try for some consensus. At some point, he has to accept your decision and in the best interest of moving the project forward, your decision has to stand. He doesn't have to like it, but lack of compliance should have consequences. There may come a time when he can lead a project and will have more flexibility in doing things his way. I would suggest if he has any desire to lead, he needs to learn how to follow.

At some point, he needs to grow up and give up on "this is how we did it at my last job." Right or wrong, it's annoying and isn't much of a reason on its own. Things should stand on their own merit. You may want to address this personal issue in private.

All his access to any production code or applications is cut off. All of his code checked into source control is subject to review and will never get put into production until he complies. There is no beating the system. Hopefully, it's more important for him to get things done and do his job than to get his way.

Answer 3

As the senior developer, you can change his perspective.

Sit down with him and ask him how the changes affect his other colleagues. If he starts referring to books and rules and courses and standards, remind him that those are not his colleagues. Ask him again how those changes affect other colleagues. (He probably has no idea.)

Mention that your goal is to have a well knit team that is able to work well together. That's your priority.

The fact that he's junior probably means he has very little exposure to other people's code. He has little to no experience in coding for the sake of someone else's skill level, and coding with someone else's code. Let him know that his technical strengths are high, but he needs to know how to code in a way that helps other people too.

Answer 4

What is wrong is that you are trying to tackle this alone. I am in a similar group and role as yours (albeit a mega-company).

The first thing you do is reach out to your 2-3 best people. Bring up some of his ideas and figure out what their objections are or in general what their ideas are. You can do this as a group if you think they will have similar views and can keep the discussion private.

Code standards are just that, standards. There are some that everyone should do, some that take time getting used to (or changing old code) and you should set goals for these, and then there are some that are more opinion. These might save some companies time or might waste time at others. It depends on the amount of devs, the amount of code, how often it is updated, how often devs cross-pollinate, and so on.

So after you talk to your other devs, sit this guy down with the group and explain why you are doing things a certain way, what things are not changing, what things could change over time, and what won't change.

Open it up for discussion. Let everyone discuss. If there are no drastic events at the meeting, you are done for a while. Tell him, "Bob we just had a meeting about that and decided something different. Any ideas you have please hold them for the quarterly dev standards meeting. If you have a lot of ideas I can meet with you 1-on-1 before the quarterly meeting. Thanks Bob."

If there are minds changed at the meeting - don't let your other devs roll over - than you can either schedule a follow up or just lay down the law. If laying down the law opposed to a group consensus then just mention those things can be talked about and possibly changed at the next quarterly dev standards meeting.

The fact is you can't change standards all the time. Four times a year is about it and you could definitely move it to a bi-annual meeting.

Answer 5

First step is to move the discussion away from right vs wrong. Having coding/work standards for a team are important, but it often doesn't matter specifically what the standards are, just that everyone agrees to abide by them.

I would suggest a one on one discussion with the new employee, to avoid group intimidation, to discuss the standards your team has developed over time. The new employee needs to understand that the team not agreeing to use the suggested standard is not saying the standard is wrong, just that the team does not believe it should be added to the list of standards that will be followed.

Answer 6

I rarely find "questions everything" and "unrelenting dogmatic standards" in the same person since people who question everything are rarely satisfied with set in stone solutions. Are you sure you are really being fair and objective in your assessment of your coworker and his ideas?

You gave the following examples:

Some examples are removing every bit of commented code (code that needs comments is poorly written?), removing line breaks he deems unneeded, or an entire discussion about curly brace positioning.

Your objections were:

My reason is often I don't agree it improves things for the better and having a strict ruleset such as that doesn't create positive results for the team. It creates a level of unneeded code management.

None of the examples you provided seem to be anything that creates significant additional code management. The other objections you raise are very subjective assessments.

Maybe you and your co-worker should both put opinions and egos aside. Work with your co-worker to figure out how to evaluate ideas based on logic, merit, and objectively measurable results.