I read somewhere that almost every very successful person’s results can be attributed to 2-3 tricks that they consistently apply to great effect.
With Elon, I think one of his is “build it as cheaply as possible, and then you can afford to only sell to people who are purely excited about the tech.” I don’t know when he learned this (I actually wonder if it was a lesson he learned from Eberhard/Tarpenning at Tesla, who were only selling the roadster to sports car enthusiasts who cared more about 0-60 than fit & finish, or range, or cost, or anything else).
Anyway, my current interpretation is that the pizza guys shouldn’t have sold to pepepizza (or friends and family, probably). I know startups do this all the time, but whenever I’ve seen it, it always seems to turn into a distraction from the Big Idea that is the company’s thesis. Then Big Customer gets hung up on ancillary requirements and Cool Startup doesn’t really get to test their thesis at all. Maybe the key is to stay small, focus on finding people who really care about the new oven tech, and size the company to that market until you’ve solved enough problems to expand to people for whom the cool tech is concern #2 or #3.
> learn to turn off the over-thinking part of the brain that blocks creativity
This is all pretty vibe-y but I think that might be what the post’s author found the ability to do and is trying to teach? TFA links to this other post in a similar vein: https://commoncog.com/get-numb-get-good/
I wonder if some of these CEOs are anticipating a big crash and trying to lay people off now, so that (1) they can raise/hoard cash while the money-go-round is spinning and (2) their eng organization is already lean and used to it if/when the money-go-round stops.
> I'm not sure how you get from "LLMs work in mysterious ways" to "So we need more discipline" to "everything is fine."
Are you referring to this part:
> I am not worried, at least in the near term, about AI creating massive, discontinuous returns on investment in the absence of engineering discipline. (Many will try, and it will be entertaining to watch.)
She's saying, "the amazing thing about LLMs isn't that they generate lots of code fast, so don't worry about people using LLMs for that taking over the industry"
She's making two points:
1. Before infra-as-code, people would be afraid to touch parts of production due to lost knowledge about how and why it got that way. Now that we have infra-as-code, you aren't allowed to change infra the old way (ad-hoc changes via dashboard/CLI), even if doing so would be faster and easier. Experienced SREs were required to abandon lots of their old skills with CLIs and dashboards and start working in a completely new way, because the knowledge captured in a terraform repo's commit history is so valuable.
2. In the past, the way code got written was through people making changes in ways that are specific to their current knowledge, the org's current problems, the current users, etc, some or all of which is not written down. Eventually, everyone is afraid to change certain things because they don't know or remember all the considerations that went into them (not just afraid to touch parts of the code, but afraid to delete seemingly-unused features, or migrate the schema, or whatever).
Charity is saying that problem 2 is a hidden/lost-knowledge problem like problem 1, and the amazing thing about LLMs is you have to write down all the knowledge you want them to have, which may lead to a better solution to the "lost knowledge" problem in software development, which would be so valuable that experienced software engineers have to abandon lots of old skills and start using it.
(Not only writing down all the knowledge you want the LLM to have, since they're flaky enough to ignore instructions and miss implications sometimes, but building test suites and tools and so on that adequately guide their solution. This is the "more discipline" she's referring to.)
> The Enigma of Reason (Hugo Mercier and Dan Sperber, 2017): their argumentative theory holds that reasoning evolved for social rather than individual epistemic purposes, to produce and evaluate arguments in group contexts.
Yes! I love that someone wrote this down!
This seems so obvious to me now. I often ask LLMs to cite their sources (they do hallucinate from time to time), and they often give me sources that don't say what is claimed. "How would the LLM know not to give this to me?" I wonder. They're trained to explain but not to convince, so they don't know what's convincing, and they should.
I think humans hallucinate at least as much as LLMs—arguments of any complexity are impossible to formulate without leaping at least a bit—but other humans ground us. That's why when people become socially isolated, they join cults or adopt conspiracy theories or the like.
Conversely, "this is convincing to an expert" converges on “this is true" as our collective expertise grows over time. This is the foundation of the scientific method, of progress in all engineering disciplines, etc.
I liked this article, and I see a lot of other commenters didn't, so I'll give my take:
When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.
I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.)
What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into its current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.
> The beginning of the end: The day I bought an Adderall from a classmate. When that amphetamine feeling kicked-in, it was as if life was perfect for the first time. I was happy, confident, felt I could do anything.
You know, I had a similar experience, but in my case I got an appointment with a psychiatrist afterwards, described the experience in detail, was given a computer test, diagnosed with ADHD, and then given a prescription. (Also in my case, I learned Adderall doesn’t actually feel great or help you if you take too much).
Take care of your kids. The war on drugs is stupid. Etc.
IIUC, the most basic version is when you have a log where every entry has both “date added” and “effective date,” so you can add stuff to the log retroactively. For example, “the user just informed us yesterday that they moved last year” -> address date added=yesterday, date effective=last year
Yeahhhh…this is not really how Linux works, though.
Most of LLM world is kind of anti-linux right now because the most popular LLMs are walled off by these huge companies and hella expensive. At some point, a nerd will realize they could hack together a surprisingly ok homebrew version of what everybody else is using, and do. Then a company realizes that they can build a brand on the anarchist, grassroots vibe of the homebrew thing, and capitalize its development (software development, but also community development, which is brand development for the company). Now, it’s much later, but the open source thing is competitive, and popular for being open-source.
At one point I got interested in why Red Hat handed over tens of millions of dollars in stock to Linus leading up to their IPO, in exchange for…nothing specific. Nominally it was a gift of appreciation, but handing out random gifts is somewhat opposed to maximizing shareholder returns. It’s because Linus controls merges to the Linux kernel and doesn’t have to care about Red Hat, and the board wanted him to care at least a little bit. They were stuck between “people trust our business because it’s built on this populist OS” and “this populist OS is mostly controlled by a guy who doesn’t work for us.” It’s hard to have one without the other.
I’m glad Apple is taking accessibility seriously, and I wish accessibility worked better on Linux, but I don’t think Linux is ever going to make developers “do their homework,” because the community wouldn’t trust a Linux like that. If the author is right, it’ll happen because “AI for the People, Inc.” builds a business on it and sponsors the work.
I mean the headline is great! I can't tell you how many arguments I've had about "you can't execute your way out of a bad strategy" (which I claim the original "you can't exercise your way out of a bad diet" is a special case of)
> One of the current trends in modern software is for developers to slap an API call to OpenAI or Anthropic for features within their app.
Well there’s your problem, control needs to go the other way. If you want your app to be AI-enabled, you need to make it easy for AI to control your app. Have you used OpenClaw? It’s awesome!
Most of my posts have aged terribly in the age of AI (especially the ones I didn't finish...so long, extended discussion of how to use a lab notebook when debugging, we hardly knew ye. Claude fixes our bugs now) but one job that engineers still have is the collection and retention of context that AI doesn't have and can't easily get.
For that matter, here's a thread from a few days ago recommending the practice of scheduling status meetings for the purpose of pressuring the attendees to work on your project in addition to their other work: https://news.ycombinator.com/item?id=47906942
What hermit wouldn't love meetings that simultaneously insist that you do more while taking away time to do it, all to avoid adjusting a pollyanna quarterly plan and budget!
Yes! So much of professional software development is about assisting the nominal job of management—planning and budgeting—rather than users or even business fundamentals.
Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later? Ah yes, so that we meet our quarterly OKR, and the next quarter's plan that the EM and PM negotiated without me or our customers isn't disrupted and doesn't need adjustment. That would invite reprimand from the director, and the extra work would be terrible for them, I understand.
I'm reminded of this recent thread in which Heroku left the devs in charge and suddenly features that the author had requested for years got implemented: https://news.ycombinator.com/item?id=47669749
My point being, in case it’s still unclear, that “I’ll create pressure on everyone and then progress will happen,” is IMO bad management.
Sometimes the problem is not enough motivation, though I think that if you hire well, that’s rare—the best engineers are intrinsically creative and motivated. Often, lack of progress is due to some other organizational problem—too much toil, unclear priorities, conflict, etc—and just adding pressure until progress happens is the manager equivalent of whining until your sister does your chores for you.
Even if it works, either
1. the team is working around the problem (which the manager doesn’t know about or understand, and isn’t dealing with it) and will eventually get fed up and leave, or
2. someone pushes extra hard and solves the problem for everybody else. Now, that person the de-facto leader, though they’re not recognized, and in fact are often penalized for getting distracted from the paper priorities, since the managers who do this are rarely interested in the mechanics of how their problem was solved. Respect for management is lost, because they don’t understand what’s happening. Eventually everyone gets fed up and leaves.
Managers can’t solve every problem themselves, of course, but the manager needs to understand what the problems are, explicitly set the priority of solving them, and understand and celebrate the solutions when they’re found.
You know what, I read it again and I don't even disagree with the concrete advice in the post—weekly meeting, starting with open tasks from last week—which I would characterize as a basic, ubiquitous, almost anodyne organizational coordination tool. My problem is this part:
> Everyone has other obligations, fires to put out, and emails to answer. It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list...this creates pressure on everyone to make progress.
One experience among many: I spent a very painful six months as a new grad, in a particularly dysfunctional corner of a mildly dysfunctional organization, in hours of daily back-to-back arm-twisty status meetings with team after team who wanted something from me and were sure this would get it (after which I would stay up all night working, since that was the only time I had left for that).
You know how it ended? The tech lead on my team cornered me in a conference room to find out why nothing was getting done, and I fully lost it with the guy. Like just started shouting that the actual consequences of ignoring the things people wanted ignored were transparently not acceptable, and I was barely sleeping trying to hold everything together. He got very quiet, said "ok," and we started going to meetings together and saying no to stuff. The amount that was collectively being demanded from me/us exceeded what could be delivered, but no one was on triage duty.
I've learned quite a bit since then (including spending a few years in management), so I've gotten better at understanding what's happening and asking for what I need. I've just also decided that "it's not my role to figure it out" managers (and PMs) are like rocks in the bowels of an organization. They’re in the way, subtly, quietly making everything bloated and painful as long as they’re there.
IMO this is such a manager-brained take. If your long-term strategic goals aren't being advanced, you have to figure out why. Talk to your team and figure out what the deal is. Talk to other teams too, while you're at it. You might accidentally solve a problem.
The number of managers who've successfully convinced themselves that knowing things and making decisions aren't part of their job, and just fill their days with arm-twisting and event-planning, is literally unbelievable to me. I've never met a founder with the attitude "yes I'll just put the stakeholders in an alignment meeting and my company will build itself," but somehow half the of the rest of leadership thinks that's a job.
A lot of this is about knowledge debt if I’m reading it correctly (people not knowing things that they should know, or knowing the wrong things). In my last few jobs, I’ve maintained an Anki deck about facts relevant to my job (who certain people are, how certain systems work, details of the programming languages we use, etc.)
I’ve started kind of a funny rule, which is that when I make a change now, I can use Claude or not. But if I use Claude, some cards have to go into the deck. Both about how the implementation works, and also about anything within the implementation I didn’t know about. It does force you to double-check things before committing them to memory.
I think about this a lot, though one paragraph from that article:
> Many assembly programmers were accustomed to having intimate control over memory and CPU instructions. Surrendering this control to a compiler felt risky. There was a sentiment of, if I don’t code it down to the metal, how can I trust what’s happening? In some cases, this was about efficiency. In other cases, it was about debuggability and understanding programming behavior. However, as compilers matured, they began providing diagnostic output and listings that actually improved understanding.
I would 100% use LLMs more and more aggressively if they were more transparent. All my reservations come from times when I prompt “change this one thing” and it rewrites my db schema for some reason, or adds a comment that is actively wrong in several ways. I also think I have a decent working understanding of the assembly my code compiles to, and do occasionally use https://godbolt.org/. Of course, I didn’t start out that way, but I also don’t really have any objections to teenagers vibe-coding games, I just think at some point you have to look under the hood if you’re serious.
With Elon, I think one of his is “build it as cheaply as possible, and then you can afford to only sell to people who are purely excited about the tech.” I don’t know when he learned this (I actually wonder if it was a lesson he learned from Eberhard/Tarpenning at Tesla, who were only selling the roadster to sports car enthusiasts who cared more about 0-60 than fit & finish, or range, or cost, or anything else).
Anyway, my current interpretation is that the pizza guys shouldn’t have sold to pepepizza (or friends and family, probably). I know startups do this all the time, but whenever I’ve seen it, it always seems to turn into a distraction from the Big Idea that is the company’s thesis. Then Big Customer gets hung up on ancillary requirements and Cool Startup doesn’t really get to test their thesis at all. Maybe the key is to stay small, focus on finding people who really care about the new oven tech, and size the company to that market until you’ve solved enough problems to expand to people for whom the cool tech is concern #2 or #3.