Quoting Murat Demirbas

From Optimize for momentum:

So the trick is to design your workflow around staying in motion. Don’t wait for the perfect idea or the right mood. Act first. Clarity comes after. If a task feels intimidating, cut it down until it becomes trivial. Open the file. Draft one paragraph. Try freewriting. Run one experiment. Or sketch one figure. You want the smallest possible task that gets the wheel turning. Completion, even on tiny tasks, builds momentum and creates the energy to do the next thing. The goal is to get traction and stop getting blocked on an empty page.

Murat is discussing research here, but I’ve found the same process is key in systems design, or writing code or documentation, or drafting a presentation. Getting the project started, and then maintaining a sense of forward progress, is really essential to getting the thing done.

You should be using custom feeds on bluesky

Custom feeds are an underused feature on bsky, and can really improve the experience.

Yes, a chronological feed is nice, but so is an algorithmic or limited feed you understand clearly.

In particular I use…

  • OnlyPosts: Top-level posts from accounts you follow, no reposts or replies
  • For You: It finds people who liked the same posts as you, and shows you what else they’ve recently liked
  • Mutuals: What it says on the tin, just posts from your mutuals
  • Quiet Posters: Highlights posts from people who don’t post frequently

Right now “OnlyPosts” is my default view, and I check out “Mutuals” regularly to make sure I don’t miss things from those folks. “For You” is for when I want to vary it up, and “Quiet Posters” is checked occasionally to surface things I missed.

My Following feed is demoted to the end of the list, and I’ve completely removed Discover.

There are a ton of custom feeds out there, and they’re worth checking out. It turns out algorithmic feeds can be helpful, but it’s nice to understand how they work and even better when they aren’t trying to sell you anything.

2025

2025 was an exciting, difficult, stressful, and very mixed year for me, and I’m really uncertain how to sum it up.

On the positive side:

  • I had a very successful professional year, including several big projects delivered and a nice promotion
  • More importantly, I also felt like my team really got a handle on our overall workflows and processes, getting into a groove rather than improvising (read: panicking) about everything
  • I’ve learned a ton about some technical areas I had never had the opportunity to dig into before, both in my work life and general interests. (So many good books!)
  • I kicked off a new D&D campaign with a group of friends that has been a great source of enjoyment and fun
  • I got to travel and visit with friends I hadn’t seen in a long time, at multiple points in the year
  • We adopted a puppy!
Maddie likes to jump directly at any camera pointed at her, making photos difficult

On the other hand…

  • It was a very rough year on the family health side, with both my mother and my partner struggling with major challenges, as well as a constellation of minor issues such that I never felt like I could really relax
  • While I felt very successful in my professional world, work was also extremely busy throughout the entire year, and I spent basically the whole year feeling like I didn’t have enough hours in the day.
  • The creeping fascism in the United States made my family substantially and materially less safe, as well as adding an undercurrent of dread to the whole year
  • Puppies are adorable but I haven’t had a decent night’s sleep in a month!

Overall if I had to sum up the year in a word it would be exhausting. I genuinely feel like I’ve been running as fast as I can all year, and there are whole months I can hardly remember except as a blur.

I’d love to say I plan to slow down in 2026, and I do hope to make some efforts in that direction…. but realistically none of the complicated areas in my work or my life are likely to change, and the world as a whole just looks more bleak. So a lot of my plans for next year look more like managing the chaos more effectively, rather than expecting it to go away.

Consider your (multiple!) audiences

I’ve been spending a lot of time helping colleagues with communications lately, and one of the refrains I keep repeating is “consider your audience!”

For any given project you’ve worked on, you may need to be able to talk about your work in many different formats. Non-exhaustively, these might include:

  • Working documentation for colleagues within your team, familiar with all the context and able to find and integrate other documentation
  • A detailed report for other experts outside your team, showing all your work
  • A short technical report, also for other experts, but without all the steps shown
  • A one-page executive summary, geared towards decision-makers who are in that fuzzy “informed but not fully expert” zone
  • A less-technical essay in more informal language, i.e. the “blog post” format
  • A single paragraph summarizing key results
  • A 30-60 minute presentation
  • A 5-minute presentation
  • A single bullet point that can go in your resume

Each of these formats is pitched at different audiences — people who have different levels of background knowledge, need different information about the project, and who are willing to spend different amounts of time reading your work. Some formats might work for multiple audiences, but a lot of the time you need to use a different format when the audience changes. IMO there is no such thing as a format that works for everyone!

A common trap I see engineers fall into is thinking that the first version, the detailed technical report, is the only document they need. And that all the others can be produced by just copy-pasting from the detailed report. To some extent that can be a starting point, but each of these different communication formats does need to be tailored to the people you expect to read it!

I also see folks forget that some audiences will not have time for a detailed report. If you’re communicating with a less expert audience, they are almost always going to be unwilling or unable to read a 20 page doc… or even a 5 page doc. These audiences need their own format because you need to be able to provide information at the right page.

Over time, and especially as you get more senior, you will likely need to be at least reasonably good at all of these. In my current role, managing a fairly high-level engineering team, I often need to be able to write all of these for any given project.

Because it’s 2025, many folks will suggest “just use an LLM translate between formats!” That’s not necessarily a bad approach, at least when you’re going from a more detailed document to a less detailed one. I’ve seen LLMs produce some decent executive summaries. But it’s really important to remember that LLMs are just text generators, not experts — you are the one who actually understands your project!

LLMs will also cheerfully invent information, so you can’t trust them to fill in details starting from a summary. (This seems like it should be obvious, but I have absolutely seen people try to use an LLM to produce a detailed doc from a summary — that direction doesn’t work!)

Some personal themes for 2023

Good riddance, 2022

This started out as me trying to write a “year in review” post, but to be honest I don’t have it in me. 2022 was a pretty difficult year for me, and I don’t terribly want to relive any part of it. Various family health issues loom large in that, but a ton of things went wrong.

Instead of looking back at all that, I want to spend some time thinking about how I want the New Year to go. Not in the form of specific goals, though I certainly have those (e.g., I’d love to get in more practice time at curling, and get a better grasp of programming in Rust). But this post is about some general themes I want to try and keep in mind moving forward.

Continue reading

A goal for the new year

Last year was, in many ways, a rather difficult year for me.

There were certainly a lot of good things — we moved into our house, we adopted a puppy, and I switched to an interesting new team at work. But there was also a lot of unpleasantness and stress, and I frequently felt like I couldn’t manage to take a breath for fear of letting some urgent thing go undone.

Some of that is unavoidable, of course. We’re entering the third year of a global pandemic, our political situation in the United States is infuriating and dangerous, and family and work will often pick the worst possible time to spring crises on us.

But in my case at least, a lot of the stress I felt came from how I reacted to things. I felt like I couldn’t slow down, couldn’t sit and think, even though doing so was often exactly what I needed to do. The urgency was often something I imposed on myself, not something that came from the situation.

So, to the extent I have a new year’s resolution, it’s to slow down. To spend more time thinking, and planning, and reading, and less time reacting to whatever I find most stressful in the moment. Overall, to reduce urgency.

We’ll see how it goes, of course. Some things are difficult to control.

SRE to Solutions Architect

It’s been about two years since I joined NVIDIA as a Solutions Architect, which was a pretty big job change for me! Most of my previous work was in jobs that could fall under the heading of “site reliability engineering”, where I was actively responsible for the operations of computing systems, but my new job mostly has me helping customers design and build their own systems.

I’m finally starting to feel like I know what I’m doing at least 25% of the time ? so I thought this would be a good time to reflect on the differences between these roles and what my past experience brings to the table for my (sort of) new job.

Continue reading

Some thoughts after reading Vincenti’s “What Engineers Know and How They Know It”

A few weeks ago I watched Hillel Wayne’s recent talk “Are we really engineers?”, where he looked at the idea of whether software engineers get to call themselves “engineers” or not. (Spoiler: the answer is yes!)

During the Q&A, Wayne mentioned that while he had seen a lot of “philosophy of science”, there didn’t seem to be much “philosophy of engineering” out there. I remembered noticing the same thing, and on Twitter I asked for book recommendations on the topic. The always-reliable Lorin Hochstein obliged, and a week later I had some reading to do!

Just as a disclaimer: this post is very much in theme of “thinking out loud”, and got a little long. 🙂 This is mostly me discussing my experience of reading the book and some thoughts on software engineering I had after reading it. Very likely nothing here is at all original, and I am not an expert, but I wanted to get my ideas down in text after finishing the read. And having done so, I thought it might be worthwhile to share.

Ok, let’s dive in.

Continue reading