Slashdot Mirror
The Extinction of the Programming Species
Max Goff writes "Given the recent chatter surrounding the extinction of the U.S. programmer, /. readers might also be interested in a series of articles I recently penned for java.net -- the Blacksmith and the Bookkeeper (part 1, part 2 and part 3) -- in which I posit that the postmodern programmer (the entire sub-species, not just those domiciled in the U.S.) shares much with the
blacksmith of old, and will become just as extinct in relatively short order. It is not due to work visas or outsourcing, but has much more to do with the evolution of work itself."
"It is not due to work visas or outsourcing, but has much more to do with the evolution of work itself."
When we have robotic programmers, then I'll buy your argument.
I will be graduating in december with a bachelor's of Computer Engineering. Just as all the other in my study program, we got work experience up'til now in programming, because that's where the job was. For 50 programmers there is about 1 engineering job offer. Now I have to find my first carreer-job.
So my work experience and part of my academic background was all for nothing this says? Great news! Now that I've studied for more than 4 years, I learn it is going to be useless.
I'm wondering how many other slashdotters feel like me at the moment. Extinction of the programmer species means for me that I lost a few years of my life and now I have to change my carreer. What about the other thousands like me?
"/. readers might also be interested in a series of articles I recently penned for java.net -- the Blacksmith and the Bookkeeper (part 1, part 2 and part 3)"
Why is blatent self-promotion reaching the frontpage of slashdot more and more regularly.
Writers! let your readers do your promotion for you, it just looks bad if you do it on your own
Error 407 - No creative sig found
A proof of the demise of the programmer the article points out:
The advent of the Codeless Development Environment (CDE)
I wonder if these "Codeless Development" environments are they themselves written in a codeless environment. If you have ever coded in a pure gui environments with boxes and connectors and such you will quickly learn the limitations.
HALF OF THE WORKING-AGE POPULATION IS NOT EMPLOYED FULL-TIME.
This is a good thing. Read it again: This is a good thing.
Why do they pay you to work? Because you wouldn't do it for free. What happens when people retire? They have enough assets so that they no longer have to work for a living, and so generally promptly quit.
Medieval serfs had 100%, full-time employment. Even better, they were employed 18 hours a day instead of a mere eight. Shame that modern businesses have slashed our workday in half! Shame that modern business have slashed the workforce in half!
Increased productivity so that not everyone need be engaged in a constant minute-to-minute struggle for existence every minute of every day is a benefit, not a drawback.
i started playing with computers in 1985, earning my living from them since '89, and since before that i hear about the dismissal of the programer... and it never happened.
i lost count of how many "friendly" languages were created that would allow a "normal" human being to code, and we still have programers doing the actual work or fixing the snafus of "normal people".
What ? Me, worry ?
I no longer care if I am ever again employeed in the IT industry. It was fun for a while, it provided a very nice income for a while also. The thing is, while I love the technical aspects of "making shite work", there is little reward in the career as a whole. You ( most of us ) fight daily battles just to make things work, and at the end of the day it is a thankless proposition.
Most of you have to know that your employers have utter disdain for you by now. If not, keep working and it will become evident one day. We are expected to accomplish miracles, we take the heat from both management and the userbase, work stupid hours, and most likely will die young doing it. For what? To make something work that never should have passed the first meeting of the minds. The trouble is, the minds in the meeting were not fit to determine if the solution was correct in the first place. You optimists can have one less resume' to compete against, I no longer want to work in IT. It is a thankless, never-ending struggle that solves nothing at the end of the day.
For those lucky enough to do interesting work or admin some sort of Unix environment, you made the right move somewhere. Most IT jobs suck, and offer little to no actual satisfaction.
I am off to embrace a new career, preferably one that offers the possibility of holding something of value in my hands at the end of the day.
The easy problems with general solutions have been solved. The hard problems will only be solved when someone wishes to gamble sufficient resources on them. (A programmer can gamble his spare time, anyone else must gamble money.)
This DOESN'T mean that programming will become an extinct job classification, but it sure means that the number of jobs will decline.
What's uncertain is the time frame. And nobody knows. I include the author (both me, and the guy who wrote the article).
Who hires people to write the kind of program that spreadsheets can handle? Nobody! (But just last year I automated an office procedure in MSExcel using scripting. Python wasn't portable enough in the desired environments. [I wasn't allowed to install a new language interpreter.])
But notice that there are two complemenatry trends in action:
1) Most of the things that used to be programmed have available general solutions
2) Most of the things that need doing are programmed interaction of higher level tools.
So long as this trend continues, there will be a declining, but continuing, need for programmers.
At some point, though, an AI will become general purpose enough to handle some reasonable subset of the tasks of a programmer. At this point, the job of the programmer will change drastically. At this point a programmer will become one who can describe a task sufficiently well that the atomaton can implement it. This already exists in specific problem domains. Screen painting programs like glade, e.g., but the transition point will occur when the automatic programmer becomes much more general.
We've probably got a decade. Possibly two. I'd be surprised if it takes longer than that.
I think we've pushed this "anyone can grow up to be president" thing too far.
Goff seems to believe that high-level programming tools and genetic programming will soon eliminate the need for programmers, but nothing I have seen suggests that such tools are anywhere near able to do this. Maybe someday, but not in the near future. What we've really seen is that the combination of more advanced tools and greatly increased computer power has enabled people with very limited skills to do things that would once have required a real programmer. The result is that lots of people can make web pages and create spreadsheets and so forth, but these are essentially all additions to the work that must still be done by real programmers. Real programmers are still needed both for the more difficult tasks and for even fairly simple ones that nobody has taken the trouble to create high-level tools for.
It seems to me that there is a parallel in medicine. With all the modern medicines, tests, and instruments (such as thermometers, blood pressure meters, glucose meters) available to the average person, the non-physician can successfully diagnose and treat many illnesses. This hasn't, however, eliminated the need for real experts to deal with the harder stuff.
but I do want to see the sources from which you got the statistics.
Bureau of Labor Statistics and the Department of Commerce.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
In the 80's when I was studying for my first degree in C.S. (yes, I'm an old fart), the fad of the time was formal methods. The basic idea is this: a problem is specified using a formal language, the specification is then translated into code automatically. This was supposed to herald the end of imperative programming languages and programmers. The major flaw was assuming anyone could put together a specification in the first place.
Hi. Guess what? I am a developer, and I prefer part-time and contract work with companies to fulltime. The benefits may be lacking, but the fact that I can make my own hours, work on other projects, study at my own pace, etc. more than makes up for the shortfall.
Do many C programmers understand the details of kernel scheduling? No, they don't need to.
No. But if you do you're more useful as an employee. You're also more versatile.
Say all you know how to code in C is say um, say, data loggers. Nothing else. Just simple logs to text files.
Now you're sitting next to someone who has dabbled in [and understands] data compression, compilers, networking, IPC, crypto, math, etc, etc, etc.
Well the guy next to you [provided they're clean cut] will be a hell of a lot more employable then you are.
Even if you both get the Axe the other guy can apply for a larger range of jobs then you can ever legitimately hope for.
It's not that being a "master of all trades" is desirable. just that you should be at least partially versed [e.g. did lab work in the subject].
Programmers working in higher level languages have a different knowledge set, not an inferior one. Like writing long-term maintainable code. Like writing non-brittle code which will be adaptable to business needs.
This is a logical fallacy. Higher level coding doesn't immediately imply long-term maintainability. I've seen many C++ projects that don't build well [say KDE 3.2.x on my Amd64 with gcc 3.4.2 in Gentoo...]. You can easily write well written, modular, highly portable and maintainable code in something as "low level" as C. You just have to design it carefully.
In fact one of my older projects was a crypto library in C that was used by hordes of companies of all shapes and sizes [and many different platforms]. Being in C wasn't a burden. In fact it helped people use it on the diverse platforms they used.
The point though is if you don't know how any of the code you wrote works then no language is going to help you make a competitive product.
For example, if you don't understand kernel scheduling how the heck are you going to write something that is complex enough to have multiple threads/processes?
If you don't understand how graphic primitives actually work how are you going to write GUIs for framebuffer platforms?
If you don't understand how networking works, etc...
Sure there are gui/network/etc libraries but they're not always accessible. A port of MesaGL wouldn't make sense for say a gameboy. Similarly glib may not be the best library for a PS2 game or linksys router [though it probably uses it... ok so lame point there...].
Point is, knowledge is power. Ignorance and arrogance is what drives companies into horrific conditions [such as layoffs and scandal].
Tom
Someday, I'll have a real sig.
There are already some industry specific programming systems - I say systems, because they are not really languages - that use flow charts and diagrams to generate instructions instead of pseudo-code or a high-level language like Visual Basic.
However, the parent does raise a valid point - many of my co-workers are good at putting widgets together and doing similar tasks, but don't really know what to do when they need to think in terms of embedded environments or program optimization.
That's one problem I see, not enough programmers today learning the fundamentals and just letting the libraries do all the hard lifting for them.
I have seen programmers obsessed with efficiency and speed waste time and money. I don't know if you are one, but we must look at things differently now. Face it, that stuff is only marginally important. Better spend time on your people skills instead. Note how most of us developers have dozens if not hundreds of techie books, but possibly ZERO books about people skills. We must change our thinking away from the idea of building a better mouse-trap toward selling mouse-traps. I know it is depressing, but it is the ugly reality. Writing better sorts from scratch or mastering closures is NOT going to save us from the big-picture: Brains Are Becoming A Cheap Commodity. Your suggesting is like telling a blacksmith in 1930 to simply learn more efficient blacksmithing techniques. You cannot stop a flood with a straw.
Table-ized A.I.
There's a better model than blacksmiths: musicians.
Before the advent of recorded music, if you wanted music, you paid musicians to come around and play it for you. It was expensive to keep them, they became status symbols, but they were commonplace in wealthy households and courts.
After recorded music came, the number of musicians required dropped off amazingly. Just tanked.
Programmers are increasingly headed in that direction because of automation: better and better libraries, software packages with increased configurability, better management of software projects. It's gradually getting easier to make a given problem go away with fewer and fewer programmers.
The countertendancy - as large problems become cheaper to solve, more people pay for them to be solved - is sustaining us for the moment, but there is no guarentee that those two forces will remain in step indefinitely.
But even in the age of fluidly configurable, massively integrated software packages (try: Apache 2, MySQL4 and WordPress - millions of lines of code with a nice user interface, and all it does is run your blog) there's still a need for the "rockstars" - the programmers who actually produce those systems.
Professional musicians these days have to fight to stay in the game, and they have to be really, really good at *something* even if it's just pouting on posters.
Programming is going the same way: it's no longer the easy option. If you're programming right now for a reason other than "I'm really good at this" or "I love this" and, preferably, both - get out of the game while you still have an income. You have less than ten years, possibly more like five.
Two more jobs, if you're lucky.
But for the rest of us? The people who can hack it under these conditions? I think it's going to be a return to the Golden Age of Hacking - the time when it was a game for the profoundly talented and educated - rather than these hordes of analgorithmic munchkins we've been competing with for years.
Rock star programmers, dude. Not garage mechanics, rock stars. You can see it already in the celebrity accorded to people like Linus, or EvHead. As software is increasingly "one hit, one kill" - packages which simply dominate an entire category - that kind of rapid rise and fall is going to be the norm, rather than the exception, in the publically popular software sphere.
That's the rock star niche.
And the rest of us will be like those touring rock bands you see all over America, or the players at your local symphony hall.
Hexayurt - open source refugee shelter,
I have seen programmers obsessed with efficiency and speed waste time and money.
I have seen programmers obsessed with pleasing management waste time and money. Let's face it, there are zillions of ways to waste time and money. Writing more efficient code is a lesser evil in my mind.
We must change our thinking away from the idea of building a better mouse-trap toward selling mouse-traps.
Outside of academia, this has always been the case. Look at the top people at most technology companies, you'll see that they're business people -- usually from a sales and/or marketing background -- and not techies. Or they might have been techies in some early life but over the years migrated into selling roles. I think, though, that few techies have the skills to make that kind of leap. So just telling people to brush up on people skills isn't going to cut it, either. If you firmly believe that good programming skills are innate (more art than science) then chances are that good selling skills are also innate.
I guess I have no answers about the bigger questions this raises. That's why we're debating it. I still think, though, that it's useful for programmers to understand how sorting works so that they can choose the correct algorithm for each situation. Really, you don't go to university to learn to be a programmer, you go to university to learn how to learn what you need when you need it. IMHO.
Ericto say bookeeping has advanced/evolved to accountant, CPA, auditor, banker, financial advisor, finance professor, .... while saying blacksmithing has dies is so totally incorrect and unfair.
We today have welders and all the related fields of metal working that back then did not exist.
Also the writer seems to have skipped over the 300 year lapse between the introduction of the hindu-arabic decimal system and its finally becomming mainstream over the roman numeral system. Hmmm, seems the elitest roman numeral accountants pursued the lies and arguements that it is silly to think that nothing "zero" can have value....
It should be noted that roman numeral mathmatics is so limited that we could have never developed computers with it.
I also noted in skimming over the article that the writer mentions the "software factory" in MS terms.... this two is with error for a number of reasons, the least of which is not the fact the the book being referenced uses "pattern" as a catch all phrase where as a matter of convience it is converted to various things thruout the book.
MS is a market company first and formost and a third party integrator second. MS's POV on software factories is with distortion of reality and biasing towards MS, rather then honesty about "putting things together" in a manner that automates alot more of what a programmer wouold otherwise do manually ---- but then isn't the act of programming the goal of creating automations of complexity, typically made up of simpler complexities, and done so in order to make the use and reuse of teh complexity easy for the users of the complexity.... hence a natural evolution of the field of programming....rather than an MS invention...
I'd imagine this is enough to bring doubt to the writers message, but I'm sure there is more in error..... though hey.... it sound sooooo good.....
Chances are if you're a blacksmith in this day and age, you're actually in pretty high demand. My father-in-law does it as a side "hobby". Sells some of his stuff a local craft shows, demonstrates at schools...he's really good, and people are willing to pay decently to get him to make them stuff.
There may come a time when we need fewer programmers, like blacksmiths. But those that are will be special "craftsman". We'll just have to change our style to fit with the times.
Adapt or die...the way of nature.
Sean D.
"Hmm. I am to metaphor cheese as metaphor cheese is to transitive verb crackers!"
Back to demand/supply of bandwidth. At the moment there is also another factor that prevents oligopoly in telecommunications: innovation. So happens that existing telecom companies are stretched almost to the limits of their productivity and can't really see any place for reasonable reaserch in the domain. So the progress is made mostly by outsiders. However, I think we might be reaching the point where any further easy progress by outsiders is impossible since it would require disproportionate investment without any guarantee of reasonable return on it. Telecom industry right now is in a quagmire. Quagmire of overcompetitive market (compared to required investments), quagmire caused by explosion of services delivered to people (just several years ago it was a phone service, only - and US regulations made it either local or long-distance, not both; now we've got phone, a long list of networking solutions, wireless, cable tv, and a host of other options more or less related to telephony), quagmire of massive layoffs just conducted by virtually every single company, and quagmire of bankrupcies. It will take time to sort all of that out, and in the meantime offshoring might be a good idea. But sooner or later, the market will stabilize again and then offshoring won't be such a wonderful idea anymore.
Now, to the machines writing code: one problem is interesting here. Say a machine "invents" an interesting piece of code. Who has the copyright on that? And if we assume the current patent situation, who should be eligible to be an author of that code?
One more thing: I've seen GA in work and one thing is certain, it'll never be nearly an efficient way to find solutions to known problems. It's basically pretty much a brute force programming - instead of a monkey hitting random keys from A-Z, imagine a keyboard with various pieces of code hooked to different keys - we might have even a million of those keys - and said monkey hitting the keys that produce that code. Is that any better than the former solution? Well, it will produce more reasonably looking code, of course. But whether that's going to be useful to solve anything important and outperform a person using decent tools, I doubt.
The big problem of programming is that it basically hasn't evolved since it was first invented. We got OO and aspects, and other sorts of things like that, but we are still stuck to writing for and while loops. All paradigms are basically reduced to different organization of the code (well, maybe with one little exception for patterns - which are probably one and the only serious addition to programming since the for loop). But we do not have tools that would eliminate the need for writing loops and conditions and such. Again one little exception are GUI and simple database applications, where for the former we've got some fabulous WYSIWYG tools (easy here to do, since we're talking about the visual aspect of an application), and the latter has some great generators backed by CASE tools. But the rest of the field has been pretty much stagnant since 1960s.
If the field is ever to evolve, we need to lift programming to another level of abstraction and create tools that will eliminate mundane typing of same code again and again. Does it mean we will be able to forget the loops and such? Maybe, maybe not. Depends how we solve the problem. The real solution should make it possible to actually forget about those.
GA used as such a tool might just do the trick, but trying to put too much on its shoulders will end with a big smoking stack of junk that nobody will want to touch for years in fear of getting burned.
iThink iHate iMod
If you apply genetic programming to software and hardware development then we may see the software and hardware breeder. This will be necessary due to genetic load ( you don't want to run microsoft runt office). Breeding or artificial selection is probably the most power full technology we know of and yet so simple. So I will have a software stud and you can purchase my germplasm to introduce to your stock of office productivity software that you are breeding. This will become necessary to cope with the "emergent properties" of the the complexity that we will have to face. In other words we don't know what will happen we we start yanking on those wires. So we will have to breed purely on the phenotype of the software who cares what language its written in
I have heard this argument or something like about once every 6 months for the last 15 years.
Basically the argument goes, "in the *future*, things will get more automated so there will be no need for programmers. Programmers are like [insert lousy analogy] and in future will become obsolete just like [insert lousy analogy]."
The whole point of programming is identifying that which can be automated and eliminating the need for mindless repetition. It's almost a tautology to say that the hardest thing of all to automate is the process of reducing what used to be considered a difficult labour/thought intensive process into a program. To do this requires a greater level of understanding than whatever job is being automated. We will write software to deliver packages, perform surgery, teach mathematics to children, etc etc, but until computers are smarter than humans we will never write software that figures out how to write software *for novel applications*. I think its nearer the truth to say that eventually everybody except programmers will become redundant.
This is good thing by the way, it only seems like a bad thing due to our economy which is designed for optimal distribution of scare resources. Until we rejig economics to deal with a post scarcity society, we are doomed to invent bullshit filltime work to make up for all the professions that are made redundant [but that's another story...]
http://rareformnewmedia.com/
This is a very narrow view on what is happening and will happen with a very large number of jobs in the Global Economic structure that has arrived since the 1990's. If you want, you can consider this whole process a Canary in a Coal Mine example of what is going to happen to most jobs in the US and all other first world nations.
There are still blacksmiths in the world today, but the economy supports a much lower density of blacksmiths today in the nation. The only way that the few blacksmiths today can manage to survive is if they are very good and have more of an artistic quality to their nature than a pure smithy skillset.
The only way any American developers will survive is if they have exceptional skills that makes tham capable of competing on a much more competative market or are able to find a density of developers low enough in the local area that they are able to do all the customization work necessary to support the local demand of the software industry.
But the days of every geek making 6 digits a year have long past. It's just as well if you ask me. Now the only people who will code are the people who do it because they love it, not because they can get paid for it. I've run into a lot of pretty useless individuals who have moved into software development because they took a 6 week course in MCSE or JAVA and got picked up by some contract house.
The people that will be left working on software development in countries like US, Canada, and most of the European nations that participate in the Global Economy will follow this pattern.