My hovercraft is full of eels

with the development of IT area, there are more and more layers sitted on top of a PC. we could not hope the people working at different layers to understand all layers. It is like you are a member of a company, a country. Could you say you are fully understand how your company works, how your country works?

One who really has deep knowledge about the inner workings of a computer system is something like a member of an endangered species. The majority of "developers" these days are not interested in that knowledge. Why? They don't get paid for it. That's because some management people are not willing to understand that all those lean production ideas can not be applied to all and everything. Real developers with real knowledge are way cheaper than we-learned-it-in-a-course programmers. But most management people seem to not believe in this.

I have been programming professionally for 2 years, and I can honestly say I don't know anything (or not much at least) about the inner workings of VM's or the OS. I know a bit of assembler from back in school but that is it. On one hand I am jealous of people who where there in 'the beginning', and know all of this stuff, on the other hand I don't think knowing how to write compilers would add business value to a solution I'd offer a client. I think that nowadays the majority of the new generation of developers is focused on solving business problems using highlevel languages (written by older people who still know everything that's happening inside a computer). Sometimes I wonder what will happen in the near future when all those brilliant, older people retire.

I have to agree that, in general, and understanding of how the VM, etc. works is, probably, largely irrelevant these days and that delivering business value to the customer is of greater importance.

My point however was not so much is it necessary to understand the inner workings of compiler etc. but rather that the skills necessary to work at these levels give rise to a degree of problem solving skills that I see becoming less and less prelevant. Morover, I feel the loss of these skills to be wholly detremental to modern software development at every level of abstraction.

So, while I'm glad not to have to know the contents of specific registers when my application terminates abnormally, I'm continually frustrated by the almost magic and hocus-pocus that surrounds much of the arhcitecture, design and forensic practices I see in "modern" software development.

I am grateful for my days of wiring up memory and controllers by hand, and then coding drivers in assembly to see it all work.

And writing multiplication routines for processors that didn't have one...

not practically useful, but useful in the same way that ancient history is. It gives context and grounding for modern tasks.

Perhaps that is how this stuff will be taught? As history? It is nice to at least have some experience close to the metal.

So how does one get from eip pointers to:
// TODO: Need more tests but I'm tired! Need sleep. (cheeky joke...)

Hahaha. I had forgotten about that hehe. Was that from the IoC container code?

Today it's probably largely irrelevant to understand exactly how the CPU works but I do not believe it's irrelevant to understand how to Java virtual machine works. Of course, the differences between what you need to know about a CPU is completely different from what you need to know about the virtual machine.

Just a couple of examples: in pre-1.2 days the garbage collector was kinda crappy so it made some degree of sense to cache instances to not produce so much garbage. Today (post-1.3) this has almost the the opposite effect a first-generation garbage collect is virtually free and all strategies to avoid producing garbage is pointless at best and would atually hurt your performance at worst.
Another thing good to know is for example the memory model and why the double-locking idiom is broken.

And so on...

Hmm...you make an interesting distinction between a CPU and a JVM. What if I were to make a JVM-on-a-chip? Could the same distinction still be made?

But I digress. I think you are correct in saying that it's really not that important to know how CPU's work anymore. However, developers get a lot of latitude simply because software development appears -- to the non-technical person -- like magic. This is then perpetuated by the fact that a lot of developers actually see it as some kind of magic themselves (although I doubt they think of it this way).

To be honest, I probably have no idea how CPU's are fabricated these days, nor how much is hard-wired versus how much is micro-code, etc. So as I said initially, I am getting soft in this area.

One of the most interesting observations I have made working in IT is that, at least here in Australia, the best developers are not necessarily those that have done a computing degree but more often than not, those that have come from some other discipline - and I use the term discipline strongly. The single thing that seems to make a good software developer is not an ability to "program" as such but rather good analytical skills.

Software development courses -- again, here in Australia -- have become somewhat of a commodity item, much like accounting and other commerce subjects used to be; people see it as where the money is and will do it not necessarily because they have any aptitude by because it's an almost guaranteed path to financial freedom. Just the other day my brother -- a physicicst, mathematician and biologist -- was helping out at an open day for the physics department at his university and almost had an argument with a parent who wanted to disuade his son from studying physics because computing has better job prospects.

Again, I'm not sure it's really a bad thing; I feel a bit like my grandfather pining for days of yore. If it's what industry want/need then that's what they'll get. Still, I look at aircraft and automobiles and I think to myself, no matter how much the technologies used to manufacture and control them have advanced, they still basically rely on the same principles of the combustion engine and aerodynamics: things that pilots and automotive engineers are taught as fundamental skills, even today.

Sure, as one commenter pointed out, you can't hope to know how _everything_ works. But I'd be willing to bet more people are interested in trying to discover how the stock market works -- something that will likely never happen -- than spending a couple of days to find out how the rule engine they use actually works or, as Jon pointed out, understanding garbage collection (something I know very little about these days.)

No it was from Drools.

Another issue is that most peoples knowledge of compilers is at best 10 years out of date, so people make comments or decisions on factors that are just not relevant any more (as Jon pointed out for VMs). So in that case, a little knowledge in arrogant hands is harmful. I think we need to respect the lower levels, but not always understand them in detail.

Knowing a VM is a good idea, at least trying to stay updated would be. And it is kind of interesting to know anyway...

Hahaha. I tend to write a lot of TODO's like that, especially at 2am :)

As you suggest, a little learning can definitely be a dangerous thing. In the end, there's certainly no probably about it: my understanding of all this stuff is years and years out of date and quite honestly, I have very little interest in it anymore (peering over memory dumps is, quite frankly, growing a little tiresome). But I couldn't help wondering if I'd lost something important in the process; though as we all seem to agree, the answer is most-likely: not really :).