How to teach an unwilling coworker better coding practices [duplicate]

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.