Earlier quoted context omitted.
Programming is probably the most democratized profession ever. The problem was never access barriers, but the fact that people are too lazy to study even a 200-300 pages on something as simple as ruby on rails.
I think there’s an actual barrier. I’ve seen it, especially since the (until recently) brisk market for programmers was sucking people out of traditional engineering. It’s puzzling because programming seems so easy and fun. And even before LLM’s, we had StackOverflow after all. But for some reason a lot of people just hit a wall when they try to learn programming, and we don’t know why. The “CS 101” course at college…
The Eternal Promise: A History of Attempts to Eliminate Programmers
191–200 of 246 posts
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#192LLMs seem quite successful when considered something like a natural langiage interface, but expecting intelligence seems a step too far. For one they do not learn, at least not online, and that is a somewhat important requirement for truly intelligent behaviour. Arguably programming is as much learning as it is writing code. This is part of the reason some people copy an entire API and don't realise they're not so mu…
In some sense, programming is about figuring out which algorithms are a fitting metaphor for business problems. By programming, you are building a model of the business problem and a model of its solution. Most of the non-programmers who are in positions of authority (managers, CEOs, even some CTOs), do not understand that this is what programmers do. From their point of view, the authorities come up with a "strategy…
Some do, but not all did that. With work-from-home I was staying at a friend of a friend that was a programmer and had a meeting. I was amazed about the level of simple things he was discussing, like "please add an error check, now you made a form where you can insert wrong data; make sure form is visible on a small screen, now it is not; etc.". And they talked ~2 hours about each, with the other person showing the guy exactly what it was not working. I do not know the history (maybe he was reconverting or something), but if this was what was he was doing usually, it was very inefficient and quite simple.
Most of my work was more similar to what you describe (fighting vague instructions and push back unfeasible ideas), but I wonder how much of "the industry" does this.
On the management I worked with all kinds, the employees have a small part of responsibility to look and select good organizations, otherwise power-hungry idiots arrive on top and start dictate and nothing crumbles because everybody just stays.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#193Earlier quoted context omitted.
The actual work happens in the head. I suspect you know this. Now, there is a clear benefit to being able to flatten some of the issues related to coding, but do you really think, any of it can be done without those meetings and muddling through those requirements? At the very least, there needs to be one person that understands what is actually needed. I mean.. I am ok with you saying saying yes. In a sense, I half…
I spend an unusually small proportion of my life in meetings, probably an idiosyncratic feature of my job. My impression is that the main reason most people have so many meetings is because meetings are equated to work. If you are in a meeting, you are at work and you need to work. This is because, in a meeting, everyone is looking at everyone else with the expectation that they are working. But if you are not in a m…
On remote work, I do see an advantage of having people interact occasionally (I agree daily is probably too much) on work topics, besides the meeting. Spontaneous "can you have a look at" or "oh what is that program that you use". This will help much less the best performers (they know how to solve things, they look actively for new tools, etc.), but most companies have lots of profiles.
Someone in this thread was also complaining "management does not get engineering", which I feel is also made worse by working fully remotely - they will not get all topics in a meeting and if you have more informal talks, if they hear the discussions they might get (a bit) better.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#194I'd say that the article left out Software Reuse - talked a lot more about in the late 90's early 00's than now. You could argue that coding with LLM's is a form of software reuse, that removes some of its disadvantages.
If you have been in the industry for a few decades you will be able to think of several hundred "silver bullets" that made great promises - some even turned out to be great ideas, but none where the 10x revolution that they promised. The article is a good summary of major movements through the decades without so much that whole point is lost in the details. I would have put in a slightly different set of things if I…
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#195The reasons vary, but in general, just as some people don't want to touch maths (even if they might be good at it if they tried), some people loathe the very idea of being technical, either because they think it is beneath them, or they just don't see themselves that way.
And like the article explains, even when "programming" tools seem to become simpler to use, they still require technical specification, and once people feel like they are getting close to "programming" they check out.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#196One other thing that is often ignored: Most of the business class, executive class, ... even working class, DON'T want to write code. The reasons vary, but in general, just as some people don't want to touch maths (even if they might be good at it if they tried), some people loathe the very idea of being technical, either because they think it is beneath them, or they just don't see themselves that way. And like the…
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#197One important and often overlooked democratization is spreadsheet formulas: non-programmers began programming without knowing they were, and without concern for error and edge cases. I cannot find the reference right now, but I recall seeing years ago articles about how mistakes in spreadsheet formulae were costing millions or more. I see an analog with AI-generated code: the disciplined among us know we are programm…
And then of course there's this: https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt#Metho...
> Or will people realize they are programming and discipline up?
Well, they apparently haven't with spreadsheets, 50 years on, so I wouldn't be optimistic.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#198One important and often overlooked democratization is spreadsheet formulas: non-programmers began programming without knowing they were, and without concern for error and edge cases. I cannot find the reference right now, but I recall seeing years ago articles about how mistakes in spreadsheet formulae were costing millions or more. I see an analog with AI-generated code: the disciplined among us know we are programm…
I often think about how the modern world genuinely does run on Excel formulas, many written by amateurs, most without automated tests and with version control based on final_final_v2 suffixes. Somehow civilization continues to function! Makes me a bit less terrified that untested vibe coded slop will sink the economy. It's not that different from how things work already.
(This paper was extremely influential in pushing austerity policies of questionable efficacy during the financial crisis.)
We don't want _more_ of this.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#199Earlier quoted context omitted.
I attended a CASE tools conference in the 1990s, which of course included a vendor exhibition. The vendors all had demos of creating an application using their tool. At multiple vendor stands I asked to see the code generated by their CASE tool. Invariably, the salespeople would start waffling about how the code was no longer important (sound familiar?), how you didn't need to examine the engine of a car while drivin…
Was a "to do" list the example they used at that time also?
In practice, Rails, while quite nice, was not the productivity revolution that it was originally touted as. These things never are.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#200Until a year ago I believed as the author did. Then LLMs got to the point where they sit in meetings like I do, make notes like I do, have a memory like I do, and their context window is expanding. Only issue I saw after a month of building something complex from scratch with Opus 4.6 is poor adherence to high-level design principles and consistency. This can be solved with expert guardrails, I believe. It won’t be l…
The closer you get to releasing software, the less useful LLMs become. They tend to go into loops of 'Fixed it!' without having fixed anything. In my opinion, attempting to hold the hand of the LLM via prompts in English for the 'last mile' to production ready code runs into the fundamental problem of ambiguity of natural languages. From my experience, those developers that believe LLMs are good enough for production…
Which is _always_ the case with these things, honestly. Remember Ruby on Rails? Make a Twitter clone in half an hour by just writing some DSL! Of course, in reality Rails was _not_ a productivity revolution, and making _real_ software which had to be operated at scale and maintained, and work properly, in it wasn't much easier than it had been previously.