Programming

I have seen a number of recent articles about projects which aim at encouraging more people to code; the aim being not one of, as it were, providing the means of acceleration for potentially good coders, nor, again, of providing the skills needed to do personal customization of editors and spreadsheets but getting more people involved in actual programming as a career.

This is, I am sure, well-intentioned, but it is probably not a good idea. If you go into software development not because you find it interesting, but because it pays reasonably (and at the upper end, better than reasonably) well, then unless you are buoyed by an unusual degree of intelligence you are potentially going to be a problem.

Consider the following profile. It's a merged profile based on some people I've known over the years (and on the code from many more people's code I've encountered). We'll call this developer Fred, because I do not know and have never known a developer named Fred.

Fred has decent credentials: at least a C.S. B.Sc. from a mid-range university. He - it has, so far, always been a he - works in the financial sector or another sector which makes significant use of custom software; he's not in the software industry itself, nor a worker at a startup.

Fred's work has always been on large and medium-sized systems. He may have been involved in some systems when they were new, but mainly he works in maintenance and extension. He's a diligent worker, and addresses the tasks given to him with reasonable speed.

Fred's real interest, though, isn't software in itself; it's a means of supporting himself and his family. When handed a task he does the minimum necessary to address the problem. Fred invariably leaves longer functions, larger files, and cyclical dependencies behind him. Unless he's carefully monitored, he doesn't concern himself with levelization or insulation.

If he were working in an environment which required adherence to best practices and enforced it, and if he were always to be assigned to implement a team leader's design, he probably wouldn't do too much harm. But in most cases I know of in environments like his, you're lucky if lip-service is even paid to the more onerous best practices, and nobody does code reviews or pair programming. The only people to see Fred's code up close are he himself and his successors when he moves on.

Fred is entropy at work on code. Even good programmers generate bugs; this sort of just-good-enough programming generates incomprehensibility over the medium to long term.

The blunt fact is that not only is good programming difficult - and if you don't believe that, try reading John Lakos' Large-Scale C++ or Alexandrescu's Modern C++ Design[1] - but it requires both an unusual degree of analytic ability and an enthusiasm for the ding an sich which is difficult to maintain at a high level.

My advice to a reasonably bright person with some competence at math but no love for it would be to gravitate to some less temperamental branch of engineering. If you have the sort of mind which revels in abstractions - if you feel the call of really pure math, or certain sorts of philosophy - then programming might be a good fit (given that positions teaching pure math are as rare as hen's teeth).

[1]And don't believe that moving to a higher language will save you. There's a ton of bad code in Java that I've seen. And scripting languages like perl and python degenerate into spaghetti code at an astonishing rate.