- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.
- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
Essential reading list:
- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...
- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
I'm sure that Rob is a great employee, and the book does have a few good points, but I'm not sure I took away a whole lot from it.
It's funny because technically, none of these three things are part of an engineer's job.
But once you do them, you start noticing how you eventually get to:
- save yourself time
- save your customer money
- avoid unnecessary complications down the road
- offer useful comments / feedback / critiques / alternatives, when need be
(because you better understand the decisions made around you)
- help your customer or team better understand what they really want
- find yourself in a better position to transition to other roles, if you choose to
Btw, I wrote a blog article a few days ago about exactly this: http://claudiu.dragulin.com/2016/12/02/dont-just-code-solve-...