https://oandre.gal/category/by-lang/english/feed

“Mr. Hunter’s grave” and “Dragger captain” are two examples of memorable writing. Mitchell weaves these stories as a conversation — the orality, the steady build up. It seems his signature to do it that way, as for the other four profiles in the book share similar characteristics. They all were published in TheNewYorker between 1944–1959, a lifetime ago.

These profile articles give voice to common people, and they cover unconventional topics that aren’t in the spotlight — shad fishing in Edgewaters, how dragger boats operate, or the rise and fall of the oyster business in the south shore of Staten Island. It feels refreshing to read them in 2025.

I discovered this book via William Zinnser. “This is a primary textbook of literary non-fiction”, he said, “and writers of any generation should be familiar with it”. I can’t disagree.

After publishing Refactor this for me a colleague reached out:

“hey, I think the original code was better. Why did you need the effect for?”

Knowing him for a few years, I knew his point was: can we have a single source of state changes?

So we talked about what I was doing. I was beginning to migrate an existing screen to use the DataViews component. I wasn’t yet familiar with how the existing screen worked, but I explained what I knew: it filters some data based on dates. The dates state is updated differently depending on the UI component. Some components would trigger state changes that end up updating the URL. Some other components (auto-refresh), would trigger interval-based state changes but don’t update the URL.

As I was writing this down, I realized:

“Why doesn’t the interval trigger an URL update as well?”

I proceeded to refactor the existing code removing all intermediary state handlers: every component would trigger a URL state change directly. That got us a single source of truth for state, which prevents unnecessary re-renders, requires less code to maintain, and simplifies the data flow. It was just a little day-to-day thing, but it triggered a question.

I was curious if there were ways for a LLM to give me feedback along the same lines an expert-level human would, so I experimented.

First, I tried open questions (“review and suggest changes”) and they didn’t provide anything meaningful or related to state management. All they offered was general or low-level suggestions: “split your components for better composability”, “use TypeScript enums instead of string literals”, etc.

I narrowed down the questions to performance:

“Me: I’ve noticed this code has multiple sources of state updates. For example, it’s using useInterval to trigger date range changes upon each interval tick. Can you suggest anything to reduce the number of re-renders in this component?”

This resulted in a bunch of “memo more things” and “batch state updates” — fine, it’s related. But suggestions were still generic and not really getting to the bottom of the issue. I asked other questions, until I finally became frustrated and wrote:

“Me: Are there ways to refactor this code to make it all dependant on URL changes (a single source of state updates)?”

“LLM: Yes! Converting the application to be URL-driven would create a single source of truth and simplify state management.”

The LLM response was “cute”.

Indeed, it suggested code changes that made sense, along the same lines I had already done. It wasn’t surprising because higher-level refactorings is something they are getting good at. But I wouldn’t consider this a success given it failed to provide impactful improvements to the data flow until I mentioned them explicitly — the whole point of a code review.

There are reasons to be positive about using LLMs in code reviews. For example, they perform fine at small-scope code changes that are structured and established such as TypeScript errors, or CSS flexbox issues. The question I don’t have an answer for is: how do we scale them up from these low-level problems to things more impactful such as application-level data flows and domain-specific code?

A dozen of us spent a cloudy Sunday navigating the northern part of the Ría of Pontevedra. Starting in Raxó, we coasted until reaching Combarro, then circumnavigated Tambo’s island, getting some nice views of the lighthouse.

By the time we were south of Tambo, the wind had picked up, and we were hit laterally by wind waves. There are no records for that particular moment in Marín’s port, so all I can tell you about weather conditions is that nobody took pictures. The situation required practicing balance, a little challenge that was fun after the fact. It was also then that some dolphins surfaced a few meters from my bow to say hi.

According to some paddlers who kept stats, it was a total of ~15 km, with peaks at ~8 km/h and a median velocity of ~4.5 km/h. A relaxed rhythm.

This book covers the evolution of the semiconductor industry since the transistor was invented in the 1940s until the early 2020s —more than 80 years. It sits at the intersection of technology, economy, and foreign policy.

Books that take such a wide angle are rare, the usual route for business books is to focus on single individuals or companies. This historical approach to business enabled the author to convey the massive amounts of money poured by the USA’s government (DoD, NASA, DARPA) through decades to create, and defend, an industry — which is not something we often hear in the stories about Silicon Valley entrepreneurs. Though, it’s also well covered the role of some talented individuals (Shockley’s mafia or Akio Morita’s Sonny) competing in the market to produce goods people want to buy — like handheld calculators in the 70s or personal computers in the 80s. Both things can be true, and the first part of the book communicates how each had a role in taking us where we are today. In the latter part, the East Asian countries take the front seat, and the story becomes gloomier: “subsides to companies”, and “industrial espionage” are the drivers, according to the author.

The main takeaway of this story is how the chip-making industry correlates with political influence: military power depends on it, and choking certain points of the supply chain can force countries or companies to go bankrupt. The latter is a soft power deployed by the USA against adversaries such as China’s Huawei or ZTE. It comes from the monopoly certain companies hold over pieces of the supply chain: you can’t produce high-end chips if you are banned from accessing these tools. These monopolistic companies are based in the USA or in countries that depend on USA’s military aid (e.g., Taiwan, Europe), hence its soft power.

There are two things I wish were a bit different about the book. First, we don’t get to learn the history of East Asia or Europe entrepreneurs in the same way we do for USA ones. Second, the economical or political aspects are widely covered, to the point of becoming a bit repetitive, while the technological ones are sometimes treated superficially.

I also have a complaint: the e-book is poorly produced. I only realized there were hundreds of (unlinked!) notes after a few chapters into it — it was impractical to navigate back and forth between the notes and the text, hence I missed them all.

I don’t remember exactly how this book entered my queue. All things considered, it’s a book that help readers understand the complex chip-making industry, no matter their background.

This is a book about investing.

The first part introduces strong competitive advantages of companies. Warren Buffet popularized them as “moats”, and so are known in the industry. Moats are patents, for example, that give you exclusive rights to produce something for a while. Moats are also ways to operate at lower costs than competitors, if you can sustain it. Different moats offer different characteristics, but all promise the same: companies with these advantages generate higher returns for longer periods of time. That’s why investors look for companies that have them.

The second part is about how to find companies with moats, how to valuate them (P/E, EPS, etc.), and the mechanics of buying and selling to maximize your returns.

I picked it up after a recommendation by one of the assets managers I follow. It was published in 2008, and it’s part of the “little books, big profits” series by Morningstar. It’s a pleasure to read, with clean prose and without unnecessary jargon.

In a coding session today, I ran into the following interaction with a Large Language Model. I had something like this:

const startTime = useMemo( () => {
  // Do something with query.from
}, [ query.from ] );

const endTime = useMemo( () => {
  // Do something with query.to
}, [ query.to ] );

The time variables need to change their value based on the query, but there’s also an extra source of state updates, so I wanted to refactor it to using local state and adding an effect. I entered a pairing session with Claude 3.5 Sonnet and this is what happened:

I asked Claude to do some changes to the startTime code. Then, I just requested to “apply the same changes to endTime” — I didn’t provide further context.

The changes aren’t correct because it’s using the same function getTimeFromValue to calculate endTime. I can fix that easily, or perhaps I should have provided better prompts. There’s also the question if the end result is better than the previous state, but that’s the programmer’s fault, not the machine’s. Whether this has produced better or correct code is not the point. The question I’m interested in is different: do LLMs to edit code improve conventional editing tools?

By any measure, this was a small refactoring. But just as small as it was, it hints at how they do. They give you access to many more code actions than any editor can bundle, and chaining them is a seamless process that doesn’t take you out of the flow. It’s also trivial to apply the same chain of actions to a different piece of code. Right after finishing this refactoring, I had a flashback: my younger self was using emacs macros to repeat some simple edits across a few dozens of lines — it was a more limited experience.

It feels like, with time, it’d go beyond incremental improvements and refactorings will be expressed in a higher-level vocabulary than conventional editing tools.

According to the logs, my first commit to Gutenberg/WordPress added the “convert to blocks” option to the HTML block. It was July 2018, months before the block editor became the default experience in WordPress 5.0 — and I still went by my old nickname.

Though my actual first memory of a contribution was me writing tutorials for the block editor with Marcus. In doing so, I grew frustrated by how poor the API docs were at the time. Most people don’t remember it now, but, more often than not, they were out of sync with the code — rendering them unusable. That was my first side quest in Gutenberg: I wanted to autogenerate the JavaScript API docs, so they were always up to date.

It took me a few days to have a working prototype, and 6 weeks to make it production-ready, convince people it was worth doing it, and get the approvals to merge it.

The tool’s job was very simple: given a entry point, extract the ES6 exports and generate a markdown file with the documentation.

npx docgen <entry-point>

Over that simple idea, in Gutenberg, we added some scripts that took docgen’s output and embedded it into the existing README files of existing packages — which are part of our official docs everywhere (block editor handbook, npm, GitHub).

Since the initial release, docgen sit there, unattended, doing its job silently. It got two major updates that I’m aware of: changing the parsing library to support newer syntax, and updating some edge cases for TypeScript a few years later. It’s the kind of little thing that fixed 90% of the use cases we had, not of all of them, and then it vanished from everyone’s view.

After that, I focused back on the things we actually wanted to ship: the main quest.

I was finally able to experience surfing a sea kayak.

It was fun, and a good way to test my recoveries and balance — they need more work. On the bright side, I learned my right-side roll is solid: I did dozens of them, easily. I only failed the last two after 3h of practice, when I was exhausted. My go-to roll is the standard greenland, but modified to forward-finishing it with sculling.

Surf is also unforgiving with the wet exits. How fast do you recover when there may not be much time in between waves? I tried, but failed, the back deck scramble self-rescue, and successfully executed the assisted t-rescue with heel hook — both as a swimmer and as a rescuer, so that’s something.

After half a day in the water, I felt a lot more confident about my abilities. Despite having rough spots, it was a good kind of challenge: hard, but doable. In retrospect, I think it was a good idea to only try surfing after having developed a solid roll on one side. It increased the time I could focus on practicing the techniques required for surfing, instead of practicing rescues. And so by the end of the session I had caught a handful of good waves, and learned something from dozens of others.

We forgot to take good pictures/videos, but at least there’s proof:

People are excited for code completion powered by AI. Excited as in: they are willing to pay for it.

A year ago, GitHub Copilot, a product launched in 2021, surpassed $100M ARR. It’s roughly 1M paying customers, given the lower tier is at $100 per year. For comparison, GitHub (+15 years old, launched in 2007) reached $1000M ARR in the same year. It only took two years for Copilot to account for 10% of GitHub’s ARR. But that was already a year ago; according to some Satya Nadella declarations this summer, Copilot may have surpassed $200M.

On different headquarters, 2024 has also been a good year. There were $83M invested in Cursor ($11M, $60M) and Supermaven ($12M), which recently announced they’ll join forces.

Cursor self-describes as “the AI Code Editor”: it’s a fork of VSCode that differs in a few DX things and that uses more LLMs for autocompletion — OpenAI’s ChatGPT like GitHub Copilot does, and Anthropic’s Claude Sonnet LLM. Supermaven is an extension that works in a few editors, and it self-describes as “the fastest Copilot”. They claim their custom LLM is superior to others because it can process more of your code (1M tokens) to suggest better alternatives, faster.

So, there’s competition and money around “AI autocompletion”. But, whose money is it?

The first contestant is Microsoft. They own the editor (VS Code), the service mediator (GitHub Copilot), the LLMs (by being the major investor of OpenAI), and the platform (the models run in Azure).

However, since Cursor came along, Microsoft has been forced to do some moves. VS Code has implemented some interactions that had been pioneered by Cursor and others. But, more importantly, GitHub Copilot now also offers Anthropic’s Claude Sonnet LLM, that runs in Amazon Cloud Services. Microsoft has been forced to share its Copilot’s revenue with its major competitors in LLMs (Anthropic, being Amazon the major investor) and platforms (AWS by Amazon).

That’s an interesting turn of events. Specially if you consider who funded Cursor: OpenAI led the seed round and OpenAI participated in the second. Cursor raised money to compete against Microsoft from… Microsoft. That wouldn’t be an entirely correct way to put it, but it wouldn’t be totally incorrect either.

Platforms and LLMs are very tightly connected and are the lion’s share of revenue. The editors are just highly disposable tools that give you access to LLMs.

August 9th: updated post to include data from July.

In a recent WordPress performance hangout, we talked about how we could assess the impact of the WordPress 6.2 release on production sites.

One of the public datasets we discussed was the HTTP Archive’s Core Web Vitals Tech report, that queries monthly a number of sites based on popularity. It is able to detect WordPress sites. One of the metrics it reports is TTFB. Or, more specifically, the percentage of WordPress sites that have good TTFB (getting a response from the server in less than 0.8s):

By default, the HTTP Archive’s Core Web Vitals Tech report lists percent of “good CWV”. Select TTFB in the top-right icon that says “optional metrics” to see this graph.

WordPress 6.2 was released by the end of March 2023, so April would be the first month to include some sites using WordPress 6.2.

• April = 31.32%
• May = 33.16% (+1.84)
• June = 34.59% (+1.43)
• July = 35.16% (+0.57)

From April to July, there is almost a four-point increase. The ratio of improvement was 1.8 in May and 1.4 in June. It’s the first time since we have records that there have been two consecutive months with that kind of growth. More on this below.

Felix Arntz prepared a report based on alternative data, by Chrome: WordPress 6.2 performance impact in the field (CrUX). He was able to filter the dataset by WordPress version (6.2 vs. 6.1) and type of theme (classic vs. block). There’s more detail in there, so I recommend taking a look.

The TLDR is that this field report also confirms the lab benchmarks we ran for the release. TTFB for sites using WordPress 6.2 has improved compared to 6.1, specially when using block themes:

The public real-world datasets are affected by changes everywhere: hosts updating the PHP version to a more performant one, browser’s updates, improvements in WordPress releases, plugins/themes getting faster, etc. There’s a lot to unpack.

We cannot isolate the impact a WordPress release has in the field like we do in the lab. However, the fact that the field data and the lab data report the same trends is a good thing. It connects the two. It suggests that improvements to the WordPress base are indeed influencing the real-world metrics in a way we can track.

In the recent versions, with the auto-updates, a new release surpasses the old one in a few days. The first weeks sites are updated en masse, and then it reaches a plateau. You can check this velocity by looking at the download counter and the stats. Right now, a few hours after the 6.3 release, WordPress 6.3 has 12M downloads while 6.2 sits at 100M (already at 12%).

This trend is the same we see for TTFB in the HTTP Archive report: higher growth in the month after the release (May, 1.8 points), and descending in the next ones (June with 1.4 points and July with 0.5 points, almost reaching a plateau).

This is what leads me to believe that, indeed, the WordPress base is driving the updates in performance we see in the public datasets.

Lab benchmarks report that 6.3 brings bigger performance improvements than 6.2. While 6.2 mostly improved TTFB, according to the analysis, 6.3 improves both TTFB and LCP significantly.

If the WordPress base is indeed driving the changes, we should see the public datasets impacted starting in August. Excited to see what the fall brings!