I hate this type of Developer who always asks to add everything as requirement for every single detail. Company is paying you for thinking, or at least asking BA, not only coding requirements in Java/C#/whatever and denying fixes because it was not in requirements.

I can go both ways. if the requirements are shit and poorly documented on a continuous basis, I've been know to turtle as punishment (especially in cases where my percent error and velocity is skewed by their failure, I'll ask for a follow on task and slip adjustment). Generally though, agreed. If it's obvious, engage your fucking brain.

When requirements are bland or one liners, then don't expect much, granted I'll still think the problem through and go outside the "requirements" in order to make sure the feature at hand will work with the rest of the system and when requirements are fairly solid, and thought out l, then that's less thinking for me and more time getting it done and worrying about edge cases as I go rather then all in advance.

But I do detest devs who have a requirement of X and only deliver X when it's plain as day they broke the shit out of Y because of it and then go put it in the "not my problem" bucket.

Depends on the environment.

Different environments require different approaches. If you're in a startup shipping a first project out there, then absolutely you shouldn't be constrained to "do what's in the spec and nothing else".

If you're in a highly regulated, large company working on an established product, then the nitpick approach is *exactly* the right one - you only develop what's been specifically signed off. Anything else you bring up as a separate requirement so it can be evaluated and scheduled as required.