Hmm, the usage of .dbc files is interesting. That format is owned by Vector and proprietary. I'm curious as to what the limits of using DBC are, as I'd love to integrate them into the product I currently work on without paying thousands of dollars for the official API from Vector.
I definitely identify with this post. I love figuring out each and every bit of the product I work on, how it interacts with other code or products or whatever, before inevitably getting frustrated when the focus is on shoving more features into the product haphazardly instead of fixing existing issues or getting a better understanding of the feature and how it best fits in the product.
I think I've begun to figure out how to use that to my advantage though. Ultimately any product is driven by business concerns, and you have to use that same skill of understanding of how code pieces fit together with how business pieces fit together. "If I improve this interface then the code will be more modularized" isn't going to make much waves with a product manager but "If I invest five man-days now, we'll save ten man-days per year and here's why" absolutely will. It's very tough as business and human concerns are much less structured and easy to understand than algorithms, but it is an important step in being an engineer and not a computer scientist.
I've actually used a subset of that book for on an embedded system. It ended up being scrapped, partly due to project management issues and partly because we were writing twice as much code for very little benefit, so I can't say I recommend it for embedded projects. The need for malloc was a pretty big negative as well.
That said, I would recommend it as a good learning experience.
Looking the PDF over again you don't need malloc, that was a quirk of our implementation. We had separated public/private structs, meaning private variables were inaccessible by non-class methods (and thus also unable to be instantiated statically by other code modules.)
