dkarl

I kind of get what they're thinking in trying to make sure all engineers use AI. For myself, and for the engineers working with me, I saw everyone go through an initial aversion and resistance to AI, and then an instant productivity boost when we started using them. So there's definitely a good reason to get everybody to start using AI. You don't want a good engineer resisting AI indefinitely if you know it will make them more productive.

Incentivizing people who are already using AI to use as many tokens as possible does seem a little crazy, though.

Little tidbit that isn't mentioned in the article: he was a consultant on the film Quest for Fire and developed movement patterns and gestures for the actors.

In the business of apparel, I think this is a natural consequence of high-end buyers turning their noses up at long-lived brands, and working to differentiate themselves from mainstream middle-class buyers. It's a revolt against modernism making more and more goods accessible to people outside the economic and cultural elite.

If you're fancy, what do you do when mass production and the internet make the markers of fanciness accessible to the very people you're trying to be fancier than? For one, you stigmatize mass production and elevate artisanal handmade goods. Those are inherently impossible to democratize. Another thing you can do is replace the appreciation of quality with the act of discovery as proof of elevated taste. Make taste a moving target, so the dirty unwashed masses are always a step behind.

Brands like Brooks Brothers or Eddie Bauer have no place in this system. The best the masses can do to imitate the elites is buy cheap fast fashion from brands that go viral and don't live long enough for anyone to know their quality before they're gone.

Flippant answer: in the U.S., in your twenties, you have no spare space, and visiting friends sleep on your couch. In your forties, you have a guest bedroom, and visiting friends stay at a hotel.

Possibly more accurate answer: it depends on what kind of housing people live in, if they have kids, and if they work at home. Most residential houses were built for couples with children, so if someone owns a house and is single and/or childless, they likely have spare bedrooms that serve as a home offices, hobby spaces, or guest bedrooms. People living in apartments usually don't pay for more space than required for their daily needs.

I don't think that's the way you're supposed to read it? I think you're supposed to read it as, the trendy extremes tell you something about a place, even if the details are silly and ephemeral. People with no filter, no shame, no interest in correctness or consequences, and no pole star except trends are like a cartoon guide to the trends and the mentality driving them.

I think the author would agree with most of what you wrote.

I interpret YAGNI to mean that you shouldn't invest extra work and extra code complexity to create capabilities that you don't need.

In this case, I feel like using the filesystem directly is the opposite: doing much more difficult programming and creating more complex code, in order to do less.

It depends on how you weigh the cost of the additional dependency that lets you write simpler code, of course, but I think in this case adding a SQLite dependency is a lower long-term maintenance burden than writing code to make atomic file writes.

The original post isn't about simplicity, though. It's about performance. They claim they achieved better performance by using the filesystem directly, which could (if they really need the extra performance) justify the extra challenge and code complexity.

Honestly, at this point, if I had a design that required making atomic changes to files, I'd redo the design to use SQLite. The other way around sounds crazy to me.

"Why use spray paint when you can achieve the same effect by ejecting paint from your mouth in a uniform high-velocity mist?" If you happen to have developed that particular weird skill, by all means use it, but if you haven't, don't start now.

That probably sounds soft and lazy. I should learn to use my operating system's filesystem APIs safely. It would make me a better person. But honestly, I think that's a very niche skill these days, and you should consider if you really need it now and if you'll ever benefit from it in the future.

Also, even if you do it right, the people who inherit your code probably won't develop the same skills. They'll tell their boss it's impossibly dangerous to make any changes, and they'll replace it with a database.

Advice like this turns almost everybody's normal state into a disorder.

"Go to sleep only when you are very tired" is a child's approach to sleep, it's what we all want to do, and by adulthood we learn that it's counterproductive. But we still want it so much that we regularly test it and are reminded why we don't operate that way.

It reminds me of the intuitive eating folks who say, "Ignore standard diet advice, just listen to your body and feed it what it knows you need," but then when you overeat, they say, "You aren't listening properly, you aren't in tune with your body." Then if you ask, "How will I know when I'm in tune with my body and listening to it properly?" they say, "When what it asks for matches standard diet advice."

If my Oura ring can be trusted, alcohol doesn't interfere with my total amount of sleep or my REM sleep, but it reduces my deep sleep drastically and can even result in me getting zero deep sleep, which hasn't happened a single time without alcohol.

Honestly, if I could quit my job for six months and work in a codebase like yours, I'm extremely curious what I could accomplish with AI.

We have a codebase at work that was "stuck." We've consistently done minor library upgrades, but no major upgrades in several years, and was recognized as a major piece of technical debt / minor disaster for almost two years, in that we urgently needed to dedicate an engineer to it for a month or more to bring it up to date. We also suspected that framework upgrades would improve performance enough to save us a little bit in operating costs. I got curious, created a branch, and threw Claude at it. Claude knocked it out in a couple of days while I mostly worked on other things. Then we dedicated several engineer days to doing extra manual testing. Done and deployed. Now we're ready to experiment with giving it less resources to see if the performance improvement holds up in practice.

This codebase was only about 200k lines of code, so probably smaller than yours. Really curious how it would go with a larger codebase.

EDIT: Claude may only have taken a couple of days because I was only checking in occasionally to give it further instructions. I don't know how fast it would have been with my complete attention.

You couldn't go far on those early Prius batteries. I had a circa-2009 Prius and semi-intentionally ran out of gas to see what happened. I was able to drive a couple of miles to a gas station, but the battery was depleting extremely quickly, and I doubt it would have lasted ten minutes.

These interactions really don't get the testing they need.

When they aren't designed, how do you know how to test?

Over the weekend, I was directed to file a police report with a chatbot and could not complete it because it was asking for information that did not exist and did not apply to my case.

(I'm sure somebody is going to say that this can be solved by having LLMs role play as victims and have an LLM observe and decide what's a failing test case and what isn't.)

This is exactly it. That's why the glasses have the same basic form (stem, bowl, and tapered rim) as wine glasses and snifters. The liquid sits in the bowl, and the aroma is captured in the empty space between the liquid and the rim.

People see lower property taxes as a silver lining for short-term swings in the market, but I don't know anybody who thinks this is a short-term swing that they can ride out.

Nobody is happy about their property values going down long term. It exposes them to the risk of a big loss if they're forced to sell because of events in their life.

I guess what I mean by that is that Rob Pike was obviously aware that his rules were not as catchy and pithy as the aphorisms he credited, and his only reason for writing his rules was to improve on them by making them more explicit and less prone to user error. But presenting his versions alongside the more catchy ones means that every time people read them, the catchy ones distract attention and remain more memorable than the improved versions.

I think it's important to think about architectural and domain bounds on problems and check if the big-O-optimal algorithm ever comes out on top. I remember Bjarne Stroustrup did a lecture where he compared a reasonably-implemented big-O-optimal algorithm on linked lists to a less optimal algorithm using arrays, and he used his laptop to test at what data size the big-O-optimal algorithm started to beat the less optimal algorithm. What he found was that the less optimal algorithm beat the big-O-optimal algorithm for every dataset he could process on the laptop. In that case, architectural bounds meant that the big-O-optimal algorithm was strictly worse. That was an extreme case, but it shows the value of testing.

Domain bounds can be dangerous to rely on, but not always. For example, the number of U.S. states is unlikely to change significantly in the lifetime of your codebase.

Anecdotally, what we found in Austin was a combination of two factors:

First, awareness of the futility and selfishness of "growth elsewhere" as a solution is much higher in younger people — and by younger, I mean currently under fifty. Generational turnover in Austin had been eating away at the NIMBY majority, and conversations about housing in Austin have long been polarized more by age than by left/right political sentiment. There's a caricature, with a strong vein of truth, of the old Austin leftist who has Mao's little red book on their shelves and thinks apartment buildings are an abomination, and Austinites of that generation are experiencing mortality. At the same time, younger people are adopting more and more urbanist mindsets compared to their parents.

However, I think a much much bigger factor was the influx of younger people, especially young people with experience of larger cities, diluting the votes of the older NIMBYs. Austin has been shaped by growth for half a century, but its "discovery" in the 2000s and very brief status as a darling of coastal hipsters (remember that term?) has had a lasting effect on Austin's popularity and its demographics. It's been twenty years since it was the "it" place for Brooklynites to visit, but in that twenty years, it's had a lot of exposure for young urban dwellers, and some of them discovered they liked it and moved here, bringing their comfort with dense living and their appreciation that growth can bring a lot of positives.

Personally, every homeowner I know in Austin has seen their houses depreciate significantly this decade, and I don't think it changed a single person's mind about Austin's housing policy. People who opposed the reforms are bitter about the outcome, and people who supported the reforms say it sucks for us personally, but it's what we set out to accomplish, and we're glad that it worked.

I think it's fine and generous that he credited these rules to the better-known aphorisms that inspired them, but I think his versions are better, they deserve to be presented by themselves, instead of alongside the mental clickbait of the classic aphorisms. They preserve important context that was lost when the better-known versions were ripped out of their original texts.

For example, I've often heard "premature optimization is the root of all evil" invoked to support opposite sides of the same argument. Pike's rules are much clearer and harder to interpret creatively.

Also, it's amusing that you don't hear this anymore:

> Rule 5 is often shortened to "write stupid code that uses smart objects".

In context, this clearly means that if you invest enough mental work in designing your data structures, it's easy to write simple code to solve your problem. But interpreted through an OO mindset, this could be seen as encouraging one of the classic noob mistakes of the heyday of OO: believing that your code could be as complex as you wanted, without cost, as long as you hid the complicated bits inside member methods on your objects. I'm guessing that "write stupid code that uses smart objects" was a snappy bit of wisdom in the pre-OO days and was discarded as dangerous when the context of OO created a new and harmful way of interpreting it.

The other reasons given make sense to me, but I bet there is also some psychological benefit in having a regularly scheduled escape from home, and having a guilt-free excuse for it built in, which partly compensates for being forced to come in a few days a week. The contrast makes it easier to appreciate the company of your spouse and probably makes child-rearing seem less oppressive. People theoretically could manage this without work imposing it on them, but in practice, having to make and justify the choice creates stress.

My degree is in math, I love Dijkstra, and I think a lot of my colleagues have often created more work than necessary for themselves by treating pieces of code empirically when they could have got a more precise understanding by spending an hour reading it carefully.

However, I think the most fascinating thing about Dijkstra is how wrong he turned out to be in his prediction that an empirical approach would not scale.

I suspect that approaching programming like Dijkstra might have paid off long-term, but it was rarely a good deal in the short term, both for bad reasons (the empirical approach is a quicker and cheaper way to create buggy software that we can sell and claim as achievements on our performance reviews) and valid reasons (the unreliability of humans and hardware ultimately forces us to approach real computer systems, which are always a composite of hardware, software, and humans, empirically anyway.)

Bullshit is so dangerous because it could mean something. That VP could mean, it's time to look beyond the set of mature technologies we've been considering and look at newer technologies that we would normally ignore because they come with risks and rough edges and higher cost of ownership.

So it might be a substantive decision that affects how everybody in the room will do their jobs going forward. Or it could be a random stream of words chosen because they sound impressive, which everyone will nod respectfully at and then ignore. And like an LLM, he might have made it into his current position without needing to know the difference.

Most anime is either a guilty pleasure or a guilty displeasure for me. The stuff I like, I feel embarrassed of the part of me that likes it, and I feel embarrassed about what I'm willing to overlook to enjoy it. Then the stuff I don't like, I feel closed-minded about it, like what's wrong with me that I'm too stuffy to enjoy it or too dumb to get it. But I don't have friends or acquaintances who are into it, so it never comes up with other people, and I generally don't think about it.

Yeah, it took me a second, too. By "gaps" they mean numbers that can't be represented in a given construction. So irrational numbers are "gaps" in the rational numbers, and transcendental numbers are "gaps" in the algebraic numbers. Not the best spatial metaphor.

I just don't understand why this was disturbing. Prior to the construction of the reals, the existence of irrational and transcendental numbers was disturbing, because they showed that previous constructions (rational numbers and algebraic numbers) were incomplete. If those gaps were disturbing, a construction without gaps should have been satisfying, reassuring, a resolution of tension. Was there some philosophical or theological theory that required the existence of gaps, that claimed that a complete construction of the number line was mathematically impossible, because of some attribute of God or the cosmos?

I should have been more specific; I understand why it was a mathematical breakthrough. What I don't understand is why it would have triggered some kind of psychological horror or philosophical crisis. It was a new way of understanding numbers, but it didn't reveal numbers to be acting any differently than we had always assumed.

If anything, it seems like it would have been comforting to finally have mathematical constructions of the real numbers. It had been disturbing that our previous attempts, the rational and algebraic numbers, were known to be insufficient. The construction of the reals finally succeeded where previous attempts had failed.

We've known since Zeno that all of our ways of visualizing infinity in finite terms are incomplete and provably incorrect, despite being unavoidable in human thinking. In other words, we knew the "gaps" reflected incomplete reasoning, not real emptiness between "consecutive" numbers. If Dedekind and Cantor only changed how we visualize infinity, I don't understand why it would cause a stir.

> This method created a new sort of infinity that mathematicians were unfamiliar with, and it was vastly larger

I understand that the construction of the reals paved the way for the later revolutionary (and possibly disturbing, for people with strongly held philosophical beliefs about infinity) discovery that one infinity could be larger than another. But in the narrative laid out by the article, that comes later, and to me it's clear (unless I misread it) that the part I quoted is about the construction of the reals, before they worked out ways to compare the cardinality of the reals to the cardinality of the integers and the rationals.

> In their 1872 papers, though, Cantor and Dedekind had found a way to construct a number line that was complete. No matter how much you zoomed in on any given stretch of it, it remained an unbroken expanse of infinitely many real numbers, continuously linked.

> Suddenly, the monstrosity of infinity, long feared by mathematicians, could no longer be relegated to some unreachable part of the number line. It hid within its every crevice.

I'm vaguely familiar with some of the mathematics, but I have no idea what this is trying to say. The infinity of the rational numbers had been known a thousand years prior by the Greeks, including by Zeno whom the article already mentioned. The Greeks also knew that some quantities could not be expressed as rational numbers.

I would assume the density of irrational numbers was already known as well? Give x < y, it's easy to construct x + (y-x)(sqrt(2))/2.

I don't get what "suddenly" became apparent.

Application design is still a challenge. I had Monday off and vibe-coded up an app that I've been wanting to use for years. The thing is, I can tell it's going to be challenging to make it something sticky that I actually use.

Which makes sense. The reason I wanted to make this app is that there are two very popular paid apps in the same category that I use every day that don't quite feel the way I want them to. It'll be easy to fix the little annoyances and missing features, but there's a feeling that's missing from them as well. I don't think it's wrong to say that I'm put off by a lack of taste, at least according to my taste. I don't know if I can do better, but I'm looking forward to trying, and I love that Claude makes me fast enough that the project has finally tipped from "I'd love to tackle this, but I know it's too big for me" (which is what I've been thinking for the last 5-10 years) to "I can make a credible attempt at this."

> You shouldn't be able to use AI or automation as the decider to ban someone from your business/service

That would mean dooming companies to lose the arms race against fraud and spam. If they don't use automation to suspend accounts, their platforms will drown in junk. There's no way human reviewers can keep up with bots that spam forums and marketplaces with fraudulent accounts.

Instead of dictating the means, we should hold companies accountable for everything they do, regardless of whether they use automation or not. Their responsibility shouldn't be diminished by the tools they use.

I've worked with some really good product managers, as well as some total duds. They all talked to customers on a regular basis. There is so much more to the job than that. Every time I think I understand a product manager's job completely, I see one fail in a way I hadn't thought about.

For example, I had one product manager who made themselves irrelevant because they wouldn't work with sales. The company needed to sell the product to pay us, and sales talked with potential buyers about what might swing their purchase decision and what they would pay extra for. Since the PM only talked to users and ignored sales when doing product design and product roadmaps, the way sales input got integrated into product development is that we frequently got top-down directives from management to prioritize one-off requests from sales over the roadmap. Needless to say, this didn't lead to a cohesive and easy-to-understand product.

Before I saw that PM failing, I hadn't thought about the relationship between product and sales.