Comment by heddycrow
19 hours ago
That's a fair response. I think I was trying to make a point which may be a bit more subtle than my questions suggest when taken at face value.
I'll attempt to explain.
From reading the article, I presume that at some point, all the people who think of code as clay will migrate out of this profession and set up shop in some mall somewhere helping married people renew their ties by making code artifacts by hand. As the article suggests, code (for them) will go the way that clay has went.
Also per the article, AI will be making some other portion of the low-hanging fruit code which business people can't justify hiring humans for.
And then perhaps there will be me and other people like me getting paid to work on things which require an understanding that code is quite unlike any medium humanity has seen before.
For the later group, code is not for everyone, it's beyond what AI can produce by itself, it's not a fetish, it's not cool, it's not fun, and it's one of the only ways to do the things we can do with it.
I sometimes think I'm addressing that later group of people when I type into this box, but maybe that's a bit naive of me.
It could have been safer for me to state that I find it unwise to make these analogies without being careful about the dangers in doing so.
hey. if u haven't seen this book/author/ideas, check those:
The Laws of Software Process: A New Model for the Production and Management of Software, 2003, Phillip Armour
http://www.amazon.com/Laws-Software-Process-Production-Manag...
about Software as knowledge medium, and effects thereof
some excerpts:
... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity.
... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.
... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed.
"... for the most part, (software) engineers do not _know_ how to build the systems they are trying to build; it's their job to _find_ out how to do it." i.e. programmers must be able to learn (and teach) - should learn that and/or be taught to it. All else are tools supporting that activity.
here some part: https://cacm.acm.org/opinion/the-five-orders-of-ignorance/
Always happy to expand and refine my take; this looks like it's a good one to push to the stack. I'm diving in. Thanks for the suggestion!