I am interested in programming languages, functional programming (especially Haskell), domain-specific languages, static analysis and program synthesis.
Working on program analysis at Semgrep.
I also worked on supply chain optimization at Target for several years, and co-authored a textbook on reinforcement learning based on that experience.
contact: http://jelv.is, tikhon@jelv.is
- tikhonjStruggling with poorly organized docs seems entirely like incidental complexity to me. Good learning resources can be both faster and better pedagogically. (How good today's LLM-based chat tools are is a totally separate question.)
- You're significantly underestimating fully-loaded cost per person + other expenses. An engineer making a $200k salary is going to cost the company something like $300k, and there are some additional fixed overheads. And $200k is quite a bit less than your competitors are paying.
So you're looking at something more like 150 employees total of which <100 are going to be pure engineers, and that's stretching your budget and operations pretty aggressively while also fighting an uphill battle for recruiting skilled and experienced engineers. (And browser development definitely needs a core of experienced engineers with a relatively niche set of skills!)
- If that's all you need, there are free alternatives that should be more than sufficient today.
- > If it was as great as its advocates say, surely it would have taken over the world by now.
That is a big assumption about the way popularity contests work.
- That's because embarrassingly bad writing is useless, while embarrassingly bad code can still make the computer do (roughly) the right thing and lets you tick off a Jira ticket. So we end up having way more room for awful code than for awful prose.
Reading good code can be a better way to learn about something than reading prose. Writing code like that takes some real skill and insight, just like writing clear explanations.
- The overall trend has been the opposite though, hasn't it? People used to buy a new phone (or new laptop/etc) every couple of years because the underlying tech was improving so quickly, but now that the improvements have slowed down, they're holding onto their devices for longer.
There was an article[1] going around about that recently, and I'm sure there are more, but it's also a trend I've seen first-hand. (I don't particularly care for the article's framing, I'm just linking to it to illustrate the underlying data.)
[1]: https://www.cnbc.com/2025/11/23/how-device-hoarding-by-ameri...
- There's a high switching cost with substantial information asymmetry. Good places are hard to find in some absolute sense and it's hard to evaluate whether a new team is actually going to be good or not. And even if you do find a good team, there's no guarantee it'll last past the next reorg.
- All of the pizza examples are about reducing cost. The argument about dating apps is about increasing retention. The dynamics are qualitatively different.
The argument with pizza is more like "people like salty, fatty food, so pizza places are incentivized to make their pizza less healthy so that people come back more often"... which is exactly what happens!
So why doesn't a legitimately healthy restaurant come along and take the whole market? It's partly because restaurants aren't just in the business of selling (healthy) food: it's also about convenience and satisfaction and experience. More importantly, that just doesn't fit with how people largely make day-to-day decisions.
The same thing happens with dating apps. People get drawn in for all sorts of reasons that don't necessarily map to getting married, even if finding a long-term relationship is explicitly their goal. Tinder competes with Tiktok more than it competes with other dating apps.
The other problem is that making a really effective dating app is just hard. It's fundamentally difficult to help people find compatible partners, especially without in-person contact. That's compounded by cultural and demographic issues. It doesn't matter how well your app is designed when there's a massive imbalance in genders!
- In the world of human-readable data formats (ie not programming languages), the best one I ever used was Jane Street's sexplib[1] s-expression format.
It was concise and expressive. There was a direct way to describe variants (types with multiple constructors), which is always awkward in JSON, but the format was still surprisingly low-noise for reading and editing by hand. I remember you could even use it as a lightweight markup format:
(The format leaves the interpretation of things like (em ...) up to you; you could use it as a slightly more verbose Markdown, but you could also use it to structure readable text with other sorts of metadata instead.)(here is some text with (em formatting) information)And, unlike certain other formats I won't name, it has comments!
It also helps that Emacs with Paredit makes editing s-expressions flow. The tool doesn't need to know anything about the sexplib format specifically; just relying on basic s-expression structure gives us fluid but simple structural editing.
I am constantly sad that nobody else uses this sort of format, and I have to deal with a mixture of JSON, YAML, TOML and other ad-hoc formats instead.
- > Imagine you are driving a car.
Rally races sometimes have two people, a navigator and a driver. The dynamic between them is absolutely fascinating. I recommend watching some videos because, before I saw it, I would not have imagined that driving a car like that would have been possible much less effective.
- There is a lot of value in reducing risk, variance and up-front costs for artists. Enough value that, to somebody barely scraping by, it makes the difference between a show/exhibition/etc being doable and not.
It also changes the distribution. I'd say it's a net positive if a bunch of artists get enough money to live on their art rather than the vast majority not making enough and a tiny fraction making the most. It's just a matter of correcting for structural factors that otherwise push towards an exponential distribution of income.
- It's used here as a specific term from Seeing like a State[1][2], which is one of those books that got popular with a specific set of online tech folks. "Legibitility" in that particular sense is a very useful concept with no other convenient word, so I'm not too surprised it caught on.
[1]: https://en.wikipedia.org/wiki/Seeing_Like_a_State
[2]: available free to read online: https://files.libcom.org/files/Seeing%20Like%20a%20State%20-...
- Category theory gives us a nice, high-level set of conceptual tools to try to understand and generalize over things that are hard to connect otherwise. Some people find that useful directly, other people just enjoy it for its own sake, or even for aesthetic reasons. (I think all three are totally reasonable!)
At the same time, it's actually rather more accessible than most other areas of pure math—at least at the level that people talk about it online. Basic category theory can be hard to learn because it's so abstract but, unlike almost any other are of math from the 20th century onwards, it has almost no hard prerequisites. You can reasonably learn about categories, functors, natural transformations and so on without needing a graduate degree's worth of math courses first. You might not understand the most common examples mathematicians use to illustrate category theory ideas—but it's such a general framework that it isn't hard to find alternate examples from computer science or physics or whatever else you already know. In fact, I expect most of the articles that get talked about here do exactly that: illustrate category theory ideas with CS/programming examples that folks on HN find relevant and accessible.
- I've also worked on some relatively senior/high-trust teams using roughly scrum-style processes, and the experience was decidedly worse. Even with the best setup and intentions in the world, the process still makes focusing on small, individual tasks the path of least resistance, which leads to less collaborative, more short-term focused work with less flexibility and ownership.
A sufficiently strong team can make even a bad process work out okay, but that just means they're strong enough to compensate for the process, not that the process had any latent merit.
- Working on somebody else's goals, and being systematically micromanaged are two very different things.
- My experience has been 100% the opposite. Daily public status check-ins, top-down decisions, every work interaction mediated through artificial structure? The points are made up, the deadlines are obviously fake, but everyone acts as if they are real? Except when they're not?
That, on its own, would make it clear the environment wasn't built for me.
The fact that the environment was very obviously built for management—for information to flow up so that decisions can flow down—but also that nobody is willing to acknowledge that? That just makes it even clearer.
I've worked in an environment that did feel like it was built for me, and it was pretty much the opposite of scrum/agile/etc. I had real trust with a clearly defined area of ownership. I was responsible for managing the interfaces and interaction points around my area and, occasionally, for real deadlines (with real context!), not a slog of fake short-term deadlines that exist just to create pressure. I didn't have to break down or justify my work in terms of bite-sized tasks that could roll up into somebody's spreadsheet.
And the best part? We got more done, faster, than conventionally managed teams.
If the culture hadn't been totally ruined by a reorg, I'd still be there. I'm still sad I haven't been able to find anything similar since. But, having experience that, I am only more confident that scrum et al are absolutely not built for me.
- Sure, but there's a gap between being poor and being wealthy. $15 million is a lot more than most people have and it's certainly enough to be comfortable and not have to worry about money, but it's still categorically different from having the sort of money that gives you institutional power.
- For whatever reason, the Berkeley campus maps[1] have East at the top. And, for whatever reason, it always felt natural—probably because it matches the terrain (East is up-hill).
It's still surprising how much that has colored my mental orientation in Berkeley even 15 years later. I now consciously know to correct for it, but still think of campus "oriented" in that direction. For years I had to really think about it to remember that up-hill was not, in fact, North.
[1]: https://www.berkeley.edu/wp-content/uploads/2025/06/campus-m...
[1]: https://www.berkeley.edu/wp-content/uploads/2025/06/campus-m...
- > You have to remember EVERYTHING. Only then you can perform the cognitive tasks necessary to perform meaningful knowledge work.
If humans did not have any facilities for abstraction, sure. But then "knowledge work" would be impossible.
You need to remember some set of concrete facts for knowledge work, sure, but it's just one—necessary but small—component. More important than specific factual knowledge, you need two things: strong conceptual models for whatever you're doing and tacit knowledge.
You need to know some facts to build up strong conceptual models but you don't need to remember them all at once and, once you've built up that strong conceptual understanding, you'll need specifics even less.
Tacit knowledge—which, in knowledge work, manifests as intuition and taste—can only be built up through experience and feedback. Again, you need some specific knowledge to get started but, once you have some real experience, factual knowledge stops being a bottleneck.
Once you've built up a strong foundation, the way you learn and retain facts changes too. Memorization might be a powerful tool to get you started but, once you've made some real progress, it becomes unnecessary if not counterproductive. You can pick bits of info up as you go along and slot them into your existing mental frameworks.
My theory is that the folks who hate memorization are the ones who were able to force their way through the beginner stages of whatever they were doing without dull rote memorization, and then, once there, really do not need it any more. Which would at least partly explain why there are such vehement disagreements about whether memorization is crucial or not.
- Performative hours are, fundamentally, a symptom of a lack of trust. A lack of trust in others but also a lack of trust in yourself.
Not trust others is pretty obvious: leaders push for long hours because they don't trust people to be intrinsically motivated or to work in the most effective way for them. If you assume people are inherently unmotivated and lazy, well, trackable hours and artificial pressure seem like the obvious consequence.
But it's also a sign of not trusting yourself. Being judged on outcomes—never fully under your control—is scary. Being judged on anything fuzzy or arguable—taste, experience, skill, insight—is scary. If you're the sort of person who is content to "grind", the best way to win competitions is to turn them into grinding competitions. You can't be confident that you are more skilled, more intelligent or have better taste than others, but you can always just "grind" that extra hour. For a certain personality, time spent is by far the easiest metric to control.
If you grow up constantly being praised for how "hard" (read "long") you work, constantly out-competing people by doing more rather than better, the inherent value of "hard" work over everything becomes fundamentally ingrained in your personal story. And, unfortunately, our culture tends to put those people into positions of power, so this tendency gets reinforced and propagated.
Taking a step back, doing something good with less effort ought to be more impressive than doing it with more effort. That's what real potential looks like.
More importantly, even if working more hours purely increased your effectiveness and productivity—and we absolutely know that it doesn't—it would still be a weak form of leverage. Maybe you can work 2× the hours, but you can never work 10x. On the other hand, with taste and experience, you can absolutely come up with a 10× better design, or a 10× better understanding of what you're doing, and, unlike long hours, those 10× advantages compound.
If you trusted your own taste and creativity to give you the leverage you need, you wouldn't work ridiculous hours because you'd know it's counterproductive.
But when you don't, long hours are an easy, socially accepted fallback.