Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
7  
I've been in this situation and never seen it really resolved successfully. Many people such as you described quit thinking about programming years ago; at this point they are only interested in solutions for their business domain. I am not going to join the bandwagons on this site who condemn such people; indeed I think they are the salt of the earth. If they are working in your code you should push to at least get your conventions adhered to. I haven't had a hard time selling that people should follow existing conventions if the contribute to a project. –  Jeremy Jul 1 '11 at 17:40
1  
What did your boss say when you raised this concern with him? –  user1249 Jul 1 '11 at 18:39
2  
@Aaronaught, since his code works, this is not a technical but a political problem, and probably one that needs to be imposed from above if you want to change anything. In other words from your boss. Have good arguments ready! –  user1249 Jul 1 '11 at 19:12
2  
@Thor: So you think it's absolutely impossible that his style is simply the product of low expectations, no peer review, and a busy life which doesn't lend itself well to independent learning during one's own personal time? Not caring isn't a hardwired personality trait, it's a product of one's environment, and it can be changed. Not knowing is even easier to change, but it still has to be approached with some level of diplomacy. –  Aaronaught Jul 1 '11 at 20:05
1  
@Aaronaught, either you have failed miserably to be an inspiration (which cannot be ruled out) or he doesn't want to be inspired. Would you consider coding your unit tests in Lisp or Haskell if there was a younger colleague telling you that this is much smarter than what you do now? –  user1249 Jul 1 '11 at 20:12
show 12 more comments

10 Answers

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.

share|improve this answer
    
Thanks for the constructive answer - although I think it could have done without the first paragraph. –  Aaronaught Jul 2 '11 at 17:12
    
@aaronaught, sorry, but it is actually quite important. –  user1249 Jul 2 '11 at 17:15
    
No, it's really not important. It's answering a completely different question and I already provided several clarifying comments and edits to indicate that it is not relevant. The inability of users on this site (and mostly only this site) to separate the question of "Should I" from "How do I" is actively harmful to the overall quality and coherence of the discourse here. Your caveat is valid, but irrelevant and slightly offensive. There's even a very highly-voted meta question on this exact topic. –  Aaronaught Jul 2 '11 at 17:23
1  
@aaronaught, the only reason you state for wanting to change this persons coding style is because it is different from the rest of the team, and then you put his style down implicitly stating that yours is better. Hence my comment. If you cannot accept his current coding style in your code base, then have a personal meeting with him and say this, and that you are willing to put in a large effort helping him learn how you need his code to be. –  user1249 Jul 22 '11 at 21:32
1  
@Aaronaught, for one who could have done without the first paragraph, I find your choice of wording surprisingly offensive. Do you think that calling others pathetic is an example to follow? –  user1249 Jul 23 '11 at 8:03
show 2 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
This is making the (incorrect) assumption that I work for a software publisher with a vertical structure. Fewer than 10% of developers work for software publishers and it is not necessarily the responsibility of an executive or middle manager to micromanage the developers. –  Aaronaught Jul 1 '11 at 19:20
1  
@Aaronaught Well, then that's the true source of your problem. If you aren't in a team with a coding standard and at least one veteran programmer to lead and guide the others, that's a bad organization. Everyone will code away randomly, thinking they are "artists", coming up with mediocre, unstable, unmaintainable results, and not learning how to improve. –  user29079 Jul 3 '11 at 16:35
add comment

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.

share|improve this answer
    
This is answering a completely different question from the one I asked. (a) I'm not a junior developer, (b) my boss already delegates most of the important design and code decisions to me, (c) his code isn't known to be buggy, just not well-structured for C#'s OOP/functional mixed paradigm, and (d) the essence of my question was how to approach the subject in such a way that they won't take offense. –  Aaronaught Jul 1 '11 at 19:25
1  
@Aaronaught, a) "This programmer is a fair bit older than I am" I assumed from this statement that you are his "junior". b) Sounds like your the tech lead then, you should have put that information in your question, it changes things considerably. c) If he isn't following best practices and his code isn't buggy then what's the problem? Why approach him about anything? Don't fix what isn't broken. d) Again, don't approach him if he isn't causing bugs with poor quality code. The real issue is that you don't have coding and development standards that everybody must abide by. –  maple_shaft Jul 1 '11 at 19:50
    
I thought that it was pretty clearly implied by my reference to (not) "going in with guns blazing and instituting rip-it-to-shreds code reviews and strictly-enforced policies" - why would I even mention that if I were a junior? And who said we don't have standards? He's just never worked with our team before and I am trying to introduce the standards without being a jerk about it. –  Aaronaught Jul 1 '11 at 19:56
    
-1 Didn't answer the question asked. –  HedgeMage Jul 1 '11 at 20:01
add comment

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.

share|improve this answer
1  
It was for this reason that I pointed out that he comes from a different part of the company. He had no problem meeting their requirements, but their requirements are not our requirements. Specifically, their requirements did not get much more advanced than CRUD. And yes, there is a problem with the code; it may work fine in isolation but will not pass integration, performance, or reliability tests. I don't believe in strict methodologies like XP or TDD or whatever, but this isn't a question of aesthetics or conventional wisdom, it's a question of maintenance requirements. –  Aaronaught Jul 1 '11 at 19:30
1  
I'm also downvoting this not for the reasons above, but because you're making several unwarranted assumptions. (a) I'm not less experienced, (b) none of the things I'm talking about are justifiably called "fads", and (c) this one's the most blatantly ridiculous assumption - he isn't the most productive developer on the team, and certainly isn't more productive than I am. –  Aaronaught Jul 1 '11 at 19:36
    
If there's actually a problem with what he produces, then as I said, its an issue for your supervisor, or whoever your mutual supervisor is. But you havent shown there is a problem with what he delivers to the client/customer, just that you dont like what he delivers to you. Which is my point, he's not writing software for you. So before you go causing a stir, I'd make darn sure that he is not less dispensible than you. –  GrandmasterB Jul 1 '11 at 20:08
    
As for fads, hang around in the industry for a while and you'll realize that yes, todays best practices are tomorrows VB6-style bad practices. As for downvoting, sure, feel free. I'm just responding to the question as posted. I cant respond to details you didnt provide. –  GrandmasterB Jul 1 '11 at 20:09
1  
I dont know your resume, nor do I know your co-workers resume. I only know what you put in the question. If it was important information, you should have included it. And based on your responses to other answers, you might consider that you left quite a bit out, thus requiring a lot of assumptions on the part of answerers. But if you want an answer, assuming you arent his supervisor, its your supervisor's or your mutual supervisor's problem to worry about how not to cause a stir. Just reject the code that is causing a problem in testing and report what the problem is to your co-worker. –  GrandmasterB Jul 1 '11 at 20:26
show 1 more comment

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.

share|improve this answer
    
-1 The question already states that the OP has no intention of approaching this in a confrontational way. Please read the OP's question thoroughly and answer that specific question, rather than discussing the topic in general. –  HedgeMage Jul 1 '11 at 20:13
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
These seem like some good general strategies. I should be clear that this is just VB6-old, not COBOL-old. Maybe 5-7 years behind the times, not 20-30 years. So not a geezer/dinosaur. –  Aaronaught Jul 1 '11 at 18:09
    
I would not ask "Why do you do it this way?" That could have an adverse affect - putting him/her on the defensive immediately. It could be that the co-worker simply does not know and you don't want him to feel ignorant. Instead, ask "have you considered this method?" –  IAbstract Jul 1 '11 at 18:46
    
@IAbstract If he likes to teach, he won't get defensive, he'll enjoy the opportunity to teach. Tone and attitude will make a big difference. If it sounds like you could easily add "Idiot" at the end of the question, then you aren't doing it right? :-) In my experience, most people are willing to answer sincere questions. –  jimreed Jul 1 '11 at 19:01
    
@IAbstract: I'm pretty sure if I asked something like, "have you considered dependency injection here?" the answer would be "huh?" Of course there's a chance I might be pleasantly surprised, but I think jim is right, it's a better conversation starter to ask "what made you decide to use a globally scoped Foo object here?" I don't foresee that being interpreted as an attack; it's me trying to understand the existing design. –  Aaronaught Jul 1 '11 at 19:06
    
@Aaronaught: fair enough ;) While the reaction to DI may be "huh?", it could spark an interesting conversation like, "well, I've heard of it but ..." ... my concern is mostly the tone (as jimreed points out) Certainly, as jimreed says, you have to pick your battles - sometimes it means carrying a big stick, sometimes it means playing in the sandbox together. –  IAbstract Jul 1 '11 at 19:15
add comment

You can't.

You can't inspire people to do things that they aren't ware 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).

share|improve this answer
2  
I appreciate the response, however, I find this hard to believe mainly because I was exactly this type of "just get it done" programmer several years ago. Nobody showed me - I had to discover it all myself - but I'm sure that a sufficiently persuasive leader (if one had existed) would have been able to effect the same change. Just because some people learn all of this independently doesn't necessarily mean that everybody else is a lost cause. –  Aaronaught Jul 1 '11 at 17:51
2  
That's true, but in my experience if people care about improving, they need little motivation to be inspired because the desire is already there - they might need a nudge or advice, but they understand and want to improve, just need guidance. I was the same way; I learned bad ways of doing things and thought "There has to be a better way" and started research. What I've seen though is the people who don't improve or show a desire to improve are lost causes because they don't want to improve. That said, best of luck in proving me wrong :) –  Wayne M Jul 1 '11 at 18:11
    
I think those are the kind of statements that need to be substantiated. I'd certainly be interested in hearing (and more willing to upvote) some real-world experiences, with respect to what you tried unsuccessfully (and why it was unsuccessful). –  Aaronaught Jul 1 '11 at 18:17
1  
This is true sometimes, e.g. "old dog, new tricks" - try explaining to someone how techniques have increased data retrieval efficiency by 800% and the co-worker just shrugs their shoulders. –  IAbstract Jul 1 '11 at 18:41
2  
The point is, you can do that and people will follow you, but you'll need to rank higher in the hierarchy. You can't do it as a simple developer in most teams. Many colleagues can only take unasked advice from someone higher in the hierarchy. If you are on the same level, they'll feel hurt and attacked. Remember that respect is earned. If you treat them well and communicate it nice and pleasantly, it can work, if you're on the same level, too. –  Falcon Jul 1 '11 at 18:58
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.