we’ve gotten good at giving people what they want in a way that prevents them from wanting anything worth having.

I thought it was just me?

The entire economy of software assumes that code should serve millions to justify its existence.

Not only software. Scalability as virtue is baked into the fabric of cultures sacred and secular.

They’re remembering, one [inefficiency] at a time, what it feels like to want something that’s actually worth wanting.

The search for and creation of meaning is inefficient. A life is measured in opportunity costs.

It’s by no means the least work, but minimizing work isn’t the goal: that would be maximizing freedom, which isn’t the same thing.

There’s a difference between minimizing work and maximizing meaning. Examining the values that are(n’t) being pursued is the key to making decisions that work for your life.

I’m not trying to escape my 9–5, because it helps me live my values and pursue the meaning I care about. Both inside and outside of the work.

Sitting with someone you’ve never met, looking them in the eye, and carrying on a conversation – what used to be so common it wasn’t considered a skill – is now a competitive advantage.

Making a phone call for 3 minutes instead of maintaining a text thread for 3 hours is also among these overlooked skills.

Housing is often a liability masquerading as a safe asset.

I want a house because I want somewhere to sleep, eat good snacks, and curate stuff I enjoy with people I like. I don’t like that it’s difficult for everyone to find a place to sleep, eat good snacks, and curate stuff they enjoy with people they like because people who don’t appear to enjoy anything and seem particularly disconnected keep buying more houses as assets in a portfolio.

How can we make this market volatile, to remove the incentive of investment?. But it has to be stable enough so I have a place to sleep, eat good snacks, and curate stuff I enjoy with people I like.

I rarely think about AIM today, despite the huge role it played in my life as a teenager.

I started learning HTML because I desperately wanted to curate my presence through the perfect away message. I’m embracing AIM as the creation myth for my career building things on the internet.

Ruby attracts people who care how code feels to write and read. Not because of nostalgia…but because most of our careers are spent living inside someone else’s decisions.

Emphasis added. It applies to code, projects, companies, countries, and ultimately all of life. We live inside a cascade of other’s decisions. Approaching them with curiosity rather than judgement is the key.

As a leader, your job is to illuminate, not obfuscate.

Illumination makes things visible. Sometimes what you illuminate is fuzzy. Make it visible, then bring it into focus.

DO NOT add tags, create projects, or create other to-do infrastructure to manage your to-dos better. This is procrastination disguised as productivity.

I’ve embraced this sentiment in recent months, and it has been an unlock. It’s better to have a long-lived task with an ever growing list of notes capturing progress than to break it down into smaller tasks that get “done” each day, without getting the real task done.

This probably breaks down for delegation amongst complex teams. But for personal focus management, this is the way.

It is therefore crucial to design toolsets and their documentation clearly and thoughtfully.

This is just good practice. We should be doing this for our team, including our future selves. If doing it for your fellow humans, including your future self wasn’t convincing, now the robots are depending on you!

you should consider adding complexity only when it demonstrably improves outcomes.

Again! This is (should be?) standard practice when collaborating with humans. The LLMs counting their tokens is bringing visibility and quantification to the costs that already existed.

Those things are not just questions, they are accusations. And, unfortunately, they do not stop.

Every piece of software becomes a TODO list. Every system becomes a scaffolding for a better one. Every inconvenience becomes an indictment of inaction.

I believe sometimes building things is how we self-soothe. We write a new tool or a script because we are in a desperate need for a small victory. We write a new tool because we are overwhelmed. Refactor it, not because the code is messy, but your life is. We chase the perfect system because it gives us something to hold onto when everything else is spinning.

Less of a slot machine, more of a marble run.

the Gmail team has shipped a product that perfectly captures the experience of managing an underperforming employee.

The modern software industry is built on the assumption that we need developers to act as middlemen between us and computers. They translate our desires into code and abstract it away from us behind simple, one-size-fits-all interfaces we can understand.

In the new world I don’t need a middleman tell a computer what to do anymore. I just need to be able to write my own System Prompt, and writing System Prompts is easy!

My core contention in this essay is this: when an LLM agent is acting on my behalf I should be allowed to teach it how to do that by editing the System Prompt.

Tools provide the security layer for agents. Whether or not an agent can do a particular thing is determined by which tools it has access to. It is much easier to enforce boundaries with tools written in code than it is to enforce them between System and User Prompts written in text.

This is what AI’s “killer app” will look like for many of us: teaching a computer how to do things that we don’t like doing so that we can spend our time on things we do.

if you have something worth sharing, it’s better to do it on a site you control, rather than on social media.

This is the desired publishing flow. Social media is for breadth that fizzles out rapidly. Personal websites are for depth that distills slowly.

It’s very cool to see the familiar concept of a blogroll given some love, care, and a .org.

Despite a fascination with digital tools, pen and paper is where my real thinking happens.

My experience is seasonal. I haven’t been journaling in the analog lately. And I think a big part of that is because I don’t like the quality of my latest notebook.

Noah’s oil paintings of modern food are perfect. An original will cost you thousands of dollars on ebay. I wish I could support an artist at that level.

The only problem? The method I need, ActionDispatch::FileHandler#find_file is private, meaning that I really “shouldn’t” be calling it. But also, it’s a free country, so whatever. I wrote this and it worked:

This is the beauty of programming in Ruby. You are trusted with sharp knives to accept (and mitigate) your own risks.

Of course, I could write a test to ensure this method still works, but I didn’t want to give this method even more of my time. So instead, I codified this assumption in an initializer:

Writing a test that will fail is routine to me. It feels like an understanding unlock to move that failure from test time to boot time. A failing test can be ignored as flaky. An app that won’t boot demands attention for resolution.

the end, judgment comes first. And that means hiring is a gut decision.

As much science as people want to try to pour into the hiring process, art always floats to the top.

Hiring benefits from introducing process and constraints. But the final decision can never be systematized away.

Everything we do must be grounded in truth and compassion.

“What we win people with is what we win people to’’ comes to mind.

A handy high-level reference to the various competing standards for establishing a decentralized social network.

Business want risks that aren’t risky, art that isn’t challenging, and new experiences that are immediately familiar. But if branding is about differentiation, we have to actually differentiate. Diverge. Do something, anything, that isn’t what’s around.

Rewards flow towards risks. But they also flow towards compliance with paved paths. There’s a tension in trying to serve both reward mechanisms. Small differentiators are a hedging of bets.

Being yourself is a better differentiator than any other strategy.

It’s the easiest to consistently implement, too!

If you’re being yourself, you are your moat.

Here’s why this matters: imprecise and euphemistic language is the language of fascists, authoritarians, and oppressors — power-craving leaders who either don’t want people to know what they are doing or don’t want them to think too hard about the illegality or immorality of their actions.

This motivates me to pursue a life of direct and precise language.

rails.style is a curated resource hub for Rails developers.

Lists of tools aren’t a thing I need every day. But it’s nice to have them bookmarked when you need them!

Ferrum provides you a high level API interface to Chrome browser and allows you to fully automate it and grab data from any public site you want. There’s no additional software required — only Chrome, Ruby and you.

I have yet to meet the limits of Mechanize, but it’s good to know there are other tools out there.

The problem here is that “sorry” both conveys sympathy without fault and sympathy with fault, i.e. “I’m sorry your feelings were hurt” vs. “I’m sorry I hurt your feelings”.

It is literally difficult to convey sorry without adding additional qualifiers.

To make things more confusing, “sorry-not-sorry” expresses unsympathy with fault.

This complication makes me believe we need another permutation that expresses sympathy even when fault of the speaker is assumed incorrectly.

I find that many people confuse refactoring with any change in code.

It’s true. I need to learn how to be gentler when confronting it because it irks me deeply.

When this happens, I say that the interface becomes a published interface (a step beyond a public interface).

Languages provide mechanisms for marking methods public or private. What would a convention for marking a method “published” look like?

It’s at the seams of the system, that’s a good place to start.

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior.

So while we refactor (verb), we apply several refactorings (noun).

It’s great to have the definitions handy.

Here’s the magic part: TCP is built on top of IP. In other words, TCP is obliged to somehow send data reliably using only an unreliable tool.

Every time I relearn this I stand amazed in the presence of TCP/IP.

What is a string library? It’s a way to pretend that computers can manipulate strings just as easily as they can manipulate numbers. What is a file system? It’s a way to pretend that a hard drive isn’t really a bunch of spinning magnetic platters that can store bits at certain locations, but rather a hierarchical system of folders-within-folders containing individual files that in turn consist of one or more strings of bytes.

What is a language? It’s a way to pretend we can understand the same concepts in a world of imprecision and subjective experience.

One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to.

Conceptual compression allows ideas to travel faster and further. Ideas need play with each other to be remixed into something new. Decompressing an idea into its component parts creates opportunities for new compounds. Everything in its time.

Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting.

This was written in 2002! Long before LLMs were going to take our jobs.

It was true then and it’s true now: writing code is not the hard part of the work. Reading and comprehending and safely transforming the code to achieve refined and emerging desired outcomes is the hard part.

So the abstractions save us time working, but they don’t save us time learning.

This is why curious programmers are the best programmers. They have an insatiable hunger for learning how things work.

You can find out where things stand. But the answer is a human one, not a digital one. It’s fuzzy, it’s a bit abstract, and it’s more a feeling than a figure. It’s taking stock of all the things that can’t be measured, and speaking or writing the actual answer, not pointing to an abstract number. “63” means nothing. “We think next Tuesday” means something.

Ledgers want numbers. Leaders want truth.

Numbers provide facts. Facts are true, but they’re not the truth.

That imprecise wiggle room is also known as the truth.

Truth is subjective when creating something new and putting it into the world. This is a feature, not a bug.

Subjectivity is a good thing. A human thing. It’s with the grain. Subjectivity and productivity are partners, not adversaries.

If I believe I’ve been productive, I’ve been productive. I can be wrong, which is why I check that belief with my peers. Shared belief and shared believability is the next step.

Over time we’ll be adding more imprecision like this to Basecamp. The more we can reflect reality, not a false premise, the better off teams will be.

Reality is the believable interpretation of facts. Facts alone aren’t enough. Facts, in context, with value judgements are desired.

I probably could have just highlighted the entire piece. It’s worth a read, and the truth is probably somewhere in the middle.

Look, we get it. “Write a policy” is a very boring idea. As a vibe, it’s giving taupe, bureaucracy, and mildew. But putting some careful thought into documents like these gives your team clarity about where you stand as an organization, and what to do when the ick — however implausible — shows up. Given the current state of, well, everything? It might be some of the most vital work you do this year.

Well written policies can be a consensus-building and decision-making accelerant. Poorly written policies generate more questions than they answer.

Names that put the verb before the noun. By giving the verb primacy, as the system grows and opportunities for reuse arise, this encourages me to generalize the direct object of the class via polymorphism as opposed to generalizing the core function of the class, violating the single-responsibility principle (i.e. PetsDog may evolve into PetsAnimal, whereas DogPetter is more likely to evolve into a catch-all DogManager)

I’ve definitely written classes that (d)evolved from DogPetter to DogManager. I’m going to give this verb-first naming a spin.

Done well, refactoring is a low-risk investment in future productivity, by reorganising code without changing its behaviour. Often however, our conversations position work that doesn’t meet this description - and needs more scrutiny - as refactoring. Let’s look at what goes wrong when this happens.

I’m thankful one of the giant robots at Thoughtbot wrote this so I don’t have to.

After a while, long periods of work with no result creates distrust.

Results build trust! Results come in the form of desirable change or desirable predictability. Refactoring is focused on not introducing change, so it must be focused on retaining predictability.

A listener is more likely to ask: “why do I need this change and not something else?”, or “what does success look like?” when meaning is not hidden.

Say what you mean and mean what you say.

We need to be careful not to claim that we’re refactoring when we’re really making bug fixes, adding new features, or otherwise changing the code’s behaviour and our product’s user experience. Disguising that work as refactoring sabotages important conversations and creates suspicion about the concept. We can fix this by getting more specific in our language and by learning more about what refactoring really is.

Amen.

A lot of modern solutions may not save time as much as they introduce complexity and reliance on more tools than you need. This whole process is not that complex.

Managing complexity takes more time than the effort saved. It’s true in many cases.

User adoption doesn’t work if it’s forced; it has to come from a genuine user belief that the new feature can help them achieve their goals. And it certainly doesn’t work if your feature actually creates a worse experience for the user and degrades the quality of the product.

Autonomy in adopting a new behavior is the ultimate sticking point.

The people might have asked for faster horses, but instead they got donkeys on LSD.

I literally lol’d at this. What a great reframing of a misquote.

The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.

It’s always helpful to recognize the difference between needs and wants. Maslov’s heirarchy of introducing complexity.

Cynicism is the cheap seats. It’s the fast food of intellectual positions. Anyone can point at something and say it’s broken, corrupt, or destined to fail. The real challenge? Building something better.

I’ve been sitting in the cheap seats, apparently. I’m just happy to be in the stadium, watching live sports, eating fast food.

Putting aside the choice of analogies, I want to accept the challenge—to value creation above critique.

Cynicism comes with hidden taxes. Every time we default to assuming the worst, we pay in missed opportunities, reduced social trust, and diminished creative capacity. These costs compound over time, creating a self-fulfilling prophecy in which cynical expectations shape cynical realities.

Being right feels so good that you’ll continue pursuing it even if it’s making you miserable.

Call it pragmatic meliorism — the belief that while perfect solutions may not exist, better ones do.

Don’t let the pursuit of the perfect become the enemy of “good enough”.

Full Feed RSS is a simple RSS feed reader that displays the full content of the articles.

This is the kind of stuff that makes the web great. Following an RSS feed that requires a click-through to view the whole article? Build your own tool that brings the full article into the reading environment you want.

The dumber the disagreements, the better the world actually is.

Don’t be surprised when disagreements exist. Instead, use their banality as a gauge for how things are actually going.

Online verification is an invented problem.

Domain ownership and SSL certificates solved this problem at a lower tier before Web 2.0. Centralization on platforms has invented an arguably unnecessary problem of authentication.

The only reason we don’t have this at scale now is because we don’t have a good RSS writer for regular people.

We need more publishing tools for regular people.