6

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.

  • 8
    How vital is this person to the successful completion of the project? It may get down to the point of "Thank you for your input but this is the standard we are following. If you dont like it you are welcome to leave" – JasonJ Nov 29 '16 at 22:36
  • "What I get back from this new employee is aggression..." - After being told your decision, did his behaviour change or did he go back and continue making whitespace changes, removing comment lines, etc.? – Brandin Nov 30 '16 at 7:50
5

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).

4

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.

  • "All his access to any production code or applications is cut off." - this sounds too extreme, especially if he already corrected his behaviour as OP suggests. – Brandin Nov 30 '16 at 7:58
  • @Brandin - Most places put new hires on a trial period with no access to production code until they prove themselves. I feel like the OP's team skipped that step somewhat. When someone indicates they're not going to follow the rules, I think drastic measures are warrented. – user8365 Dec 6 '16 at 0:37
2

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.

1

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.

0

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.

  • this is a good suggestion, and accurate to the goal. it's not that i want a different coding standard or believe his is better than mine. i just don't believe all rigid coding standards are productive at this point with just a handful of coders. i also don't like the standard it creates that all code must be reviewed, nitpicked line by line, to be a success. – Miro Nov 29 '16 at 22:43
  • 1
    @Miro: You really might want to rethink your stance on code review. If no one reviews code then you functionally have no standards since no one reviews to see whether code is actually meeting the standard. Also, people do not grow professionally when they rarely look at anyone else's code – David Cram Nov 30 '16 at 2:18
  • I think my frustration around his code review expectations is that he is reviewing for subjective things like line break usage, and not more meaningful things like architecture or choices in class setup. I don't object to reviewing all together. – Miro Nov 30 '16 at 17:55
-2

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.

  • I just wanted to mention, that I might have given a different answer for a different industry. Process and standards are enormously important in programming. In a small startup that is only 2 years old, I doubt these things are already entirely at the level they should be. As your company grows and ages these things will only become more important. So working these things out now is a wise time investment. – David Cram Nov 30 '16 at 2:05
  • 4
    A person with dogmatic standards is always going to question anything that doesn't match them. Perhaps your understanding of the original question does not match its intended meaning? – user53718 Nov 30 '16 at 2:27
  • @Nij: You may be right but there are 2 sides to every story. I feel like this story seems a little lopsided. As an experienced programmer, there is something about the OP's question that has me questioning what is really going on. So I don't know the real situation but I think it is worth considering that the description of his co-worker may not be unbiased and the company may actually have weak standards and processes. – David Cram Nov 30 '16 at 3:09
  • 2
    A dogmatic person questions everything - that doesn't agree with the dogma. – gnasher729 Nov 30 '16 at 8:51
  • @DavidCram, it doesn't actually matter if the current standards are weak. A new person cannot expect to come into an established project and rewrite everything to his personal preference. It causes a major disruption for everyone else and is thoroughly unprofessional. He has to adapt to the new company and once he has a reputation for being knowledgeable, he can start to move the team in a better direction and only after his suggestions are approved. Acting like a child having a tantrum when he is turned down is horrible behavior. Making standards changes without approval is unprofessional. – HLGEM Nov 30 '16 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.