I have a junior developer on my team who consistently struggles to meet our code formatting standards, particularly in SQL and PL/SQL. We're lacking a good linter or style formatter for guidance, making adherence a manual process. During code reviews, I often find their submissions are significantly misaligned with our standards. Simply pointing out a single error isn't effective, as they'll fix only a few and overlook the rest. It's become a repetitive task for me to explain why their code doesn't meet expectations, which I feel is a poor use of my time.
I've discussed this with my manager, who believes that with enough feedback, the developer will eventually get it right. However, I've seen that even when I'm diligent about providing feedback, the quality of their work deteriorates once I ease off. I suspect this issue might be rooted in management, but I want to know if there are other strategies I can employ to help this developer change their habits.
5 Answers
Have you considered using SQLFluff for your linting needs? It could help automate checking similar code issues and might alleviate some of the burden on you during reviews.
Ensuring they are aware of the importance of code standards is key. If the junior dev keeps failing to meet them and fails to learn from feedback, it might be time to address this with HR or management as potential insubordination.
That’s exactly it! Learning to follow standards is part of the job, and ongoing issues need to be formally recognized.
Right. If they ignore guidance repeatedly, documenting these failures becomes vital for further action.
You could be persistent about returning work until the standards are adhered to. If he continues to slip after receiving feedback multiple times, it could indicate a lack of commitment or ability. It's valid to raise this in his performance review too.
I understand you’re not his direct manager, but documenting these issues can still help in providing feedback. It builds a case for management if there’s no improvement.
True, make sure you keep your own records of feedback given. This could guide conversations during performance reviews later.
You might want to reject PRs with a note saying 'Does not adhere to our code standards, please refer to this link for details' instead of pointing everything out each time. It'll prompt the developer to take the standards seriously without you needing to hold their hand every step of the way.
Definitely start with thorough code reviews. But, you should also set a rule that merge requests won't go through until they've addressed formatting issues. Just ensure the coding standards are documented clearly and easily accessible for the developer. They need to understand why following these standards is crucial, so it’s also worth sitting down with them and discussing this.
Absolutely! Having well-organized, easy-to-follow standards can make a huge difference. And maybe take the time to create a nice flow or examples of what you expect.
If the standards are too vague or hard to access, it might explain some of the issues. A good documentation will help everyone on the team!
Good idea! I’ll definitely check that out. Thanks for the suggestion!