brhsagain

I agree that the word “just” carries that connotation but I disagree that it’s a bad thing. When I ask if we can just do something my intent is exactly to communicate that I think the thing is simple, that the details are unimportant (to me, to us) and that it ought to be easy to do (and if it’s not, that’s a problem in and of itself).

A lot of things are like this, and so to excise the word “just” would be to stop using a word that often concisely and accurately conveys what I’m trying to say.

It would be better if the article just said “this is rude.”

I've never seen so many epicycles in my life...

I get what the optimism is about in theory. Parsing unstructured data is something we can now do that we couldn't before. It adds a whole new vector to the span of software, a big piece of capability that software now has whose emergent, unforeseen consequences we can't predict.

I'm just not quite sure I buy this. It feels to me like there's a light motte-and-bailey going on, where supposedly AI is going to be a paradigm shift that changes the very notion of what's possible, but the actual proposals are mostly about LLMs being a finite-multiplier enhancement for the existing ability of software to model and optimize processes.

In particular, a big fraction of the concrete proposals seem to be about making business processes more efficient. Are businesses generally constrained by this to begin with? Like businesses don't seem to be sprinting at the edge of software technology to get as much efficiency as they can, buying diminishing returns from existing tech and waiting eagerly for the next wave of improvements. Judging by revealed preferences, it just doesn't seem like a very high priority for them.

Taking your automated library example, that sounds very cool from a hacker/tinkerer perspective and I'm sure it would result in some efficiency improvements, but it just doesn't seem like, no offense to anyone, a problem that needs urgent attention. How does this significantly improve the situation for anyone involved?

Of course it's true that we don't know what we don't know, and I don't disagree that often technology changes the world in unpredictable ways or even that current AI could possibly lead to this. At risk of being the dropbox-is-just-rsync guy, I'm just skeptical about the following pattern:

(1) some new tech gets invented that's supposedly the next internet;

(2) no one can quite explain or plausibly hypothesize how; but

(3) in the meantime, a wave of companies start building "platforms" and selling shovels to people who will supposedly later build the actual useful thing.

I suppose with a blanket statement like "nothing is happening" I'm practically begging to be contradicted :)

Some of this stuff looks very cool. Have we started getting RL to work generally? I remember my last impression being that we were in the "promising idea but struggling to get it working in practice" phase but that was some time ago now.

I guess we'll see. I use a Mac and iPhone and I use the internet like everyone else, so I see the AI stuff that Apple and Google and others are pushing. Personally, I find almost all of it to be annoying and unnecessary and not solving any actual problems I have. Like believe me, I am the laziest person on the planet and if AI is going to make my life easier, it's like, where do I sign up? ChatGPT does make my life better, and accordingly I happily pay them the 20 bucks every month. But every time I try one of these AI thingies it ends up being a disappointment. Time will tell if others secretly share the same view and the emperor's clothes come off at some point, or if I'm actually just a grumpy luddite.

I remember when bitcoin was taking off, and everyone instantly started saying "bitcoin may not win but one thing is for sure, the **blockchain** is here to stay." Then 15 years went by and the crypto market is basically bitcoin, which won as a store of value, and then a long tail of shitcoins that were "unlocked by the blockchain as a platform."

AI feels to me like it's in a similar state. ChatGPT was a genuinely exciting breakthrough, and because of the previous example of web, everyone instantly wants to see "LLMs as a platform" take off. This has not happened whatsoever. I literally only use ChatGPT. I don't even use Copilot because it's janky and doesn't solve any real problems for me. I guess I sometimes use the RAG-based applications (like docs pages now support a ChatGPT interface), but these are basically ChatGPT with some extra context injected in-- so, ChatGPT. You talk to any of these AI companies and they all admit they're just using the AI label to fundraise and behind the scenes it's either a CRUD app or the thinnest GPT integration in front. I literally don't use any other AI applications. They're all annoying and flooding the web and it is pure clutter everywhere that adds no benefit ever, all because everyone wants to see "LLMs as a platform."

I grew up being a huge fan of YC, and I would respect them so much more if they would take the contrarian (but in my humble opinion correct) view and say actually, judging by the structural evidence and actual results, it's not clear what exactly AI has to offer right now, and we're going to return to PG's founding philosophy and continue funding unsexy and unpopular but ultimately actually important things.

Back when I was building an IDE with a custom text editor, I initially used embedded Neovim thinking I would get the entire vim feature set out of the box for free. Unfortunately this became a never ending source of bugs. I think the fundamental problem was that my application was structured like a game with a main loop in a single thread, and Neovim turned text editing into an async operation, where I would have a separate thread reading events from Neovim and then trying to safely update the global buffer.

Also, I was constantly fighting/reverse engineering Neovim to get the granular level of control over behavior that I needed for a seamless integration. It’s just a type of programming that’s extremely frustrating and not fun.

In the end I implemented custom vim emulation from scratch and surprisingly it wasn’t that hard to get the “20% of features that people actually use 80% of the time,” except it’s more like 5% and 95%, and in exchange I could own the whole stack instead of depending on a third party black box. Never been happier to delete a whole subsystem of code in my life.

I probably should've defined "real value" more carefully. My framework here is basically the idea of technology as humanity's "skill tree," the total set of stuff we're able to do. Back when RCT (and Doom before that) were written, we genuinely weren't sure if such things could be created, and their creation represented a novel step forward. The vibe in software feels like we're long past the stage of doing things like that, like we're not even attempting to do things like that. I can only think of two things in recent history: whatever strand of AI culminated in ChatGPT, which is genuinely impressive, and Bitcoin, which ostensibly was created by one guy.

My theory is not that individual genius accomplishes more than a group, but that whether a field is currently more suited for individual single-brain productivity or assembly-line cooperation is a signal of whether that field is nascent, at its peak, or in decline. I genuinely think software technology has not advanced in a long time. Computers got really fast, which allowed us to build a mountain of abstractions on top, and now you can throw together web apps, and there is no shortage of companies running around with that hammer and banging on everything. But the actual boundaries of what is possible with software have not moved in a while.

Most of the software nowadays (in addition to being terribly slow and broken, by the way) feels like stuff that doesn't actually need to exist. It doesn't advance the boundaries of technology or humanity's skill tree in any way. It's a "nice to have" — it might have some social value or make some business process more efficient or whatever — but no one looks at it and goes, wow, we couldn't do that before.

Someone is going to bring up AI and LLMs, and about that, I will just say that ChatGPT was a real accomplishment... but after that, I have not seen any use cases of LLMs that represent a genuine step forward. Like smart contracts, it's a solution in desperate search of a problem, a technology in search of a breakout app. You feel like there's just no way it doesn't have wide reaching implications, and everyone around you (especially VCs) talks about the "possibilities unlocked" — but two years in and we haven't seen a single actually interesting use case. (Again, of course they're being incorporated to optimize some business process or whatever. But who cares?)

Meanwhile, as far as the day to day reality of software engineering goes, if you work professionally as an engineer, your job is more or less wrangling microservices in one form or another. If you're at a big company this is probably literal, but even if you're at a startup the bigco transplants start doing microservice stuff basically on arrival, and a bunch of the "best practices" and frameworks and tools are meant to mimic microservices type thinking (making things more complicated rather than less).

As a final note, I grew up being a giant fan of YC and PG's essays, so I will make a comment about the latest batch of YC startups. It seems to me that a bunch of them basically exist to make some process more efficient. But then you wonder, why does that process need to exist in the first place? Like there was one startup helping you to optimize your AWS costs or something, but why is software written in such a way to begin with that you have all these microservices and towers of abstractions and untrackable infrastructure? Like you look at these startups solving a problem of solving a problem... and then you get to the root problem, and the whole thing is just a giant castle in the sky. I think this describes much of the motivating thrust of software today.

I know absolutely nothing about math, but... I'm thinking about the history of software, where back in the day you had all these amazing projects like RollerCoaster Tycoon basically being written by one guy. Then software engineering became modularized in a way that sounds kind of similar to what is described in the interview, and now you have hordes of people who churn out React for a living (like myself) and software engineering is now a giant assembly line and the productivity (or skill required) per individual has dropped to near zero.

I guess I have the impression that when fields are in their heyday, the best work is done by some genius fitting like a hundred things in one brain, and when that gets replaced by an assembly line, the field has basically stopped producing anything of real value. Anyone in math (or otherwise) want to tell me why that's completely wrong?

I've always heard "auth" to mean authentication and "perms" to mean authorization.

I dunno. On the one hand I hate “web dev” more than anyone. I think it has led to such an astronomical decline in software quality that if you described it to someone from the days when computers were 1000x slower, they straight up wouldn’t believe you.

That said… the article doesn’t really ring true to me. What he is saying about the complexity of each part of the stack (http, html/dom, css) is technically true, but that’s not really how it washes out in practice. This whole “CSS is a complex graphics engine!” “HTTP is a protocol you could write a whole dissertation about!” sounds like an argument being made by someone trying to make a rhetorical point about web. In practice for most of web dev you don’t need to understand the deep nuances of CSS or HTTP or whatever. Yes, there is a large breadth of material you have to learn but the depth you actually need in any one area is much less than the author is trying to imply.

And yes, web is trash, but for different reasons. In fact some of those reasons are the opposite of what the author is saying. He says that each part of the stack is so complex it should be a separate specialty. But the real problem is the very fact that things are so complex. Rather than accept that complexity and subdivide the field into different disciplines, we should get rid of all this unneeded complexity to begin with.

Why are financial crimes morally exempt in a way that, say, violent crime is not, even if the aggregate damage from the financial crime is greater? Unless you’re arguing that this isn’t possible?

What’s wrong with that argument? Doesn’t getting more money from the user mean that the user is choosing to pay more, which reveals their preference?

Do the cops “breaking procedure” know for certain if the accused are guilty? How can they?

Politicians know the electoral vote is what matters, so they adjust their campaign strategy to optimize for it.

Theoretically, after everything washes, the electoral vote is what the people want, because it reflects which of the two candidates, both of whom are optimizing intensely for the electoral vote, is able to get it.

Having an existing example showing that something difficult is possible causes everyone else to replicate it much faster, like how a bunch of people started running sub-4-minute miles after the first guy did it.

Thought experiment: what if you copied and restored the backup into two bodies, and both bodies were a state continuation of the original? Would the two existences be simultaneously the smae person? I think it would make more sense to say that at the moment of cloning the two bodies are separate consciousnesses with the same state.

In your analogy, if you copied the VM state onto two different host systems, I would think each host system would be a separate conscious experience. It's whatever being a host system is that generates consciousness, not the state itself.

Someday we may be able revive the brain itself by connecting it to a body, in which case you would experience falling asleep and waking back up.

I think the principle of 50 Stalins is at the heart of microservices adoption. [1] The philosophy and core argument of microservices inherently beget more and more microservices. If you work at a company that does microservices, there's no argumentation pathway available in the culture and protocol for you to reduce microservices, only to increase them. So the only people who get promos are the people who realize they should say, "10 microservices? How about 50 microservices?" Soon the whole company accelerates towards infinite microservices with every click of the ratchet, and then all of these stockholm syndromed people come out in waves and argue how microservices are not that bad— "you only need one meeting to discuss what would've previously been a function call!"

[1] https://sanerthanlasagna.wordpress.com/2016/02/01/50-stalins...

The biggest difference I’ve seen in how people learn is whether they learn things top down or bottom up. I generally prefer to just have the main idea or concept explained directly to me so that’s how I try to teach people things as well. Came as a shock to me when I realized lots of people want to go the other direction, seeing lots of examples and then later arriving at the general concept themselves.

> Splitting a system into subsystems allows each team to focus on their piece of the puzzle while minimizing the amount of peer-to-peer coordination.

This does not happen at all. When you break a system into subsystems, all the previous connections that get remapped to new connections between subsystems still need to happen, in order to solve the fundamental problem that the system solves — except now instead of just making the connection directly, there has to be a "cross-functional" meeting between teams and a complicated communication layer between the systems. And if somehow you find a breakdown that requires minimal connections between subsystems, then those connections wouldn't have existed in the original system either, and the N² problem doesn't exist.

The flaw in this point is, there are really only a handful of measures that actually matter: writing performant code, shipping quickly, delivering business requirements (really this is an official sounding way of saying "doing the actual thing the program needs to do"), and eliminating bugs.

The other things are just proxies for the real measures, that people made up, and in fact are often harmful to the main goal. Like "documenting code" and "writing tests" a lot of the time are just cargo culting to make people feel like they're being responsible and following "best practices" without actually improving the measures that matter. I think that the other unlisted metrics in your "every measure someone dreams up..." are likely to fall under this category.

There aren't an infinite number of possible measures like you're suggesting, there's a finite number and a rather small number at that. You can definitely be really good or really bad at quickly shipping performant bug-free code that does its job. The problem in this debate is that one side is completely ignoring one of these categories, and trying to claim that it's because they have to focus on the other categories, and that this is just an inevitable tradeoff, rather than that we lack the skill as an industry to do all of these things at an acceptable level. Being a good programmer may have more variables than being a good chess player, but I think the claim that there's no such thing as programming competence reductios to absurdum pretty quickly.

I don't think the implicit mental model of the "business requirements" argument is correct, and I will try to explain why.

To a first approximation, the reason modern software is slow isn't due to failure to optimize this algorithm or that code path, but rather the entire pancake stack of slow defaults — frameworks, runtimes, architectures, design patterns, etc. — where, before you even sit down and write a line of "business logic" code, or code that does something, you're already living inside a slow framework written in a slow language on top of a slow runtime inside a container with a server-client architecture where every RPC call is a JSON blob POSTed over HTTP or something. This is considered industry standard.

The "business requirements" guy is basically saying, dammit, I have to ship this thing by my friday deadline, I'm just going to pick the industry standard tools that let me write a few lines of code to do the thing I need it to do. Ok, but that's the tradeoff that he's making. He's deciding to pick up extremely slow tools for the sake of meeting his immediate deadline. That decision is producing unacceptable results.

It's not enough just to say people have different priorities. Selecting an appropriate point on multivariate system of tradeoffs is part of the skill of being a programmer. And if there's no point on the curve that delivers acceptable results — if, given a certain set of tools, it's not possible to ship quickly and deliver acceptable performance — then it's the responsibility of the programmer, the craftsman, to pick better tools, and improve his skills, to push the "production curve" outward, until he can meet all the requirements.

One example of this is how a large percentage of modern programmers don't really know how to program from first principles, and tell the computer to do precisely and only the thing it needs to do. Essentially they only know how to glue tools together. Then in their head they're like, well gee, given that skillset, I could either (1) spend a bunch of time optimizing "hot spots," writing crazy algorithms, heroically trying to fight through all that slowness... or I could just (2) deliver the business logic and call it a day. Then they call this "prioritizing business requirements." No, there's a third, alternative, better option, which is to use better tools, which might initially be harder and more time consuming and less ergonomic to use, and then learning to get good with those tools, putting in the practice, recognizing patterns, thinking faster over time, coding faster... all of this is part of what mastering the trade of programming is about.

At the end of the day, there is just an ethic of self improvement and craftsmanship that is totally missing from programming today, and it surfaces whenever this debate comes up.

That feels like a bit of an edge case. I mean, I take your point that you can definitely have no social skills and run around interrupting people's conversations and going "hey, did you know that animals are tortured every day?" and that would be you being a jerk. But I'm not talking about that.

Am I crazy? I feel like what I'm describing is a near universal phenomenon and everyone knows what I'm referring to/has experienced this. I'm talking about how in general, people just don't like people who are right all the time. People don't like criticism delivered bluntly even when it's correct, relevant and actionable. People don't want to hear things with implications that go against their moral values, or suggest that something they spent lots of time on was wasted, or reflect badly on themselves. There's that famous quote about how people don't want to hear things when their paycheck depends on them not hearing it. They don't like hearing those things even when they are true and directly related to them. I'm talking about those cases.

This might just be a silly semantics debate that boils down how you define responsibility. If your definition is like, there's a strategic, practical reality of what people are like, and responsibility is just working within that framework to get the goal you want, then sure, I agree with you.

I'm working with a separate definition of responsibility that's asking whose fault something is as a matter of principle. I disagree philosophically that the messenger of a truth is the primary cause of the emotions of the receiver as a reaction to that truth. In my experience, if we sit down and inspect those emotions and trace their root cause, an overwhelming proportion of it is the bad news itself, not the delivery of it. The delivery is just the easiest thing to latch onto in the moment.