I have a coworker who is a bit older than me and doesn't follow good coding practices. His coding style is like the wild west - no encapsulation, no reviews (aka run from them, commit on master...). His opinion is that you don't need to encapsulate or make the code more readable, since he can read it just fine.

I am the Code reviewer on paper. And also the one who is activating and maintaining the live systems. The problem is he is bypasing all controls we put in place.

I already tried talking and yelling (when he yells at me because i suggest he reworks a 300 lines function) and teaching him. Any suggestions on how I can get him to change his coding practice? I am the Main reviewer on paper and quality controll. But he buypasses all of the agread controlls, because "he has no time for them" now... even tough none is rushing him.

  • Do you directly work on the same pieces of code? – Twyxz Oct 15 '18 at 13:21
  • 3
    Are you his manager? Just because someone codes in a way you don't like doesn't mean they have to change their ways unless it is agreed upon by everyone there. – Dan Oct 15 '18 at 13:23
  • Answers [workplace.stackexchange.com/questions/74388/… : might give you a hint. The way I was taught is by coercion: your code doesnt make it to master if your PEP-8 (python coding standard) is not clear. My reviewer didn't even care if it compiled as long as it wasn't following the formatting standards. – BoboDarph Oct 15 '18 at 13:33
  • 4
    @Sangoku there are not any situations in the workplace where yelling at a coworker is appropriate (except safety warnings, I guess). It's entirely possible your actions have resulted in you being seen as the problem here - because yelling at coworkers is a problem in most countries. You don't list your country but in many places, this is going to get you fast tracked to removed from the company if that type of behavior persists. – enderland Oct 15 '18 at 14:27
  • 1
    @Sangoku how does he bypass the contols your company has put in place? – dbeer Oct 15 '18 at 14:41

Generally speaking the reason there are coding standards is less to do with performance reasons and more to do with the team being able to maintain, fix bugs, and adding new features or areas. If you're noticing difficulties with this, then bringing it up with a manager is the ideal solution. Being "that guy" who hates everyone code and simply want to refactor it to use encapsulation for no other reason than because you don't like the coworker's code will never, ever, in a million years fly. Being that you're the "new guy" you'll just be ignored.

Coming to the manager with things like, "Hey look, boss, I used cache and not query the database inside each for loop and I saved time by as much as a minute." Boss would be highly impressed, call for a meeting and say, "Hey look everyone, pay attention to this, we're going to start doing this."

Instead of, "Hey boss, for no reason other than because I hate my coworkers code, I think we should use encapsulation." Boss would say, "Why?" You would say, "I read it in a book. It's the industry standard for anyone anywhere. We should totally get up and yell at the coworker for being so dummy." Boss would say, "Now hold on Bob, I want you to concentrate on your work and not worry about your coworkers code."

  • That is my only problem. The code he is producing is almost not maintanable. That is my main problem. Thank you for the advice. Will bring that up to our manager. – Sangoku Oct 15 '18 at 14:10
  • @Sangoku I think an example would be ideal to bring with your boss. Something like, "I wanted to add feature X, but because this code base does not follow the industry standard Z, I am unable to add feature X as easily and as timely as one could. Other places in the code follow similar construction and difficulties." – Dan Oct 15 '18 at 14:13
  • The problem is the code it self is already old and messy. So i cant take such stand... we are cleaning it up atm.. but he is on it to make it more messier. – Sangoku Oct 15 '18 at 14:16
  • 1
    @Sangoku I would have to disagree. I work on legacy mainframe apps, nothing is unmaintainable. There are things that are more easily maintained. If you really want to change anything, start taking notes when you come across tech debt and find out how much money the company is losing then you will have a leg to stand on – SaggingRufus Oct 15 '18 at 14:17
  • @Sangoku If you guys - this is plural so I assume one or more of your teammates are on board with you on this - then you guys can go to the manager together and impose rules. As with any commits to revision control, you can definitely add scripts that run code rules, sniffers, etc to determine if at the very least they followed an agreed code rule. Then from there, it's quite easy to designate someone to reject committing to master unless they adhere to strict rules agreed upon by everyone. – Dan Oct 15 '18 at 14:25

Unless you have positional authority (manager, tech lead, etc), you don't.

What does is mutually agreed upon team best practices. If you want to have a team consistently work in a way that everyone is good with, the only real way is to have written down agreements. You see this in a lot of open source repos with contributing.md files - they are solving the same problem.

I would suggest bringing this up with your manager. Identify the problems your team collectively has by not having a consistent SLDC practice. Discuss with your manager how this employee is bypassing practices which are part of your responsibility and causing the quality of code/systems you own to degrade.

After that, your manager will likely begin the process to talk with your team to try to standardize how your SDLC should go. However, given this:

I already tried talking and yelling and teaching

I suspect you will have a huge uphill fight because if you actually yelled at your coworker, the likelihood of you being taken seriously by him is close to zero.

Very likely you will need to first reconcile this relationship you have made toxic in order to have any hope of getting your team on the same page.

  • I am the Code reviewer on paper. And also the one who is activating and maintaining the live systems. The problem is he is bypasing all controls we put in place. – Sangoku Oct 15 '18 at 14:12
  • 2
    @Sangoku if he actually can bypass everything, that is the real problem – SaggingRufus Oct 15 '18 at 14:18
  • @Sangoku then the only real solution is to talk with your manager. – enderland Oct 15 '18 at 14:29

I'd like to respond to the substantive parts of your question, as I think they are valid and generally applicable.

His coding style is like the wild west - no encapsulation, no reviews


The problem is he is bypasing all controls we put in place.

This is where you need to focus your energy, instead of trying to educate this co-worker. Companies that have standards have to enforce them, and they need to be enforced by those in authority. If the company doesn't want to enforce their coding practices and standards, then that's a very serious problem that will build a lot of tech debt. I see you as having two options for dealing with this:

  1. If you are going to stay, you need to find someone in the technical leadership of the company and to discuss tech debt with. In short, you need to make sure they understand that passing proscribed tests does not mean that the code is bug-free or even particularly maintainable, and that there are industry standard ways to mitigate these kinds of risks, such as evaluating cyclomatic complexity, code reviews, encapsulation, etc. One way to perhaps demonstrate the risks of this kind of code would be running a static analyzer like clang against spaghetti code that's already been checked in. If it's truly problematic, then a static analyzer should be able to help demonstrate issues in it.
  2. You should consider whether or not it's worth working at an organization that doesn't enforce basic standards. Your question states that he checks in code without reviews, and also that you are the code reviewer of record. If the company you work at has no objection to the fact that you are the code reviewer (whether de facto or by him claiming you reviewed it) and you haven't reviewed the code, then that's a sign that this company has no intention of enforcing these kinds of standards, and you should consider whether or not you want to work at a place that effectively doesn't have coding standards.

Personally, I recommend you work on option 1 and look into option 2 depending on the reaction from the company. I would not stay at a company that doesn't care to have coding standards.


You will probably never convince your co-worker to change.

I work on legacy mainframe applications and I have seen my fair share of carnage. I too tried to change people, but here is where the problem arises. How can you possibly justify to your boss that Bob's code is terrible when it performs as expected.

This is not a rhetorical question, there is an answer. First of all, Bob's code is not terrible just different. You mentions Bob is older than you. Coding standards change all of the time and some older people started working on older systems where there no standard. The mission was: Make it work.

If you want anything to change, you need to first, leave Bob alone. It will already be hard enough to fix the damage you have done to your working relationship. Instead, you need to find an objective reason to have EVERYONE adhere to a standard that works for your application. The way you can do this is by tracking your technical debt. If you can do the math and show the company how much extra it costs to maintain rogue code, you may have a shot. That is just about your only option. That is not even guaranteed to work.

The true answer to this question (IMO) is to take a look at yourself and try to imagine someone coming to you and telling you that you are doing everything wrong because you aren't using that design principle. How would that make you feel? Probably unhappy and you would probably not change, most of us would not. Find out why this angers so much and use this as an opportunity to become a professional. Professionals do not act in the way you have described.

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