tikhonj

This is one of the things I like with NixOS: it's easy enough to add new packages and patch existing ones that stuff like this can either live in the core nixpkgs repo or be managed through some community-supported overlay. (Great example of this is [nixos-hardware](https://github.com/nixos/nixos-hardware) which shares settings and fixes for specific laptop models and the like, or [emacs-overlay](https://github.com/nix-community/emacs-overlay) which has a bunch of extra Emacs-specific stuff that would not belong in the core repo.)

Why not put the content from the md file in the code as documentation?

Ideally, the code can actually help you structure that information. I've written a bunch of Haskell and OCaml like this, where the types in each module let me structure my documentation in a way that is actually easier for people—and maybe also LLMs—to track. As a bonus, it makes it more natural to keep the two in sync.

You can never understand complex adaptive systems to anywhere near 95%, and leaders believing that they can—that the map is the territory—leads to some pretty bad dynamics.

You can also exercise your voice by... talking. That might mean trying to convince leadership, it might mean trying to coordinate a bunch of people who agree with you but don't want to act on their own, or, who knows, it might mean something else. But there are quite a lot of things you can do that are short of threatening to quit or simply leaving.

(And sometimes just leaving really is the best step!)

Part of the value is to help the people stuck in bad cultures realize that it's the culture that's broken, not them. It's easy to lose sight of that! If you can recognize it, it's easier to do something about it whether that's changing your behavior and expectations, trying to change the culture bottom up or leaving altogether.

> You couldn't just put something down, and walk away.

This seems like a pretty big problem. A lot of tasks should be put down. And, on the flip side, you absolutely need room for people to do things without needing to publicly justify themselves ahead of time.

I've been in places that try to approximate this sort of tracking, and I never felt like they were free of blame, I felt like blame was the default. There's no need to play the "blame game" if the whole system makes people feel blamed automatically!

That said, I've found a variant of this works: give people ownership of general areas, with well-defined but permeable boundaries. You only need to track the details at the interaction points, and only a subset of the work has to happen at those points. This also gives you a lot more room for overlap between people and teams; an interaction point naturally has at least two "owners" and, in a pinch, either side can come up with a (possibly sub-optimal) solution on their own. Or people can shuffle interaction points around—stop depending on one thing, move to some alternative—to work around problems.

There are a lot of known problems... but there are also a lot of unknown, or at least unrecognized problems. Some of those unrecognized problems are going to be more useful and higher-leverage than recognized problems. The same "being a sponge" approach still helps.

I had some typing classes in middle school but they never stuck. The only reason I became a reasonably fast and confident typer—which ended up being amazing for everything from work (emails and Slack more than code!) to HN to writing a lot on Quora—was Type Racer :P

It's amazing how much easier gamification can make it for me to stick with something.

The exams aren't the thing that matter, they're an experiment to measure the thing that matters. Which, presumably, still matters at work!

I was in the same position in high school and college and then—over a decade later!—I got diagnosed with ADHD and everything made a lot more sense. Just having the diagnosis on its own made me happier because it let me understand what was happening, get some coping strategies and feel less guilty about it. (And, later on, getting treated helped even more.)

I mean, in a lot of these cases people take those jobs because they're able to work remotely initially... and then get hit with an inflexible, top-down RTO mandate once they've settled into the role.

Too bad so many companies insist on top-down management practices that actively make this harder: planning and tracking work in individually owned tickets, individual stack-ranked performance evaluations, "productivity" metrics that don't account for collaboration or shared learning...

(This is something I've repeatedly noticed in discussions about getting people in-office, and about open office plans vs individual offices: the same managers who push these changes through in the name of "collaboration" create a bunch of other management processes that strongly disincentivize collaborative work.)

But in environments where I've been able to do this effectively, it's always been great, far better than going of totally on my own!

Exactly the same thing happens with in-office work. I've certainly had that experience! But it's hard to talk about because in-person work is the "default", and it feels like if you have problems with that it's a sign of problems with you.

(Not to mention that, in both contexts, it's very hard to pull apart being remote vs in-office from other aspects of the work and culture.)

If I get lucky in IPO land I'll have my eye on a Jaeger-LeCoultre watch with a meteorite dial, so I guess things have not changed all that much in the last 3500 years :P

My personal view is that programming languages are amazing tools for understanding. Some more than others, but even the worst—the most verbose, the lowest level—are better than they have any right to be.

So I think that we are leaving a lot of power on the table if we treat generated code exclusively as something to understand, rather than something to understand with. The techniques Geoffrey presents are great, but they should come alongside approaches that use code itself to develop and articulate conceptual models.

Bloomberg is big enough that different aspects of the system are going to be absolutely key for substantial subsets of its customers.

It's a sign of how much distribution matters to VCs. Whether that is enough in the medium- and long-term is unclear. I'm a bit skeptical but not very confident either way... which is part of the reason I am not a VC!

I mean, in this case, it's 2^{0.6039n}, and the n is pretty important. I can see why trying to automatically detect cases like this would run into a bunch of wrong behaviors (either styling text that was not meant to be math notation, or parsing the implied math notation incorrectly).

Everybody saying "coding was never the hard part" is really telling on themselves. Coding was never "hard" because most organizations were absolutely unwilling to take on any technical work that was hard. That tells us about business strategy and culture rather than anything about the fundamentals of programming or technical work.

The real conclusion is that programming is such a high-leverage activity that even technically trivial, low-quality programming is immensely valuable economically. That's not going anywhere, but maybe LLMs are going to make it all that much cheaper. (Which is mostly great! But I really don't look forward to the painful debugging and maintenance that reams of shit code will push down on programmers.)

But also, there still is a ton of programming that is fundamentally difficult. That's not going anywhere either. And LLMs are useful there too, but they're currently nowhere near replacing the expertise needed to do novel and non-trivial technical work.

In an ideal world, making mediocre code cheaper should leave more room for taking on harder technical challenges. In reality, this has always been dictated far more by non-technical factors—culture, leadership, trust, risk tolerance...—than by anything intrinsic to programming. But, at least for now, we can use the LLM hype to motivate the kind of deeper technical work that always made sense but was too uncertain or too open-ended or too long-term for non-technical leadership.

And we should also drop the bullshit "code was never the hard part" framing.

The main thing that Bonsai gets you is a nice programming model for making your UIs interactive. If you're mostly producing static reports (with maybe some basic interactive visualization widgets or something), it will not get you much over generating some variant on HTML + JS.

It makes more sense for applications where you have complex interactive logic in the UI, with a lot of different components that need to control and display some shared state.

notion isn't too far off

wave failed for weird google organizational reasons far more than anything inherent to the product or tech

> A few months post-acquisition, he got fired for an allegedly silly reason, but my intuition is that he was coasting hard and couldn’t focus at all because of home office and lifestyle creep.

This seems like a pretty dubious conclusion to make from the outside. There are a lot of reasons somebody would get fired after an acquisition. Hell, even if he was coasting, an acquisition followed by a rapid change in environment and culture can cause somebody to lose motivation for a wide range of reasons. Blaming this on "lifetstyle creep" is rather premature and, frankly, pretty judgemental or moralistic.

This is downstream of a pretty frustrating belief I've seen repeatedly in the tech industry: that whether a person is "motivated" or "hard working" is some kind of inherent quasi-moral characteristic of the person, rather than something substantially affected by environment. But hey, it's much easier to blame individuals and lean on the perf review process than it is to change organizational culture or leadership!

"Everything is a trade-off" assumes you're on the Pareto frontier.

Go is... very much not on the Pareto frontier of programming language design.

A pretty big part of the reason we didn't switch earlier is that most people—certainly most non-technical leaders, but also a lot of engineers—don't value correctness or security enough. We didn't have good alternatives until recently because we did not, collectively, invest in developing these alternatives.

One surprising thing is that, in the grand scheme of things, developing an alternative like Rust is not that expensive. It takes something like a small team a few years. Maybe a person-decade of effort to get to a viable point? Maybe two, whatever. The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects and internal dysfunction every year.

Of course, even once we have an alternative, the switching costs are high. And the barriers are far more social, organizational and political than they are technical. But even so, moving to alternatives incrementally has been viable for decades. And hey, if we include moves to garbage collected languages, we have been moving quite a bit... but we could have been moving more. It was only a matter of will and, upstream of that, cultural change.

So really, the problem isn't that people complain too much, it's that they don't complain enough :)

I've already seen at least one promising experiment about how static checking helps LLMs: https://arxiv.org/abs/2606.01522

Key parts of the abstract:

> This raises a question the programming-language community has not previously had reason to ask: should error-message detail be calibrated differently for AI agents than for humans?

> We investigate this question through a controlled experiment using Shplait, an ML-style statically typed language. We construct a suite of programs containing a single deliberate type error each, and measure how often an AI agent repairs them under ablation: a detailed error context using the unification stack; a proximate error location; a minimal type error; and a dynamic (test suite) error only. An automated oracle uses a test suite to classify each repair attempt as a type error, semantically incorrect, or semantically correct.

> We find concrete evidence that more detailed error messages generally improve an agent's ability to fix type errors. We also find that the presence of a type system appears to help more than only test suite failure reports.

If all you do is replace the recursion in that example with one (or more) loops with mutable indexes, chances are the code will get worse.

Well, maybe it is... but then the PM never prioritizes testing or fixing the problem. They're not intentionally trying to get more people to accept cookies, it's just that there are always more important features to build and fires to fight, and fixing the cookie banner won't move any of the metrics executives are breathing down their necks about, and it won't look good in the perf packet...

But of course, designing the system that pushes people to make this sort of decision was absolutely intentional.

So even when it's incompetence, it's still malicious, just in a way that obscures the explicit decision-making that led to the result.

I mean, if you wrote an article like "the whole premise of disallowing people to spray-paint your house is daft"...

The real point isn't that they're "obligated" to allow AI-generated comments, but that they're being something of a hypocrite.

The "data inputs" were also, very much, somebody's "value added" IP.

We're talking about things like text people wrote, not some kind of raw data floating out in the ether.

There are still a lot of smaller totally independent projects like this. I suspect that there are more—far more—just-for-fun projects today than in past decades in absolute terms.

I love Haskell, I've spent a lot of time in the general area around functional programming, types, proofs and PL, and there is still a vibrant community with lots of amazing non-commercial projects there. I'm sure the same is true in other areas of the programming world.

Ditto for the Emacs world. Emacs and its package ecosystem are amazing, better than they've ever been, and ≈entirely driven by non-commercial work.

Same for a big chunk of NixOS, although there's also been some real commercial investment there now.

I never really thought about it before writing this comment, but, except for games, most of the software I use and care about is primarily community-driven rather than commercial. And it's absolutely great.

Despite smaller communities and low monetary investment, a remarkable number of things about Haskell and Emacs and Nix are simply better than any commercial alternative, full stop.

The problem isn't that this kind of software has died—it's thriving more than ever—but just that the rest of the field has grown around it even faster. Programming is so commercially valuable that there has been a ton of investment in it and now we have millions of people for whom it's just a career, and trillions of dollars pouring into companies powered, primarily, by programming. It's a wild time. The overall feel of the field is definitely different now, but you can still find classic hacker enclaves. You just have to cut through the noise first.