Team makes excuses about bad software and practices instead of fixing it. How to head in the right direction? [closed]

Question

At my new job I sometimes make mistakes. Usually these mistakes are because of assumptions I make based on other jobs I've had, other tools I've used, and other software I've developed on this very team.

Inevitably when we talk about what went wrong, I ask "Where is this information written down?" or "How can I avoid this in the future?" and the answer is always along the lines of "Remember that X in context Y is different than X in most other contexts". The lack of standardization on any practice is hurting my morale, productivity, and perception among the team (I'm seen as negative, and I don't want to foster a toxic workplace). If we have to make a decision, we usually do a little of both; we also never completely roll off of old practices.

The excuses I'm given for this go something like this:

1. Why in this case things really did need to be different, but why we couldn't make a solution that was either documented or automatic.
2. What team should've been responsible for documenting this, but were (inevitably) really busy or (my personal favorite) what obvious solution would've been better, now that I've hit one of the many edge cases in yet another poorly thought out solution.
3. A stressful sigh, because I'm being unreasonable, thinking things should be standard in any way, and a phrase like "yeah, we really should work on that in the future" or "yeah, maybe we can fix that when [project touching that system] starts up"

How do I tell my team:

• I'm tired of excuses; we're all adults, and we should be able to work in an environment that isn't held up by the whims of whoever wanted a quick workaround instead of doing their job.
• We shouldn't accept this kind of environment. Think of how many workarounds just one senior person knows. How are we going to continue to function if new employees don't stick around to learn them all, and senior employees retire? We're going to pay for this tech debt one way or another some day.
• We really can fix this. It will be tedious, and we might step on some toes (everyone around here is cool with just slapping some (metaphorical) tape on it and waiting until it falls off again to take another look), but if we put some thought and diligence into our solutions we can slowly pay up some of this tech/process debt.

As an alternate solution, I see myself as having these options:

• Don't try to fix things. Make only the necessary changes. Try to document edge cases (either just for me or posterity somewhere), and avoid them.
• Go home and study and jump ship once the time feels right. Get on a team of people who solve problems instead of finding the workaround that requires the least amount of effort and just trying to remember that in the future.
• Work super hard to fix all these problems. Try to avoid pushback from people used to this way of working, and don't be discouraged when people that neither understand the problem nor have read your proposed solution say things like "if it ain't broke, don't fix it", meaning "if all we have to do is ask others to restart their servers from time to time, what's the big deal" or something similar.

These "solutions" are not mutually exclusive.

I don't feel like I can change this culture myself, and I like my immediate team, but it's super draining to constantly step in these mud puddles that real professionals would not tolerate.

Edit: I can't comment, so my responses to the comments are inline below:

Jimbo: that's a part of the third "option" I guess. Work diligently to document everything, make tickets so one day things might be fixed, and try not to get frustrated as the rabbit hole deepens.

Vietnhi Phuvan: I have no authority over this team. I'm not sure what you mean by meddling. I don't have a responsibility for fixing the software and processes that we work with each day, but it affects us all, and it affects our output. I have not "build a coalition". Others feel strongly about certain things, but usually just accept them and go on with their day-to-day work, or try to get resources to fix them. I'm not the only one ranting, but I am the most discouraged on my team; part of the problem is that "problem with an acceptable workaround" is no longer a problem to most people around here, and "acceptable workaround" means "any workaround". I'm working on a plan of action. I'm going to research how other companies solve these issues, why it's more effective to solve these problems instead of live with them, and come up with a clear upgrade path. Alternatively I'm going to build my skills until I can leave. The credibility I have has to do with the kinds of questions teammates already ask me.

Kent Anderson: Thanks for the thoughtful response. I'll try to stay positive in the future. The point that surprised me most was "try and understand how/why your teammates think like they do". Maybe I can figure out their motivations/process/intentions and be more effective. P.S. I'm not the one always speaking up in meetings, in fact I've stopped almost completely, choosing instead to try to help form a consensus instead of trying to put new ideas on the table.

Finally I'd like to accept Kent's answer, but I've forgotten the first throwaway account's email :(. Thank you all for your comments. I'll work on this.

Answer 1

This is going to seem like I'm picking on you. I'm not, just trying to be objective...

Be very careful about declaring everyone around you as unprofessional. It's not true, especially if they are veteran workers. As the new person on the team, you are likely unaware of the historical reasons they do things the way they do. Sure, there are unprofessional behaviors in the workplace. Complaining and accusing others of being unprofessional is one such example.

Does every meeting contain an element of you vocalizing that things are not what you wish they were? If so, there is some basis for your team to regard you as difficult or a complainer. If this is the case, try to identify a solution and offer to implement it for them. (Maintain a wiki page for the team, for example.)

I am sure you were much more positive when you first started working on this team, and now you are beaten down and fed up. Try to recover some of that positivity and tolerance you started with. You will be happier. Do what you can to try and understand how/why your teammates think like they do. Take personal notes you can review if you get into one of these areas where you think you might be "stepping into a puddle." Resist the urge to flash a page of notes as "proof" your team is being inconsistent or capricious. That never makes things better.

If you get to the point of bailing out (either from the team or from the company altogether), remember, there is no such thing as a team that does everything right, all the time. (What does "right" even mean in this setting?) Leaving might help you feel better, and might be the right thing for you to do. Just don't embark on a nomadic career searching for the perfect team. You won't find it.

Again, I'm not picking on you. I remember the frustrations I felt early on in my software development career because others did not measure up to my ideals, or to my "standard" of technical excellence. Patience, tolerance, and offering to help fix things are the best ways to ease your frustrations and encourage changes to be made.

Answer 2

In situations like this often the best solution is to simply find a new situation. Not all shops run like yours. There are development teams that strive actively for continuous improvement, that do not rely on individuals to remember obscure work-arounds or bizarre dependencies, that understand current best practices and follow them or have a very good reason to do something differently. In my long experience, shops like yours eventually go out of business. It may take a while, but eventually they will be overtaken by a smarter competitor. Now that you know the sort of place you do not enjoy working, you can be more careful about the next offer you accept.

Answer 3

Put yourself in their shoes.

If the code base that you have to deal with is no good, they know about that. It is quite likely not because your new colleagues are not decent programmers, but because there is pressure to deliver things quicker than possible while doing a job properly. Things are not documented because someone couldn't hit a deadline and document what he was doing, and when he or she delivered at the deadline, new work came up before anyone could start with the documentation.

Some of them may have arrived at the company recently and had the exact same ideas that you have now, and then it turned out they couldn't do anything about it.

But what are they going to say if you say "your code is rubbish and needs changing"? The same thing that you would do in two years time of the next new addition to the time says exactly the same to you. They will be defensive. Nobody wants to admit that their work (through no fault of their own) is not the highest quality. If it is through their own fault, they will be even less likely to admit it.