Not always. The best code is no code. Sometimes you can clarify requirements (and realize the request is redundant with existing capabilities), adapt workflows, combine existing features, etc.

If someone has a request, the first instinct shouldn't be to write more code, it's to clarify what they are trying to accomplish.

"How do I get the last 3 letters of a file? I need a feature for that."

"Are you trying to get the file extension? We have that in the metadata."

Yes you do, but there are thousands of ways you can skin a cat.

Sometimes that automated something you thought was really important but super hard to do might not be as useful as one would think and the user requested it because he could.

The trick is to have a flexible scope based on what problem you are trying to solve and not around a specific feature/solution.

I have also created many problems by implementing features - usually by weighing down a system with extra complexity that turns out to be of very limited value to users. From this extra complexity are born future bugs.

Some features are best left unimplemented.