[umussetu]

although there is a lot of truth in your analysis I think developers don't just output code but "think"/solve problems. And problem solving is not a common skills , it's interesting to see what non-technical people VS developers prompt on marblism. Like you would be surprised how many people struggle with the concept of an if condition.

So developers are definitely not dead but will be empowered by the new tools and maybe their work will shift from solving problems+writing code to only solving problems.

[austin-cheney]

Perhaps, but this isn't about non-developers or developers in general. This is targeting "full stack" developers, the overwhelming majority of which cannot write original software. If a tool provides a business the ability to replace a developer that cannot solve problems on their own, without some tech stack and colossal framework, it pays for itself immediately. That's why it is inevitable.

[awesomeMilou]

> the overwhelming majority of which cannot write original software

Usually a client or employer does not want write original software. I can code in C++/Rust/$LANGUAGE and am able to write you a high performance backend for some very specific, custom use case, but in 99% of the cases that isn't necessary because the underlying business is either 1) too generic or small to need something like this or 2) doesn't want the hassle of having to maintain something in-house.

Most companies that hire typical web/full stack devs value speed over anything else for the nth crud app they churn out. But I also don't see the value in these companies either.

[austin-cheney]

In my 15 years of doing that work most of the time employers couldn't tell if a solution were original or not unless it was something they specifically requested. Even then most of the original work was in context of original content messaging, user interaction, and the measurements there of.

Where employers in the past really cared is in the speed of delivery. Typically speed of delivery was faster using a framework solution only if the exact solution were already written and available as an extension. In absolutely every other case software originally written in house was always faster to deliver back to the business. This is because with original software the developers are not limited by prior existing conventions. It always comes down to the prior experience and confidence of a given set of developers.

The business knows this before assigning the tasks to the development team, and that awareness (more than anything else) determines the opportunities for developers to identify their own speed of delivery. Most development teams are entirely unaware of just how thoroughly their performance is measured from a business perspective. That should be painfully obvious, because developers only cost money, and those costs go straight to the bottom line.

[shaiansvdid]

> This is targeting "full stack" developers, the overwhelming majority of which cannot write original software

Does this mean they just copy paste solutions? Otherwise I’m not sure how they’re writing anything but (albeit it might be very similar to code written at some other point in time, but do that often enough and you turn into an AWS service).

[austin-cheney]

Have you even written an original essay, article, or research thesis? Those thoughts are entirely of your creation or finding from evidence as well as the organization thereof. Original software is no different in that you are writing both the solutions and the architecture.

It sounds like this originality should be slow and of great challenge. It isn’t. With practice the words just appear in the correct order as fast as they are typed.

In the overwhelming majority of full stack jobs that level of originality does not exist. Most of these jobs, and the developers filling them, are utterly reliant upon large tool sets of prior formulated architectures. These large frameworks rob the developers of the practice necessary to become faster in their solution delivery and cripple their ability to consider answers of their own design.

As an example consider state management. That is an astonishingly simple problem to solve, essentially saving a result of modification for later artifact generation. With these large frameworks, however, the solution becomes a complex science to compensate for modularity considerations introduced by the frameworks that do not otherwise exist. For developers that have never written an original application without one of these large frameworks the simplicity of the solution is almost impossible to fathom, thus resulting in solutions of complexity outside their control and no ability for consideration of alternatives.