I came across two posts recently which inspired me to do a more thorough job in my day-to-day life as an engineer:<p>1. https://news.ycombinator.com/item?id=33439052
2. https://news.ycombinator.com/item?id=33594264<p>At my current job, there is a lot of open field, and one can be creative about finding solutions. On one side, you really have to know and understand the business to come up with something "good". On the other side, I want to be able to clearly spec out what I am currently working on.<p>I most often jump head first into a problem, see if I can figure it out from the code, and think to myself: Once I know what I am dealing with, I am taking a step back and map it out on paper. Although, the second step rarely happens.<p>Next would be the case when creating open source libraries. I would like to start with an idea, and really spec out the broader implementation before jumping into coding.<p>So, dear HN crowd, what's your best insight into getting better at this?
A specification is written to solve a problem of some kind.<p>It is surprisingly often that people try to write a specification without fully understanding the problem - the steps are Problem Identification, Requirements Capture, Specification.<p>This is especially the case with user requests, they often don't specify the problem in their request, but provide their desired solution, which may not be optimal across the system, or may not have considered all the possible options at the right level.<p>The requirements should solve the problem, and the specification should address the requirements.<p>If you break it down in this way then is can become easier.<p>On large conventional engineering projects as much as 15% can be spent on these first phases, and then a decision made whether to fund or not.