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:
- 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.
- 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.
- 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.
Where is X documented?is asked when a piece of code has surprises or confusing behaviors. I would contest on the grounds that the code should not have been full of surprises and should have been less confusingly written. But I feel your pain about documentation.