I must post a link to this because, well, the guy that wrote it shares my last name. Who knew?
I’d probably generalize away from this conclusion some distance. What’s always a good idea is to spend the time to get closer to the situational details of the problem at hand. What really puts the hex on real world problem solving is becoming distanced from the realities of of the situation on the ground where the solution is utilized. In business they talk about getting close to the customer; for example.
There is certainly something very valuable to be learned by getting down to the assembly language. One of the things you come back with is that there are dozens of programming tricks of the trade available at that level that are very hard to invoke from the high level language level. For example if you have control over the memory manager you can build very sweet caching schemes that use memory faults to trigger cache loading. For example if your have access to the register block move instructions and the displays memory mapped hardware you can get some very sweet graphic effects.
Those lessions generalize to other situations where you gain situational knowledge. For example all the abstract understanding in the world about the way open source works won’t reveal that the value that a CVS diff brings to making the conversation about changes clear and focused. All talk about public spirit won’t recognize that if users can’t find the developer mailing list and simple instructions about how to submit patches that they wander off rather than contribute.
It’s always good to get close to the situation; and I suspect that any situation will do.