July 12th, 2026

Articles of the week

This week I picked up these articles:

Learned/Notes

The standard life playbook is broken. That's fine.

The playbook the author is talking about is the familiar one: go to school, get good grades, go to corporate, climb the ladder. He argues it doesn't work anymore because the economy is growing slower and jobs are changing so fast with AI that just following the steps isn't enough. I mean... just look at how many college grads can't land a job right now.

I couldn't fully relate to the "if you grew up believing this was the way" framing, since I grew up without much guidance, so I don't think I ever had this mindset in the first place. The rest of the article is more general though.

The first big idea is about thinking for yourself. He says the most important thing now is agency/taste because LLMs give you the mean by default, unless you get better at prompting, and getting better at prompting is developing taste. From there he goes into knowing your own values, since a lot of what you think you want might just be inherited (from your parents/grandparents for example), and you won't know which is which until you actually sit down and examine yourself.

I really liked this section on happiness vs. contentment. YJ says we get dopamine from thinking about achieving something, not from the achievement itself (which has been studied and it's a fact). So he argues you should aim for contentment (being okay with where you are today while still working toward what you want, instead of tying your happiness on some future accomplishment). About a year ago I started praying and just practicing gratitude, being okay with who I am and what I have, while still changing what I don't like and building the life I want. Reading this was basically a confirmation that I'd already found the right approach.

This was my favorite line of this blog: "So ask the question, today and often: is what I'm doing right now bringing me closer to what I want? Not what the culture wants, not what the algorithm suggests, not what the consensus rewards. What you want, after you've done the work of figuring out what that is."

Mostly this read was a good reminder that I'm doing the right thing, and I'm glad.

Tech jobs market in 2026, part 3: hiring managers & job seekers

Gergely's deep dives can get long, I also don't care about everything all the time, so in this piece I only read parts 3, 4, and 6: part 3 covers how the market is great for people in newer roles (FDE and AI roles) and rough for everyone else, part 4 is compensation going down for some and up for others, and part 6 looks at US market trends specifically.

The part that made me laugh: companies now want people with expertise in things like design to be able to produce nice websites using AI, or security expertise to review what AI ships, because the AI already has all the general knowledge in the world — what it doesn't have is judgment. So the premium went from "knows things/general" to "knows what to do with what the model already knows (depth)." It made me laugh mostly because I've always been a big believer in depth/expertise, but this industry used to reward generalists, which always rubbed me the wrong way but it made sense. Now though, AI makes everyone a generalist.

The bigger point: it's an employer's market right now. Companies can get whoever they want for less money because everyone else is firing people. And the folks experiencing the "best market ever" — AI/ML engineers, forward-deployed engineers, a few people from big tech with strong networks — are mostly in the US. The same roles aren't seeing anywhere near the same conditions in other parts of the world.

Nothing here changed my thinking, honestly, just confirmed the following: if you want or need to work for someone else, the key is to acquire the skills that are currently paying handsomely.

Interview With Mitchell Hashimoto

Yet another Mitchell Hashimoto interview (been reading & listening to a couple the last few months aha), this time about Ghostty, building in general, and how he approaches learning (especially systems).

I already knew the backstory from other interviews: after leaving HashiCorp he wanted to learn about GPU applications, play with Zig, and understand terminal emulators (which he admitted he didn't really understand at the time) — that's how Ghostty happened. In this one he goes further (at least I have not seen this before): he's tinkering with two new protocols, one for mouse events and one for screens (in a terminal you typically have at most two "screens" — the terminal itself and something like vim) where he seems to want to push to allow for any number of screens instead of just 2. But instead of jumping straight into building the protocols, he's studying the systems that already exist — GTK and Qt on Linux, the DOM and JS APIs for browsers — and reading up on why they ended up the way they did.

He talks a lot about open source too. His take: if you're demanding a lot from software that's free to use, you should either pay for it (at which point, sure, demand away) or fork it and do the work yourself. Apparently that is a hot take and people give him shit for it??? But I totally get where he's coming from.

He clearly has strong opinions about craft and community (he likes Zig because of how the community operates, and won't touch Rust, not because of the language, but because he doesn't like the people around it). My favorite thing he said, though, was about building solutions: you don't find real solutions by listening to 1-3 customers describe their problem and building exactly that. You need the holistic view (how did they get here, could this have been avoided further upstream) to find something actually worth building.

When asked whether someone should learn C before jumping into Zig, his answer wasn't really about the language at all: learn how computers work first, then use the language as the tool to understand that. Don't take libraries for granted — dive into them, especially the standard library, to see how they actually work.

One thing I honestly did not understand: it sounds like C, Rust, and Zig sit in roughly the same layer, close to the syscall layer, while languages like Python and Java sit way above that. I get the general idea but I don't fully understand what that layer means in practice yet — something I gotta dig into.

My takeaway, beyond just enjoying anything Mitchell talks about (I sound like a fanboy D:): if I want to be a builder, I need to find the things I care about most and learn them properly, from the ground up.

Understanding is the new bottleneck

Geoffrey Litt is a designer at Notion, and this one scored a 93/100 with my reading skill. It's about using AI to speed up your understanding of the products/systems you're building, so you stay a collaborator instead of turning into a bottlenecked AI code reviewer.

His framing borrows ideas from education, which was funny to me at first (my gut reaction was "but education, especially the public one in the US, is kind of broken.") Still, the core argument is good: understanding matters because without it, you eventually lose track of why the project exists at all, and that's exactly where new ideas come from. He walks through techniques for cultivating that understanding that go beyond just reading git diffs line by line.

The first is explanations: He built a skill that generates HTML or markdown artifacts explaining a change, following explicit principles: explain the background (what existed before, what it did), build intuition (state the goal, explain related concepts, generate visuals), then walk through the actual differences as a "literate diff" (ordered, explained, visualized, with embedded code snippets, instead of a raw code diff). It even ends with a ~5 question quiz, because reading something doesn't guarantee you understood it.

The one I loved most was micro worlds — an idea he credits back to Seymour Papert's concept of living in "Mathland" to learn math. Here it means using AI to spin up small interactive applications purpose-built for understanding: an interactive debugger you can step through yourself, or a tiny app that walks through a script change step by step.

Shared spaces was the last technique, and it felt a bit like a Notion ad (using it to collaborate on understanding with others, since the first two techniques are solo exercises).

My takeaway: I want to start building versions of these skills for myself. This felt like a really new set of tools for using AI to actually understand things faster, not just produce more code.