How to get colleagues to follow best practices?

[Raihan Razish]

So in my workplace, our current Web application is a monolithic mess. Database calls from the UI layer, so much duplication and just some down right horrible code, plus don't get me started on the lack of test coverage.

Now by no means am I a saint. I'm still very early in my career, but I've taken a keen interest in writing clean, readable and testable code, as I want to instill good habits on myself and also to help those who come after me and read/extend my code.

The problem I have is that I am so junior. My lead developer is very understanding and she's started to take a vested interest in writing cleaner code, but the other devs on the team don't seem to listen or follow best practices. I feel with being so junior the other devs won't listen to me and shrug me off sort of. I've been trying to lead by example by refactoring code, adding tests and mentioning in code reviews about certain improvements.

So what have you guys done in your workplace to improve the quality of code? Have you hosted meetings stating the importance and showed some of the steps to writing clean code? Kept mentioning improvements in code reviews? Adding some rules to the code base for test coverage/naming conventions etc?

[dev7060]

I'm still very early in my career, but I've taken a keen interest in writing clean, readable and testable code, as I want to instill good habits on myself and also to help those who come after me and read/extend my code.

The problem I have is that I am so junior. My lead developer is very understanding and she's started to take a vested interest in writing cleaner code, but the other devs on the team don't seem to listen or follow best practices. I feel with being so junior the other devs won't listen to me and shrug me off sort of. I've been trying to lead by example by refactoring code, adding tests and mentioning in code reviews about certain improvements.

They probably might need a reason to make a change in their coding habits. Making a change in style that one has been following for long might prove to be a tough task sometimes, but it is possible.

Reach out to people in the upper hierarchy of the company with a proper proposal stating the pros of adopting best practices and how such can benefit the company in the long run etc.

Just my two cents as a college sophomore.

[gits]

while i can understand the feelings when you see existing code and feel its 'old school' or not in a 'hip' architecture - i can understand the senior devs in your case as well. Let alone call something a 'monolithic mess' shows that you judge over it from your own point of view without honoring what these devs already built - and obviously is in production and helps to earn all the money the company can use to pay your salary.

I think you get my point. Of course there are some advantages in cleaner code, loose coupling of services, testable code and all that - but you never should go ahead and tell someone what they did is straight out a mess - and in many cases these days a lot of software is more then 'over-engineered' by trying to implement all the 'new' stuff because outright seeing it as 'better'. In a lot of cases i see young developers that only can build - but not run stuff.

To init a change - you have to tackle the mindset of the team - which includes your own mindset as well - since i think you just see everything technology driven. But the issue with that is - that it will not outright provide any value to anyone without proving such. While there are lots of academic reasons that can be told for nearly everything in a codebase to be done differently - the real life value depends on solving a concrete problem. If you can find such and show that it can be solved with what you want to suggest - then you might start to earn trust - and you might start noticing that people come and ask you things and even then you won't make the world better overnight. Start with the 'no go's - and show why they are such and how to improve that - but always avoid judging the developers for it - keep it on the code only. A team is humans - so they have to be treated as such.