![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jsburbidge) wrote2020-01-23 09:48 pm
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.
no subject
Abstraction is hard; the old OR dicta that you can automate anything you can fully specify has teeth, and fangs, and tentacles.
I just finished something that's got a multi-entrant/multi-exit recursive grouping setup because the entirely flat input has four kinds of notes, three of which have different relationships to list levels. I am very aware that I don't understand the whole thing at any one time and that it doesn't quite do precisely the right thing. Now that I've done it, I would want to approach the whole problem differently, but it's a one-off for a specific "cheaply as possible" conversion exercise. Which is another part of the problem with Fred; code code is expensive.
no subject
I recall particularly converting ten volumes of typesetting files into SGML so that the content could be edited for semantic correctness and then uploaded into an Oracle database, doing as much regularisation of content automatically as possible at the same time, e.g. standardising court abbreviations.
no subject
I have had just enough contact with court abbreviations to shudder.
no subject
It's worse than you think. Thus was citation data going back to pre-Confederation times, and it had been originally input by low-paid temp data entry sub-editors, not trained compositors.
That project - the one where the input took place - had been run by a prime example of Dunning-Kroeger syndrome, and the data from it was utterly useless, for reasons I won't go into here. So we had to go for the tapes from the compositors, which was classic format-only markup.
I used flex as a front end (with some frightening regexps) with a C++ engine behind it, and a ton of lookups to regularise to known data.
A good block of the core regexp logic ended up being reused for an entirely different purpose - marking up citations via pattern-recognition and database lookups in report data input in the Philippines and, later still, coming in from the courts, and for all I know is still used. The last I heard of it was a few years ago when I ran into an old friend of my sister's who had met someone from Carswell who, when she mentioned my name, found that Carswell wss basically running my code but had nobody with the skills to maintain it, as they had moved away from C and C++ to Omnimark and other 4GL tools.