How to avoid bad practices of work by employees

Question

Hello I am working in web development. I have the responsibility for execution of a project. I have some juniors that I delegate tasks to them and they do it. This flow seems fine to me.

But when I look in the code I find some things that should not be there. Some practices need not be there. I am not any kind of ninja coder but I can recognise bad habits.

By bad practice I don't mean wrong , the code will work as expected but I am kind of OCD and it irritates me sometimes because it may limit the performance of the app.

I have two options to tackle this:

1. Leave the work as it is tell them not to repeat again as the current version is working fine.

2. Correct all by myself or instruct them to correct it , but this approach will take some time and cause project delay.

What approach should I take here or is there any other solution for this?

Answer 1

Setup a coding standards document for your team, setting out what is acceptable and what is not.

Then only allow code to be merged into the master branch of your source code repository after that code has undergone a code review. You can use tools such as StyleCop to enforce particular rules automatically, but sitting down and doing code reviews means you come across as more personable within your team.

Answer 2

Since you're team lead....

First...did you have any type of coding best practices in place? If not, the bad code is your fault.

Second...do you do code review, either formal or informal? If not, then the bad code is again your fault.

Third...is the code actually bad practices, or just not your preferred method of doing things? Since you said, "..because it MAY limit the performance of the app" seems to imply that it isn't broke, just not how you want it.

Regardless, to answer your question, NO...you do not make the changes yourself. Talk with P.M. and if there is time and a real NEED, then let the dev who wrote the code make the change and explain why it's needed. You sound like the 'perfectionist' programmer, so honestly look at the code and yourself, and ask if this isn't just you wanting things done your way, or is it really bad code. Be aware that nit-picking someone's work just b/c it's not done how you would do it is a sure way to lose their respect and desire to listen to you.

Good code and a quality product is not your only deliverable responsibility to the company; you should be teaching and moving your team along also.

Answer 3

Most programmers are keen to write good code, and have ideas about what the best way is to do it. They don't always agree with each other on this. The goal should not be to get them to do it exactly as you say - apart from anything else, you can undoubtedly learn from your team too.

Of course, you want to keep to good standards, and that includes having the team write code in a consistent way, rather than each doing their own thing. As you have mentioned, some practices are technically better than others, and you'll want to include the good ones in your guidelines.

This can be achieved through various routes. I'd suggest the following:

1. Put it to your team that some coding standards are needed. You can probably find some guidelines online to use as a starting point. Ask your team to give feedback on this, and allow them to add practices that they know to be good from their own experience.
2. Set up a meeting to go through your draft guidelines and finalise it. There will certainly be some things that are controversial, and you'll need to allow sufficient discussion, but then close down on a decision. Even if a decision goes against something that one of the devs holds dear, they'll have the consolation that they were consulted and that a rational discussion took place.
3. Get the team to do code reviews. Ideally this is not a hierarchical thing, but one team member helping the other to stick to the standards, and maybe making suggestions for design improvements. You can also consider pair programming, but many teams do fine without it.

Try as much as possible to act as an enabler for your team to produce high quality code. They will appreciate the respect this entails

Answer 4

If you have the authority then you can set out guidelines for coding and ask the juniors to adhere to them.

If you don't have the authority then you can't do much, you can fix it yourself or ask the manager to speak to them. But if you do the latter you should have guidelines written up, it's no use saying it's wrong unless you can show them the 'right' way to do it.

Answer 5

As said the others there are set of good pratices that exists pretty much for every langugages/framework and are documented on the net and they're tool to assist you in code review.

If you have the authority but not the proper skills to enforce a proper document of best practices, delegate it to someone. I prefer no best practices enforced than having them from someone who do not understand really of what he's talking about, specially if it's about performance.

By bad practice I don't mean wrong , the code will work as expected but I am kind of OCD and it irritates me sometimes because it may limit the performance of the app.

Is that only about performance ?

If so I suggest you to add to your validation process a proper data tests if you haven't them yet. By proper data tests I mean data generated which volume match to the expected reality. If you're doing for instance a web application, you could set that every that is a basic actions should take less than a second, a comlpicated night job less than an hours? If the test fail then there is something to dig.

Finally, if there are some special piece of code that really look wrong for you in terms of performances and the high level performance test isn't enough for you, isolate it in a unit test, run them against some huge generated dataset and see yourself the result.