Obsolescence
Feb. 1st, 2016 11:06 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
garoteEvery couple of months, somewhere on the planet, some acolyte programmer or frustrated employer of programmers comes up with the bright idea that they could solve the problem of software development once and for all if they just built a set of software tools that management could use on their own, to describe their needs to the computer and have the computer do the work.
In the 60's it often looked like a telephone wiring panel. In the 70's the popular designs involved physical cards or cartridges that you could move around. In the 80's it was rudimentary wireframe gears and puzzle pieces, in the 90's it was drag-and-drop shapes that you connected with arrows, in the 2000's it was touch-based drag-and-drop shapes, and this decade it's the voice interface that just has a dialogue with you until it figures out what you want. Plus a zillion variations on all of these themes, drawn from contemporary sci-fi.
Despite endless attempts all over the world over the course of 50+ years, no one has managed to make programmers obsolete.
Instead, demand for them has exploded with each new leap in processing power. In the 60's computer programmers were a vague presence, somewhere in the depths of the largest buildings. Nowadays all middle-class parents nationwide worry about teaching their young children how to program so they aren't "left behind".
And that's what sets programming apart. If you want to be a programmer for any length of time, you need to keep learning. In a single season your skills could become half as useful as the next guy/girl, because you didn't notice some new advance in the field and learn how to leverage it. Programming is obsolescence-proof - because the obsolescence is built-in, and happening fast enough to shroud the whole discipline in a permanent blur. We are all like Lewis Carrol's Red Queen, running to stay in place.
In the 60's it often looked like a telephone wiring panel. In the 70's the popular designs involved physical cards or cartridges that you could move around. In the 80's it was rudimentary wireframe gears and puzzle pieces, in the 90's it was drag-and-drop shapes that you connected with arrows, in the 2000's it was touch-based drag-and-drop shapes, and this decade it's the voice interface that just has a dialogue with you until it figures out what you want. Plus a zillion variations on all of these themes, drawn from contemporary sci-fi.
Despite endless attempts all over the world over the course of 50+ years, no one has managed to make programmers obsolete.
Instead, demand for them has exploded with each new leap in processing power. In the 60's computer programmers were a vague presence, somewhere in the depths of the largest buildings. Nowadays all middle-class parents nationwide worry about teaching their young children how to program so they aren't "left behind".
And that's what sets programming apart. If you want to be a programmer for any length of time, you need to keep learning. In a single season your skills could become half as useful as the next guy/girl, because you didn't notice some new advance in the field and learn how to leverage it. Programming is obsolescence-proof - because the obsolescence is built-in, and happening fast enough to shroud the whole discipline in a permanent blur. We are all like Lewis Carrol's Red Queen, running to stay in place.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-02-02 07:33 am (UTC)Recently I think I came up with some kind of complexity hierarchy.
1. Individual blocks, can be moved around. If you put smaller blocks over larger blocks, you can build a pyramid. Good job! In language hierarchy it's finite language, the kind animals use.
2. Assembly lines. Loops, with break statement (optional, but considered a smart thing to have). In language hierarchy these are regular languages. Sys admins think they can do anything using regexes. Parse XML, for instance. Oops.
3. Context-free languages, parsers-combinators. These are good for relatively complex but well-organized systems; what's good with this level is that one can hide complexity (that's encapsulation is available). Any level of parentheses. Monads are here.
4. Context-dependent languages, spaghetti code, modern microservices architecture, everything is connected with everything, and nobody knows what will break if one small router in a dusty corner is suddenly disconnected. Applicative functors are probably here.
5. Fixed-point solutions. Dynamic programming is somewhere there too. It's like magic. Free monads, suddenly providing a solution for the problem that does not seem to have any. The solution just exists, and we can (or cannot) prove it, without getting into details how it works.
But all these things are only interesting to those who do something. The people who need tools to fulfil their dreams. There's also another kind of people, whose tools are just words. Their world is full of magic. They say something, and it just happens. They think of themselves as powerful magicians. And they are too dumb to see the levels of complexity.
no subject
Date: 2016-02-02 08:07 pm (UTC)I wouldn't call the people whose tools are words "dumb" ... but certainly "impractical", and perhaps "ignorant" and "unskilled"...
It reminds me of all the special effects "computer displays" in Hollywood films, where the "hacker" types furiously away in a terminal window while meaningless 3D widgets spin around elsewhere on the screen, and the performance - whether it's "break into a security system" or "locate the president" or whatever - plays out like a particularly aggressive game of Halo.
I think people watch that, and they assume that software development is just like video gaming, only more intense. So when they see computers playing games, they assume computers developing software is right around the corner.