I recently started a new role at a new company several months ago. I am an experienced software engineer from big tech.

My new team consists of engineers who are older and more senior than me, but their code is woeful. Code reviews are incredibly painful if I decide to try to coach them a bit because they become defensive and double down. I decided I would just go with the flow and maintain the current bar rather than trying to push the bar higher but it's making me frustrated. The code bases are beyond messy, we have poor or no test coverage depending on the modules.

Leadership praise these engineers and promote them so I don't feel like raising it with my manager is an option.

Should I continue trying to push them towards cleaner code and architecture or just admit defeat and leave?

  • Have you spoken with you manager, team leader about this? If so, what did they say? Apr 19 at 4:40
  • And is it possible that despite the poor code base state, the process is "working"? Apr 19 at 4:41
  • 1
    @GregoryCurrie They probably wont mind given that they are familiar with it. The problem would come when someone new tries to understand what is going on and all the various hacks in place that aren't documented. If the current team were to leave, it wouldnt be maintainable by a new team IMO.
    – Eamon
    Apr 19 at 4:57
  • 2
  • 2
    The question as asked, "Should I keep trying or leave" (or stop trying but stay), is not really a good fit for this site as the best option in that choice very much depends on your own feelings, preferences and priorities. The on-topic version of the question would just ask how to approach the problem, but I feel this is already answered by Can I criticise the more senior developers around me for not writing clean code?. Apr 19 at 13:47

You say these developers are older than you. I'm assuming that they've been at the company considerably longer than you as well? If so then their approach to developing at this company may have been molded by their experiences at this company.

Management may very well prioritize getting things done over "best practices". Maybe they tried to push back, long ago, but then decided to adopt the same "go with the flow" attitude that you've adopted. In this scenario you might conclude that this is a bad reflection on management but I think condemning management could be naive as well.

If you take too long to launch your product then someone else might beat you to it with a half assed product and corner the market whilst you're still trying to make your product absolutely perfect. If that happens then all your work is for naught. As Facebook COO Sheryl Sandberg famously said "done is better than perfect".

  • 2
    This. If the company has a codebase and engineering team that works well, has happy customers, and leaves the company in profit and growth, and if the only thing wrong with it is that it offends a junior dev's philosophical sensibilities, then the argument for change is pretty darned weak. The company, the codebase, and the engineers have proven themselves. The junior dev has some work to do.
    – J...
    Apr 19 at 13:18
  • 1
    "Management may very well prioritize getting things done over "best practices"." The fallacy here is that these two things are in direct competition with one another. You say 'may', but the only thing management care about is getting things done. They also care about that on a long-term basis, though, and consistently taking shortcuts and failing to address tech debt will begin to affect the ability to do that.
    – Michael
    Apr 19 at 13:35
  • @Michael - "They also care about that on a long-term basis". Sure, but at the same time, worrying about something that might bite you in the ass two years from now is of little consequence if your company isn't even going to be around in two years. "If you're not in growth mode then you're in decay" is the philosophy a lot of business owners seem to have and when you have that attitude then non-progress could easily be seen as decay.
    – neubert
    Apr 19 at 13:45
  • It all comes down to measurability. If you cannot measure a problem, then you don't even know whether you have a problem. The talk of tech debt is an abstract concept. If you can translate this to "Our code debt costs us $10 per man-hour worked, and it can be lowered to $5." then it is something tangible.
    – Nelson
    Apr 20 at 2:54

The code bases are beyond messy, we have poor or no test coverage depending on the modules.

Is the lack of test coverage allowing bugs to slip through, and are these bugs costing the company in terms of revenue or reputation?

If yes, then make a solid business case to your manager that resources should be put towards improving the QA process. (More tests won't change how "messy" the code base is, of course, but they will catch more bugs, which is the important thing.)

If no, then the business is working as expected, and since it sounds like the culture is well-cemented, there is unfortunately not really anything you can do outside of looking for a new position elsewhere.


Which path you take is ultimately up to you, but personally I would recommend looking for another workplace where the code you work with, the attitude of your co-workers and the astuteness of management better suits what you're looking for in a job. You could stay and try to single-handedly change everything, and while it's not impossible you'd succeed, a much more realistic outcome is you quickly burn out trying to help a bunch of people who are resistant to change.

You said you haven't talked to your managers about it, so that's also an option, but again that could be difficult. You said they love existing staff, so you coming in as a new hire and telling them how crap all the current devs are (given the managers are non-technical and currently everything is "working") might not go down well. Or maybe they'll listen and start pressuring the current devs, and now all your co-workers see you as someone who came outta nowhere and starting messing with the status quo.

The job I just joined, the codebase was heinous, Borderline unusable. And the remote team who had built it was very inexperienced. Luckily I put it to the CEO to remake it from scratch, since it wasn't a huge project, and for me to do it myself, without the developers of the previous abomination (I phrased it slightly more professionally) - and he agreed. And it went great, and I'm happy. But if he hadn't agreed, you better believe I would've been out of there. Not spending 40 hours a week rummaging around in a programmatic septic tank with people who don't share my standards.

Now, you mentioned that the project is relatively new, so maybe making a barely functional mess and doing big refactors or even rebuilds down the line once the project is established and the customer base is there is what the company would prefer - which is a perfectly valid choice for them. But then you'd have to decide whether that's something you'd want to be a part of.

Just as a heads up though - you mention your previous experience is in big tech, and this current one is a relatively new project. If you're referring to a start up, and/or a smaller company, then just be forewarned that this is not an uncommon occurrence in smaller companies and start ups. They don't usually have the standard and regulations and checks and balances and so on that the big tech companies do. In future interviews make sure to ask about what coding standards the company enforces to get an idea if they have anything in place at all - might give a hint to ones that have none and would likely be a mess.


Your relationship with your team is utterly unclear. Are you their superior or just a colleague?

Regardless, this is your downfall:

trying to push the bar higher

If I can jump over a 1-foot bar and get paid for it then life is good. Why should I welcome a suggestion to raise the bar beyond my jumping capabilities?

If jumping over a singe 1-foot bar today causes me jump 20 more bars in the future then I am okay with that since I can do 1-foot bars no problem. You're coming in and saying I only need to jump this 8 foot bar once to avoid twenty 1-foot bars.

Do you see the issue?

If code reviews are nothing more than a chance for you to down-talk your colleagues then I'm not sure why you're surprised at their resistance.

You might have ruined your relationship with them already but a good way to get on people's good side is to ask them:

What do you think about the current environment? Is there anything globally beneficial that we can work towards?

Set the bar to 1.2 feet for a few months and raise it incrementally. Just because you learned something new and are used to it does not mean everyone is as eager to jump in the same boat. Think of it as a grandparent which you are trying to convince to use a smartphone.

  • "Are you their superior" ... "My new team consists of engineers who are ... more senior than me". So no
    – Michael
    Apr 19 at 13:42
  • @Michael Why can't a leader have subordinates that are more senior than them? Seniority isn't necessarily rank but rather a length of time.
    – MonkeyZeus
    Apr 19 at 13:47
  • in the general sense of the word maybe, but in the context of the workplace, I think that would be an extreme stretch. Otherwise every junior developer who has been at the company for 2 months could be considered "more senior" than the principal engineer with 20+ years experience who just joined. Seniority, in the context of the workplace, is your position in the hierarchy. His question isn't "utterly unclear" just because you choose to interpret words with non-standard meanings.
    – Michael
    Apr 19 at 13:52
  • 1
    @MonkeyZeus - I think it's useful to distinguish between hierarchical seniority (ie. manager vs dev) and temporal seniority (ie. 6mo employee vs 10yo employee). Not that the OP did that.
    – neubert
    Apr 19 at 13:56

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