3 ms·

Programming is like music in that the act of producing it is itself a medium for thought. Any but the lowest level languages are not just instructions for a com

by bitwize 10d ago

Programming is like music in that the act of producing it is itself a medium for thought. Any but the lowest level languages are not just instructions for a computer, they're a formalism for abstract procedures rigorous enough to be executed by computers in a predictable, repeatable way (what you put into an LLM is emphatically NOT this) but expressed in a form that can be reasoned about and shaped readily by humans. If you take away the mundane doing of the thing, you don't just remove the challenge or sense of control, you take away the entire craft. So it's a bit strange to treat composing program code as something that's incidental or ancillary to what software engineers do. A software engineer solves problems through writing code. If you make the writing of code go away, you're no longer building software. You're a product manager or a systems analyst, delegating the building of the software to someone or something else. If that's what you want to do, go nuts. But say what it is.

aogaili 10d ago
What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent? What about codebase architecture? The user experience, and how using the software makes someone feel? What about the narrative and mental models the software offers users? How does it shape the way they think? What about expanding into adjacent, bigger, or deeper products? Is none of this part of the artistic side of the craft? If I tell an LLM, 'Connect to DB X, pull data from Y, and display it in table Z,' is that really less of a craft than manually referencing API docs, wiring up data pipelines, and serializing objects? Is telling an LLM 'Do X, then Y, then Z' truly that different from writing if X do Y or while X do Z? It reminds me of the pushback against Java and other high-level languages when they were first introduced—people panicked over losing low-level control. I do recognize something is lost by moving to a higher abstraction (e.g. from JS/Java/PHP to English), but to say the entire craft is lost and what we had before was "music" relative to the nothing now, I believe it is a narrow take on what is happening.
- bitwize 10d ago
  > What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent? That's what Steve Jobs brought to the table. Was Steve Jobs a software or hardware engineer? I would argue no—he was fundamentally doing product design and management. You can argue this is a craft as well, but it's a fundamentally different one from software engineering. > What about codebase architecture? LLMs are getting good at this too. Within a few years we may not need humans for this. If you're hoping that "architecture" will be your moat, well, I'm sorry... > The user experience, and how using the software makes someone feel? What about the narrative and mental models the software offers users? How does it shape the way they think? What about expanding into adjacent, bigger, or deeper products? Again, these are largely product design concerns. Software engineers can do them, sometimes even well, but they alone do not constitute software engineering. > Is none of this part of the artistic side of the craft? You seem to be getting hung up on my music analogy as some sort of "code as art" thing. While I agree that code can be artistic, that's not where I was going with it at all. I mean that in order to compose, a musician usually picks up and plays an instrument, or simply sings in order to play with melodies and harmonies to determine what sounds right. They set up a sort of ear/brain/muscular system feedback loop to shape how a song sounds and feels in real time. If you have them specify what kind of song they want in English, you've cut out that feedback loop. They're not really being a musician anymore, they're commissioning music. They're more of a musical director. It's the same with programmers. Programmers work and think in code. Code becomes a medium of exchange of ideas about procedure between each other, their future selves, and the machine. I learned a lot about this writing Lisp, but even in a stodgy language like Ada, I can get a lot of thinking through of a solution done by writing what types I want to be working with, in Ada. If you take the code away and say "here, specify the program you want in English", you're basically asking the software engineer to stop being a software engineer and start being a product manager or business analyst. Which is fine, you know, maybe we just don't need software engineers anymore. > I do recognize something is lost by moving to a higher abstraction (e.g. from JS/Java/PHP to English) No, it's not "just another layer of abstraction". It's fundamentally different. Generally speaking, software abstractions are transparent homomorphisms from the constructs in the language of expression (e.g., Java, PHP) to instructions the computer can execute. How an LLM converts your prompt into code is both opaque and unstable. I get that we're really not supposed to care about that, nor did many people care exactly how the compilers they used work. But with a compiler, if you do care, you can examine it and it'll make sense, or you can write your own. An LLM, not so much really. Again, you are no longer building the software yourself. You're asking a teammate to. It's just that your teammate exists in silico now. This becomes more true, not less, as LLMs become more capable of the grunt work of, you know, engineering, freeing you for the more important business of stating what you want in vaguer and looser terms. I guess the dream is that we'll all become business founders, with the LLM as our founding engineer, and we can just ask them to build what we think the business needs, and go through them to make refinements and changes.

by bitwize 10d ago

aogaili 10d ago

What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent? What about codebase architecture? The user experience, and how using the software makes someone feel? What about the narrative and mental models the software offers users? How does it shape the way they think? What about expanding into adjacent, bigger, or deeper products? Is none of this part of the artistic side of the craft? If I tell an LLM, 'Connect to DB X, pull data from Y, and display it in table Z,' is that really less of a craft than manually referencing API docs, wiring up data pipelines, and serializing objects? Is telling an LLM 'Do X, then Y, then Z' truly that different from writing if X do Y or while X do Z? It reminds me of the pushback against Java and other high-level languages when they were first introduced—people panicked over losing low-level control. I do recognize something is lost by moving to a higher abstraction (e.g. from JS/Java/PHP to English), but to say the entire craft is lost and what we had before was "music" relative to the nothing now, I believe it is a narrow take on what is happening.

bitwize 10d ago
> What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent? That's what Steve Jobs brought to the table. Was Steve Jobs a software or hardware engineer? I would argue no—he was fundamentally doing product design and management. You can argue this is a craft as well, but it's a fundamentally different one from software engineering. > What about codebase architecture? LLMs are getting good at this too. Within a few years we may not need humans for this. If you're hoping that "architecture" will be your moat, well, I'm sorry... > The user experience, and how using the software makes someone feel? What about the narrative and mental models the software offers users? How does it shape the way they think? What about expanding into adjacent, bigger, or deeper products? Again, these are largely product design concerns. Software engineers can do them, sometimes even well, but they alone do not constitute software engineering. > Is none of this part of the artistic side of the craft? You seem to be getting hung up on my music analogy as some sort of "code as art" thing. While I agree that code can be artistic, that's not where I was going with it at all. I mean that in order to compose, a musician usually picks up and plays an instrument, or simply sings in order to play with melodies and harmonies to determine what sounds right. They set up a sort of ear/brain/muscular system feedback loop to shape how a song sounds and feels in real time. If you have them specify what kind of song they want in English, you've cut out that feedback loop. They're not really being a musician anymore, they're commissioning music. They're more of a musical director. It's the same with programmers. Programmers work and think in code. Code becomes a medium of exchange of ideas about procedure between each other, their future selves, and the machine. I learned a lot about this writing Lisp, but even in a stodgy language like Ada, I can get a lot of thinking through of a solution done by writing what types I want to be working with, in Ada. If you take the code away and say "here, specify the program you want in English", you're basically asking the software engineer to stop being a software engineer and start being a product manager or business analyst. Which is fine, you know, maybe we just don't need software engineers anymore. > I do recognize something is lost by moving to a higher abstraction (e.g. from JS/Java/PHP to English) No, it's not "just another layer of abstraction". It's fundamentally different. Generally speaking, software abstractions are transparent homomorphisms from the constructs in the language of expression (e.g., Java, PHP) to instructions the computer can execute. How an LLM converts your prompt into code is both opaque and unstable. I get that we're really not supposed to care about that, nor did many people care exactly how the compilers they used work. But with a compiler, if you do care, you can examine it and it'll make sense, or you can write your own. An LLM, not so much really. Again, you are no longer building the software yourself. You're asking a teammate to. It's just that your teammate exists in silico now. This becomes more true, not less, as LLMs become more capable of the grunt work of, you know, engineering, freeing you for the more important business of stating what you want in vaguer and looser terms. I guess the dream is that we'll all become business founders, with the LLM as our founding engineer, and we can just ask them to build what we think the business needs, and go through them to make refinements and changes.