Link Details

I used to have a colleague who had a math background and understood many of the patterns and theory behind computer science. He was interesting to talk with, but I'll be damned if he ever got an application out the door.

To contend there is no valuable difference between Computer Science and a Software Engineer is ludicrous. I don't think anyone reasonably expects engineers who build bridges or buildings to be expert in theoretical physics. They need a very strong grasp of physics and math to build the structures, but they do not need to be academics to actually build their structures. I believe the same is true in creating software. Much like software engineering today, mechanical engineering was an apprenticeship trade in the 19th Century.

I would concede that there are realms of problems in programming that require a deep understanding of particular facets of computer science, but there is a large swath of programming work that can be done with a basic to proficient understanding.

Knowing more and lifelong learning are always going to help you, but the notion that you need formal training in high level mathematics to be a good programmer is a fallacy.

On Dijkstra's larger point that software engineering is programming for people that don't understand programming, he indicates that computers are good for solving easy problems, not hard ones. He's right on many levels, but there are lots of easy problems that need solving. There is no doubt that some software projects bite off more than can be chewed and thus end up in failure. Is this limited to software? I don't think so even though it may be more prevalent there.

He is also being pedantic about the bug business. Sometimes an error in software is not the programmers fault. And I don't really care what its called, and people who use software don't care what its called. All that matters is that a piece of software does not work appropriately. To illustrate my point. Software X displays a list of expenses rounded off to the nearest dollar. That was how the client told the programmer all business was done. It turns out that someone didn't tell the programmer that they need dollars and cents in one case. The software isn't working how the client wants it to work, but is this the programmers fault. Would any knowledge of any math have prevented this? No. There is an error in the program, but the blame does not lie with the programmer. Perhaps someone could come up with a generic term that acknowledges that something is not working right, but have less implication of blame, which can be figured out. Oh, wait, we have, its called a bug. In this case is not the programmer's fault, and while the error may have been the clients for not supplying a specification, its bad form to explicitly blame people who pay your salary. While this may go over in the ivory tower: "Hi client/boss, I know your software doesn't work the way you need it to, but the error is there and it is not our fault. It is your fault. Please hire me some more/give me a raise.", it does not on the outside (nor even inside in the administration of the ivory tower). Programmer error is one of many problems that crop up with building software. We've named the penumbra of these problems "bugs" for practical reasons as much as historical.