I really don't see how any alternative alignment of the software development profession would benefit the updating of the stereotype in the views of non programmers.

The core problem with licensing developers is who would be responsible for creating the requirements? Software developers are rarely hired by other software developers, so they really have no say in it (and we software developers are reluctant to demand a say in it). Marketing hires developers at a much higher rate, but their dilemma of not ever knowing what they need means that they also can't write the requirements. Management controls the money, but we as software developers are not comfortable with them monopolizing the requirements, and management under no circumstances wants software developers to control their destiny. As much as I do not like the status quo, I don't have a solution that all of the players involved would agree is better.

At some point software load will level off and drop. We software developers cannot continue to believe that marketing will continue to throw money at us because of their blindness that the effort we charge for things like A-B testing or customer relationship software is actually returning a valid return on investment. If the consumer loses faith in the truth in online reviews, then that money will be turned off. If questionable data collection justified by improvements in AI turns sour due to some horrendous breach of private information, this could cripple a large portion of our industry. I could go further, but it would all devolve to the plots of the Dune prequels and the tenet "that no machine can be made in the image of a man." Needless to say, our industry is treading on very shaky ground.

The level of intelligence of software development hasn't changed, it has just shifted to different aspects. The tools we use help facilitate the transfer, but not the sum amount. It also helps to define the concepts of constructive and destructive laziness. I'll try to explain all this with this example:

If I were to compare my intelligence to the software developers who had to program using punch cards, I would consider myself really stupid. Those people had to keep so much stuff in their head. They had to code at a level of precision and discipline I will never achieve, because their time with a computer was fleeting, precious, and tedious. I rarely can write code that passes a compiler first pass, and if I do I am highly dubious that what I wrote truly works. One of their tools I had the privilege to witness was a mechanical card sorting machine that would organize a large stack of punch cards. If one were to drop their stack of punch cards, and they had the discipline to number them properly, the device would quickly organize the cards into the correct order. Now this tool's purpose was for pure laziness, but this laziness was constructive because it saved precious time.
Though these programmers had level of precision that I will never see in my lifetime, it came at a cost that their programs are very simplistic to the things that I can achieve, with my horrible typing skills and wealth of computer access.

A developer will continue to require a certain level of combined intelligence, but can shift the burden to our tools. The simpler the tool, the easier to maintain, and the easier those tools will transfer. If the tool becomes too specialized, its beauty and constructive laziness will befall the fate of the magical card sorting machine. Complicated tools provide the illusion of acceptable stupidity. If one doesn't know how to properly use a hammer, a nail gun just makes one's stupidly more prolific to see. Complicated tools require somebody smart enough to create the tool and the infinite time and patience to maintain it for lesser intelligent people to use improperly. Very few people have the desire to do this, even fewer for free. A really good example of a complicated tool that has gone overboard is Curl. So much effort has gone into the command line interface that the true gem, the curl library, becomes overshadowed. Too many people, through destructive laziness, attempt to do nontrivial tasks through the command line interface when it would be more sane to create a program that uses the library directly. Same could be said about using Perl for build processes, and ridiculous search strings for grep, but this tangent veers into holy territory that I have no vested interest (If you don't want to do as the Romans, than don't go to Rome).

The only way I know of to improve quality is to never stop learning. Unfortunately this solution does not lessen quantity. Quality and quantity are not related. These are things I do:

1. Sometimes I attempt to do things without a tool. I always find some insight and appreciation for the lack of the tool or define its level of constructive/destructive laziness. Do not allow yourself to be crippled by your tools. I am blessed with time and freedom to do this at work.
2. Always have a secret project that you believe may have some benefit to how you do things. I cannot stress the secrecy. This should be a project with no deadline. This should have no consequences other than downtime lost if you find out it does not pan out. I am blessed to being able to do this at work.
3. Find a software developer who you respect and take them out to lunch/dinner in return for them critiquing your code, and in turn be available to explain their code. The dinner is to balance out that you are inconveniencing them for your benefit. Do this even if your organization has useful code reviews.
4. Treat documentation with the same precision and zeal as coding. Understand and write developer, operator, and user level documentation. Documentation should always be in a system neutral document format first, and in system biased format (such as man pages) second.
5. When working on open source projects on your own time, don't get frustrated when they dismiss your submissions. If it works for you but not them, keep it for yourself and take your talents elsewhere. Never allow yourself to be abused for free.
6. Understand that quality requires discipline. Discipline is always detrimental to time.
7. Do not abuse your QA team by sending untested code. The sole purpose of QA is to prove the stereotype that developers are morons. Do not allow QA to accept your code without them testing. There is nothing more frustrating than losing a great QA analyst because they assumed that your code will always work.

My answer was more towards dismissing the argument of this article that the stereotype of the classic software developer was misapplied to today's developer because of how great all programmers are today. I also laid bare many prejudices that I have towards my community. Though I'll answer my biases on this aspect of my response.

A top notch programmer should not be wasting time writing A-B tests. In fact, this would be a QA task, or a marketing research request. A programmer would at a minimum write the variant codes, submit both of them to QA. and when requested merge the desired result (if any) to the mainline source. Of course, many programmers don't have access to a competent or existent QA. I have never seen a competent or non-existent marketing department.

Most software development is not glamorous, it is tedious. I would say that the stuff that top-notch programmers do is even less glamorous, but with the benefit of less tedium. Tedium is writing a complete software interface over a period of three weeks for a 300 lb. cash dispenser using Korean specs translated into 2nd grade level English, with diagrams that use happy face/unhappy faces. I wouldn't want to force anyone to watch a movie about that, nor do I hope to ever mention it ever again outside of a job interview.

The stereotype that we software developers willingly focus on menial and tedious tasks that non-programmers will not appreciate will always stand. It wasn't my intent to state that menial tasks or A-B testing needs to go away, nor fracture the programmer community into top and bottom notches.

I guess me writing menacingly on my basement man cave computer isn't helping the cause. But that's life.

Let's not try and elevate our profession with vapid and sanctimonious poop. Programming as a profession may be expanding, but it's level of quality and prestige is rapidly declining. For every developer whose job it is to maintain the security of people's personal data, there are twenty developers whose sole purpose is to make sure a fake watermelon hat sits perfectly on a throwaway vacation picture. For every developer who is responsible for making sure a chemical mixture is within safe levels, there are twenty developers who are using A-B testing to figure out if a blue background is better than a teal background for selling toenail clippers online. At what point did it become acceptable that a 12 year old taking a vaguely worded three week programming course could be considered industry ready let alone hirable? Sure, there are some developers out there that are maintaining critical parts of our infrastructure, but that is being dwarfed by the levels of work used to maintain poorly our social networks, entertainment, and other novelty parts of society.

Developer tools seem to propagate at a higher, devolving clip. The tool builders primary focus seemingly is to prey on the laziness and sometimes ineptness of developers in exchange for ever increasing licensing fees. Software development paradigms seem to be devolving to a development cycle that optimizes to the timeframe of a single line of cocaine.

I've seen enough CuRL, OpenSSL, libSSH2, and ZLIB code to know that showing more code is not going to help our cause to non-developers. To be blunt, these code and build paradigms don't even help developers.

No entity has the ability to decry their stereotype null and void. Collectively we have to fight to be better than the stereotype. If you can't prove you can handle the whiskey, then you're better off with the Kool-Aid (you'll live longer). From an industry standpoint, we are on a precipice that leads mostly to failure. If you are working on automated cars, then you better not kill anyone. If you are working on financial systems, then you better not lose our grandparents' retirement accounts. If you are working in robotics, then you better not kill anyone you weren't authorized to kill. If you are selling toenail clippers online, use the blue background. If you manipulate non-critical images, then you should reassess your role in life and/or wear a hoodie.

The only thing we have in common with engineers is the following:
If we do one thing wrong, people die. If we do everything right then we get a certificate of appreciation.

I just have an HP AlphaServer ES47.

News Alert. Authorities in California are raiding Justin Bieber's home looking for evidence through his security videos of him throwing rocks at the Mars Rover Opportunity.

Technically, The algorithm is still N log(N) + whatever extra you need to do to coordinate between the processes. Many digital hands make light work, but the amount of work is still the same (plus extra time for some of them to surf the internet). The big question that needs to be asked is how do you take a programming paradigm that is object centric and make it care about the process centric or (gasp) architecture centric? Let alone make programmers (double gasp) that went to that paradigm under the promise that they didn't have to learn this icky stuff actually learn the icky stuff. Laws of thermodynamics still apply: 1. You can't win. 2. You can't break even. 3. You can't leave the game.