Live data from Hacker News

The recurring dream of replacing developers

caimito.net

271–280 of 535 posts

Re: The recurring dream of replacing developers

#271

In the end, I think the dream underneath this dream is about being able to manifest things into reality without having to get into the details. The details are what stops it from working in every form it's been tried. You cannot escape the details. You must engage with them and solve them directly, meticulously. It's messy, it's extremely complicated and it's just plain hard. There is no level of abstraction that sav…

“Writing is nature's way of letting you know how sloppy your thinking is.”

— Richard Guindon

This is certainly true of writing software.

That said, I am assuredly enjoying trying out artificial writing and research assistants.

Re: The recurring dream of replacing developers

#272
post #118
post #81

Earlier quoted context omitted.

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

Pre industrial revolution something like 80+ percent of the population was involved in agriculture. I question the assertion of more farmers now especially since an ever growing percentage of farms are not even owned by corporeal entities never mind actual farmers. ooohhh I think I missed the intent of the statement... well done!

I am not sure if this is sarcasm or a commentary on the explosion of the number of humans out there.

Re: The recurring dream of replacing developers

#273
This is looking at the wrong end of the telescope. The arc has been to move computing closer to more and more end users. In the 1960's, FORTRAN enabled scientists and engineers to implement solutions without knowing much about the underlying computer. Thompson and Ritchie got a PDP11 by promising to make a text processing system for patent applications. Many years later desktop PC's and programs like VisiCalc and PageMaker opened up computing to many more users. The list goes on and on. With this movement, developer jobs disappeared or changed.

Re: The recurring dream of replacing developers

#274

In the end, I think the dream underneath this dream is about being able to manifest things into reality without having to get into the details. The details are what stops it from working in every form it's been tried. You cannot escape the details. You must engage with them and solve them directly, meticulously. It's messy, it's extremely complicated and it's just plain hard. There is no level of abstraction that sav…

Counterpoint: perhaps it's not about escaping all the details, just the irrelevant ones, and the need to have them figured out up front. Making the process more iterative, an exploration of medium under supervision or assistance of domain expert, turns it more into a journey of creation and discovery, in which you learn what you need (and learn what you need to learn) just-in-time.

I see no reason why this wouldn't be achievable. Having lived most of my life in the land of details, country of software development, I'm acutely aware 90% of effort goes into giving precise answers to irrelevant questions. In almost all problems I've worked on, whether at tactical or strategic scale, there's either a single family of answers, or a broad class of different ones. However, no programming language supports the notion of "just do the usual" or "I don't care, pick whatever, we can revisit the topic once the choice matters". Either way, I'm forced to pick and spell out a concrete answer myself, by hand. Fortunately, LLMs are slowly starting to help with that.

Re: The recurring dream of replacing developers

#275

In the end, I think the dream underneath this dream is about being able to manifest things into reality without having to get into the details. The details are what stops it from working in every form it's been tried. You cannot escape the details. You must engage with them and solve them directly, meticulously. It's messy, it's extremely complicated and it's just plain hard. There is no level of abstraction that sav…

Yes! I love this framing and it’s spot on. The successful projects that I’ve been involved in someone either cares deeply and resolves the details in real time or we figured out the details before we started. I’ve seen it outside software as well, someone says “I want a new kitchen” but unless you know exactly where you want your outlets, counter depths, size of fridge, type of cabinets, location of lighting, etc. ad…

Is your kitchen contractor an unthinking robot with no opinions or thoughts of their own that has never used a kitchen? Obviously if you want a specific cabinet to go in a specific place in the room, you're going to have to give the kitchen contractor specifics. But assuming your kitchen contractor isn't an utter moron, they can come up with something reasonable if they know it's supposed to be the kitchen. A sink, a stove, dishwasher, refrigerator. Plumbing and power for the above. Countertops, drawers, cabinets. If you're a control freak (which is your perogative, it's your kitchen after all), that's not going to work for you. Same too for generated code. If you absolutely must touch every line of code, code generation isn't going to suit you. If you just want a login screen with parameters you define, there are so many login pages the AI can crib from that nondeterminism isn't even a problem.

Re: The recurring dream of replacing developers

#276

In the end, I think the dream underneath this dream is about being able to manifest things into reality without having to get into the details. The details are what stops it from working in every form it's been tried. You cannot escape the details. You must engage with them and solve them directly, meticulously. It's messy, it's extremely complicated and it's just plain hard. There is no level of abstraction that sav…

This rings true and reminds me of the classic blog post “Reality Has A Surprising Amount Of Detail”[0] that occasionally gets reposted here. Going back and forth on the detail in requirements and mapping it to the details of technical implementation (and then dealing with the endless emergent details of actually running the thing in production on real hardware on the real internet with real messy users actually using…

Can you give an example of an "other stuff"?

Re: The recurring dream of replacing developers

#277
post #53

I've watched this pattern play out in systems administration over two decades. The pitch is always the same: higher abstractions will democratise specialist work. SREs are "fundamentally different" from sysadmins, Kubernetes "abstracts away complexity." In practice, I see expensive reinvention. Developers debug database corruption after pod restarts without understanding filesystem semantics. They recreate monitoring…

> Excel proves the rule.

I think you’re just seeing popularity.

The extreme popular and scale of these solutions means more opportunity for problems.

It’s easy to say X is terrible or Y is terrible but the real question is always: compared to what?

If you’re comparing to some hypothetical perfect system that only exists in theory, that’s not useful.

Re: The recurring dream of replacing developers

#278

This is looking at the wrong end of the telescope. The arc has been to move computing closer to more and more end users. In the 1960's, FORTRAN enabled scientists and engineers to implement solutions without knowing much about the underlying computer. Thompson and Ritchie got a PDP11 by promising to make a text processing system for patent applications. Many years later desktop PC's and programs like VisiCalc and Pag…

I keep saying the real advancement by LLMs isn't for professional programmers, but for every job that is programming adjacent. Every biologist writing code to do analysis. Every test engineer interfacing with test results and graphing results. (eg all the instruments from cold weather testing) Anyone that's figured out you can glue Jira to a local LLM and then have voice command Jira. Etc.

Re: The recurring dream of replacing developers

#279

Earlier quoted context omitted.

This rings true and reminds me of the classic blog post “Reality Has A Surprising Amount Of Detail”[0] that occasionally gets reposted here. Going back and forth on the detail in requirements and mapping it to the details of technical implementation (and then dealing with the endless emergent details of actually running the thing in production on real hardware on the real internet with real messy users actually using…

Can you give an example of an "other stuff"?

I once wrote software that had to manage the traffic coming into a major shipping terminal- OCR, gate arms, signage, cameras for inspecting chassis and containers, SIP audio comms, RFID readers, all of which needed to be reasoned about in a state machine, none of which were reliable. It required a lot of on the ground testing and observation and tweaking along with human interventions when things went wrong. I’d guess LLMs would have been good at subsets of that project, but the entire thing would still require a team of humans to build again today.

Re: The recurring dream of replacing developers

#280

[flagged]

>COBOL was supposed to let managers write programs. VB let business users make apps. Squarespace killed the need for web developers. And now AI. The first line made me laugh out loud because it made me think of an old boss who I enjoyed working with but could never really do coding. This boss was a rockstar at the business side of things and having worked with ABAP in my career, I couldn't ever imagine said person wr…

Many business people I've worked with are handy with SQL, but couldn't write e.g. go or python, which always surprised me. IMO SQL is way more inconsistent and has a mental model far more distant from real life than common imperative programming (which simply parallels e.g. a cookbook recipe).
Post reply on HN