Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
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.
C0D45594175dWhen 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.
AlmondSauce788675dDepends 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.
molaram223475dwell we should also consider how some employers/clients ask for a blog then @payday are surprised it has no CRM features.
Takes a while finding that sweet spot...