I am assigned a project with a teammate and their code is really bad - lots of duplication, many 100+ (even going to 200!) line functions all over the place, unreadable variable names, hard-coded values and the list goes on. I don’t even know if their code works (I’m assuming it does because it compiles and his outputs make sense) but it’s really frustrating when I have to read through their code or integrate changes. Whenever we merge changes together, we always have to sit together to go through every single merge conflict. Recently I’ve started to notice regressions in our codebase that are extremely hard to debug. In these cases I’ve had to ask them to fix the problem.
It’d be one thing if they wrapped their code into some interface that I can call and it works like a charm, but they literally put their code into some of the main classes I built, and I’m getting really annoyed by it. Partially because they “ruined” a class that I built by turning it into a god class and also because it’s hard to debug.
I know that their code is refactorable because I’ve refactored smaller scripts they built, and it became much easier to change the code.
I’m working at a research lab, so code quality isn’t a huge deal as long as you get results.
First I'd like to acknowledge how frustrating the situation must be for you.
I also want you to put yourself in their shoes for a minute. You mention they don't come from a traditional CS background. I do not think just by telling them nicely "your code sucks, you need to write better code", they would actually understand exactly how to make the appropriate changes. I don't come from a CS background as well, and I can tell you that it is not necessarily "natural" to immediately execute upon feedback, which assumes you already know 1. what the feedback means, and 2. how to make the appropriate adjustments. If you've never learnt proper clean code practices before or know how to do it in the first place, it's quite challenging. Most non CS-background folks learn to close the gap with a lot of personal effort, reading blogs/books, doing side projects, seeking mentorship and having great managers/Tech Lead that teach them (but they need to be coachable). That requires effort and willingness to learn. But the first step is to want to improve. And then be willing to put in the appropriate effort. If they don't have that (and you mention the job doesn't really *require* good code quality), they might not feel a change is absolutely required despite acknowledging their code quality is bad and slows the team; the code works after all!
Here's my perspective : I am assuming you are colleagues (same level of seniority). I don't think the problem is convincing them that code quality is important. They might know it and still not see any urgency in levelling up, or just have no clue how to improve. I think you need to gauge wether they actually want to improve and are willing to put in the appropriate effort. If that's the case you can recommend Taro courses, and start a book club to discuss blog posts/books about great practices. If you're willing to take some time to mentor/teach them on how to enhance their code quality, do so. It'll also teach you leadership skills.
If they do not want to improve their code quality or do not see the point (and are not willing to put in the work), it is going to be much harder, simply because you can't force someone into becoming a better engineer.
I really like this comment. Very empathetic 😊
I'd just refer them to Taro - and then have them take the coding course
Wow your colleagues sound a lot like me when I was doing research in my Master's! My code was complete garbage. They most likely just don't know any better.
Some possible action steps:
This does require some tact though. People don't like their baby being called ugly. Depending on how serious this problem is for everyone's productivity, the harder you can push.
The main mechanism here to prevent this is code review. For both of you, you should be submitting clean pull requests whenever you want to make a code change, and you can even review them together to share knowledge faster.
Another thing you should do is work with them before they write a single line of code. When they get a task, you can work with them to write up a detailed plan on how to implement it (i.e. what classes to make/modify, interface design, edge cases to account for, etc).
Overall, you want to take as collaborative a tone here as possible, especially since it seems like they are self-aware that their code has problems. The failure mode is it just feels like you're reprimanding them for bad code, and they shut themselves off from you.