Pros
The users of our software almost never worked nights or weekends, so we never really had to make ourselves available to fix production issues during off hours. That's about the only thing I can think of that I appreciated.
Cons
My company was acquired by Symplr. Very quickly we were forced by leadership to abandon our development process, and had to adopt the "SAFe" (Scaled Agile Framework) process for our team. Engineers are not encouraged to participate in the design and architecture of features. Instead they are told to provide estimates for work that management and product have already planned out. Estimates are expected to be made MONTHS ahead of time that the work is to be done, and if they are wrong (which they always are) management lashes out at engineers, sometimes screaming at them in large meetings in front of all their coworkers. The expectations that management has for planning is very unrealistic. The entire development process dictated by upper management seems like the worst parts of agile development combined with the worst parts of waterfall. I stuck with this for about a year, after management said "give it time, it will get better". It never did. Before being acquired by symplr our team had dedicated time to address technical debt. After being acquired, new middle management was shuffled in and that time was taken away. Technical debt was growing out of control when I left. The only way to pay it down was to lie to management about what you were doing, and work secretively with other engineers on things. There was hardly any time spent by engineers on design and architecture. There was NO ownership of any part of our code base. Engineers that wrote bugs rarely had to fix them. There existed hardly any engineering leadership. Most "senior" engineers had no desire to do anything but take the path of least resistance to implement CRUD features. Zero thought was given by them to best practices, code organization, performance, backwards compatibility, data models, service boundaries, testing (even basic manual testing was ignored by some). Some engineers actively ignored and worked against attempts to implement best practices and improvements to the code base. After being acquired by Symplr, our team size was doubled. All the new engineers were hired from cheap offshore code shops in India. The quality of work was what I might expect from 1st year computer science students or interns with no professional development experience. They were not given any chance to train or onboard with the full time engineers on the team. Instead we were just expected to review their exceptionally bad code. Most full time developers quickly gave up on trying to review their code because it was so bad. Any serious attempt to review offshore code would take WEEKS of back and forth because of how bad it was. To contrast this, most on shore code review took less than an hour. Despite most developers airing many grievances about the offshore teams, management stuck their heads in the sand and praised them whenever they fixed a bug once every couple of weeks. The pay was subpar. Compared to current market rates, they underpay their developers by tens of thousands of dollars. The CEO told employees they should not discuss their salaries with one another in a company wide meeting (a right that the National Labor Relations Act protects). The CEO explicitly says in company meetings that they do not want to pay market rate for software developers. They prefer to loose their talented engineers who know they can make more elsewhere and replace them with armies of outsourced developers. As they implemented this staffing strategy the quality of work drastically fell.
