Programming? You mean that clever trick people do to make progress on a code base slowly while Claude is down?
21,392 karma · joined July 27, 2007
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.
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.
Dabadooba, ba dabadooba!
Working with AI tools is like trying to eat with silicone rubber chopsticks. You're so removed from the point of contact that you no longer have effective haptic feedback for the problem you're trying to solve. You're not doing the work, you're commissioning and checking someone else's work. It's an entirely different job now.
Pivoting from programming-brained to business-brained has proven so successful for the likes of Bill Gates, that quite a few other programmers have done likewise (including arguably the esteemed founder of this place, Paul Graham). In addition, the filed has attracted so many people who are indeed business-brained and mainly in it for the money, especially over the past 20 years or so.
I used to gently make fun of colleagues of mine at college, who switched majors from computer science to MIS (Management Information Systems) as they discovered that programming is hard and math is hard. I thought of MIS as "computer science on easy mode", and called the textbooks they used "Richard Scarry books"[0] because they were full of busy-looking illustrations but lacking in depth.
Serves me right for my arrogance, I guess, because the Richard-Scarry-book kids are winning bigly, going from zero to go-to-market in no time flat with LLM agents to do the work they were afraid of in college.
Having a business brain is the new moat.
[0] Richard Scarry was an American children's book author, known for his books whose pages were filled with large colorful illustrations of the animal citizens of Busytown. https://en.wikipedia.org/wiki/Richard_Scarry
I think I'd rather have that than the state of the art in "modern" TUIs, which is to do the opposite and treat the terminal as a special case of React canvas, redrawing the whole damn thing every time there is a keystroke or other action by you or the program. You can see Claude Code redraw itself all the time; it's maddening. And the program would absolutely be unusable on, say, a 9600bps connection, whereas Emacs could still get by on that. This is from the company that retains the best and brightest programmers, and will have self-improving runaway genius AI by Christmas, for realsies this time.
Of course, it's important to be right when there are consequences on the line, but being wrong isn't ipso facto something bad.
And there are technological "advances" I would very much like to undo. One of them being social media, another being modern cars. Automobiles peaked when they were purely mechanical. An average American high schooler could understand all its systems, and many did. When they started becoming LANs on wheels beginning in the 90s, they became necessary millstones around their owners' necks, and these days they're as inscrutable as a smartphone, just as user-hostile, and just as tethered to vendor services. I think my father was speaking from a place of wisdom when he groused about computers in automobiles.
And no, EVs are actually simpler than ICE engines, their drivetrain being basically a battery, a set of electric motors, and maybe some variable resistors to control speed. An EV that is purely electromechanical and operable via analog controls would be a godsend, but it's not going to happen under current regulatory environments.
Carmack has cheerfully admitted to being wrong in the past, for example admitting that the Saturn port of Doom should have used the Saturn's hardware primitives for a smoother experience rather than a faithful replication of the PC's BSP renderer which made it slow. When brilliant guys like him are wrong, they often are in profound ways.
AI is getting good at picking those as well. Frontier models can be fed a vague problem, analyze the code base, and pick out an architectural solution that makes sense.
We're going from a world that needs specialized "software engineers" to speak the language of the machine into one where ordinary people need only sit down and think, "what exactly would solve my problem here?", spell it out in ordinary procedural language, and get a software solution that employs best practices without the intervention of professional computer-touchers.
Tim Bryce was right 20 years ago. Abolish programmers, bring back systems analysts!
Milt Bryce and his son Tim were pretty much the inventors of modern information-systems management[0]. And they were open in their hatred of and contempt for programmers and how they worked. Their methodology, PRIDE, was centered around giving the programmers as little to do and as little autonomy and leverage over the organization as possible, because information systems is a business function and not a technical one. The key decisions would be made by systems analysts and designers, not programmers. Without AI, the part that programmers contributed in a PRIDE project was about 15%; with AI, it asymptotically approaches zero. I've been studying PRIDE a lot over the past few years, because with Tim Bryce's death it's at risk of being forgotten; and because now with AI in the mix, it helps me understand what's actually going on from a business perspective.
This is what management has wanted all along. Programmers are expensive, tetchy, and they resist standardization and discipline, preferring instead to employ their own little bespoke methods and tool choices. (Hello, vim vs. emacs!) Failure to keep them in tight rein can spell doom for the company, as they can use their technical skills to their advantage, potentially holding the whole business hostage. You may bristle and think the above is not true, but your boss or skip-level manager probably thinks it's true, and the C suite absolutely does (especially in traditional businesses: banking, insurance, manufacturing, etc.). Nerds were seen as a necessary liability to automating a business's information systems; now, they are no longer necessary.
The only way out for us is to follow Rogue's mom's advice: "Have you tried not being a nerd?" Learn business, learn what customers actually want and what business operations need in order to fulfill those wants. Think like a systems analyst—big picture, focused on information flows between companies, departments, people, not like a programmer (detailist obsessed with the machine in PRIDE ideology).
[0] Maybe Margaret Hamilton predated them, but not by much.
Dario: All right, frontier is paced! From now on, AI moves forward at a rate WE decide!
[Kwindla Kramer bursts into the apartment]
Kramer: You guys might want to sit down for this. You know that Chinese place down on 4th? They got a model that's smoking you guys at SWE benchmarks!
[laughter, applause, slap bass intensifies]
It's over. AI is here, and it's so vastly better than any tooling we've produced before, that you have to be really stupidly stubborn not to use it if you're doing real work. And if you object to say that it's not vastly superior, then, you know, "tell me you haven't used a frontier model without telling me you haven't used a frontier model". If you want to get together with your friends and hold a code 'n' sip on Wednesday evenings, maybe fire up an old copy of Vim or Visual Studio and write a game or a little webapp like they used to do in ye olden times just to see what it is like, fine, go nuts. But that's not how software meant for people to actually use gets written anymore.
Dario: We gotta pace the frontier!
Sam: How do you pace a frontier? The frontier's not goin' anywhere. It's right where it was, just go out and explore it!
Dario: Sam, I'm tellin' ya, ya gotta pace it! Things are getting very doomy out there, and Dario's gettin' upset!