Inspiring a co-worker to adopt better coding practices?

Question

In the Handling my antiquated coworker question, various people discussed strategies for dealing with coworkers who are unwilling to integrate their workflow with the team's.

I'd like, if possible, to learn some strategies for "teaching" a coworker who is merely ignorant of modern techniques and tools, and possibly a little apathetic.

I've started working with a programmer who until recently has been working in relative isolation, in a different part of the company. He has extensive domain knowledge and most importantly he has demonstrated good problem-solving skills, something which many candidates seem to lack.

However, the actual (C#) code I've seen is a throwback to the VB6 days. Procedural structure, Hungarian notation, global variables (abuse of static), no interfaces, no tests, non-use of Generics, throwing System.Exception... you get the idea.

This programmer is a fair bit older than I am and, by first impressions at least, doesn't actively seek positive change. I'm not going to say resistant to change, because I think that is largely an issue of how the topic gets broached, and I want to be prepared.

Programmers tend to be stubborn people, and going in with guns blazing and instituting rip-it-to-shreds code reviews and strictly-enforced policies is very likely not going to produce the end result that I want. If this were a new hire, a junior programmer, I wouldn't think twice about taking a "mentor" stance, but I'm extremely wary of treating an experienced employee as a clueless newbie (which he's not - he just hasn't kept pace with certain advancements in the field).

How might I go about raising this developer's code quality standard the Dale Carnegie way, through gentle persuasion and non-material incentives? What would be the best strategy for effecting subtle, gradual changes, without creating an adversarial situation?

Have other people - especially lead developers - been in this type of situation before? Which strategies were successful at stimulating interest and creating a positive group dynamic? Which strategies weren't successful and would be better to avoid?

---

Clarifications:

I really feel that several people are answering based on personal feelings without actually reading all of the details of the question. Please note the following, which should have been implied but I am now making explicit:

• This coworker is only my "senior" by virtue of age. I never said that his title, sphere of influence, or years at the organization exceed mine, and in fact, none of those things are true. He's a LOB programmer who's been absorbed into the main development shop. That's it.

• I am not a new hire, junior programmer, or other naïve idiot with grand plans to transform the company overnight. I am basically in charge of the software process, but as many who've worked as "leads" will know, responsibilities don't always correlate precisely with the org chart.

• I'm not asking people how to get my way, come hell or high water. I could do that if I wanted to, with the net result being that this person would become resentful and/or quit. Please try to understand that I am looking for a social, cooperative method of driving change.

• The mention of "...global variables... no tests... throwing System.Exception" was intended to demonstrate that the problems are not just superficial or aesthetic. Practices that may work for relatively small CRUD apps do not necessarily work for large enterprise apps, and in fact, none of the code so far has actually passed the integration tests.

Please, try to take the question at face value, accept that I actually know what I'm talking about, and either answer the question that I actually asked or move on.

P.S. My sincerest gratitude to those who -did- offer constructive advice rather than arguing with the premise. I'm going to leave this open for a while longer as I'm hoping to hear more in the way of real-world experiences.

Answer 1

The starting point is know your audience. You seem to already understand this because you know the difference between mentoring a junior coworker and influencing a senior coworker.

You still need to figure out what will motivate this particular individual. What works on one old geezer (like me), might not work for your old geezer.

If he likes to mentor/teach others, you could approach an issue by asking questions like "why do you do it this way?" That can get a dialog going where you can ask him to evaluate newer approaches and give his opinion.

If that doesn't work, you could point out bugs that can be avoided by using the practices or styles you'd like him to adopt. This takes a lot more work because you have to find the bugs and show how the behaviors you want to encourage would help.

If he seems willing to help others, you could appeal to his desire to help the newbies. Explain that "kids today" aren't used to seeing his style of coding and will be more likely to break his code because of that.

Sometimes you may just have to get in his face and force the issue. You need to pick these battles carefully. Make sure you start with a topic where you know you can prove to him that you have a better way.

Answer 2

I think that you have the right attitude. Just make sure to point to say all the nice things you've already said - Great problem solving skills, suberb grasp of the business, etc and just ask him for a little bit of his time to show him the current standards that the group is using and give him a chance to ask some questions about them.

When you get together bring him a coffee or something, and let him know that working to the standards will benefit him by making it easier for him to support your existing code and also making it easier for someone to be able to help him out if he gets covered in work (a big plus for someone that's been working in isolation), etc.

Make sure he's engaged and getting good explainations for why you do the things you do and don't focus on why he shouldn't do the things he was doing, bring in other people if you have to and make them explain it to you. Make yourself available afterwards if he has any questions and followup with a few places he can refer to for examples of your standards.

If he's not interested after that then you can refer to that first question you linked.

Answer 3

It is really your manager's job to

1. Realize that the company must have a coding standard. Every somewhat professional company has this, no matter company size.
2. Get everyone to sit down together and start to work out a standard. That way, everyone can have their say, and they will then be more motivated to follow the standard.

If your manager doesn't realize this by their own, they aren't qualified for their job. And if so, you should give them some nudges above the above two. The advantages of having a coding standard are so many, there is really no arguments against having one. (If some programmer's feel that they are "artists" and shouldn't be restricted by the bounds of professionalism, they should get a job doing fine arts instead.)

The coding standard in itself should first and foremost focus on banning dangerous practice and dangerous library functions. Work towards a safer and purer subset of the language you are using. Keep the coding standard free from "coding style", because coding style is far harder to agree upon, and not nearly as important. It's rather classic that a company decides to make a coding standard and then immediately gets stuck in a heated nonsense discussion of where to place the { } braces.

For reference, check out how the MISRA-C/C++ and CERT C/C++/Java standards are written.

Answer 4

First of all you need to clarify WHY you want to change this persons way of working. If it is just for aesthetic reasons, I think you should reconsider, because this person has demonstrated that his way of working actually works.

If, however, there is a technical reason for it, then you should consider approaching said person with something like:

I have a suggestion for how you can save tedious time for you, and money for the company. Are you interested?

Be aware that this should be low hanging fruits because they will most likely require changing existing habits which always require extra effort.

Even if you have gazillions of suggestions, just pick one or two, and demonstrate that it will be a change to the better.

Either this will work, and you will be asked if you have more suggestions, or it won't and then the damage is limited to one or two suggestions.

Note that it is very important that it becomes a success, and does it quickly.

Also you need to be careful. There might be very good reasons for doing things the way they are done, but that you are too new to have seen why. Hence, be respectful to your elder and ask before you assume that your suggestion is better. You might learn a thing or two.

Answer 5

I would like to severely discourage you from getting in his face as this would cause the situation to turn worse very quickly. I realize it was brought up as a last resort type of measure but in my experience, at this point, the developer has functionaly stopped participating.

Forcing the issue could turn the individual into an enemy where they are doing battle with your every action. That would truly have a negative team impact and it doesn't end until somebody quits or is fired.

If this individual truly has domain knowledge that you need/want then have them document that knowledge.

Answer 6

Starting out with breaking it to him gently: I don't know how experienced and how well versed you are in giving feedback. You could well already know, employ, or even have rejected the following, but here goes anyway. There are some guidelines on giving feedback when you want to change someones behaviour. The conversation structure I've been thought, and still try to employ in situations where I want to give feedback (because they work) are the following:

1. Describe the behaviour you see. This has to be concrete behaviour. Example: "I see that you are using a lot of static variables in your code"
2. Describe how that impacts you/your team. Example: "I find such code hard to maintain"
3. Offer a reasonable solution. (possible solutions are mentioned in other answers, and I'll dabble into some myself later this answer.)
4. Give him the oppertunity to discuss the solution. Ask him what he thinks about the solution. Take his response at face value. You have given him your opinion, and he is free to accept it or not.*

A quick resource on feedback can for example been found at http://managementhelp.org/communicationsskills/feedback.htm (though there is a plethoria of this kind of stuff on the web)

Now on the solution part, from what I am reading in your answer I gather he's plenty smart, and has the right mindset, but he's just behind in modern good practices. Those require time and effort to master, apart from the actual learning about them in the first place, so you'll have to provide him with the opportunity to do so. That probably means gathering learning resources (web, magazine, books, whatever) as a starting point, and providing him with free time to study them. I could imagine giving him every friday afternoon to broaden his horizons on programming style, where he can do whatever he believes furthers those goals. People inheritently want to improve themselves. Provide the materials and the time, and they will make good use of it.

Possibly most importantly, don't expect change overnight. He hes done things his way for a long time, and has probably gotten pretty good at it. It will take some time getting as good in a new way of doing things, and for a while, he probably won't see much value in new ways, because in the beginning, there is none. His old way will probably be more effective for a while.

*Note: the funny thing about conversations is they are very hard to model. They have a life of their own, so though it looks nice on paper, it tends to muddy up a bit.

Answer 7

Explain how you want things done and show him how it works with design and architectural choices you have made for the project at the start of the project you will have him working on. Sit down one on one (and privately) and explain the issues you have seen in his previous coding and why they are a problem for this project. Ask him what he needs to have to get better, but make it clear that not getting better is not an option.

Then use code review as a tool to get him to adjust his methods of working. Plan a good long time for the first one and really talk about why you prefer this over that and let him explain his reasoning. Make sure to really hear him out, people are more ameable to change when they feel their concerns have been addressed. Expect in your planning (but don't tell him that) to have rework on the first task and don't accept it until it meets the standards of your team. Once he knows what you expect and that you won't let it slide in the interests of time, he will probably come around to your way of working. But you may ve to use the code review as an educational tool for several iterations. You don't have to be nasty about not accepting the work until it meets you standards, but you do have to firm about it and consistent. Don't let it slide sometimes and not others.

Answer 8

The $64,000 question is if he's delivering his projects on time and meeting functionality requirements. If so, he's doing it right. There is no objective right-way or wrong-way in software development. Ultimately its about solving problems. And if problems are solved to the satisfaction of the client/customer, then by definition, software development is being done correctly.

It becomes an entirely different issue of course if his projects arent being completed. At that point changes need to be made by your supervisors, perhaps with your input. But just because he's violating your personal sense of code aestetics or today's conventional wisdom doesnt mean what he's doing is 'wrong'. You are not the arbitor of the definition of 'good code'. He might, after all, have a low opinion of your code.

So... unless there's actually a problem with his work (which you havent indicated there is), dont do a thing. Part of being a successful developer is learning to merge your code with other developer's styles.

He could, after all, come on here and post a similar question about dealing with a less experienced developer who's more concerned with keeping up with fads than finishing projects. Its all about perspective.

Answer 9

As a junior developer talking to a senior developer it is too risky for you to try and approach him with better ideas than his own.

The best way to deal with this is to try and convince your/his boss of a better practice, and see if he will make it a decree that all code must follow specific standards and be enforced to those standards through peer code reviews.

A sizable portion of people are (even if at a subconcious level) vindictive, egotistical, and defensive, even if they are completely unaware of their own subconcious motives, they will take offense if you try to change them or imply that they are wrong in any way.

The Chain of Command is the safest way to go because he HAS to listen to his boss, nor does he have to like him. Let the boss be the bad guy, thats what he is there for.

If you can't sell the boss or he IS the boss then just deal with his bugs but lead by example in YOUR code.

Answer 10

You can't.

You can't inspire people to do things that they aren't aware of in software development. I speak from experience as I've tried to do this often in my career, and every time the end result is that my own status diminishes in the eyes of the company; I've even been fired or quit in frustration after nothing happens, simply for trying to improve the development culture around me to modern practices.

If your co-worker wasn't ignorant, you could show them. Since they are, however, there's nothing you can do since they aren't capable or caring enough about software-as-craftmanship to strive to adopt better coding practices. Chances are if you try, they'll either ignore it or muck around without really understanding, which from the sounds of it is what they're already doing ("Trial and Error Development" i.e. just hacking around in code until the errors stop).