[rhythane]

This book actually makes some sense to me as a software engineer. We’ve all learned this at school, but they were just scattered pieces of knowledge. This book actually offers a way of systematic organization of useful knowledge in production. Content is actually not for learning, but for quick check and review. The organization might not be perfect, but really is a way of reflecting on our understanding in this field.

[viraptor]

Did we all? I haven't done a lot of this during my master's and neither did any of my friends (that's across multiple countries/unis).

But yeah, it's a really interesting way to organise the knowledge.

[globular-toast]

What did you do?

[viraptor]

Everything apart from design or software architecture as such. (Unless you include that one weird class on UML and Sybase) Math, electronics, algorithms, encryption, physics, legal side of things like gdpr, networking, compilers, UX, embedded systems, chip design, different CPU architectures, reading research papers, databases (about acid, not specific implementations), ...

But the part of "how to manage the process of creating this" and related ideas you were basically supposed to figure out on your own. Or actively ask the teachers. It feels very sink-or-swim now in retrospect. I've never been explicitly taught about testing for example, but if you didn't write them for your projects, I don't think you'd complete them.