Live data from Hacker News

The recurring dream of replacing developers

caimito.net

191–200 of 535 posts

Re: The recurring dream of replacing developers

#191

[flagged]

Right! Sysadmins got displaced, but many became developers.

this works for small increments in skill or small shifts in adjacent skills.

imagine being an engineer educated in multiple instruction sets: when compilers arrive on the scene it sure makes their job easier, but that does not retroactively change their education to suddenly have all the requisite mathematics and domain knowledge of say algorithms and data structures.

what is euphemistically described as a "remaining need for people to design, debug and resolve unexpected behaviors" is basically a lie by omission: the advent of AI does not automatically mean previously representative human workers suddenly will know higher level knowledge in order to do that. it takes education to achieve that, no trivial amount of chatbotting will enable displaced human workers to attain that higher level of consciousness. perhaps it can be attained by designing software that uploads AI skills to humans...

Re: The recurring dream of replacing developers

#192
post #161

[flagged]

> The pattern that gets missed in these discussions: every "no-code will replace developers" wave actually creates more developer jobs, not fewer. Doesn't mean it will happen this time (i.e. if AI truly becomes what was promised) and actually it's not likely it will!

> if AI truly becomes what was promised

I mean they are promising AGI.

Of course in that case it will not happen this time. However, in that case software dev getting automated would concern me less than the risk of getting turned into some manner of office supply.

Imo as long as we do NOT have AGI, software-focused professional will stay a viable career path. Someone will have to design software systems on some level of abstraction.

Re: The recurring dream of replacing developers

#193
post #81

[flagged]

Machinery made farmers more efficient and now there are more farmers than ever.

If AI tools make expert developers a lot more productive on large software projects, while empowering non-developers to create their own little programs and automations, I am not sure how that would increase the number of people with “software developer” as their full-time job.

Re: The recurring dream of replacing developers

#195
post #20

Don't take it personal. All business want to reduce costs. As long as people cost money, they'll want to reduce people.

Which is why quiet quitting is the logical thing. Managers and business owners shouldn't take it personally that I do as little as possible and minimize the amount of labor I provide for the money I receive. Hey, it's just business.

Which is why I fire the quiet quitters on the spot

Re: The recurring dream of replacing developers

#196
We could have replaced tons of developers if only employers were selective in their hiring and invested in training. Instead there are a ton of hardly marginal developers in employment.

Case in point: web frameworks as mentioned in the article. These frameworks do not exist to increase productivity for either the developer or the employer. They exist to mitigate training and lower the bar so the employer has a wider pool of candidates to select from.

Re: The recurring dream of replacing developers

#197
post #68

[flagged]

Classic Jevons Paradox - when something gets cheaper the market for it grows. The unit cost shrinks but the number of units bought grows more than this shrinkage.

Does that automatically translate into more openings for the people whose full time job is providing that thing? I’m not sure that it does.

Historically, it would seem that often lowering the amount of people needed to produce a good is precisely what makes it cheaper.

So it’s not hard to imagine a world where AI tools make expert software developers significantly more productive while enabling other workers to use their own little programs and automations on their own jobs.

In such a world, the number of “lines of code” being used would be much greater that today.

But it is not clear to me that the amount of people working full time as “software developers“ would be larger as well.

Re: The recurring dream of replacing developers

#198

We could have replaced tons of developers if only employers were selective in their hiring and invested in training. Instead there are a ton of hardly marginal developers in employment. Case in point: web frameworks as mentioned in the article. These frameworks do not exist to increase productivity for either the developer or the employer. They exist to mitigate training and lower the bar so the employer has a wider…

I disagree. A good framework makes code more maintainable, and makes it so you can focus on what’s important or unique to your product. It certainly makes you faster.

Re: The recurring dream of replacing developers

#200
Who remembers Model-Driven Architecture and code generation from UML?

Nothing can replace code, because code is design[1]. Low-code came about as a solution to the insane clickfest of no-code. And what is low-code? It’s code over a boilerplate-free appropriately-high level of abstraction.

This reminds me of the 1st chapter of the Clean Architecture book[2], pages 5 and 6, which shows a chart of engineering staff growing from tens to 1200 and yet the product line count (as a simple estimate of features) asymptotically stops growing, barely growing in lines of code from 300 staff to 1200 staff.

As companies grow and throw more staff at the problem, software architecture is often neglected, dramatically slowing development (due to massive overhead required to implement features).

Some companies decided that the answer is to optimize for hiring lots of junior engineers to write dumbed down code full of boilerplate (e.g. Go).

The hard part is staying on top of the technical (architectural and design) debt to make sure that feature development is efficient. That is the hard job and the true value of a software architect, not writing design documents.

[1] https://www.developerdotstar.com/mag/articles/reeves_origina... A timeless article from 1992, pre-UML, but references precursors like Booch and object diagrams, as well as CASE tools [2] You can read it here in Amazon sample chapter: https://read.amazon.com/sample/0134494164?clientId=share

Post reply on HN