> The real concern is for generations of learners who are being robbed of the opportunity to acquire the expertise to objectively discern what is slop and what is not.
How do new developers build the skills that seniors generated through time? I see my seniors having higher success in vibe-coding than me. How can I short-circuit the time they put through for myself?
Code is cheap. Show me the talk
61–70 of 237 posts
Re: Code is cheap. Show me the talk
#62I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you. But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about…
> I know a lot of counter arguments are a form of, “but AI is automating that second class of job!” Uh, it's not the issue. The issue is that there isn't that much demand for the second class of job. At least not yet. The first class of job is what feeds billions of families. Yeah, I'm aware of the lump of labour fallacy.
Discussing what we should do about the automation of labour is nothing new and is certainly a pretty big deal here. But I think you're reframing/redirecting the intended topic of conversation by suggesting that "X isn't the issue, Y is."
It wanders off the path like if I responded with, "that's also not the issue. The issue is that people need jobs to eat."
Re: Code is cheap. Show me the talk
#63The original phrase "talk is cheap" is generally used to mean "it's easy to say a whole lot of shit and that talk often has no real value." So this cleaver headline is telling me the code has even less value than the talk. That alone betrays a level of ignorance I would expect from the author's work. I go to read the article and it confirmed my suspicion.
Yes, the original phrase has a specific meaning. But in another context, "talk" is more important than the code.
In software development, code is in a real sense less important than the understanding and models that developers carry around in their heads. The code is, to use an unflattering metaphor, a kind of excrement of the process. It means nothing without a human interpreter, even if it has operational value. The model is never part of the implementation, because software apart from human observers is a purely syntactic construct, at best (even there, I would argue it isn't even that, as syntax belongs to the mind/language).
This has consequences for LLM use.
Re: Code is cheap. Show me the talk
#64> Code was always a means to an end. Unlike poetry or prose, end users don’t read or care about code. Yes and no. Code is not art, but software is art. What is art, then? Not something that's "beautiful", as beauty is of course mostly subjective. Not even something that works well. I think art is a thing that was made with great care. It doesn't matter if some piece of software was vibe-coded in part or in full, if i…
Well, why do humans read code:
1. To maintain it (to refactor or extend it).
2. To test it.
3. To debug it (to detect and fix flaws in it).
4. To learn (to get better by absorbing how the pros do it).
5. To verify and improve it (code review, pair programming).
6. To grade it (because a student wrote it).
7. To enjoy its beauty.
These are all I can think of right now, and they are ordered from most common to most rare case.
Personally, I have certainly read and re-read SICP code to enjoy its beauty (7), perhaps mixed in with a desire to learn (4) how to write equally beautiful code.
Re: Code is cheap. Show me the talk
#65Earlier quoted context omitted.
This is actually a really good description of the situation. But I will say, as someone that prided myself on being the second one you described, I am becoming very concerned about how much of my work was misclassified. It does feel like a lot of work I did in the second class is being automated where maybe previously it overinflated my ego.
SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.
is it? I really fail to see the metaphor as an F1 fan. The cars do not change that much; only the setup does, based on track and conditions. The drivers are fairly consistent through the season. Once a car is built and a pecking order is established in the season, it is pretty unrealistic to expect a team with a slower car to outcompete a team with a faster car, no matter what track it is (since the conditions affect everyone equally).
Over the last 16 years, Red Bull has won 8 times, Mercedes 7 times and Mclaren 1. Which means, regardless of the change in tracks and conditions, the winners are usually the same.
So either every other team sucks at "understanding the requirements and the technical challenges" on a clinical basis or the metaphor doesn't make a lot of sense.
Re: Code is cheap. Show me the talk
#66The original phrase "talk is cheap" is generally used to mean "it's easy to say a whole lot of shit and that talk often has no real value." So this cleaver headline is telling me the code has even less value than the talk. That alone betrays a level of ignorance I would expect from the author's work. I go to read the article and it confirmed my suspicion.
I think you are hyper-focusing on the headline, which is just a joke. The underlying article does not indicate to me that the author is ignorant of code, and if you care to look, they seem to have a substantial body of public open source contributions that proves this quite conclusively. The underlying point is just that while it was very cognitively expensive to back up a good design with good code back in 2000, it'…
And… the design (artistry) aspect is always the toughest. So explain to me, where do the returns come from if it is seemingly obviously only those who are very well informed of their domains/possess general intelligence can benefit from this tool?
Personally I don’t see it happening. This is the bitter reality the LLM producers have to face at some point.
Re: Code is cheap. Show me the talk
#67I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you. But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about…
My job is to make people who have money think I'm indispensable to achieving their goals. There's a good chance AI can fake this well enough to replace me. Faking it would be good enough in an economy with low levels of competition; everyone can judge for themselves if this is our economy or not.
Re: Code is cheap. Show me the talk
#68Feels like this website is yelling at me with its massive text size. Had to drop down to -50% to get it readable.
Classical indicators of good software are still very relevant and valid!
Building something substantial and material (ie not an api wrapper+gui, to-do list) that is undeniably well made, while being faster and easier than it used to be, still takes a _lot_ of work. Even though you don't have to write a line of code, it moves so fast that you are now spending 3.5-4 days of your work week reading code, using the project, running benchmarks and experimental test lanes, reviewing specs and plans, drafting specs, defining features and tests.
The level of granularity needed to get earnestly good results is more than most people are used to. It's directly centered at the intersection between spec heavy engineering work and writing requirements for a large, high quality offshore dev team that is endearingly literal in how they interpret instructions. Depending on the work, I've found that I average around one 'task' per 22-35 lines of code.
You'll discover a new sense of profound respect for the better PMs, QA Leads, Eng Directors you have worked with. Months of progress happen each week. You'll know you're doing it right when you ask an Agent to evaluate the work since last week and it assumes it is reviewing the output of a medium sized business and offers to make Jira tickets.
Re: Code is cheap. Show me the talk
#69Earlier quoted context omitted.
SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.
is it? I really fail to see the metaphor as an F1 fan. The cars do not change that much; only the setup does, based on track and conditions. The drivers are fairly consistent through the season. Once a car is built and a pecking order is established in the season, it is pretty unrealistic to expect a team with a slower car to outcompete a team with a faster car, no matter what track it is (since the conditions affect…
I wonder about how true this was historically. I imagine race car driving had periods of rapid, exciting innovation. But I can see how a lot of it has probably reached levels of optimization where the rules, safety, and technology change well within the realm of diminishing returns. I'm sure there's still a ridiculous about of R&D though? (I don't really know race car driving)
Re: Code is cheap. Show me the talk
#70I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you. But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about…
A software engineer with an LLM is still infinitely more powerful than a commoner with an LLM. The engineer can debug, guide, change approaches, and give very specific instructions if they know what needs to be done. The commoner can only hammer the prompt repeatedly with "this doesn't work can you fix it". So yes, our jobs are changing rapidly, but this doesn't strike me as being obsolete any time soon.
I listened to an segment on the radio where a College Teacher told their class that it was okay to use AI assist you during test provided:
1. Declare in advance that AI is being used.
2. Provided verbatim the questions and answer session.
3. Explain why the answer given by the AI is good answer.
Part of the grade will include grading 1, 2, 3
Fair enough.