I have been working for the same company for 20+ years, fortunately I have not been on a team with such lack of care and focus. I have however worked on teams where we had to work significant overtime. You are very mature to realise that this will have a negative impact on your wellbeing. Studies anyway show (as Jack have published previously) that working 60-70 hour weeks is only effective for a short period of time, thereafter you are so tired you could have just worked 40 hours a week from the start. One should only work overtime for genuine unforeseen problems and NEVER for lack of good planning or because other people are doing the minimum they can.

I agree with some of the previous responses. You will not get good mentoring in this type of team, look to transfer to another team or another company if you have tried to improve the situation without success. You will only know what other opportunities are available if you start looking around.

This experience is however invaluable  and when you do find a new team or company which is mature and works together well, you will be able to appreciate it. Often people do not appreciate a good team and leave for better money and end up in a bad team.

I would like to take you to task somewhat on the late and buggy firmware. You provide some articles to back up these claims, but there's nothing newer than 20 years ago.

I would have agreed with you back then, but now I think complexity is by far the bigger enemy these days.

In that time there are so many things that  have completely changed the nature of defects. Straight critical programmer errors (what I tend to think of as real bugs) are less frequent. Some of this is due to improved test regimes, using operating systems with bounds checking, better compiler warnings and many other factors.

One large change is that much of what is now considered "firmware" is actually application software. Many, if not most, complex embedded devices are now running Linux of such and are really high end computers (compared to 20 years ago). Most of the programmers are now software-oriented people with software training rather than EEs who did a 6 month course in programming.

So the "dumb stuff with pointers" and other coding problems have diminished (relatively speaking).

Instead I think the massive increases in complexity give us far more system integration problems:
* Subsystem A is bug-free and works fine. So does subsystem B. But when they are plugged together unexpected interactions cause the system as a whole to fail.
* If you have a remote Bluetooth device interacting with Android and iOS, you might test it and it all works great, but then a subtle timing difference in a new Android/iOS version causes it to fail.
* Increased complexity means it is easier to forget to specify or cater for some required features.
* Increased complexity makes it harder to test different use cases especially when different regulations kick in across the world.

A modern cell phone maybe has 5 different cell bands as well as FM radio, two Wifi bands, Bluetooth (Classic and LE), GPS. That's a lot of radios (before we even consider the unintentional radios such as DDR buses, power supplies, ...).

So much of this is changing very rapidly. Very few products will ship with the same set of specifications/requirements that they started with.

Often the complexity is such that the marketing team determining requirements do not sufficiently understand the technology and their customers' problems to make solid specs. And the engineers likely don't either. Instead they end up learning during the development.

Thus it is not surprising that often specifications and requirements change, leading to massive project blowouts.

I of course recognise that different people have different experiences, but that's been my experience on the last few projects I have worked on over the last 10 or so years.