>If your coworkers are pouring into a product with severe defects in the technology or business plan, the best thing to do is start that conversation, not help

>If your coworkers are pouring into a product with severe defects in the technology or business plan, the best thing to do is start that conversation, not help them waste their effort. I agree, and in that case 'the work' becomes exactly what you described. I never intended to imply that 'the work' always consisted of programming. Also I'd say that flaws in the business plan are more important to address than flaws in the code. Shitty code has conquered the world many times over, I don't know if I've ever seen an example of good code doing the same. (see below) >At the end of the day, if your leaders are making bad choices, talk about it and be ready to find a boss or organization you're excited to work for. Except they all make bad choices, compared to the ideal code we imagined our future selves would be writing. See my comments on the big ball of mud. In the end the centre cannot hold, mere anarchy will be loosed upon the world[1], and all that code will devolve into a big ball of mud anyway. If the business plan is good the CxOs and sales guys will be happy, though. So in my opinion, it can be better to stay at a company that is good enough, with colleagues and bosses that you know, instead of idealistically seeking some programmer heaven that doesn't exist filled with colleagues and bosses that you don't know. [1] http://www.potw.org/archive/potw351.html http://www.potw.org/archive/potw351.html