A. No. Good developers can run up the abstraction chain to keep providing value at a higher level. Most good devs fundamental value prop isn’t “I can make something in HTML”.
If anything, this will mean that more people can do the redundant stuff faster.
As a frontend guy, I can’t wait for the day that a tool can generate presentational stuff.
I'd argue in part you're both right about A. Good devs (those can keep running up the abstraction chain) will always be useful. But the bar for what a "good dev" is keeps getting higher as we introduce more and more abstraction. The sheer amount of knowledge and understanding that the average dev needs in order to be productive AND understand what's going on enough under the hood (to the point where they're not doing stupid things constantly) keeps getting larger.
Think back to CS in the 70s - AFAIK, the majority of the field that was understood is now covered before an undergraduate gets to their upper division classes. We're now expected to understand things at a much higher level of abstraction, but we ALSO need to know how logic gates and machine code works in order to fully understand what we're doing.
The 'incubation period' to produce a good dev is going to keep growing. The ones that make it to full dev maturity are going to be more productive than ever before, but fewer people will make it there.
Sure, there is a divergence of skill sets...We're going to have "doctor" developers – people who carry an incredible breadth of knowledge and are paid accordingly.
Beside them will be "nurse" developers – people who are just as professional, but less learned in the full range of computer science ideas.
Though the abstract nature of the field often benefits from analogical representations, I think this one detracts. I don't see how our current hodgepodge list of role titles we've already borrowed from other fields (architect, developer, designer, scientist, ops, product manager, evangelist(?!), quality assurance, security specialist, chief information officer (not to mention wizards, code monkeys, Java baristas (aka the bespeckled missionaries (they don't C# for whatever reason) who walk through your neighborhood every once in a while to knock on doors with warm smiles hoping to share their beliefs on the one true Oracle and some bizarre philosophy of enterprise scale spiritual development involving complex and brittle structures and subservience to feudal and [frankly] regressive class structures that most favor a nepotistic inheritance procedure designed to chiefly empower their children and a small circle of similarly interested functionaries that seem hellbent on oppressing the rest of the system), unicorn jockeys, tech debt lawyers, and whatever you call that long-gone contractor who years ago thrust a bizarre moonscript backend into the core of your team's architecture like Excalibur waiting for an Arthur everyone hopes won't happen along because rock that asshole stuck the sword in happened to be the kingdom's cornerstone and even the slightest nudge will cause the whole system to precariously sway ...)) can be summarized with a doctor / nurse dichotomy.
Even if writing, practicing and administering software legally required a degree and license, I think this still detracts. Maybe useful once software powers organic, higher-order life forms, at which point I imagine our doctors and nurses will be entirely software driven anyway[0].
Whatever the "doctor" developers write to abstract away the nurses, it's still not going to be able to communicate with nontechnical managers. Or at least, once it can do that, the "doctor" developers will be obsolete soon anyway.
> As a frontend guy, I can’t wait for the day that a tool can generate presentational stuff.
Qualified agreement from this sometimes front-end guy, but that's assuming the generated presentational stuff is of equal or higher quality as that of the other front-end devs.
Being the front-end guy who has to debug the auto-generated code that doesn't quite work in a corner case or two sounds potentially worse than the status quo.
I agree with your response to A in the short term. In the long term, however, much like a mountain in a flood people can only scramble so high before they run out of oxygen, or run out of room.
To take your metaphor a bit too far, it’s fortunate that we have more than one mountain. ;)
Sure, the days in which the web guy was viewed as a special guru won’t last forever. But even with auto-generated mockups, we’re still a long way from computers taking over everything.
As the baseline of tooling gets raised, the baseline of expectation gets raised.
Programmers will use these tools the way we always have: To automate the simple work on the way to building a finished product that's more complex, and done more quickly, than would have been possible previously.
Some markets die, yes. It's no longer possible to make a business out of selling Unix clones for commodity hardware, like you still could in the 1980s. It's no longer possible to make a living just making static HTML websites, like you could in the 1990s.
Ultimately, what programmers trade in is a specific kind of problem-solving design sense. Not just solving this single problem as fast as we can, but creating a more general solution, which composes well and can be understood and changed later on. Once programs can do that... well, we'd better be willing to offer them citizenship and recognize their civil rights as thinking beings.
The top of this metaphorical mountain involves learning new APIs, frameworks, languages and programming paradigms. An AI that can do that will be a threat to everyone.
A. No. Good developers can run up the abstraction chain to keep providing value at a higher level. Most good devs fundamental value prop isn’t “I can make something in HTML”.
If anything, this will mean that more people can do the redundant stuff faster.
As a frontend guy, I can’t wait for the day that a tool can generate presentational stuff.