If that is their current culture, there will be a lot of pushback if you want to initiate changes. Especially among the senior (responsible for the mess) ones who get defensive real fast.
Maybe ask more about how their engineering culture is next time around during interviews.
The devs in teams I've worked with (including me) are most of time all quiete aware of the places where their code en setup is lacking and as long as they don't feel personally attacked are very happy with people who come with implementable solutions.
The not feeling attacked and implementable parts are key.
This. I've never had a negative response when I joined a project and discovered obvious problems when I explained why I think that they are or are going to be a problem and offered to help fix them. Nobody likes the guy that shows up, says "that's all shit, you need to fix it", and vanishes again. But I've never seen anyone hate the guy that shows up, says "I've noticed there's a lot of friction around X. I think we could make it easier to work with and more stable by doing Y".
And I've always liked it personally when somebody does that to me. When somebody with a lot more experience and/or skill helps you, it's like some super high level player carrying you through boss fights: you level up much quicker than if you did it on your own.
I'm of the same opinion. I love getting feedback, better if it's constructive, but all kind of honest feedback is useful and welcome. And it doesn't always come from people with more experience, sometimes a greenhorn will see things that a greybeard like me doesn't.
But I've seen people giving negative responses to the best feedback. Hell, I've had people complaining for hours because someone else replaced their manual process that took an hour to do with a script (and copy&paste of the result) that took literally seconds to run.
Yeah, I've seen that as well. I believe it's mostly fear-driven, in a way of "if this gets automated, why would they need to keep me around". It's a terrible mindset for everybody involved. It really slows the team down, and it's a major issue for the person themselves. It's like impostor syndrome on steroids. Not only do they worry that they might be found out, they worry they might be replaced by a script.
I've never personally seen somebody getting fired because a script can do their job. I've seen them being freed from doing the same repetitive bullshit day after day though, and finally being able to actually tackle new challenges.
But unfortunately, that kind of mindset is not something you can change through rational arguments, at least in my experience.
Unfortunately I have to second this advice. There's very little chance you'll be able to make things change so better to move on now than when you're depressed in a few months or years.
If the author is not going to accept the challenge, then yes, run away is the best choice. On the other hand, the situation is unique, and the author can try to show himself with these challenges.
But I agree with the last sentence. This is a huge mistake, and it seems that the author did not ask these proper questions during his interviews. Perhaps, this is the most valuable lesson to him from the story. You have to know which company you are going to join and the state of engineering.
Yup unity was what spelled the end for the Ubuntu wave. I think this has been the single biggest mistake they made. I think it will take at least a decade again to bring the linux desktop to the masses.
Gnome 2 was perfect for people coming from windows moving over. Gnome 3 is like windows vista.
Me personally, I was really disappointed (of course you can install gnome 2 etc). But at the end of the day you just want something that works out of the box.
I saw a quote somewhere from Linus Torvalds that Chrome OS may end up being the future Linux desktop, once they finish polishing off their Linux app integration (Project Crostini). I'm able to actually get most of my work done now in that environment.
Was just about to post this. I was looking for my next laptop after I got so frustrated with the direction MacBook Pros we're heading, so I took the plunge and got the high end PixelBook.
I do all my development on it: VSCode, Postgres, docker, node, python, all works great. Importantly, the Crostini project is progressing rapidly and I get new functionality with each new ChromeOS release (e.g. shared files between Linux and ChromeOS, one-button container backup, etc.)
Went in to a large rails codebase as a backend developer in the middle of a v1 to v2 rewrite and it had custom folders with their own conventions on where to put stuff.
All that with no documentation except for the setup.
What I did was just ask how the app works + specific workflows in front-end side of things and just connect the dots on the backend part.
Most of my troubles where on where to put modules because of their existing conventions.
Tips:
1. Ask a lot
2. Read the code
3. A debugger helps
4. Make sure you add tests for areas you touch.
Started with alacritty, but without tab support, was a deal-breaker for me.
I use tabs in kitty with tmux on each tab. Each tab is a context in my environment (dev/services/ansible/terraform/etc).