Anybody can code

There's a real problem in my place of work and probably in other places where you have scientists and engineers who haven't been formally trained in CS and haven't taken the time or effort to learn about proper techniques but who are writing a lot of code. It's one thing to whip something up quickly to answer a question, but some of this code becomes pieces of larger things or gets delivered to a customer. And someone has to maintain it, but it's got memory leaks, isn't documented, it is unreliable, it's not secure, and no one knows what all licenses were on the random bits and pieces.*

Now for the sad reality: My 10 years as a professional software developer has taught me that people who have CS degrees, and cart around the title "software engineer" seldom bother to use the proper techniques they damn well know, and just like the scientists and engineers you're complaining about, produce buggy, undocumented, unreliable, insecure code, attached to pieces with who knows what licenses.

Sort of why I went for Information Science as opposed to a pure Computer Science degree.

I can code, no doubt about that. Last contract I had I think they were stunned that I could figure out the UPC check digit algorithm.

Simple really, sum up the digits you have and then round up to next tens unit. Divide that by 10 and you've got your check digit.

It has to be simple, hardware manufacturers aren't going to waste CPU cycles to do a complex hash or calculation.

I prefer to draw a distinction between Computer Science and Computer Engineering. CS pretty much *is* math. CE is programming, algorithms, design, ect.

CE folks need to know basic CS, but not much more typically. CS folks could care less about proper coding practices and project organization/design beyond the little needed to implement the odd proof of concept or tool.

That isn't to suggest the CE isn't very worthwhile, it is just quite different. Kind of like the difference between chemical engineering and chemistry.

BTW: I'm a bit odd... not CS or CE, but I dabble in both a bit. I'm quite interested in making the tools I've been developing actually usable since I think that is actually contribution to science. Sadly, the incentives are actually against me spending the time and effort involved in coding more carefully, much less actually putting together a decent package for distribution.

The saying while I was going to school was, "An engineer can do CS, but a CS can't do engineering."

I've seen loads of horrible programmers who have full-fledged CS degrees - the issue is competence, not training. At most institutions, CS is a "lighter" degree than something like engineering or physics. This attracts more of the people who couldn't cut a harder workload, and of course their lower level of performance continues throughout their life.

Obviously speaking in generalities - some programs have blistering CS routes, and there's quite a few CS people who could've easily handled the more math-intensive programs. But as a rule, CS < Eng/Phy.

'scientists and engineers who haven't been formally trained in CS and haven't taken the time or effort to learn about proper techniques but who are writing a lot of code.'

A quick comment on this - i'm a phd student, who needs to do a fair bit of coding - i've found it difficult to gather support to go on courses teaching basic good coding practice. My lack of experience limits the size of program i can write, and its efficiency.There are some course around, but they can take a bit of finding - i wonder if this is also a part of the problem?

I've known plenty of people who have a CS degree but still can't and/or don't code worth a damn. I've known plenty of people who were not CS and could code better than CS people.

Then again, computer science has little to nothing to do with writing good code.

"I can write programs that control air traffic, intercept ballistic missiles, reconcile bank accounts, control production lines."

"So can I, and so can any man, but do they work when you do write them?"

Fred Brooks, after Shakespeare, in "The Mythical Man-Month", quite possibly the best book on software engineering yet produced.

'To a man with a hammer, everything looks like a nail,' - Mark Twain.

The worst I've seen is a self-styled programming expert open a file, incorporate 200 lines of boilerplate C (to get his favourite include files, as well as asserting his identity and copyright), CVS-ing the thing and only then engaging the brain to understand it wasn't really that sort of problem.

Eric Raymond's Art of UNIX programming has plenty of wisdom on this - that programming should be appropriate - and that includes the fact that military-grade exception-handling is not usually required ...

Yes, I've seen this phenomenon, as well as its corollary that one's own code is excellent and everyone else's is junk. So I sometimes have to decipher code with unexplained magic numbers, mysterious loops, and the like.

I have the second edition of Numerical Recipes in C on my bookshelf. It's a useful reference for a number of things, one of which (a feature the authors presumably did not intend to include) is a tutorial in how not to write C code. The authors are disdainful of comments and white space, they make no real effort to have their variable names reflect their purpose, and they impose a 1 to N structure on a language that prefers to go from 0 to N-1, even when it makes no substantive difference to the algorithm. Which makes it difficult to figure out what they are doing when their algorithms get a little too clever.

Speaking of comments: In homegrown code, their primary purpose is not to make your code readable to others (although that is a secondary purpose). Their primary purpose is to remind you what your thought process was, so that you can debug or modify the code months or years later.

"I've known plenty of people who have a CS degree but still can't and/or don't code worth a damn. I've known plenty of people who were not CS and could code better than CS people."

I second that, Phil. I have come across a few CS types who have not got a clue about HCI or interface. They really should be kept away from doing HCI/design-related projects.

It's about imagination and drive, really, and how much you enjoy your job. I must say coding takes patience. It's the 'patience' bit that is tough, not the codes.