As someone that has had several times now to "productionize" or "modernize" an Excel spreadsheet or Access database many times, this is one of those prognostications this is one of those things people think from time to time and thus far in my experience tend to be incorrect about.
The issue with "computational thinking" in so far as how this article seems to want to teach it and how most schools often do teach it already in the real world is the tendency to stop at the basics and Office applications and just enough VBA/macros to give people a feeling of competency without giving them a glimpse into the real depths of programming and what software developers really do.
I keep wanting to make a XKCD-style sketch graph of the idea. But there's a lot of Dunning-Kruger over-competent business people that thinks all the software they need to run their business is spreadsheets and spreadsheets pretending to be databases like Access. To them real software developers seem over-paid based on their experience of Lovecraftian "systems" they can hack together given what they think they know.
That's a very real and dangerous place for business people to be, but it is unsurprisingly common. Those people don't respect programming as a discipline and a craft, and sometimes those are the people out in the corporate world controlling software developer salaries or morale...
It's also the same lack of knowledge about software as a craft (as engineering, in a very classical sense) that leads people time and time again to the well of "well in the future people won't be coding because [ Excel will do it all | There will be a visual tool everyone will easily understand | AI will do all the programming based on natural language queries | Insert some other magic idea here ]".
There's as much art to software development as there is science, and forgetting that art will still need artists and will not make itself is a strange thing that is surprising common.
To be fair, there are a lot of software developers themselves that have played into this delusion, and it's something of a trap that a software developer can easily fall into. We're trained to break down systems and try to automate them to their fullest potential and it's hard sometimes to avoid that meta-leap to wanting to do it to our own systems. We fall into building "Business Rules Engines" that we think some business users might be able to understand and comprehend and might obfuscate away the need for programming. We experiment with boondoggles like visual programming languages and "auto-coding" experiences. We get grandiose visions of the machine or software product or great AI that will make it all more accessible...
The future will probably look like the present in that regard. We'll still have the Dunning-Kruger folks building mission critical applications out of complex webs of Excel and Access and other past and future productivity tools we build in the goal of making programming more accessible. We'll still have software developers eventually hired to clean up the messes and craft versions that can sustainably last or reliably operate outside the hacked together environment from which they were originally built. There will continue to be software developers continuing to think they can build the environment that will done rule them all and save everyone time (and meanwhile eat up so much of software development budgets and time to built it)... And all of these groups will still have a hard time communicating between each other the real risks and efforts involved in any of it.
The issue with "computational thinking" in so far as how this article seems to want to teach it and how most schools often do teach it already in the real world is the tendency to stop at the basics and Office applications and just enough VBA/macros to give people a feeling of competency without giving them a glimpse into the real depths of programming and what software developers really do.
I keep wanting to make a XKCD-style sketch graph of the idea. But there's a lot of Dunning-Kruger over-competent business people that thinks all the software they need to run their business is spreadsheets and spreadsheets pretending to be databases like Access. To them real software developers seem over-paid based on their experience of Lovecraftian "systems" they can hack together given what they think they know.
That's a very real and dangerous place for business people to be, but it is unsurprisingly common. Those people don't respect programming as a discipline and a craft, and sometimes those are the people out in the corporate world controlling software developer salaries or morale...
It's also the same lack of knowledge about software as a craft (as engineering, in a very classical sense) that leads people time and time again to the well of "well in the future people won't be coding because [ Excel will do it all | There will be a visual tool everyone will easily understand | AI will do all the programming based on natural language queries | Insert some other magic idea here ]".
There's as much art to software development as there is science, and forgetting that art will still need artists and will not make itself is a strange thing that is surprising common.
To be fair, there are a lot of software developers themselves that have played into this delusion, and it's something of a trap that a software developer can easily fall into. We're trained to break down systems and try to automate them to their fullest potential and it's hard sometimes to avoid that meta-leap to wanting to do it to our own systems. We fall into building "Business Rules Engines" that we think some business users might be able to understand and comprehend and might obfuscate away the need for programming. We experiment with boondoggles like visual programming languages and "auto-coding" experiences. We get grandiose visions of the machine or software product or great AI that will make it all more accessible...
The future will probably look like the present in that regard. We'll still have the Dunning-Kruger folks building mission critical applications out of complex webs of Excel and Access and other past and future productivity tools we build in the goal of making programming more accessible. We'll still have software developers eventually hired to clean up the messes and craft versions that can sustainably last or reliably operate outside the hacked together environment from which they were originally built. There will continue to be software developers continuing to think they can build the environment that will done rule them all and save everyone time (and meanwhile eat up so much of software development budgets and time to built it)... And all of these groups will still have a hard time communicating between each other the real risks and efforts involved in any of it.