Advice that I give to interns/grads:

In uni/college, you're taught *how* to code something to achieve a goal, and 99% of the time the code will work and do the job in a lab.

But when building things for a real production environment, you learn the 100 ways how *not* to code, from seeing things break left right and centre - basically everything and anything can break your code, whether it is users, the OS, other people's code, legacy code, lag, concurrency, the alignment of the moon to your server...

Anyone care to explain why programs nowadays use so much bloody RAM? We went to the moon on what amounted to a bunch of potatoes wired to each other, Linux (a whole bloody OS) with a graphical interface consumes only a couple hundred MB of RAM, but my IDE needs 1+GB?

Seriously, unless you're handling very large amounts of data (like a high res image or doing some insanely crazy math, I doubt there's any need for such high usage. I get it, 8/16GB is commonplace, but that doesn't mean more should be used for shits and giggles...

Theorem 2.71 All software is shit.

Corollary 3.14 So stop the braindead OS wars. All OS are shit, too.

Proof. The only software that can stay beautiful and clean is software that is never used. Maybe if you are Dijkstra or live in a Haskellian world, you might come away with it, but for the rest of us our artifacts have to interact with other artifacts or are build upon strange historically grown systems, they have to deal with users who will put it to creative use.. and in the process we also actually might have to alter some state.
Or put another way: code is a social construct. Like science are the beliefs and superstitions grown by a scientific community, software is the montainous dunghill produced by our laborious efforts to make shit even work. Of course this only piles the stack higher and higher until you can already smell it from the moon.

There should me moonOS for programmers, instead of sun. As they love to work at night. :)