How do I help a coworker with more years of experience write cleaner code? Let's call them Dario. What are some tips on how to gradually introduce clean code concepts while still being respectful and helpful?

My teammate happens to write spaghetti code with unnecessary complexity. For example, instead of using the built-in forms API for Angular to keep track of the form state, they write these monstrosities that first loop over each item in the form, find the control they are looking for, and update the state.

Inside of these methods there are a lot of side effects and it's written in a very imperative way. As you can imagine, this leads to a lot of bugs that are preventable and as we add new features, it just takes longer to refactor and fix. A small example being a list of radio buttons that behaved like checkboxes (when you clicked on a selected radio button, the monstrous code treated it like a checkbox and set its state to be unchecked).

  • 2
    Group code reviews. Code reviews where his code gets reviewed, but also where everyone's code gets reviewed. – Stephan Branczyk Jun 29 '19 at 21:48
  • The coworker does know about the angular forms api, but they insist it is too complicated. I'm having a hard time with their argument. I have asked for more details, but they repeated the same thing in a different way. I didn't want to push it too far, but at the same time this code is causing us extra work. – throwawayjdafjk2329 Jun 29 '19 at 22:48
  • 1
    One day, I went asking to a co-worker why he wrote the code a certain way, he answered "If I wrote it that way, there must be a reason behind that" while never telling me the reason. Never asked anything to that co-worker again. Sadly, you have no power changing those kind of people. – Med Jul 1 '19 at 9:52

You can talk about it.

Just ask them that you wish to discuss about a module in the project. Discuss on how they can leverage the Angular's built-in forms API to write more maintainable code which can reduce their work as well produce good quality code.

Make it sound objective without implying that that's something that you are pushing. Talking developer to developer, if they see the benefit, they'll definitely understand.

| improve this answer | |
  • "if they see the benefit" is a key point here. They may very well not see the benefit (or sufficient benefit) and if this is the case they will be incredibly stubborn. – P. Hopkinson Jun 30 '19 at 10:36
  • Some will just say "It's working, why are you bovering me ?" and won't be able to understand what they done wrong – Med Jul 1 '19 at 9:47

You've already pointed out the problem to this person. It appears he understood your suggestion clearly, and rejected it. Your question is about changing his mind.

First, remember that people almost never just say, "doh! You're right! I've been doing things stupidly for years!" Suggestions like yours take a while to sink in. Be patient.

Second, "too complicated" is often a way of saying "I don't understand." And, "I don't understand" is very hard for people to say. You may have to be even more patient than usual.

Third, decide whether changing this person's work practices is important to you. How do his work practices affect you personally? Is it worth your time and effort to get this person to change? (It might not be.) Be sure to consider whether "being right" is your only motivation to get him to change.

If you DO decide to move forward, treat the problem as one of education. Do YOUR work in a way that your colleague can look at it and learn how you do it. Ask your mutual supervisor if it makes sense for you to make a "how to" presentation.

Getting people and organizations to change is a long game. It takes years and is harder than cranking out software (or whatever). It's often worth doing, but it requires allies (your mutual manager?) and, again, patience.

Good luck.

| improve this answer | |
  • "Do YOUR work in a way that your colleague can look at it and learn how you do it", but what if the colleague doesn't want to look at it? Some people write dirty code, and won't bother improving themself, sadly – Med Jul 1 '19 at 9:49
  • 1
    Yah can lead a donkey to water, but yah can't force him to drink. – O. Jones Jul 1 '19 at 15:42

Am I correct in saying that your colleague has a firm notion of how they would like any/all software to work? and that they would rather force a given piece of software to work their way than to try to adapt to the way the software creators intended their product to work?

If so then your colleague is (to some extent) stupid or lazy.

It is a very understandable thing to be stupid or lazy about (after all, who hasn't got fed up with a novel programming "solution" and tried to force a solution through a big IF statement?) but stupid or lazy is the root cause of the problem and you want to find solutions that attack the root cause.

This is a really tough problem to fix and you can drive yourself wild by trying too hard. The best you can do is try a little bit of this and a little bit of that and see what works. What you absolutely shouldn't do is to treat them as stupid or lazy or resent them for their behaviour. That doesn't work or make anything better.

One option is to appeal to authority. Identify a key feature in the software which you know that your colleague will try to dodge. Once you have identified this feature try to get it written into the specifications for your current or future software as a "key feature" or similar language which will give it undue importance. This will place a certain amount of pressure on your colleague to use the feature.... once they are using it they will start to understand it and hopefully will add it to their repertoire.

| improve this answer | |
  • There's value in having an architecture/vision. Too many system these days end up a big amalgam of mismatched frameworks. And appeal to authority? Ugh.. that is risky, unless you want the not-a-team-player label. – Jeffrey Jul 1 '19 at 2:15
  • Any attempted fix is going to be risky (or ineffective). I'm not sure I'd go down this route myself but it is an option if the OP were really keen to change the current dynamic. – P. Hopkinson Jul 1 '19 at 20:23

You must log in to answer this question.

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