Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Daniel De Laney
Have you ever gotten to the end of a long work day and realized you’re no closer to your goals? I have. The problem, counterintuitively, was lack of interruption. Sure, I was doing a lot of stuff. But I never paused to ask whether I was doing the right stuff. Or whether my approach was working. Or if I was spending the right amount of time on it. So I needed a reliable way to interrupt my “unproductive productivity,” and refocus on what’s important. The obvious first-thought solution was a timer. Unfortunately, if you use timers a lot, you learn to dismiss them reflexively. And it’s really easy to forget to set the next timer. A week later I’d think “Hey, that timer idea really worked, I should get back to that.” And then I didn’t. So I built a new kind of timer. It does 2 unique things: My timer asks me a question. It gradually blurs my screen if I don’t set a new timer. Every few minutes it asks me the same question: “What will you focus on?” I answer in a word or two, hit enter, and keep working. Having to name my intention keeps me fully aware of my trajectory. If I’m in danger of drifting, it’s obvious. If I’m flying on something simple and don’t need to reorient frequently, I can set the timer for a longer duration, maybe 30 minutes. But if I’m working on something more open-ended, I might tighten the leash all the way down to 3 minutes. Then I can’t get off track. Unlike a regular timer, I can’t fail to set the next one. If I don’t restart it promptly, the screen gradually becomes less readable until I do. If I wanted to avoid answering, I’d have to make a conscious decision to close the app just so I could see the screen clearly. I’d have to decide to be less productive. I never do. This small intervention has worked beautifully. Not only am I catching unproductive divergences earlier, I’m noticing fewer of them over time. It seems to be training me to do more and better thinking. It’s not a replacement for a more extensive journaling practice. I love to journal, but that only happens once per day. What about the rest of the day? There’s a lot of benefit in reflecting more often than once every 24 hours. If you’re running macOS, I recommend giving Intention a try. I use it every day, and I think it’s the superior way of working.
Have you ever gotten to the end of a long work day and realized you’re no closer to your goals? I have. The problem, counterintuitively, was lack of interruption. I never paused to ask whether I was doing the right thing. Or whether my approach was working. Or if I was spending the right amount of time on it. The obvious first-thought way to interrupt myself was a timer. But I discovered those are too easy to dismiss, and too easy to forget about. A week later I’d think, “That timer idea really worked, I should get back to that.” And then I didn’t. So I built a new kind of timer that asks me a question: “What will you focus on?” Every few minutes I answer in a word or two, restart the timer, and keep working. This keeps me fully aware of my trajectory. If I’ve drifted, it’s obvious. If I’m flying on something simple and don’t need the reminders, I can set the timer for a longer duration, maybe 30 minutes. But if I’m working on something open-ended, or my attention is wandering, I might tighten the leash all the way down to 3 minutes. Unlike a regular timer, I can’t ignore it. If I don’t answer the question, the screen gradually blurs until I do. Drifting requires making a conscious decision to close the app. I have to decide to be less productive. This tiny intervention has worked beautifully. At first, I caught myself drifting constantly. Over time, I naturally became more focused. It’s training me to stop wasting time. Setting a recurring timer every few minutes sounds like it could be too much. Instead, it’s a relief. There’s nothing worse than spending all day accomplishing nothing useful. All I have to do to prevent that is type a word or two and hit enter. Importantly, it’s not a blocker. It doesn’t try to stop me from using distracting apps or sites. I’d just disable that, anyway. Instead of trying to take control away from me, it gives me more control, because I’m more aware. Plus, this makes blockers unnecessary. I can tell you from experience: by the third time you set a 3-minute timer you’ve titled “Aimless scrolling,” you’ll feel ridiculous enough to stop. It’s also not a journal, or a log. Those are harder to keep up with, and they don’t help minute-to-minute. Journaling once per day is great, but then I’m still potentially spending a full 24 hours off course. This is every few minutes, and it only takes a couple of seconds. All I have to do is name what I want to focus on. If you’re running macOS, I recommend giving Intention a try. I use it every day, and I think it’s the superior way of working.
I’m the person my friends and family come to for computer-related help. (Maybe you, gentle reader, can relate.) This experience has taught me which computing tasks are frustrating for normal people. Normal people often struggle with converting video. They will need to watch, upload, or otherwise do stuff with a video, but the format will be weird. (Weird, broadly defined, is anything that won’t play in QuickTime or upload to Facebook.) I would love to recommend Handbrake to them, but the user interface is by and for power users. Opening it makes normal people feel unpleasant feelings. This problem is rampant in free software. The FOSS world is full of powerful tools that only have a “power user” UI. As a result, people give up. Or worse: they ask people like you and I to do it for them. I want to make the case to you that you can (and should) solve this kind of problem in a single evening. Take the example of Magicbrake, a simple front end I built. It hides the power and flexibility of Handbrake. It does only the one thing most people need Handbrake for: taking a weird video file and making it normal. (Normal, for our purposes, means a small MP4 that works just about anywhere.) There is exactly one button. This is a fast and uncomplicated thing to do. Unfortunately, the people who have the ability to solve problems like this are often disinclined to do it. “Why would you make Handbrake less powerful on purpose?” “What if someone wants a different format?” “What about [feature/edge case]?” The answer to all these questions is the same: a person who needs or wants that stuff can use Handbrake. If they don’t need everything Handbrake can do and find it bewildering, they can use this. Everyone wins. It’s a bit like obscuring the less-used functions on a TV remote with tape. The functions still exist if you need them, but you’re not required to contend with them just to turn the TV on. People benefit from stuff like this, and I challenge you to make more of it. Opportunities are everywhere. The world is full of media servers normal people can’t set up. Free audio editing software that requires hours of learning to be useful for simple tasks. Network monitoring tools that seem designed to ward off the uninitiated. Great stuff normal people don’t use. All because there’s only one UI, and it’s designed to do everything. 80% of the people only need 20% of the features. Hide the rest from them and you’ll make them more productive and happy. That’s really all it takes.
Code forces humans to be precise. That’s good—computers need precision. But it also forces humans to think like machines. For decades we tried to fix this by making programming more human-friendly. Higher-level languages. Visual interfaces. Each step helped, but we were still translating human thoughts into computer instructions. AI was supposed to change everything. Finally, plain English could be a programming language—one everyone already knows. No syntax. No rules. Just say what you want. The first wave of AI coding tools squandered this opportunity. They make flashy demos but produce garbage software. People call them “great for prototyping,” which means “don’t use this for anything real.” Many blame the AI models, saying we just need them to get smarter. This is wrong. Yes, better AI will make better guesses about what you mean. But when you’re building serious software, you don’t want guesses—even smart ones. You want to know exactly what you’re building. Current AI tools pretend writing software is like having a conversation. It’s not. It’s like writing laws. You’re using English, but you’re defining terms, establishing rules, and managing complex interactions between everything you’ve said. Try writing a tax code in chat messages. You can’t. Even simple tax codes are too complex to keep in your head. That’s why we use documents—they let us organize complexity, reference specific points, and track changes systematically. Chat reduces you to memory and hope. This is the core problem. You can’t build real software without being precise about what you want. Every successful programming tool in history reflects this truth. AI briefly fooled us into thinking we could just chat our way to working software. We can’t. You don’t program by chatting. You program by writing documents. When your intent is in a document instead of scattered across a chat log, English becomes a real programming language: You can see your whole system at once You can clarify and improve your intent You can track changes properly Teams can work on the system together Requirements become their own quality checks Changes start from clear specifications The first company to get this will own the next phase of AI development tools. They’ll build tools for real software instead of toys. They’ll make everything available today look like primitive experiments.
More in technology
Google told K-12 schools they could turn off AI, but only if they gave up search too. That isn’t integration. It’s holding education for ransom.
A Pika author was editing the same post in two browsers. They added six images in Browser A, then later they referenced an old tab editing the post in Browser B. That copy of the editor did not include those images. Browser B saved and removed all six images from Active Storage. A short time later, Browser A saved its newer copy of the post and put the image references back, but at that point the originally uploaded files were gone due to Browser B saving the post without the images. This exposed two separate problems: Missing images produced uncached 404 responses that the editor requested repeatedly. Action Text purged an image as soon as one save removed it from the body. Here’s how we fixed those problems. Why Action Text deleted the images Action Text keeps a rich text record’s embeds synchronized with the attachments in its body. When a submitted body no longer contains an image, Action Text removes its ActiveStorage::Attachment. Active Storage then purges the dependent blob, deleting both its database record and its file. That behavior makes sense when there is only one current copy of a document. It is unsafe when the same post can be open in multiple tabs, browsers, or devices. One stale save can delete an image that another editor is still using. Why the missing images flooded the server Browser A still had the six images in its editor, each pointing at an Active Storage redirect URL: /rails/active_storage/blobs/redirect/:signed_id/:filename Pika uses the ProseMirror-based Rhino editor. Rhino rebuilt an image’s DOM node when its caption or selection changed. Each new <img> element requested its URL again. Healthy images did not cause trouble since Active Storage makes its redirect cacheable. For a purged blob, Rails returned a 404 without Cache-Control, so the browser kept sending the request to Rails instead of reusing the failure. In a gallery, typing could re-request several missing images per keystroke. In these scenarios, this issue led to hundreds of requests hitting our servers. Fix 1: Cache permanent Active Storage 404s A purged blob’s redirect URL can never start working again. Blob IDs are not reused, and uploading the image again creates a new blob with a new signed URL. Sinc there is no concern of a 404 becoming stale, we made a specific 404 cacheable for the same period as a successful redirect: # app/controllers/concerns/active_storage_missing_blob_cache.rb module ActiveStorageMissingBlobCache extend ActiveSupport::Concern included do rescue_from ActiveRecord::RecordNotFound, with: :render_cacheable_not_found end private def render_cacheable_not_found expires_in ActiveStorage.service_urls_expire_in render file: Rails.public_path.join("404.html"), layout: false, status: :not_found end end We included the concern only in the controller serving these blob redirects: # config/initializers/active_storage_missing_blob_cache.rb Rails.application.config.to_prepare do ActiveStorage::Blobs::RedirectController.include(ActiveStorageMissingBlobCache) end (We also offered an update to Rhino that avoids it being so aggressive re-requesting images.) Fix 2: Detach dropped images instead of purging them When a save removes an image from an Action Text body, we now remove the attachment while temporarily keeping its blob. Another browser can save the image again and reattach that same blob. If nothing brings it back, a cleanup job purges it later. First, we added a timestamp for when the image was dropped: class AddDetachedAtToActiveStorageBlobs < ActiveRecord::Migration[8.1] def change add_column :active_storage_blobs, :detached_at, :datetime end end We then intercepted the private callback Active Storage uses to purge a dependent blob: # config/initializers/detach_dropped_embeds.rb module DetachDroppedEmbeds private def purge_dependent_blob if dropped_from_rich_text? blob&.update_columns(detached_at: Time.now) else super end end def dropped_from_rich_text? record.is_a?(ActionText::RichText) && !destroyed_by_association end end ActiveSupport.on_load(:active_storage_attachment) do prepend DetachDroppedEmbeds end The destroyed_by_association check preserves intentional deletion. Removing an image from a saved body detaches it, but deleting the post and its rich text still purges its images normally. Purge detached blobs after a grace period The cleanup query considers both when the blob was created and when it was detached: ActiveSupport.on_load(:active_storage_blob) do scope :unattached_since, ->(time) { unattached.where( created_at: ..time, detached_at: [nil, ..time] ) } end That scope handles both kinds of unattached blobs: A new upload that has never been attached becomes eligible based on created_at. An image removed from an old post becomes eligible based on detached_at. Pika gives both a 30-day grace period: class PurgeUnattachedUploadsJob < ApplicationJob GRACE_PERIOD = 30.days def perform ActiveStorage::Blob.unattached_since(GRACE_PERIOD.ago).find_each do |blob| blob.purge_later end end end If another browser saves the image during that period, it is attached again and the unattached scope excludes it from cleanup. The result Replaying the original two-browser edit now works safely: Browser B saves a body without the six images. The attachments are removed, but their blobs are only marked as detached. Browser A saves its newer body and reattaches the existing blobs. The images remain available and do not need to be uploaded again. If no editor brings a detached image back, the cleanup job eventually purges it. Much better! Reply by email
Yesterday, a group of MIT researchers released an article titled “Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights”. The piece describes a set of experiments which convincingly show OpenAI’s latest Astra model is able to understand and successfully alter raw weight data. Wowzers! It’s a rough analogy, but an LLM’s weights are sort of like its brain. A set of weights is a large pile of numbers generated during training, and an LLM’s output is derived by running input through the weights using some matrix multiplication and a bit of randomization. While the steps to generate weights are well understood, the weights themselves are extremely opaque. There’s ongoing work to try and explain how weights work, but researchers currently have a limited understanding of what these numbers do. Based on this, I was quite surprised to learn that LLMs are able to act on raw weight data — even if it’s still just in limited cases. It’s unclear if OpenAI’s model was trained on weight data. Even if it was, I still find these results surprising. The article shows the model accurately predicting what a never-before-seen set of weights was built to do, fixing another model by updating its weights, and creating new sets of weights that performed simple tasks. I would not have guessed any of that would be possible a couple of days ago. This whole thing is slightly unnerving. The whole “weights as a black box” thing has always felt a bit sketchy to me, even when I was working with much simpler machine learning models. Now these experiments hint at a future where LLMs could be self-improving in ways that aren’t human-verifiable. Machines building machines, and we can only hope that they’re not doing anything weird. I don’t know if this strategy is scalable, but I’d guess that it’s something more people will be exploring very soon. More and more often these days, I wish we were living in less interesting times.
Harry threw me off course in episode 48 of Traction Heroes. At first, I thought was reading from a book about mind mapping. Soon, it became clear it was about something else: how to define a clear vision for a team or organization. Visions are notoriously hard to articulate. Drawing a picture — especially a picture of the whole forest, plus the trees — can help. The passage Harry read from Cameron Herold’s Vivid Vision explores this idea: So to visualize something a little more tangible, think about a tree trunk in the earth, inner core with its branches stretching out into the sky. Each of those branches contains twigs extend further out. The mind map works in a similar way, a core that branches out into smaller components. Now, apply this to the world of business. As the leader of an organization, you’re firmly planted at the center, and the various areas that contribute to the business branch out: marketing, sales, engineering, and so forth. With that in place, build off that by describing those branches in about three or four bullet points each. In other words, describe what your marketing looks like and sales and so on until you’ve captured every idea. Remember too that among the branches of your business, you want to consider every aspect of the organization: the vibe, informal codes of conduct, the fiscal environment, the scenery, all of that. Deliberately leave out numbers and data. Get a feel for the place. When you step out of your time machine three years from now and walk around the office, what’s happening? What can you say that is typical of the business three years from now? The mind map is an initial foray into the vivid vision and will act as an outline for the rough draft that you, the leader, will then write. I’ve sketched diagrams before when outlining articles, workshops, and presentations, never in service of aligning around a company’s vision. Harry’s done it several times and found it easier than trying to write it out. Seems useful — check out our conversation for more: Traction Heroes episode 48: Visions
Sharing a few data points because some people did not expect these drives to last that long.
