1

How do you deal with poor coders?

Profile picture
Software Engineering Intern at Taro Community3 days ago

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.

  1. I’ve mentioned several times to them to refactor the code but they don’t seem to listen (even after explaining that it’s hard for me to contribute since I can’t understand their code), though they seem to acknowledge their code is bad. I think they don’t come from a traditional CS background which is why they don’t care (or know) that much about proper engineering. How can I convince them that quality is important? How do I tell them (politely) that it’s because of their quality that we’re iterating much slower than before?
  2. It’s likely that I’ll have to deal with bad codebases at some point in my career. When do I suck it up and when do I actively address it to the team to do maintenance? What are some heuristics?
34
5

Discussion

(5 comments)
  • 1
    Profile picture
    Supportive Tarodactyl
    Taro Community
    3 days ago

    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.

    • 0
      Profile picture
      Tech Lead @ Robinhood, Meta, Course Hero
      3 days ago

      I really like this comment. Very empathetic 😊

  • 1
    Profile picture
    Mid-Level Software Engineer at Walmart
    3 days ago

    I'd just refer them to Taro - and then have them take the coding course

  • 1
    Profile picture
    AI/ML Eng @ Series C startup
    3 days ago

    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:

    • If it's a monorepo or not that big, you can introduce a linter with custom rules
    • Offer constructive feedback. Their code works, but it's ugly. The polite way to say this is "Code works great, just a few style changes" on the PR reviews.
    • Find people who are either underperforming due to the codebase or are tired of dealing with shitty code and work with them. Suffering people are the most open to change.

    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.

  • 0
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    3 days ago

    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.