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.

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.

Quite a few of the programmers I work with are in their 40s and 50s. A few of the senior software engineers are in their 60s. I sometimes find myself explaining things to them, but overall, they're quite smart people relative to many people I have met in the past. At least they don't make obvious mistakes and are good at following industry standards.

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.

First you have to find the top 20 Indian programmers. The same issue exists for finding good programmers anywhere, lots of noise from the not so good ones. You also have the issue of communications. They may speak English, but there are some large cultural differences when it comes to actually communicating ideas.

The level of interest someone has in a subject is generally a good indicator. When it comes to programming, it's not the answers that count so much as how one arrives at an answer. What we need is interactive dynamic analysis of logic. Generally it works best just to have another "great" programmer strike up a conversation with another.

Programming is a bit different than other fields, there are many technically correct answers, but few good answers. In hindsight, identifying a good programmer is much easier, because their creations are easy to debug and work well, even when beyond their design.

A great programmer understands enough stuff that they can debug their creations on a whiteboard without looking at the source code or using a debugger.

I know for myself, I have no background in the Go language. My co-worker came to me telling me he had an issue with an example program where it became slower and slower, very quickly, when it came to lots of channels and go-routines, and he couldn't figure out why. First I started asking basic questions about how the Go language is meant to work, then I asked him how he had his stuff setup, then asked him what he expected. I couldn't find any fault with his setup with my limited understanding of the Go language, but I do understand multi-threading and generally work with complex interacting systems. So my next question was what compiler he was using. Turned out he was using GNU. Then I asked him how they implemented it. After a bit of digging, turned out they used threads for go-routines because threads are much easier to implement quickly for a proof-of-concept compiler. Then I found out they limited how many threads could run at once. This meant that his go-routines, which were blocking each-other, normally would not have an issue in a correctly implemented compiler, but because the number of go-routines which could be processed at a given time was a fixed small number, it effectively created a pseudo-dead-lock, which fixed itself after some timeout that scaled poorly with the number of go-routines. A quick minor change to how the channels were configured, and it ran quickly.

Obviously, in my example, my co-worker is quite smart also, he was able to answer all of my questions or look them up quickly. He came to the same conclusion as I did at the same time. We work well together, which is why my boss paired us. We're great at asking questions. Good answers are hard to come by, good questions are rarer yet.

Having no background in a specific language, I was able to quickly, I think about 15 minutes, figure out a kind-of-deadlock issue in what technically should have worked, by understanding how the compiler implemented "go-routines". My only real-world experience in programming is C#, I don't do any at-home hobby programming, but I do a lot of reading.

FYI: You can snoop L2 cache, but not L1. Intel went with inclusive cache so snooping wouldn't be needed. AMD went with exclusive, which gives better cache usage, but went trying to sync threads, all of that cache snooping is a high latency operation. By having cache being inclusive, you no longer need to snoop, just look at cache normally.

AMD has higher overall throughput for many GPU type work loads, but Intel shines with work loads that require thread syncing.

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.

Taxing the 96% to cover the cost of hardware and man hours to maintain these filters, which just amounts to something similar to religion or out-sourcing parenting, seems to be an abuse of power. What's next, taxing people in health care to cover homeopathic "remedies"?

I also have the ability to look through people's wallets and purses when they're at my house, but it doesn't make it legal for me to start taking note or changing stuff in their belongings.

IOMMU can already control DMA access. Secure boot can restrict what images can boot, the images can restrict what devices have DMA access, and after granting DMA access, what memory ranges they have access to. We already have the tech to handle this situation, it's just a lack of implementation or a poor implementation.

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.

There's many chicken and egg issues going on in Africa. Send food, and the incoming food becomes like money and manages to help fund local war lords. This actually happens. Sending food causes people with guns to start to show up and find a way to exploit the situation.

You also can't send money or send technology. All of those things cause issues with exploitation. One of the few ways that have actually worked is making real demand for work in those areas.

Any artificial support creates exploitation, you need real demand for real work. This is hard to do in areas of under fed people with no education and no real government. Intel has started sourcing their rare minerals from some of these poor areas. They painstakingly make sure trace all of their mineral sources to make sure they're not "blood minerals". This makes it very hard to exploit. The gun men stay away because once they move it, the operation loses all value because Intel refuses to trade with them.

Stuff like this has helped a lot. I'm sure there are other ways, but throwing money/food/etc at an issue actually makes it worse. Temporary help is one thing, but for sustaining issues, it does not help.

But if the house was unable to be sold for $70mil in the future, there would be less chance of anyone building it in the first place. It's the people in the future that drive the demand for it being built in the first place.

The parts that are not dependent on Windows. They didn't opensource the Windows Secure Storage API, because the fundamental parts required for that API to work is in Windows. Pretty much all of the stuff that can work on any system, has been opened.

The "Windows" version of .Net is going to be based on the OpenSource version. MS is working on transitioning the Windows .Net stack to the exact same version as what they have on GIT. While there may be some forks of .Net, the official MS repo on GITHub will be the one Windows uses.