-2

I'm a senior software engineer working for a tech company. I've been in the same company for more than two years. There are lots of interesting problems to solve that I love.

I'm super happy to have some super smart coworkers, they can understand and solve the hardest problems. However there's a huge problem: they write the worse code I've ever seen. Everything is solved with more if lines, duplicated code, non descriptive variable names, long methods, global variables and everything you can imagine. It's devastating seeing that I've spent two weeks doing a refactor to later see that a coworker completely broke the new abstraction I've added copying and pasting code instead of using it. I could expect this from junior developers, but they aren't.

I've discussed this with my manager in a 1:1 and he completely agrees with me. He encourages us to take as much time we need to deliver something good, we are not a startup anymore. The problem is nobody cares, we have code reviews but, for example, if I ask to add a test, they will ignore my comment and get an approval from another person. Basically, they write code that just work but sucks and I feel there's nothing I can do to improve this.

I guess that I'm not a good fit for this team and the culture doesn't match what I like, but I live in a third-world country where there aren't many jobs and leaving the company is not an option.

4
  • Are there cases where those bad practice have an effect? If this is the case then it would be good to let them realise their mistake by correcting someone else's code plagued by this. If the culture isn't there then people will go for the easiest solution unless they have an incentive to improve. That incentive may be bugs or other people.
    – Al rl
    Sep 9 '20 at 17:09
  • I makes our system really hard to reason about. We have to do lots of manual test because it's almost impossible to test in an automated way, so it slows us down a lot. And as a personal effect it's really frustrating. Sep 9 '20 at 17:17
  • 4
    I've read it twice and I am not sure is there some answerable question here. How to tolerate something that annoys you? Just ignore it. Or do you want to somehow train the unwilling coworkers into a new level? Sep 9 '20 at 17:21
  • 2
    Much (most) of what you've stated is subjective. Who's the arbiter of good/crappy code? Is your code above reproach? I don't see a question that can be answered here.
    – joeqwerty
    Sep 9 '20 at 18:00
5

I've dealt with this in the past, "senior" developers who write code which works (barely) but is sloppy, has lots of design errors, is untestable, etc. Here's what I did:

  1. Deny all PRs sent to you. Firstly, write comments in each PR telling them what to fix (yes, I know, it's exhausting). Then if they refuse to fix them, click the "close PR" or "deny PR" or whatever button on your VCS to shut down the PR. Then contact your manager to alert him that the PR was denied and why.

  2. There really is no way to prevent people from merging their code by going around you. So you have to put yourself in the position of a roadblock. This is going to take approval from your manager. Alert your manager to the issue (it seems like you have), and offer to take responsibility to be the gatekeeper until the code quality improves. If your manager trusts you and puts code quality above timelines (which it seems he is amicable to trying), this should not be a problem. Then, your approval will be required on all PRs, so there is no getting around you. Be aware this will put additional load on your work schedule as you will have to approve every PR, so be prepared for that responsibility.

Now, if you are positioned as the roadblock, you can maintain the code quality and your team's code won't get merged until and unless it meets your standards, and you have your manager's blessing to shut down things that aren't proper. Your team will be forced to write better code, and eventually they'll just start doing it and you won't need to be the roadblock anymore.

It might be helpful to set up a Lunch and Learn session about proper coding standards and so on, to teach your team what you expect of them. They might not know it, so explaining it to them so they're not blindsided might also be productive.

2
  • Prepare for fierce backlash...the manager should make a public statement with the team to explain the new path and set consequences for not playing along...otherwise great answer!
    – morbo
    Sep 9 '20 at 18:33
  • Unless you are actually in position to have a final say to make decisions like this, and are not just another teammate following this answer is likely going to get you in trouble. Don't act above your station, and especially don't be a pest to people you have to work with, even if you disagree with the code they create. And as this answer doesn't explain those risks, I have to -1. Sep 9 '20 at 18:45
1

This is one of those things that needs to be escalated to management, and shop standards need to be outlined and then implemented.

In my case, I was the lead, so I could enforce the standards personally. If you want to do that, you are going to need buy-in from management.

Badly written code may run well during sunny day conditions, but when something blows up, or needs to be changed, thing go south quickly.

This is a point which you need to drive home to your manager. All of this hideous code that works now will have to be maintained, and in cases where it's a coding free-for-all, it becomes a nightmare for anyone having to maintain the code if they didn't develop it.

Emphasize all of this with management, and see if you can parlay this into a position where you have more control. Make management aware of the nightmare scenario when a customer encounters a condition that throws an exception and they want it fixed NOW

How is anyone going to quickly fix poorly written code? Answer: It can't be done.

3
  • Yep. While there is an upfront cost related to building quality code versus cut and paste, patched over code, technical debt represents a higher hidden cost that eventually kills projects if allowed to accumulate unfettered. The tee shirt I'm wearing right now tells it all: "99 little bugs in the code, 99 little bugs in the code, take one down, patch it around, 117 little bugs in the code." Sep 9 '20 at 20:39
  • @DavidHammen the majority of my career has been the life of a maintenance programmer, I am going to find that T-shirt and get one for myself. Sep 9 '20 at 20:53
  • Find one with a better scansion than mine. (A quick google search shows there are multiple versions.) My tee shirt doesn't quite match the drunken scansion of "99 bottles of beer on the wall". Sep 9 '20 at 21:04
1

You could attempt to placate this issue by suggesting simple and quick ways to improve code quality.

This will depend on what languages and IDEs you're working with, but consider using code quality tools such as SonarLint https://plugins.jetbrains.com/plugin/7973-sonarlint . These are (usually) free, easy to install, and allow you to improve code quality with plenty of customizable options and minimum overhead while coding. I've used SonarLint in a previous Java/Spring project and was surprised by how little the additional corrections bothered me, and was able to produce considerably simpler code in pretty much the same amount of time.

Be sure to discuss this issue with your team, though. You might find more success convincing them by appealing to their convenience with something along the lines of "it will be way easier to look at each other's code if we use these tools" and by providing constructive criticism. Management should also not be a problem if you can demonstrate that this lower quality code is causing time losses, and is therefore a financial burden that could easily be minimized.

1
  • Using "SonarLint" and "Easy to Install" in the same sentence is of questionable veracity.
    – Ertai87
    Sep 9 '20 at 17:44
0

they write code that just works

Well, at least the code works. Nice code which didn't work would be worse, right?

Firstly, you should be grateful you are working at a place which produces working software, because believe me, I've worked in places where most software releases are late, missing entire features, and buggy as hell.

I'm not saying that nice code has no value, but it's value needs to be measured. If writing bad code resulted in buggy, un-testable, unmaintainable code then that means there is a financial cost to writing bad code, and this cost can be measured.

Assuming writing good code will eradicate the bugs, high cost of ownership, etc, then it's down to the management to make that cost decision.

I also think that you should not be "devastated" that colleagues don't follow your lead. It doesn't mean that they don't value your input, or appreciate the work you are doing. Perhaps they are thinking, "well Throwaway123 is keeping the codebase clean, so I can just focus on delivering working software as quickly as possible".

7
  • Definitely, the product makes lots of money which is the most important thing. My manager trust us a lot and always asks us how long a task will take. Although he is a technical person, he never sees the code, so as long as it works it's fine for him. There's some legacy code which I don't expect to change, but not having tests for new things? It's not something he will get as a requirement, it's up to the team to do it or not. Sep 9 '20 at 17:25
  • The problem comes when things need to change. Sloppy code breaks easily, even if it works, and is damn difficult to fix on the fly Sep 9 '20 at 17:26
  • 2
    @Old_Lamplighter not once in the original post does the OP mention low testability, buggyness, slow release cycles, etc. From this I was forced to assume that the code was simply ugly.
    – numenor
    Sep 9 '20 at 17:33
  • @numenor although I didn't mention it, our code base is buggy, we have slow release cycles (because of other teams, too) and most of our testing process is manual Sep 9 '20 at 17:39
  • 3
    @throwaway123 - OK, this is the point I was trying to make with my answer - you described the code itself, rather than the bad effects this code was having - the measurable effects. It was designed to draw attention to this fact. Rather than agonising about the code, you should be focusing on the effects and how to counter them. If changing the code is the solution, then you need to change the code.
    – numenor
    Sep 9 '20 at 17:46
0

It's devastating seeing that I've spent two weeks doing a refactor to later see that a coworker completely broke the new abstraction I've added copying and pasting code instead of using it. I could expect this from junior developers, but they aren't.

I don't think your co-workers are purposely broke the abstraction rules. They probably didn't know any better.

I've discussed this with my manager in a 1:1 and he completely agrees with me. He encourages us to take as much time we need to deliver something good, we are not a startup anymore. The problem is nobody cares, we have code reviews but, for example, if I ask to add a test, they will ignore my comment and get an approval from another person. Basically, they write code that just work but sucks and I feel there's nothing I can do to improve this.

I don't think this is good enough. The fact that he only agreed with with what you said rather than doing something about it tells me that he probably doesn't care. It's also a hint to his mindset because he's saying that "we are not a startup anymore" which to me means that at some point he's okay with just getting things working rather than having a good code base.

There are three things you can do:

  1. Quit. Find a job that has more senior members who care about the code quality.

  2. Tolerate or educate. Just accept that since your manager enforces no standards that you must either tolerate it and/or educate your team mates.

  3. Demand your manager to enforce rules. This will be hard since your manager already made it clear he's not willing to enforce anything. Have #1 handy so that way if things go south, you can easily just bail out.

Not the answer you're looking for? Browse other questions tagged .