Personally I have no horse in the coding-skills race; I really enjoy problem solving and architecting systems more than writing the code itself. If there were lots of commodity coders, I could direct and manage them and enjoy myself plenty ;)
From the 'software is eating the world' perspective, I see increased use of software, but not increased production in unconventional areas. If you look at the progression of home computers, we've gone from booting directly into BASIC, to an iPad, where you really can't do any development. The slow march to 'appification', and the trend of taking away customization and development tools from consumer-grade products makes me think that while software is becoming more important, average people need (and want) to code less and less.
It's definitely a programmer's perspective to say that any knowledge industry (like finance) is just software + domain knowledge. Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world. This is where I think the industry is going: not universal programming literacy, but a more stratified culture where 'commodity' development is it's own discipline.
Consider the ease with which any consultant can knock together a CRUD Rails app with some business logic the client specifies. We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously. As time goes on, and development technology advances, I see software development/engineering and computer science diverging more and more. At some point, development might be an apprenticeship or more 'hands-on' education, to learn the existing patterns and practices.
In short, development will become a commodity, but via an emerging class of commodity developers who can handle 95% of client requests. There will still be people who do hard things, and hack in their spare time, and they'll make things better for everyone. But they'll stay in the minority, and development will stay out of reach for people who aren't explicitly 'developers'.
Well here is someone "in the industry", who completely agrees with the need for coding literacy. I can program, but I'm not a "programmer" by any means, and it's clear to see in whatever client I work with (I'm a Big 4 Management Consultant, sorry), coding skills are becoming increasingly relevant. Macro skills are the tip of the iceberg, some industries such as investment banking and engineering practically require programming skills to find a job, as the previous poster stated. Sure they can write the requirements for an application, but mostly these are not applications, these are ad-hoc, on the fly, limited use models that need to be made and altered in time with market fluctuations or environmental conditions - far quicker than monolithic IT departments can respond (even with agile work teams).
I don't really care which way you phrase it, whether you see the programming as incidental or the job function as incidental is just a matter of perspective. The fact is, programming (or at least "soft" programming skills such as VB and SQL) are becoming increasingly essential for many of the top tier jobs in today's economy. Don't want to learn programming? No problem - I'll find a few million Indians who do.
>>. average people need (and want) to code less and less.
But this is exactly my point. I am sure I can pull Hansard from 1870 and find exactly the same words used to justify why we should not waste money teaching all those poor people to read and write.
>> ersonally I have no horse in the coding-skills race; I really enjoy problem solving and architecting systems more than writing the code itself. If there were lots of commodity coders, I could direct and manage them and enjoy myself plenty ;)
This idea totally failed at Microsoft in the eighties, why would it work any better now? I prefer thinking up ideas for articles than actually writing them - I can even go to textbroker and get some commodity writer to actually do the words - and guess what - it's rubbish.
Code is the design - if you are not writing the code you are not designing the systems. You might be doing nice artists impressions but its not design.
> Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world.
I agree that's how they'd like it to work. But in reality, their in-house teams have become more and more technology-oriented, and programming literacy has become a higher priority in hiring. An "analyst" used to be a clever kid with a finance degree; now they have a finance degree and are comfortable in VBA, SQL, and an analytics package. Badass programmer? No. Software literate? Yes.
> We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously.
Agreed (I'd caveat that by noting that we've also hugely increased our expectations for software functionality, but the point still stands). But note that all of these consultants who can knock out a CRUD Rails app still have to read and write code. What the lower barrier to entry means is that a bunch of people who previously couldn't do it now can, including potentially the business analyst who defined the requirements, assuming they have some basic software literacy.
That's going to quickly translate--is already translating--into the expectation that the analyst can actually write the code. Being able to actually code your solution to a problem makes you more productive, because your employer doesn't have to pay a consultant to accomplish that work, and because there isn't an extra layer of communication overhead. So businesses will begin demanding software literacy as they become more reliant on basic software development (or, depending on prevailing labor conditions, simply paying more for it), because it makes them more efficient. This is similar to how productivity technology (voicemail, email, software calendars) hasn't made secretaries' jobs easier, or turned them into a turnkey commodity; it has largely eliminated secretaries and replaced them with the expectation that you do that work yourself. Same with travel agents. Same with tax accountants. As the tools allow for more productivity, people are forced up the productivity ladder. Progress.
Being literate in software is different than being an expert software engineer, and fortunately for expert engineers, we can simply solve higher-level, or at least harder, problems, so this development is actually good for us. My view is consistent with your idea that there will be a bifurcation between hardcore developers building frameworks and a bunch people who know the basics and can use the tools. The only difference in our views, as far as I can tell, is that in mine, this army of "commodity" programmers fielding client requests will be the clients themselves, and not an outsourced stable of kinda-engineers. Those kinda-engineers will be employed at firms as business analysts, product managers, etc, because their computer literacy will be really valuable there.
From the 'software is eating the world' perspective, I see increased use of software, but not increased production in unconventional areas. If you look at the progression of home computers, we've gone from booting directly into BASIC, to an iPad, where you really can't do any development. The slow march to 'appification', and the trend of taking away customization and development tools from consumer-grade products makes me think that while software is becoming more important, average people need (and want) to code less and less.
It's definitely a programmer's perspective to say that any knowledge industry (like finance) is just software + domain knowledge. Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world. This is where I think the industry is going: not universal programming literacy, but a more stratified culture where 'commodity' development is it's own discipline.
Consider the ease with which any consultant can knock together a CRUD Rails app with some business logic the client specifies. We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously. As time goes on, and development technology advances, I see software development/engineering and computer science diverging more and more. At some point, development might be an apprenticeship or more 'hands-on' education, to learn the existing patterns and practices.
In short, development will become a commodity, but via an emerging class of commodity developers who can handle 95% of client requests. There will still be people who do hard things, and hack in their spare time, and they'll make things better for everyone. But they'll stay in the minority, and development will stay out of reach for people who aren't explicitly 'developers'.