zlacker

Some people really like killing those kind of bugs. I know people who would move from project to project, at the end of each, killing the show stoppers. I've done that myself.

But what I'm describing there is an environment where:

1. Developers are treated with respect

2. Different skill sets and different motivations of those developers are recognized

>>lowblo+(OP)
Actually what you're describing is completely different. Because if you're expected to only be working on those long, abstract, difficult tickets, none of the pressure to deliver features/bugfixes piles up as in the GP comment. But when you've got features on deadlines, there's not enough freedom to skip meetings and chug coffee all day without turning in any code.

>>diggin+M2
So make that the expectation.

Expectation management is a huge driver of quality of life.

Knowing how to carve out your niche and not be expected to delvier feature after feature without a break is part of "managing upwards", which is another important life skill to gain.

>>diggin+M2
A lot of those long, abstract, difficult bugs become blocking/ship preventing issues, so...no pressure. And alas, many (most?) developers suck at debugging, so if you're any good at it, you get everyone else's broken code to fix. sigh

>>eterm+On
"carving your niche" involves either through a lot of experience (power) or to be known in the industry (clout). The latter isn't all based on raw skill so you just hope you don't burn out before you get to such a point.