How do you TEACH best practices?

Question

I work with a bunch of people that write sloppy code. I mean things like defining variables in multiple places, tightly coupling code, etc. I am not an expert but I have a willingness to improve. It seems the people I work with are completely fine with what they are doing. How can I motivate them to improve? I can't offer any incentives though as I am just a co-worker.

Answer 1

Give them an example why it is bad. And give them some reasons why the best practices are called best. But don't underestimate the power of stubbornness. If they don't want to see the light, they have to walk in the dark.

Also, keep in mind that it is always harder to read code written by other people. It is easy to call it sloppy (and it sometimes is) but sometimes you just have to get used to their coding style.

And if you are really smart, you are using some piece of your own code as first example and show what you have done to improve it. Then you can ask if they have examples of their own code.

Answer 2

Document the coding standards, refer to them often. I work in PHP and am supposed to stick to PEAR standards.

Review code and critique people.

Leadership is needed to keep people in line. It can be done with positive, or negative reinforcement. Positive is usually better for programmers.

Answer 3

You can teach until the cows come home. Unless they want to learn, they aren't going to take anything you say to heart. And tyring to incentivize it isn't going to help either. As soon as the incentive goes away they aren't going to want to learn anymore. It sets up a false reward system that doesn't really work.

Answer 4

You can most definitely offer incentives. You can produce better code faster. If doing that isn't incentive enough then they don't care enough to be incentivised anyway.

Answer 5

Co-worker approval can be an incentive if people like the co-worker, so don't rate that out off the bat.

Practical examples of what makes best-practices better, and why bad practices cause problems. Try to get support from organization leadership. It will be real hard to make progress without support from above.

Answer 6

It takes patience, humility and repetition. You have to respectfully be able to illustrate to them why something is wrong and what is the better approach. It will certainly test your patience; no one can change their practices quickly. In fact, some people will be stubborn and will not change. But if you keep at it and are able to convince them that your methods are more effective without attacking them, you patience might be rewarded.

Answer 7

Lead by example, if they care about improving they will catch on, if they don't there is nothing you can do, and you should be looking for a new employer.

Answer 8

import cultural references;

Horse, water;

Flavor the water;

end

Answer 9

Refactor some code that will improve significantly, and show them the difference. It serves as a double check, as if it is really improvement, it should be really obvious for all on the team that it is better. Then explain the best practices you used to achieve that :)

And of course, do some pair programming :)

Answer 10

You're "just a co-worker," so you can't prescribe any actions. The best alternative is to set a good example and ensure that it's public without cramming it down people's throats. If they aren't already in place, try to get code reviews instituted as a good practice. Looking at samples of everyone's code will help each individual improve their coding.

If you follow best practices, and they really are best practices and not just formatting standards, your code will be better. It will have fewer bugs and be easier to understand. That understanding will make it easier to extend, or to debug when it does have problems. Your co-workers who see your code will note that if they follow those practices, they will also have fewer bugs and easier to understand modules.

Even if you did have authority, having a good example is probably more effective in the long run than dictating "best practices."

Answer 11

Programmers usually have a "my way is right" mentality when it comes to working on their own code. So just telling them that their way is wrong is not the best.

However, I do not think it is wrong to gather all the developers and discuss creating coding standards to use. What this will do is cause everyone to be on the same page and program the same way. What are some good reasons for this? * Software is rarely maintained by the original author for its entirety. * Code conventions improve the readability, which means it will take less time for other engineers to follow the code more quickly. * 80% of the lifetime of a program goes to maintenance.

This will obviously take time to implement, but peer reviews will help to make sure that the standards are followed and that your code is written well.

Answer 12

Twelve Ways to Win People to Your Way of Thinking

1. Avoid arguments.
2. Show respect for the other person's opinions. Never tell someone they are wrong.
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions the other person will answer yes to.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person's point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Call attention to other people's mistakes indirectly.
3. Talk about your own mistakes first.
4. Ask questions instead of giving direct orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give them a fine reputation to live up to.
8. Encourage them by making their faults seem easy to correct.
9. Make the other person happy about doing what you suggest.

http://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People

Answer 13

Have an inner-office code contest promoting best practices, clean and efficient code.

Every week or so email a bit of code which is in need of some love and ask everyone to make it as good as they can for their entry in the contest.

Have the entries reviewed by non-participating good code reviewers and make a list of improvements which the coders could have fixed. Entries which have at least X% of the improvements are entered into a draw for something like free movie tickets, free dinners, whatever. Alternatively, the best entry can win, as per the reviewers.

Try to have HR or your manager provide a small budget for it, if you can't you can publish a list of top 10 (or whatever is appropriate depending on the number of applications). People love to be publicly told they're doing well, and everyone like to try to move up on a list of something good.

Make sure no-one's entry is shown publicly, but at the end of each week provide an ideal (or at least very good) implementation.

This should promote learning best practices and will make everyone have them in the front of their minds rather than being balked at every time they commit something.

Also, if people continue to commit the same errors, it's easy to point to the contest code/answer and have them learn from it.

This has worked quite well in one of my past jobs. It gets everyone discussing about ways to make things better.

Answer 14

Lead by example.

Write the code you wish others would, then ask them to review your code, not on a pretense, but as part of the checkin process.

If asked to perform a code review, point out improvements they could make - but be gentle and don't point out absolutely everything wrong all at once.

Start small, work slowly and have patience.

Answer 15

I only had success when I stopped preaching and just put into practice on my own. Some people got on board and others didn't. After a while some of our results got noticed and then more people wanted to know what we were doing right.

This has always been a problem and it will always be a problem.

don't preach and don't try to teach. Just be supportive of better ways to do things.

Good luck.

Answer 16

The three Ls: Leadership, Lunch and Learning

Mix in some shining examples of code that uses the best practices. Lime light on these and pair program with the people and show them why somethings better.

In short there is no magic over night thing you can do. It takes time and elbow grease. Forming sincere community at your company is very important. Thats where the latter two Ls come in. Try to make learning fun and extracuricular. And realize there are some people that are just there to get a paycheck. Not much you can do about them besides sustaining your activities and having other participating. Sometimes just that, the herd mentality, is enough for them change their mind.

Answer 17

Code Reviews & Peer Programming

Answer 18

I can't offer any incentives though as I am just a co-worker.

Maybe you can't offer monetary incentives, but there are plenty of others incentives you could offer. Just look at how effective Stack Overflow's reputation and badges are.

One simple idea would be to offer weekly "[YourNameHere]'s Excellent Code of The Week Awards". Just send an email every Friday highlighting an example of what you consider good coding practice and praising the developer who used it. If you really can't find anything you like from your own team one week, give that week's award to somebody you found on the internet.

Answer 19

Lead by example, and get everyone to agree on the right approach.

That second point often means having to make compromises on what you think is right. It's way more important that all of you get on the same page, then what the page actually is. You can accept a less optimal standard in the short run, if everyone is using it.

The hard part is getting agreement. Over the years I've found that compromising photos from the Christmas party are often effective for that. :-) The next choice, if you don't have photos is just being nice and doing a LOT of listening.

Anybody on any team can be the glue that brings people together (I did it as often when I was a junior as when I got older). Patience is key.

Paul.

Answer 20

Since you're "just a coworker", you might try asking others to review your code before you check it in, and ask why they suggest their improvements. Just getting people to think about making your code better will be a good start. Maybe that will kindle some interest; it's pretty fun to talk about code with others.

If you can get the bosses to spring for free food you could try bringing in the occasional speaker about software topics. Maybe once a month for six months?