The last time I was sitting in the train on my way back home I sat next to some computer science students complaining about the operating system course at their university.
“It’s way too low level”, “I never going to need this because in my Groovie world everything is painted in pink.”

Well, I do not agree here.

When you work on any project with a decent size there will be moments where you find yourself struggling with the limitations and quirks of the OS you are using. This may be anything from performance issues to all kind of allocation restrictions and filesystem limits.

If you attended the classes, you know about those problems in the first place and can code around those critical parts with appropriate methods. But if you have no idea about scheduling, threading, memory management, I/O stuff and security, to just name a few, there will be certainly a moment where the program is unexplainable slow or runs into strange errors and you have no idea what is going on. Or even worse, the external problem does not get identified as such and you start wasting ages finding the point in your code base which is responsible for the unexpected behavior.

And what will you do then? Analyzation programs nor your fancy tools will help you here. Suddenly, the pinkness of your Groovie world will become the everything covering tacky and brown glue which, slowly but steadily fills up your head-internal project cache and gives you those clammy feelings when something gets changed.

Frameworks and developing environments get better and better over time, let developers create more reliable applications in shorter time. But even today, in the age of Java-VM, .NET-VM, Whatever-VM you still have to deal with that thing which is running your hardware because the perfect abstraction doesn’t exist.

Thats when your computer science knowledge from some dark place deep in your head comes into. Because after the operating system course you can pass by the limitations of your framework and operating system, because you know what you are actually doing and what you cause deep down in your framework or operating system. Otherwise you don’t even have the slightest chance to fix, not even to detect those kind of problems. This ability differs you also from the outsource-endangered species “code monkey”.

And that leads me to the point that you generally should somehow understand the tools you are using because one day they will strike back and you will find yourself in huge problems and cannot go on with whatever you were doing. In that moment where the fancy automatizations you are using fail, the only thing you can do is hoping that there will be some kind of guru around who has the time, knowledge and lust to help you. Or you just know what the whole thing is about, search for somehow related keywords in the internet and find a solution for your problem within one or two hours.

However, obviously you cannot be familiar with all apps’ details you are using, but at least the core stuff you should understand. Putting your work in dependency of something you have no idea what it does and just hope that it will run yet another day is a bit crazy.