A couple things to combat some of these: - When interviewing for a new role, interview the people you will work with and ask questions about the company. Inte

A couple things to combat some of these: - When interviewing for a new role, interview the people you will work with and ask questions about the company. Interview them. Discovering during interviews that an employer or co-workers aren't a good match for you is the best place to figure that out. - Realize and accept that most software doesn't need to be perfect. There is an acceptable level of quality and then after that it doesn't matter to the business. Sure its likely someone else's money but that contributes to unhappiness. When production bugs happen, tackle them like a professional and save the "I told you so's". - Same can be said for large waterfall driven software processes. They tend (not all but many in my experience) to have a lot of feature bloat of things people want but never actually use. This could be borne out of politics or appeasing people, misrepresented requirements or the business changes faster than software delivery. Recognize if you work in a shop that does this and come to terms with it or suggest gathering metrics on usage of your system as part of your requirements process. - A lot of the reasons stem from existing software and issues it has. You might think to steer clear of old code and work at a startup or greenfield project where everything is new. There is a certain satisfaction, maybe enlightenment is a closer word, when you figure out unexplained/broken software and fix it. Have you felt that? You'd be amazed what little fixes to do quality of life for the people using the software. "I am one with the code and the code is one with me".