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.
Best Answer
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.