Don't just do something, stand there!
– Pragmatic Thinking & Learning, by Andy Hunt

It's easy to want to rush into a feature or ticket that you get at work. The building is the gratifying part, and doesn't force you to think too hard about it.

But I deeply encourage you to spend the first 15 minutes of your work on a ticket – every ticket – analyzing it. Your goal in those 15 minutes is to answer as many questions about unspecified requirements as possible. Say you're tasked with building a search bar. At first glance you think, this'll be easy! It'll only take 30min or so, max.

But take the time to break it down. At my job, for instance, you need to think about:

• What forms of input will this text search input accept?
• What is the backend expecting? What form will the results be in?
• Is it going to be possible to type in the bar while results are loading? Is there going to be any type of loading
• What does the application state need to look like for this?
  • Actions?
  • Reducers?
  • Types?
• Does something like this already exist in the style guide / component library / app in general? Should these be used as guidance?
• What will testing look like for this search bar, if testing makes sense for it?
• Will there be a need for this search bar in other places in the app? If so, should I make it a reusable component?

15 minutes might not be enough time to answer all these questions, but it's enough time to get yourself thinking. If it takes longer than 15 minutes, by all means take more time!

By asking these questions ahead of time, you're able to write the cleanest possible code, and save the most time re-writing old code.

There are a few mental barriers to this desired behavior:

You have to bother your coworkers, your PM, your designer.

Take it from me, a person with terrible social anxiety: your PMs and designers love to hear feedback. They get anxious when they don't. Feedback on a half-baked or misled feature spec helps prevent disaster and shows your attention to detail, a skill which is extremely desirable in this field.

It's not gratifying in the same way as coding is. You're not seeing your output appear before you.

Think about this prep time as investment in your future code quality and speed. By preparing now, you're more likely to:

a) Give a better estimate on how long the ticket will take
b) Waste less time working towards a dead end as a new part of the spec comes into focus
c) Get all of your question asking out of the way so you're not blocked by waiting for an answer during a high-productivity moment later on.

It requires honing a different skill than raw coding, which can feel like a distraction.

As mentioned above, being able to think abstractly about a ticket and identify what things the spec is missing can feel sluggish and useless at first, but other people really appreciate it. A programmer with an eye for design and product is a programmer to be reckoned with. It'll enable you to move further and faster in your career.

Additional Benefits

Engaging in dialogue with your PM and designer more often will help improve the quality of their specs and mockups too, as they gain a better understanding of what's feasible versus nearly impossible as an engineer, and why a slight change in spec on, for example, a form, can change the total dev time by hours, if not days.