I'm more offended by the guy's attitude than what he has to say. He sounds like some middle-aged manager who got miffed by some young "rockstar" (ugh, hate that

I'm more offended by the guy's attitude than what he has to say. He sounds like some middle-aged manager who got miffed by some young "rockstar" (ugh, hate that word) and the kid's sense of entitlement... because it clashed with his own. The "young hotshot" sense of entitlement is pretty repulsive, but so is the "fuck you, I'm your boss" attitude exemplified by the OP. The saving grace of the former is that it tends to fade after an ass-kicking or two. Some general observations: 1. There's a difference between mundane and boring. Things that are mundane are not thrilling, but rather neutral in their psychological effect. Stopping at a red light is mundane. That which is boring is psychologically offensive. Mundaneness is fine (and inevitable) in software development. Boredom is different. Having a programmer spend 8 hours per day working on tax forms/compliance work, without the option of automating it, is just ridiculous. It actually is better to let him write an abstract system so that someone else's time-- preferably someone less expensive-- can be put to the "dirty work" using his tool. 2. The "big picture" of a project is what makes it interesting and provides motivation; the details of even the coolest projects are mundane. I'd even go so far as to say that 75% of the time spent on a cool project is still involved with mundane details. People unable to handle this fact generally don't become good programmers-- or good anything. What this means is that if someone's a decent programmer, his problem is not that he's unable or unwilling to do detailed work. Even on cool projects, programming is one of the most detail-oriented jobs there is. 3. Mundaneness escalates into boredom only when there are so many mundane details as to occlude the interesting part of the problem... or when no such interesting part exists (e.g. implementing compliance/tax logic). The pattern-match for the supplemental forms is a trivial example of a mundane detail, and certainly not enough to make a whole project "boring"... but 10000 lines of such code is going to become an incomprehensible mess (much like, well, the bulk of bureaucratic red-tape that exists in the business/legal world). 4. Taking a design perspective on this issue, boring things generally belong in data, not code. On the example of the supplemental forms, those rules should be encoded in such a way they can be put into a database. Computers are great for managing large masses of boring information. Humans are not. 5. At root, the OP sounds like he's whining about the fact that he's unable to motivate his employees and that his attitude (which, of course, is without flaws) turns them off.