implementation trivia is not one of your concerns
An architect that does not know how to implement is a bad architect and a programmer that does not understand the architect is a bad programmer. Implementation trivia is extremely important to the proper implementation of a system.
The implementation drives the architecture and the architecture drives the implementation. The best system meets in the middle.
quote:
Sometimes what the hackers do is called "software engineering," but this term is just as misleading. Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it's there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.
What and how should not be kept too separate. You're asking for trouble if you try to decide what to do without understanding how to do it. But hacking can certainly be more than just deciding how to implement some spec. At its best, it's creating the spec-- though it turns out the best way to do that is to implement it.
I knew quite a few people who designed and wrote code that was easy to read, worked, easily maintained, got it all done on time and were considered mediocre.
That would be above average in my book. To me, an "excellent" programmer would not only do that, but also not be wasteful with resources, and would analyze the problem themselves and architect the program their-self.
If you don't get the right answer, you fail,
Getting the "correct" answer is not good enough, the answer needs to be correct for the right reasons. A lot of my job is cleaning up "correct" implementations. Quite a bit of my job is handling high profile cases that need quality, performance, reliability, debugability, and needs to be able to handle massive feature creep. You know how to handle feature creep in a way that doesn't involve lots of technical debt? You anticipate the features ahead of time, or at least the general direction.
Most work being done is "good enough" and "works", but I am back-logged with projects trying fix the inadequacies in other systems that I did not make. I have a back-log of projects to improve my daily work, but instead I constantly get drafted to fix other people's poor designs. They work great for the first year or two, but then go to crap once they need to start extending.
Before I got into my current position, we've had relay feature requests from high paying customers to engineering, only to get quotes like this poster-child of 1,000 man hours and 6 months. Then I wrote it myself in less than a week, deployed it to production, never had a bug, has been running for 3 years on hundreds of systems.
This is good for job security, but can be quite annoying, because it's a waste of my time cleaning up other people's messes. I have plenty of job security with my official job description duties.
Memory speed can technically still be the bottleneck
And taking a piss before you head to work can save you gas money. Your link shows an 80% increase in memory speed giving a 1.7% increase in performance. Congrats, you just doubled your memory's power consumption.
Do you understand that using a single RSA style dongle for multiple places is a huge risk?
If you have an infinite number of systems to log into, how many dongles is optimal, and how do you keep track of which dongle to use with which system? Where do I keep these dongles? My pocket is already uncomfortably full with a keyring with 4 keys and a fob on it. My other pocket has a smart phone.
To the systems programmer, users and applications serve only to provide a test load.