I have a special spot in my heart for toxic management styles, so here's my take:

First of all, I don't really agree with a programmer adding things in ad-hoc to make things more (from their perspective) user friendly. I'm not taking a stab at you, I'll explain what I mean in a moment.

It seems your first manager seemed a lot cooler, and was the kind of manager that's easy to impress with unexpected features and shiny things. This is fine, I do get a nice buzz too when I'm able to impress a manager, but I find these guys are often pretty much ok with letting process slide on the development level so long as they perceive their programmers as being productive. Also the just "fix it" attitude, in my experience, has led to us having to sit on top of a lot of tech debt just to get the manager off our asses. Of course when things break it's going to be priority, but in these cases I think it's more important to "just fix it" AND think about how to prevent it, and have a look at how our process failed in order for that problem to arise. A good manager, in my opinion, will ask those questions and give developers space to put feature development off for a moment in order to address any technical deficiencies.

As for your second company - this sounds completely horrible. If it were me I'd be making some serious noise about how things are running there or finding another job. First of all, I'm totally against any blame game against individuals in a team so long as they're cooperative and supportive of the team (and of course show some level of competence). There should be no blaming individuals for breakages - you are a team, and together you're building a product with processes that I hope you've all decided on. If things break, the team's process is broken and you need to have a discussion.

For example, you should have test coverage and have a requirement for all developers to write tests around their code. Let's assume that you do and the app still breaks, well, then you can write a test around that breakage so it doesn't happen again. You can also check and see how that case managed to get skipped while writing the test. A breakage should be an opportunity to learn and improve the system, not a blame game where everyone's covering things up to cover their asses.

Now just to cover my first point, I think it's great that you like to add new features and stuff to your software, but I believe that these kind of features should be put through a pipeline before they're accepted into production code. In past projects we've used Agile-ish practices involving a card wall. We have say, a backlog column, dev column, test column and accepted column.

An example of how this would work is if one day you decided you wanted to add feature X to the app, you'd first consult with the business side who'd either accept or reject your idea, then it's added to the backlog and prioritised. When it's ready to be put in, it'd go into the 'ready for dev' column and then you'd just go ahead an implement it. Of course, before it's put into production it needs to go through the pipeline on the wall I described earlier. Not to get too specific as to how the project should be run, but you can see that management, development and testers are all involved in feature X being implemented. As such, who's ass is on the line when things break? Everyone's! And that's ok, hopefully then, as a team, you'll have a constructive discussion about why and not who.