It never ceases to amaze me how many “expert-level” programmers never consider the effect that optimzing compilers may have on their code. There are many ways of writing high level logic that make it easier on compilers to squeeze out every drop of performance. Without the lower level knowledge, one is blind to such issues.

The question I continually hear when this subject comes up is, “Isn’t better to write correct code than performant code?” Well, the answer is, of course, it’s important to do both.

First off, companies do not invest in their employees! I have met SO many computer science majors who are not working in a computer related field. Why? Some decided to do something else.

Most just never found that rogue developer group job I did. In that group, the boss knew we spent half of our time learning and trying different things. Why don’t most companies insist their employees spend 2 to three hours a week learning something new and reporting back on what they learned? I have lit a fire under my own ass and learned what I need to know and even things in computer science that are interesting to know (I’ve started working through a book on Assembler).

Quality software DOES not necessarily get built by those who know the machine like the back of their left hand. I’ve seen it more than once. I know a guy who is fluent in C++ and wrote hardware drivers for Microsoft, but would introduce a bug into nearly every patch build I tested when I was still in QA! He understood all the concepts, but when he sits down to code he does not TEST!!! Why don’t developers test? Lots of reasons, including our overly accelerated market place, but some of them are developers fault. When I’m programming, I always test my stuff. And you know what? When I do that, it WORKS! I love the TDD revolution. It is not a cure-all, but developers should fully embrace it as an essential part of building software.

We should know the basics of the machine and the software stack we stand upon. I am attempting to correct that fact about myself. It’s slow going, but I find it very interesting. However, just knowing that will not fix software. We need to TEST our code and our SOFTWARE (QA engineers unite!) with both automation AND manual verification. And the industry needs to embrace these things as necessary parts of the SDLC.

Regards,
Sam

And “best programmer” is highly subjective. personally, i’d rather hire a programmer who knows how to program DEFENSIVE code and with respect to multiple threads than one who knows the last optimizations on single core machines. And the fun part is: Doing “parallel” right requires more knowledge of algorithms. Simply because parallel algorithms are a superset of linear ones.

So to sum up, I don’t know if it is correct to deduce little knowledge about algorithms from any kind of programming language preference or knowledge about CPUs and pointers. ;) And from my point of view a defensive programmer who knows about multithreading is better suited for the future. Because the future simply won’t be about single core optimizations.

Developers need to have a basic understanding of how a computer functions in order to design efficient algorithms.

In the past I have had to explain that computers like NUMBERS and not TEXT to these type of developers.

Anyone with a fundamental understanding of a computer knows “Numbers are more efficient because it’s less bits across the bus”.

Just as a mechanic needs to know how an engine fundamentally works to fix it, but they DON’T need to know how to design an engine.

A developer needs to know how a computer fundamentally works to program it, but they DON’T need to know how to design computer hardware.

My intent was not to suggest that everyone needs to know everything about everything, as that would just be foolish. But I would suggest that we as developers need to know at least high level details of what we are working with.

I do not think it to be unreasonable to want a new hire candidate to understand the basics of HTTP requests, even though it maybe abstracted away in some web framework. Likewise, I do not need them to know every detail of the hardware that they use, but the answer “I have no clue” when asked how a CPU works is unacceptable as we don’t develop on magical glowing boxes.

I am not suggesting the bar needs to low, but I am suggesting it shouldn’t be high enough to walk under.

First, registers are not an abstraction. If anything, they make life more difficult. They improve performance by reducing instruction size and holding data that will soon be used in higher speed storage. They don’t really abstract anything. It would be much easier to program in assembly if you could just directly refer to memory locations.

Second, do you *really* understand how your CPU works? Do you understand how it takes apart instructions and schedules the use of processing units, often out of order? Do you understand how cache architectures works? Do you understand how synchronization instructions interact on the memory bus on an SMP system? Do you understand how interrupts are routed to processors on an SMP system?

You may understand these things, but very very few software people do. I have to know about them since I work inside a kernel, but the really low level details belong to compiler writers and processor designers. The “CPU” as most software people know it is an abstraction on top of something quite different.

Third, I don’t see what algorithmic analysis has to do with languages. You can do algorithmic analysis in any language.

As far as your premise, I used to think that way also, but I’m no longer so sure. Perhaps understanding the details a level down from where you work is useful, but if you go to far you will be buried in too many details.

I *do* think that teaching and doing algorithmic analysis is a good thing because of how it trains your brain to think. You may forget how a quicksort works, but the training that went into understanding it stays with you. And knowing the various tradeoffs of tools you choose is probably a useful thing, too. But understanding how superscalar architectures work is probably not useful to the average software designer.

Also there is a shift toward web based apps and people won’t care about how the CPU works they’ll be happy knowing how to do their job. And you’ll be thankful when someone that knows the basic of HTTP ;)

It’s great to have all the modules and such that the extra layers of abstraction provide in Firefox, but it is no competition against a simple browser that is as fast as lightning.