> read "The Design of the UNIX Operating System", read "TCP/IP Illustrated Volume 1"
What? Those are unnecessary details as far as software engineering is concerned.
What? Those are unnecessary details as far as software engineering is concerned.
To this list, I would also suggest compiler construction or database systems as different topics exhibiting the same thing.
A more basic challenge for a scientific programmer might be absorbing the mindset of tool building rather than problem solving. It's a different mental perspective to think of your code as a product for other developers rather than as a means to producing a data artifact.
What I like about them are that they describe large complex systems that have to work with a bunch of people plugging in their own implementation of the parts. For me, both books give a good sense of what you need to do to enable the product you are working on to evolve successfully, and highlight areas where a lack of flexibility impacted that evolution.
So often in programming you look at your code and have to evaluate not only what features you are delivering but also what paths you are closing off with your design. In my experience the folks who excel at programming hold both the model of the system in their mind while they execute some part of it.
I think both books give a flavor of that.