In The surprising habits of original thinkers Adam Grant describes the sweet spot between precrastinators and procrastinators for optimal original thought.
In short, completing your tasks far ahead of time or at the very last minute leads to less original thought.
Think of this in terms of a developer getting their tasks done.
Typically we're pulling tickets off job queue. If you're a developer then you've probably worked with GitHub Issues or Jira or some similar system. Tickets are usually prioritized from most important to least important.
If we've never seen the ticket or problem statement that we've just pulled to work on then our original thought process for solving this is the equivalent of an extreme procrastinator. We're learning about the problem at the same time as we're solving it. This leads to less original solutions and probably the first solution we think of instead of the best solution.
One way to mitigate this is to have grooming sessions. We meet as a team and go through the backlog of tickets and in addition to prioritizing them the ticket creator will explain the ticket in more detail so that we can estimate the effort in completing this. More details are also added to the ticket if needed. The team sometimes discusses possible approaches to solving this. Most important, in my opinion, is that this problem has been dropped into your subconscious and whether you like it or not your brain is noodling on a solution in the background.
Something that I feel we don't do often enough is "kick tickets down the road." In other words, there are tickets that we should procrastinate on that we don't.
Some tickets are critical and need to be done immediately. Major security vulnerabilities fall in this category.
If the ticket is not urgent and can be punted and you or the team are uncomfortable with the current array of possible solutions then do it. Kick that ticket down the road. And do it intentionally and without shame. Add a comment on the ticket stating exactly that:
The team discussed this issue on DD-MMM-YYYY and we were unable to come up with an idea for addressing this in way that we wanted so we're putting this back in the queue to mull on.