Apologies for the wrong thread title. I meant "Have you ever". Sometimes I read stuff over and over and over and still reads fine but is wrong. Oh well, sorry.
That's exactly one of the problems that I have. Somehow people are okay with things taking 2 years rather than 3 months though so there isn't a lot of pressure to change.
I'm at a point where I don't know if sticking around can have a positive influence on my career, maybe I'll learn to be more zen? How will that help if I change jobs? Or, will I become used to bad engineering and sabotage myself in the future? These are the kind of questions I'm having.
Assuming I have a good set of skills and enough experience, when faced with a challenging situation like this, I should try to be a positive force and bring improvements. However, I'm failing at that constantly and I just think it could have a negative impact on myself (burnout is a fact at this point).
Really trying to find the silver lining in all of this.
I think being zen is important for dealing with interpersonal situations however I think it is a mistake to be too accepting of the status quo when it comes to getting things done. Your time is valuable.
What has worked for me in the past is to find people that are able to force changes to the product (typically project or product managers, or someone else that represents the client) and find out what they need, then focus on producing something for them that gets them further down the path they are taking the product or company. These can be small things or big things, if you can help them create progress then you have a valuable advocate moving forward.
If there is no way to do that within the current engineering processes at your company then consider working outside those processes, and if that is not possible then you should look for opportunities at other organizations.
Culture comes from the top. That culture is busted. The fact you can spot problems and solutions plus you care enough to try is a big indicator you're far better off in a culture that will utilize your mindset much better.
There's a certain disdain for metrics so we're not tracking a lot of things proactively (think latency/rate, for example). That means every new change is based on a feeling of how it'll impact the systems. We also don't have a dev/test environment so changes to production are what I'd call, "faith based". There's a lot of apply to production, revert cycles. Or worse: no changes at all for fear of breaking things.
But there are more mundane things like not using a code linter because $linter enforces some rule that someone doesn't like, so discussions stall. There are literally hundreds of JIRA tickets about some proposed idea that fails to reach consensus.
I think isolating myself from the craziness is a good idea but I'm having trouble with how it would be received. Say I push a code change that fixes a bunch of things that $linter complained about, including stylistic changes. Now that has to be reviewed by someone and...? Should I just keep pushing the envelope like that? Someone will probably contribute some piece of code full of violations and then... I fix it and cause an incident with teammates?
One possible outcome is to just accept things and let go. I see this a lot in people that have been here for many years. They are also not people I would aspire to be so... I kind of have to accept defeat but that's demoralizing. I'm coming to a point where I'm asking myself where I could be and I don't have a good answer. Should I stick around and keep trying to change things? Back to the swimming against the current question.
If you think it's valuable to track latency, that seems like something you could just do. Grab the logfiles process them in your home directory, produce some graphs, keep the data over time and track changes. Ideally it would be done centrally, but as a starting point just do it yourself.
Not having a dev / test / qa environment is inexcusable, why do you not have that? Why can't you just set one up yourself? Possibly on your own workstation or some VMs, just find a way to do it.
Linter warnings are of highly variable quality. Don't bother about anything stylistic - tabs vs spaces, camel case vs underscores - those things never caused anyone's software to not work. Ask yourself "could this break something in production?".
If the answer is yes, then create a code change to fix one instance of the problem and submit it for review (not every instance of every problem, just one instance of one specific problem that could affect production). People will ask why it's a problem, you can explain it, and if you've selected a good example of a non-trivial problem, they'll accept it and merge it. Then, go and find the other instances of the same problem after you have set the precedent, and there will be less resistance. Then, start working on other problems, rinse and repeat.
Doing this will educate people along the way, and will work better than some big shock-and-awe change that touches a lot of things at once. Go easy on criticizing other people's work during code review, they're often emotionally attached to their code at that point since it's the last step in something they've been working on for weeks and want to move on from. Again, only raise things in other peoples code that could break things in production.
As for accepting things and letting go, I'd say it's more a question of picking your battles. Don't accept everything and let go. Try to improve things to the extent you can while you are there, even if that isn't forever.
Honestly it’s disingenuous for people to suggest that one person (in this case, you) can somehow fix everything by “leading by example”. That’s first and foremost a management job. So first you need to decide whether you have management support for the changes you’d like to see.
Start by examining the behaviors and outcomes your managers currently reward. This will tell you their true priorities.
Next, determine if management is rewarding those behaviors because that’s the best way they know (ignorance) or other reasons, e.g. politics, don’t care, empire building, etc. Ignorance is potentially fixable, anything else is a sign you won’t be successful.
If you’ve found that management is simply ignorant, see if they’re open to learning new things. If not, you’ll find yourself preaching to the deaf. Find another job.
Also be aware that survivor bias means that your coworkers are well adapted to the status quo. They will likely resist changes as well. See if you have any allies amongst the troops. If not, leave.
I know that this advice is heavily biased against staying, but with good reason: Cultural change is extremely difficult, and even CEOs, who theoretically have the most power to make changes, often fail at it. Better to find a culture that’s ready for the change you want to help with, rather than to stay in one that doesn’t.
Unfortunately, I have to agree. I've been hired into an informal "staff/principal" role for my part of the organization and it's simply impossible to work. The other staff/principal engineers I see here are exactly how you describe. They are against anything that will make their roles as "the oracle" less important.
Documentation is such a mess because of that and the onboarding process specifically says there are a lot of "oral history" newcomers have to learn before doing anything meaningful.
I don’t get that but it does happen. I don’t want to be stuck working on the same project forever and the only ways I can avoid that is by documenting everything, using off the shelf widely used frameworks where documentation is available and cross training.
It can be a tricky one, but fundamentally the _reason_ why change isn't happening needs to be understood. A company full of smart people is unlikely to _never_ want change for any reason - especially if that change would clearly make everyone's life easier. But maybe everyone is overloaded with work and a bit burnt out, so 'big' change is scary to them? Or perhaps the 'important change' really isn't that important? I've worked with devs before who have spoken for hours a day on the need to change x, y and z, when in reality it wasn't fully needed (and/or their suggestions stemmed from misunderstandings).
I guess my latter point there relates to the fact that there's not always a single "right way" of doing something.
Now I know that this might sound like I'm the same as the people shooting down your suggestions in your linked 'Ask HN' thread. Trust me, I'm not like that: I left my previous job a few months ago for the exact same reasons that you have outlined (i.e. there was clear change that was needed, but the 'powers that be' weren't willing to make those changes).
But to circle back to your question: assuming there aren't massive organizational problems at a company, change usually needs to be made slowly-but-surely with the buy-in of any previous 'change blockers' (where possible). Anyone trying to force through lots of change in a short period of time will usually struggle.
If even minor change is not possible, there's two main possibilities:
1) You're wrong about the change, and you might be the problem.
2) You're right about the change, the company is dysfunctional, and moving to a new job is the answer.
From your linked thread, (2) does sound like the situation in your case (fortunately/unfortunately).
