Matt Pocock shared a /grill me agent skill:

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree resolving dependencies between decisions one by one.

If a question can be answered by exploring the codebase, explore the codebase instead.

For each question, provide your recommended answer.

Incredibly simple, but the times I’ve used it so far it has been incredibly effective. (Almost annoyingly considering the amount of follow up questions you get; for a good cause!)

I’ve recently switched to Current as my main RSS reader. Reeder will always have a place in my heart, but at some point you get to so much unread stuff that it becomes a chore to get through.

Current solves this with “the river”.

The main screen is a river. Not a river that moves on its own. You’re not watching content drift past like a screensaver. It’s a river in the sense that matters: content arrives, lingers for a time, and then fades away.

Each article has a velocity, a measure of how quickly it ages. Breaking news burns bright for three hours. A daily article stays relevant for eighteen. An essay lingers for three days. An evergreen tutorial might sit in your river for a week.

Outlets like The Verge have always been frustrating to follow with RSS because they generate 20+ posts a day and take over your feed. Essays from my favorite blogs often only appear once every few weeks and drown between the noise. The river balances them all out.

Current is made by Terry Godier. He also wrote a beautiful essay on the design decisions he made building it.

Highlights

• I got to the front page of Hacker News with an article that I wrote in one sitting.
• I expect the next few years to be scary for software security.
• I’ve completed the first milestone of my family photo sharing app.

Goal grades

At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals:

If I were to share some thoughts on making a meaningful impact at work, Ben Kuhn’s post would be it. His essay had me nodding yes, yes!, and YES! throughout, and it’s written more eloquently than I ever could.

Don’t rely too much on permission or encouragement. […] instead of asking people for approval to go do something, you can just tell them what you intend to do (implicitly giving them space to object or course-correct if they feel strongly).

You can just do things.

Make success inevitable. There’s a huge difference between the following two operating modes:

1. My goal is to ship this project by the end of the month, so I’m going to get people started working on it ASAP.
2. My goal is to ship this project by the end of the month, so I’m going to list out everything that needs to get done by then, draw up a schedule working backwards from the ship date, make sure the critical path is short enough, make sure we have enough staffing to do anything, figure out what we’ll cut if the schedule slips, be honest about how much slop we need, track progress against the schedule and surface any slippage as soon as I see it, pull in people from elsewhere if I need them…

The hard part is being honest with yourself. I’ve often fallen into trap (1) because I’m afraid my plan will surface failure.

On taste:

I’ve noticed a lot of people underestimate their own taste, because they expect having good taste to feel like being very smart or competent or good at things. […] For this reason, the prompt I suggest here is: what does it seem like everyone else is mysteriously bad at?

Taste isn’t about being the best at something. It’s about slowly lifting the whole by leaving small things in better shape than you found them.

Henrik Warne on the --dry-run flag:

Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option. Other linux commands have this option too. If a command is run with the argument –dry-run, the output will print what will happen when the command is run, but no changes will be made. This lets the user see what will happen if the command is run without the –dry-run argument.

I’ve added a --dry-run flag on scary destructive stuff I’m planning to run on prod. But not as often as I’ve wanted.

The downside is that the dryRun-flag pollutes the code a bit. In all the major phases, I need to check if the flag is set, and only print the action that will be taken, but not actually doing it.

This is one of the things that has become less of a downside with AI writing more code for us. AI helps us write code faster, but what especially entices me is having more breathing room to add affordances like this.