This weekend I was reading Operating System Concepts, 9th Edition, commonly known as 'The Dinosaur Book'. It seems to be well regarded as THE book on operating systems for undergraduates. I've been reading it maniacally since I have an open-book test for my OS class on Monday, and the course is entirely based on this book.

I've been really enjoying reading it (and not in a Stockholm syndrome kind of way), but it got me thinking about how many of my class mates will NOT be enjoying reading it, and probably aren't reading it at all. This train of thought led me to wondering about how much of this knowledge the average software engineer (or developer) has.

Do they know about preemptive vs nonpreemptive process and thread scheduling? Do they know their page replacement algorithms, or how modern operating systems make use of virtual memory? How often do they consider thrashing while developing? Do they need to?

These are questions that I don't have the answers to, as I most certainly don't have enough experience interacting with the 'average' engineer in my area. Not to mention the higher-tier areas where everyone is a super-engineer.

A couple months ago there was a guest on Scott Hanselman's HanselMinutes podcast who mentioned that he thought every developer should have a working knowledge of the 'level below' their regular work, and AT LEAST be aware of the issues of the level below that. If my memory serves me right, by levels he meant how abstracted the level of work is from the bare metal of the machine.

In the podcast they were talking about JavaScript libraries, but I think the issue is well demonstrated by the Java language. In this land of levels, a Java developer will obviously be very knowledgeable about the Java programming language, but they should have a working knowledge of the Java Virtual Machine (JVM) and JVM Bytecode (what happens to my code when I compile it), and they should be AWARE of how that level interacts with the one below it. How does the JVM interact with the operating system it's running on? What can, and does, it do?

I think the vast majority of developers will find that the operating system is either the level directly below their level of work (and thus should have a working knowledge of it), or the level below that (and thus should be aware of what it concerns). This makes sense since I think you'd be hard pressed to find a developer that wasn't at least somewhat aware of process scheduling and possibly parallel processing.

I'm interested in what you, the reader, have to say about this though. Have you read Operating System Concepts? Did you find it useful? How much do you know about operating systems, and how much would you say your colleagues know?