DEV Community: Björn Andersson

Your name is still on it — learning to ride the AI motorcycle without crashing

Björn Andersson — Thu, 24 Jul 2025 15:00:00 +0000

A colleague recently said something that’s been rattling around in my head: “AI gives you speed, but it doesn’t give you direction.” And the more I use these tools, the more I think that undersells the danger.

I have been wondering how to think about AIs (or genies) and how computers are like bicycles for the mind, as Steve Jobs put it, and I think these tools take it further. They are more like motorcycles for the mind. They go really fast, and you better not treat them like a bike, because you need to know what you’re doing. How to handle that thing. You need to make sure you don’t try to go too fast too soon, or for too long, because you’ll get speed blind and… things will happen.

I’m pretty sure motorcycle insurance costs way more when you’re in your 20s than in your 40s or 50s. There’s a reason for that. People who are older generally know how to ride the thing, and they’re not as wild when doing it.

But I think when it comes to using AI we’re all kind of in our 20s because we’re figuring it out.

It’s my name on whatever goes out #

I was at a wedding recently, talking to this lawyer, 50s, 60s maybe, working at a multinational. He’s been playing around with AI and feels it’s giving him an enormous productivity boost for writing and doing research for him.

As we were talking about how he was using it he said something that stopped me cold: “It’s my name on whatever goes out.”

He’s already caught the AI making things up. He has to check every line, every reference. He explicitly asks it to give him the references so he can look them up himself. And if I understood correctly, this isn’t significantly different from when juniors do the work for him. Because it was still his name on it. He needs to validate it. Whatever he puts his name on and sends out has to be right.

And that’s when something clicked for me. Remember how I was talking about the different hats we wear? Well, here’s the thing: you can outsource wearing the hat. You can have the genie do the work. But it’s still your name on it. No one else cares if you outsourced it, they only see your name on it. You can’t blame the genie for a shit job. It was your name.

What we think we’re automating #

I keep hearing engineers say, “oh, I don’t have to do this boring thing anymore!”

Meeting notes are a perfect example. I have access to Google Gemini at work, and people just let Gemini take meeting notes and send them out without reading them. Really. “Huh?” I hear some of you say now, that’s what it’s great for, the notes are just toil. Well, no, what are meeting notes actually for? They’re about making sure we’re on the same page, that we have the same agreements and understanding. If you let the machine mindlessly capture words and don’t check that it actually documented the meaning behind what we said and understood, you’re failing at the actual job of running that meeting.

This reminds me of Chesterton’s Fence, that principle about not removing a fence until you understand why it was put there. Before you automate away some “boring, pointless thing,” maybe ask yourself: why is it that I’m doing this in the first place? Because if you don’t understand why it’s done, how do you know the automation did it well?

And I wonder if what’s really happening is that we’re not automating the work, we’re automating away our attention to the work. We’re not automating the output. We’re automating away our understanding of what that output should be. And here’s what we lose: experienced people are the ones who spot strange patterns (or have taste) precisely because they’ve stayed engaged with the work over time. You can’t develop that instinct if you’re not looking.

The work worth doing #

Which brings me to something eyebrow raising that Kent Beck said: with AI, 90% of his skills became worthless, but the leverage of the remaining 10% is now worth 1000x. The question is: which 10%? This is the “knowing where to put the X” skill, that judgment call and experience you bring: that’s what makes the genie do what’s needed.

When you let the genie write code for you and it introduces bugs that you would have caught if you’d actually read the code… you’re not doing your job as a product engineer. Yeah, you’re slinging more code and doing it faster. But it’s not about the code, it’s about delivering the solutions we need when we need them.

There’s a difference between delegating execution and delegating responsibility. You can have the genie execute tasks, but you can’t delegate the responsibility for the outcome. That’s still yours. The hat is still on your head, even if AI is helping you get things done faster while wearing it.

And here’s the thing: there’s pride in doing the work well, even the boring bits. Sometimes we might not enjoy the work, but learning to enjoy doing it well will make most things worthwhile. Because there’s value in knowing how to do it well, in understanding why it matters.

Finding your balance #

The question isn’t “can the genie do this task?” It’s “when it does this task and puts my name on it, am I comfortable with what might happen if it gets it really, really wrong?”

In my experience, the engineers who are using AI most effectively are the ones who treat it like that lawyer treats it: as a powerful tool that still requires their full professional judgment. They understand they’re being paid for the judgment part of the work, not just the execution part. The genie can help with execution, it can draw lots of Xs quickly. But knowing where to draw them? That’s all you.

Right now, these systems can’t truly understand context the way a senior does. They can’t make actual judgment calls, they’re pattern matching (even if, admittedly, slightly magical in how they do it). They give us speed, not judgment or direction. Output, not understanding.

I’m still working out what learning looks like when AI can show you all the moves. My cooking has genuinely leveled up with an AI coach: I’m making dishes I never could before, and understanding why certain techniques work. But I know this is like training wheels. I couldn’t fully do this alone yet, and that’s the thing: I’m not mistaking this speed for actual skill, not confusing making progress with real proficiency.

So here I am, learning to ride this thing safely, trying to get out of my AI twenties you might say, before I take it on the highway.

Because whether you’re wearing your engineering hat, your architect hat, or your team lead hat, your name is still on it. And I’d like to make sure I am not only wearing the helmet but also know how to ride this motorcycle before I really open up the throttle.

Which hat are you wearing? ...you wouldn't wear a beanie to the beach

Björn Andersson — Sat, 12 Jul 2025 07:06:00 +0000

I was in an incident review recently where one of the problems was a human going too fast. This process is very manual, repetitive, and boring, and it rarely fails, so we skip some steps. That mostly works (see Why Do Things Go right?), except when it doesn’t. Ripe for occasional issues and likely in need of automation.

I believe we often skip steps because we don’t know why we do them. It’s not tedious for tediousness sake, it’s often there because it’s important. And until we have the automation, or maybe we’ve intentionally chosen not to automate it, we need to find some way of helping the human ’live the situation.'

Which reminded me of this Terry Pratchett quote: “Every trade, every craft had its hat. That’s why kings had hats. Take the crown off a king and all you had was someone good at having a weak chin and waving to people. Hats had power. Hats were important.”

And there’s something to this, right? Like in my own role as a principal engineer, I am definitely seen as my role more often than I am the person beneath it. When people see me in a meeting, they see the title first. Hopefully I provide valuable insights and useful things. But even if I provide absolute garbage input, there’s a significant chance people will listen, and maybe even not push back, because of the hat.

But, I have been wondering: what is your role and what is your ownership? What is it that you individually provide to whatever work you’re doing? And is it always the same hat?

The hat you don’t know you’re wearing #

I think your hat changes depending on the role you’re fulfilling at the moment. When you’re working as a software engineer, you wear an engineering hat where you think about the feasibility of what you’re building, like, can I maintain this thing long term, how far will it scale, and how testable is this design?

But if you’re working as a product engineer, you’re probably first thinking about how do I get this damn thing out the door, so you can see if it works or not. It’s about trying things, slapping it together, flinging it against the wall with the smallest responsible amount of tests (so you know you don’t break existing things when you iterate), and see what sticks.

I’ve noticed, though, that we often forget to switch hats when we need to.

Take deploying to production. When we’re about to take something live, we should be wearing a different hat. We need to embody the spirit of production itself, become its guardian of stability (yeah, yeah, too many roleplaying games). Some orgs have a “release manager” as a dedicated role, but even if it’s not a dedicated role, the need is always there. Taking things live is one of the most dangerous things we do: because most incidents happen when we change something. Whether it’s config, a flag, or code.

The product engineer hat and the production guardian hat often feel very similar, and that’s exactly the problem. Just because a hat is similar doesn’t mean it’s the same. The product engineer wants the experiment live yesterday. The production guardian knows we can only ship today, and wants to make sure we still have a tomorrow. It’s this impossible tension, one person wanting to have already finished something we haven’t even started, the other pumping the brakes to make sure we don’t break what’s already working. And that often leads to “safety theater,” where we do it a little bit slower, say 30m to get everywhere instead of one quick change, to catch disasters but not slow burn issues. Obviously this tension changes, to use Kent Beck’s 3X model, depending on whether you’re in eXplore, eXpand, or eXtract mode. We’re mostly in eXtract, so breaking things affects a lot of customers and the production guardian hat needs to be especially strong.

For example, in another incident, someone didn’t manually check dashboards after deploying, which was part of the process, because they trusted the automated alerts. The alert came in after 10 minutes when it had enough data to be sure it wasn’t temporary. But a human who was actually monitoring, really living that production guardian role, would’ve realized something was wrong within a minute or two. The manual step was there because the team knew their automated alerts weren’t good enough to handle all issues around deployments.

Where I work today, we have some 250 backend components. We can test all we want, black box integration tests, contract tests, end-to-end tests, manual QA, all of it. We’re still going to miss and get stuff wrong sometimes.

The point and our challenge in mindset is: when we’re taking things into production, we’re not wearing the hat of the product engineer anymore. We’re taking on the role of production’s guardian, and we’re shepherding changes safely into production.

It’s like Vim modes, but for work #

Say whatever you want about Vim, but one really nice thing is that it’s modal. The idea that I’m now doing this thing (inserting or editing text), and now I’m doing this other thing (normal or moving and transforming), and you behave differently in those modes.

I see this in my own work all the time. I regularly review my own PRs because even though I went through everything when writing my commit message, I invariably look at it differently when I’m on GitHub in the interface I use for reviews. I switch much better into reviewer mode when I’m leaving comments there. It’s common that I review and leave myself comments for what to fix, discover I need a comment, or elaborate a little bit further on something the reviewer might not be familiar with.

It’s like TDD in a way. When you’re red, you rush towards green by just getting it to work in the simplest way you humanly can. Then, when it’s green, when you got it working, you refactor it. Different modes, different goals.

We need to be more intentional about which hat we’re wearing at the moment.

Becoming the character #

I saw this story about Christian Bale recently (and look, I can’t find the original source, so this might be one of those stories that’s too good to fact-check, but it perfectly captures what I’m talking about). He’s a famous method actor, someone who becomes their characters completely. Apparently, when he wasn’t getting much work, he dreaded having to read through his insurance contract and have that conversation because it was boring.

But then he decided: if I were a character who really cared about understanding insurance thoroughly, who would want to have an informed conversations about it… So he became that character and called up his insurance company. Apparently, they’d never talked to someone so well-researched on their contract.

And that’s the thing, we kind of need to do this throughout our day. When you’re taking something live, you’re not the “ship fast” product engineer anymore. You have the right to say no, the right to say this has to be done slower because of these risks. Your responsibility is to make sure production is stable and things will continue to work.

The $9,999 skill #

There’s this great story about Charles Steinmetz and Henry Ford. Ford’s engineers couldn’t fix a generator problem, so they called in Steinmetz. He spent two days just listening to the generator and scribbling calculations. Then he climbed up, made a chalk mark, and told them to replace sixteen windings at that exact spot. It worked perfectly.

When Ford got the $10,000 invoice, he asked for an itemized bill. Steinmetz sent back:

Making chalk mark: $1
Knowing where to make mark: $9,999

And think about what Steinmetz did: he could have torn the whole generator apart, called in a team of engineers, or tried a dozen different approaches. Instead, he recognized this was a moment for careful analysis. He spent time listening, thinking, calculating. He put on his expert diagnostician hat, not his collaborative problem-solver hat or his hands-on mechanic hat.

And this is it exactly. Knowing where to make the mark, knowing which hat to wear when, that’s the $9,999 skill.

But it’s not just about perspective: each hat comes with different expectations, different powers, different rights, and different responsibilities. The production guardian has the authority to halt deployments. The incident responder can stop all feature work immediately. The planning hat carries the responsibility to think long-term even when it slows things down. When you put on a hat, you’re not only changing how you think and approach the situation: you’re claiming the legitimate authority that comes with that role.

I think that we often fail not because we lack skills, but because we’re wearing the wrong hat for the moment. Or worse, we’re trying to wear all the hats at the same time.

The product engineer hat wants speed. The production guardian hat wants stability. The incident responder hat wants recovery. The planner hat wants predictability. These aren’t compatible mindsets, you can’t optimize for all of them simultaneously. The goal is to negotiate productively across them, which is hard as one person, and, this is also why working through problems with others is so powerful.

THE INCOMPATIBLE MINDSETS
Product Engineer 
 → Wants speed (ship it yesterday)
Production Guardian
 → Wants stability (safety today, here tomorrow)
Incident Responder
 → Wants recovery (fix it now)
Planner 
 → Wants predictability (sustainable pace)

So here’s what I’ve been trying to do, or rather, what I should start doing: be explicit about which hat I’m wearing. Right now I say things like “okay, from a stability POV” before raising concerns about deployment risks. But I should actually say, “let me put on my production guardian hat for a second.” It helps others understand which perspective I’m bringing, and it helps me focus on what matters for that role.

Tying it on #

I think there’s more to the hats we wear throughout the day because it’s not just at work: supporting partner, fun uncle, mentor, learner. Each comes with different expectations, powers, and responsibilities.

But for now, I’ll leave you with this: What hat are you wearing right now? What are the expectations that come with it? What responsibilities? And more importantly, is it the right hat for what you’re trying to do?

Because understanding when to switch might be one of the most underrated skills we need. I’m currently convinced that being intentional about our roles, knowing which hat we’re wearing and when to change it, that makes a difference. Not between being good or great, but between solving the right problems and creating new ones.

What would change my mind is if someone showed me that this context-switching has too much overhead. But, I think these aren’t the context switches we usually complain about, the ones that kill our flow when we jump between meetings and deep work. These switches are within the same context we’re already working in. We’re just tilting our perspective, changing how we evaluate the situation. And in my experience, the cost of wearing the wrong hat is far higher than the cost of being intentional about switching.

Working with Go's test cache on CI — be fast by avoiding work, while doing the important work

Björn Andersson — Mon, 07 Jul 2025 13:50:00 +0000

I was trying to speed up our slow CI by caching Go builds. The easy win was caching Go’s module downloads (via GOPATH), but when I added GOCACHE for the build cache, I got a pleasant surprise: the tests were caching too. 🥳

I shared the change for review, and a colleague raised a great point: “What about our black box integration tests?” These tests hit APIs and external services that Go can’t track as dependencies. If they cache when they shouldn’t, we might miss real failures: the tests would pass because they didn’t re-run, not because the code actually works.

The Fundamental Problem #

When my colleague warned me about integration test caching, I realized we had a bigger problem than just my PR. How could I fix this across our entire org? We’ve got ~250 repos, and asking every team to remember special flags or change their test execution wasn’t going to fly. I needed something that would just work everywhere with minimal changes.

The fundamental issue: our black box integration tests don’t “declare their dependencies” to the Go compiler, so it doesn’t know that something the test is critically dependent upon has changed and requires a rerun (and practically, neither do we really), because they test network services and external binaries that Go has no visibility into. I always have to run these tests.

I wanted the caching benefits without the risk, ideally with minimal changes since we have lots of codebases that could benefit from this caching improvement. Since our black box integration tests use a shared internal library, I was hoping to find a solution I could implement once there rather than asking teams to modify individual tests or change how they execute them.

So… How Do I Make This Work? #

I started by looking for the obvious solutions, there’s probably a flag to ignore the test cache, right? And there were two straightforward options: go clean -testcache and --count=1. But here’s the thing, both of them throw away ALL test caching, which felt like using a sledgehammer when I needed a scalpel.

Then I remembered reading something about environment variables, and files, affecting test caching. I went into go help test and I remembered right, tests that read environment variables get invalidated when those variables change, so since this is about CI, and I know that CI systems give us unique commit SHAs as env vars… and we have a shared library to help write black box integration tests… so I can make the fix once in that library and everyone gets this benefit!

Alright, that gives me three options, how do they compare?

Simple Option: go clean -testcache

Pro: Dead simple - add one line to your CI config, no test changes needed
Con: Zero caching benefit for tests
When to use: Safest solution that still gives you build benefits without changing scripts or tests

This works by creating a file with the current Unix time in nanoseconds and then, whenever Go runs tests, it checks if the cached test is newer than that timestamp. I appreciate the simplicity: the cache cleaner doesn’t need to understand which cached items are tests (and there are only hashes in that folder), it just sets a “tests are invalid after this moment” marker and the code skips it or not.

Explicit Option: --count=1

Pro: Granular control per go test invocation
Con: Need to change test execution and remember it everywhere, easy to miss (especially in monorepos with many go.mods)
When to use: Only some tests need cache invalidation

This is the one you’ll see when people ask how to make Go not cache tests, for our situation not super useful, but mentioning it for completeness.

Elegant Option: Environment Variables

Pro: Automatic cache invalidation on CI when needed, maximum caching benefit when possible
Con: Requires thoughtful test design
When to use: You have enough tests that the speedup matters and you’re willing to be intentional about cache invalidation

Or laid out visually:

Approach	Changes Needed	Test Caching	Safety
`go clean -testcache`	CI config only	❌ None	✅ Safest
`--count=1`	Every test invocation	❌ None	✅ Safe
Environment variables	Shared code/library once	✅ Full	✅ Safe*

*When implemented correctly

How the Environment Variable Approach Works #

This works because Go invalidates the entire package’s test cache whenever an environment variable it depends on changes, and most CI systems expose a unique commit SHA as an environment variable. For example,

GitHub Actions: GITHUB_SHA
Drone CI: DRONE_COMMIT_SHA

When your integration test reads this variable, Go automatically invalidates the cache for that package whenever you push new code. The key insight: you don’t need to use the variable meaningfully, just read it. One thing to keep in mind: consider keeping integration tests in separate packages from unit tests to avoid invalidating unit test caches unnecessarily when only the integration tests need cache invalidation.

package integrationtesting

func IsIntegrationTest(t *testing.T) {
    t.Helper()
    // This ensures that we invalidate the cache
    // on CI whenever we have a new git SHA
    _ = os.Getenv("DRONE_COMMIT_SHA")
}

// ... another file relying on integrationtesting

func TestAPIIntegration(t *testing.T) {
    integrationtesting.IsIntegrationTest(t)

    // Your actual integration test
    resp := callAPIEndpoint()
    assert.Equal(t, expected, resp)
}

Understanding How It Actually Works #

I was getting worried about edge cases. The Go docs said tests won’t cache if environment variables change, but what exactly did that mean? Would reading an env var in one test invalidate all tests everywhere? Just that package? What if the variable is read through a library call?

I did some searching and found the testlog package, which is how Go implements the tracking of when env vars are read and files opened. That gave me a good sense of how it should behave, so I made an experiment to validate what I expected from the documentation and the code I found.

The Experiment Results #

I created three test packages to understand the boundaries:

One that reads DRONE_COMMIT_SHA directly
One that reads it through a library call
One that doesn’t read any environment variables

Then I ran nine scenarios to test my assumptions: What happens when I set the variable? Does package listing matter (./... vs manual package lists)? What about go test with no arguments?

Key findings:

Package-level invalidation : All tests in a package get invalidated if any test reads the variable and the variable changes,
Library calls count : Reading env vars through dependencies still invalidates the cache
Package listing doesn’t matter : ./..., manual lists, even ./ all cache the same way
No arguments = no cache : go test without targeting never caches
File-level targeting = no cache : go test file_test.go also never caches

The big takeaway: Go runs tests per package, and packages are run in parallel. If any test in the package touches an environment variable, the entire package’s cache depends on that variable’s value, so the cache is invalidated when the value is different on the next run.

Or as a semi-flowchart:

Package reads env var? 
 Yes → Env var value changed? 
 Yes → Cache invalid
 No → Cache valid
 No → Cache valid

This made me comfortable that the approach was predictable and wouldn’t have surprising edge cases, especially because the way testlog works is by simply recording that something called os.Getenv with this value, and it doesn’t know which test or from where, just that in the course of running these tests this happened. Nice and simple.

If you want to explore how Go makes decisions around caching yourself, you can run tests with GODEBUG=gocachetest=1 to see Go’s caching decisions in real time. There are more debugging variables available in go help cache.

The Results #

We cut our CI times in half with this caching approach, and I’m confident it’s safe to roll out widely because I understand exactly how it works and I can make the required changes to our shared integration testing library so it will just work for the standard case.

What I appreciate about Go’s design here is how it avoids clever optimizations in favor of predictable behavior. I knew caching wasn’t just on/off, but I wasn’t sure if there would be complex edge cases to worry about. Instead, Go picks the straightforward solution: package-level invalidation that’s easy to reason about.

The “bigger packages than you think, but still not huge” philosophy means we get plenty of caching benefit, while keeping the invalidation scope manageable, and if we need finer control, we can always split into more packages.

And that’s the thing, Go just picks the simple and boring solution that works, it’s why I love working with Go. 😁

The full experiment is available if you want to dig into it yourself.

Running effective meetings uses the same skills as running successful projects — from meeting minutes to project milestones

Björn Andersson — Sat, 03 May 2025 08:20:00 +0000

You’ve probably sat through your fair share of meetings where time slips away as conversations wander aimlessly, not unlike being dropped into an unfamiliar codebase, with twisting branches all alike.

A colleague asked for feedback on a meeting they ran, and after sharing my thoughts, I realized my advice about meetings sounded exactly like how I talk about planning projects. This got me thinking: the skills for running good meetings and successful projects are nearly identical.

Yet somehow, we still treat our meetings like they’re different beasts entirely. Why do so many meetings fail? Usually because we approach them without a clear plan.

Meetings are often run like debugging without a hypothesis, just throwing log statements everywhere and hoping something works, where you have a list of topics but no clear goals or time constraints. You might cover everything, but that’s more luck than design.

This is similar to “planning forward” in projects: We start with a feature list without understanding the details, create up-front timelines in Gantt charts that rarely get revised, and postpone integration until the end. We move through tasks sequentially, assuming everything will go right, only to discover problems when time is about to or has already run out.

Both approaches ignore that time runs out, whether in a 30-minute meeting or a three-month project. Without a plan, meetings go nowhere and projects fall behind.

In my experience, here’s what both have in common:

Gather everything that needs to get done
Clarify goals for each item
Group similar things together
Prioritize the important stuff first
Estimate how long each section will take
Guide the work to keep it on track
Define next steps so everyone knows what’s happening after

The pieces #

Let’s break down each of these components and see how they apply specifically to meetings:

1. Gather: Define your scope #

Just as you wouldn’t start coding without requirements, don’t start a meeting without defining what needs covering. List all topics and be realistic about what fits in the allotted time. If your meeting scope looks like your backlog after a year of “we’ll get to it later,” you’re doing it wrong.

2. Clarify: Set measurable goals for each topic #

For each topic, be clear about what you’re trying to accomplish:

Discuss: “We need to decide on auth providers. What criteria should guide our recommendation?”
Decision: “We recommend Provider A because…”
FYI: “We’ve implemented the new provider in staging and learned…”

Pro tip : Prefix each agenda item with one of these categories (Discuss/Decision/FYI) to ground everyone in what you’re trying to accomplish with each topic.

3. Group: Combine related topics #

Identify when similar items come from different people and combine them. This prevents redundant discussions and gives a clearer picture of what needs attention, similar to combining related user stories into an epic. When several people raise the same issue in different ways, it’s usually important.

4. Prioritize: Focus on what matters #

Sequence by importance, not by who talks loudest or which item has been sitting on the agenda longest. Start with critical items so when you inevitably run out of time, at least the important stuff got done.

5. Estimate: Time boxing #

We accept that iteration estimates will be wrong (it’s just a question of how wrong), and meeting time estimates work exactly the same way. Having a clear time target keeps everyone aligned. Be explicit about constraints: “We have 15 minutes for this topic” creates healthy pressure to stay focused.

6. Guide: Keep discussions on track #

Just like daily standups in project work, regularly check in on your meeting’s progress. Help nudge the meeting along:

Monitor progress toward goals #

Just like in daily standups, pay attention to whether the discussion is moving toward your goal. Ask yourself, “Are we just talking, or are we getting closer to making a decision?” If you’re 10 minutes into database options and no one has mentioned the actual requirements, it’s time to refocus.

Keep discussions focused #

When someone goes off on a tangent describing an intricate edge case, redirect with: “That sounds like an important edge case. Will this affect the decision we’re trying to make right now? If not, could you chat with the relevant team after this? Right now we need to focus on making our decision.”

Provide time checks #

My rice’n’garlic advice is to check in halfway through a conversation and remind everyone of the time left. Sometimes simply saying “We have 7 minutes left to decide on this” creates the right pressure to wrap things up. If needed, quickly restate the goal: “Remember, we just need to agree on which two options to research further, not make the final decision today.”

Make realistic time decisions #

Be realistic about whether you can finish in the time you have. If a 15-minute agenda item is turning into a 45-minute discussion, decide whether to:

Extend the current meeting (if everyone can stay)
Schedule a follow-up with just the key stakeholders
Assign someone to gather more data and come back next time

7. Next steps: Ensure clear outcomes #

Don’t let topics end without everyone knowing the outcome. For each item, ensure everyone knows:

Is it done or still open?
Who owns any follow-up actions?
When should we expect progress?
How will we track it?

Capture this in your meeting notes. Don’t rely on memory. Write down the decisions, owners, and deadlines so our future selves can thank us.

In practice #

Different meetings need different approaches, but a well-run meeting follows the same meta structure. This structure works for all kinds of meetings: one-on-ones, planning sessions, even technical architecture reviews, because the topics and participants change, but the structure that makes meetings effective doesn’t.

Let’s see how this structure looks in practice with a couple of common meeting types.

Retrospectives #

Retros help teams reflect on what worked, what didn’t, and what to improve, much like code reviews but for your processes.

Gather : Have everyone add topics to a shared retrospective board
Clarify & Group : Cluster related topics to understand common themes
Prioritize : Vote on which issues will have the most impact to address
Estimate & Guide : Timebox discussions, default 3 minutes per topic, explicitly decide to extend or move on
Next Steps : Capture clear action items, owners, and timelines

Pro tip : Seeing the same issues iteration after iteration? Try a reverse retrospective where you start with known problems and dedicate the entire session to brainstorming solutions.

Recurring team meetings #

Regular meetings work best with a consistent structure, like good software needs a reliable architecture.

Gather : Maintain a living document where people add items between meetings, plus time at the start to add more
Prioritize : Critical conversations happen first, not just what’s been on the list longest
Clarify : Define each topic’s goal and intended outcome (FYI, discussion, or decision-making)
Estimate : Allocate time to topics based on importance and complexity
Guide : Check progress mid-topic with “Are we getting closer to our goal?”
Next Steps : Note who’s doing what by when

Pro tip : For complex topics, try a silent meeting approach where everyone reads and comments on a shared document before discussion. This helps people think deeply, solve quick questions in writing, and prevent a few voices from dominating.

The meta-skill #

Running a good meeting uses the same mental muscles as running a good project:

Scope definition is like requirements gathering
Timeboxing topics is like defining iterations
Progress checks are like standups

If you can’t keep a 30-minute meeting on track, how will you keep a three-month project on track? Both require the same core skills:

Clear Goals : “We want to discuss database options” is as useless as “We want to build a better app.”
Risk Management : Put risky, important topics first, whether in meetings or project timelines.
Progress Monitoring : Regularly ask: “Are we moving toward our goal or getting sidetracked?”
Flexibility with Discipline : Sometimes you need to extend a meeting or an iteration, but do it consciously, not by default.
Follow-through : Track action items like you track bugs, they’re just as important.

I wonder if running meetings could be good practice for running projects? The skills are similar, but the feedback cycle is much shorter.

Conclusion #

Every engineer knows that a well-designed system needs both good architecture and regular maintenance. Your meetings are no different.

By applying the same structured thinking to your meetings that you use in your code (defining clear requirements, managing scope, prioritizing effectively, and documenting outcomes), you transform the meetings in your calendar into productive work sessions.

In my experience, these skills compound nicely. I bet you’ll get better at delivering focused projects as you get better at running focused meetings.

So before you schedule your next meeting, run it through the same mental checklist you’d use for planning a project:

Have you gathered topics and defined what you want from each one?
Have you prioritized what matters most?
Can this all get done in the time you have?
Do you have a plan to keep discussions on track?

Keep in mind that guiding meetings is a lot like incident response. You can plan all you want, but you need to react to what’s actually happening. This framework gives you a starting point, but the real magic happens when you apply it in the moment. Start small by focusing on timeboxing discussions or defining clear outcomes. The structure matters, but how you adapt when the sewage hits the aerowatt generator is what really counts.

If not, refactor before you commit.

Efficient meetings aren’t magic. They’re just good engineering applied to communication.

Day-to-day automation using Alfred on your Mac — reducing TOIL outside of your DevOps practice

Björn Andersson — Mon, 15 Apr 2024 11:15:00 +0000

I try to be aware of where I have friction in my day-to-day when working at my computer, keeping an eye out for TOIL to remove. Whether it’s from manually repeated actions, or from differing behaviors across apps and services I use. When I identify any of these I try to spend some small amount of time automating or changing how I work to improve.

All of these things don’t necessarily make a lot of sense from how much time I save, but, it also makes me happy to spend a bit of time improving my environment, and spending a bit of time to make me happy is good enough for me.

I view doing these kinds of small workflow improvements like a kata because it improves my automation/scripting skills and encourages me to think about how I work. I usually give myself 10-20m to try and make these kinds of improvements just so I know how much time to spend. Just don’t go overboard. XKCD, as always, have a comic to illustrate the downside of going too far. 🙂

What is Alfred and why is it an app I’m focusing on? #

Alfred is an application launcher but oh-so-much-more. It connects with macOS and the Workflows contains a lot of extensions that allow you to interact with all kinds of programs, websites, etc.

A big part of what Alfred has helped me create is a more unified experience across the apps and websites I use. I have moved some operations that behave differently in different apps into Alfred because then I can focus on what I need to do and then use Alfred to provide consistency (and as I’ve been told, “consistency is good even outside the bathroom”).

Now, let’s look at how I use Alfred.

Built-in functionality #

These are features that don’t require anything extra to install and use.

Open an app #

Alfred’s starter feature is the application launcher, and it means you summon it with a keybinding and type the name of the app you want to start and voilà. I have bound the keyboard shortcut to cmd+space and replaced the built-in Spotlight search.

Spell / define #

There are certain words I rarely get right (continuous) and some words are spelled very differently from how they sound. Summon Alfred andspell <word> and you’ll have suggestions that often will go right. And if you don’t find it, replace spell with google and see if Google knows better. Hit enter to copy the correct spelling to the clipboard.

And define is the same thing but for dictionary lookup because you have some word you’re unsure what it means, or because you’re wondering if someone was trying to call you something you with some subtle nuance to a word. 😉 Hit enter to open the definition in macOS’s dictionary app.

Calculator #

You can give it an expression and when you hit enter the result goes into the clipboard. I often end up using this instead of opening a Python console on the CLI.

Custom web search #

A custom web search allow you to quickly open a web browser at a particular website with whatever value you’ve typed into Alfred which doesn’t have to be a search engine or even a search page.

To configure a custom web search summon Alfred and hit cmd+, to open the settings page. Go into the Features tab and click on Web Search.

Some example search engines I have made:

Jira: https://jira.example.com/browse/{query}
- This isn’t a search but rather the view this ticket. Because I often get a ticket id (either from a commit message or someone rattling it off in a meeting) and this way I can open it quickly
Confluence: https://confluence.example.com/dosearchsite.action? queryString={query}
Wordnik: https://wordnik.com/words/{query}
- So I can find synonyms and other alternatives for words. Often use this when I want to find a good name for something which has been inspired by Hunting for great names in programming.
Pypi: https://pypi.org/project/{query}
- To look up python packages ## Working with other applications #

Alfred has ended being the tool that brings my apps to focus and smoothes over differences between apps.

Give my most common apps a keybinding #

Instead of cmd+tab between the various apps I’m using I have bound specific keybindings to my most used app, so I can quickly swap between them. Hat tip to Rico Sta. Cruzwho blogged about this a couple of years ago and who I picked it up from.

The big benefit I have found here is just the ease of being mid-thinking and wanting to switch back to another app, whether it’s to jot down a quick note, to finish that Regex you were visualizing on Regex 101, or to get back to Slack to paste that thing your colleague asked for. It feels so seamless compared to tabbing between.

This is using Alfred’s Workflows, and they’re part of their advanced set of options. You can do keybindings that work across all of macOS as well as actions based on what you’re typing.

Spotify controller #

I have been using these keybindings since before Alfred, in Quicksilver, and there are other workflows for Spotify but since I had these I never bothered installing anything else.

The cool extra in this workflow is that I added a keyword to open the current playing song on Genius.com because I like reading the lyrics.

This is an example of something where the automation is _far from necessary,_but, I enjoyed adding it. It’s something I do every other week and knowing I can just go straight into the song nearly every time is great.

My Spotify workflow is on Github if you want to install it, or here’s a gistif you’re just curious how I made “open on genius.”

Global microphone mute/unmute shortcuts #

I regularly use Google Meet, Slack, and Zoom for talking with people, and these apps all use different shortcuts to mute. So instead of keeping the app focused and remembering the various shortcuts I now just leave myself unmuted everywhere and directly mute/unmute the OS through Alfred. My mic has a visual indicator when it’s on. +I have a notification posted, so I can see the current status on the screen.

As I started using this workflow I realized that sometimes the microphone bugs out but swapping it between the built-in and back will fix it. So after a while I made a script to help swap as well.

And finally, I realized that sometimes my virtual soundcard which removes background noise (krisp.ai) hangs and needs to be restarted, so another keybinding to quickly restart the soundcard.

The only downside of this workflow is that others can’t as clearly see when I want to speak by unmuting myself in the current app, so in those rare cases I’ll use the mute in the app itself. Because optimizing my workflow shouldn’t come at the pain of everyone else, we live in a society. 🙂

This mute/unmute workflow is available on Github, and here’s a gist if you want to see the toggle code. My dotfiles got the swap mic script and the restart krisp script.

Improvement to my day-to-day workflow #

Text replacement / snippets #

Snippets are short pieces of text that expand into something else. It can be a static string, or it can be dynamic and I use both kinds as I work. For me they fall into these categories

“Named paste”, things that are hard to remember or unwieldy and are now not
Dynamic replacement, something that follows a pattern and I want to swap between. Generally these use the clipboard
Generated inputs, I need the current time in a specific format or some other piece of data

You configure snippets by summoning Alfred and hitting cmd+, which opens Settings, then go into Features -> Snippets. Snippets work by specifying a keyword, in my default bundle I require that my keywords are prefixed with \\, meaning that Alfred will expand my snippets if it sees \\<keyword> and with the example keyword exp you’d then type \\exp to add it. If you need to type the exact string for some reason it’s easiest to add a space somewhere before you type the last character and then go back and remove it.

My trigger for creating a snippet is finding that I keep typing or pasting the same thing again and again.

Let’s look at how I use them in a couple of different places.

GMail #

Finding emails from “unusual senders:” I label the majority of emails I get at work as they are notifications or otherwise automated emails. So if I get something that isn’t labeled it’s probably a human or something I need to look into, and it can sometimes get hidden in a sea of everything else.

<prefix>gmailn in the search bar turns into is:inbox is:unread has:nouserlabels which only shows unread emails in the inbox which doesn’t have a label.

When I’m processing my labels, which are effectively buckets of things to do, I often go into a label and want to see only the unread items, so I can open the first and then go through them one-by-one. So open the label, focus on the search bar, and type in <prefix>unr to give me is:unread and then get to that focus.

Jira tickets #

If I’m writing a message on Slack and I need to reference a ticket I think it’s nice to give a link even if I only have the jira ticket ID, so I made a snippet that adds the current clipboard item at the end of my company’s Jira instance in a Markdown link. Now it looks nice where markdown is and the other person doesn’t have to open it up themselves.

Copy WRK-123 and then type <prefix>jiramd which replaces it with[WRK-123](https://jira.deliveryhero.com/browse/WRK-123).

The Alfred snippet configuration

[{clipboard:trim}](https://jira.example.com/browse/{clipboard:trim})

Roam Research #

Roam is my notetaking app and where most of my thinking happen and I have a whole slew of replacements for how I work with Roam Research and most of them are to help me keep my workflow consistent (using the right tags) and to make common actions easier and faster.

<prefix>rts turns into the current time in bold since I practice interstitial journaling. Example **15:03**. Snippet configuration: **{time:short}**
<prefix>b<shortcode> for how I bucket tasks so when I spend time on a particular bucket I can find the things I need to do. I.e. my bucket “Life in Production” (on-call, observability, continuous delivery, etc.) is prefixed with <prefix>bl and that turns into [🥬]([[Bucket/Life in Production]])
<prefix><INITIALS> to turn into the name of my most frequent collaborators at work, so I can tag what I’ve said to them or a task we need to do.

Emoji search #

Spending a lot of time communicating across continents involves timezones and people rarely hearing your voice, so I have gotten used to peppering my inputs with emojis to help since it’s so easy to come off sounding like an ass otherwise.

And because some websites or applications don’t have a good search for emoji and this way I only have to learn one keyboard shortcut and normalize it across places. This way I don’t have to remember how Slack named this emoji vs. Miro vs. Google Docs vs. Confluence vs. other random website. I just learn it in Alfred and then paste it straight into the textbox I wanted.

This is an external Workflow made by James Sumners, and you can download it from the workflow’s Github page.

Generate uuids on the fly #

As I was writing the tying it up section I realized that I had a recent pain which where I kept jumping between apps to create new UUIDs. I was running the following command on the CLI and then pasting it into some yaml files in my editor.

uuidgen | tr '[:upper:]' '[:lower:]' | tr -d '\n' | pbcopy

So I instead created a new workflow that is triggered by a snippet that runs this for me.

Note: To make it behave just like a regular snippet you need to configure the Copy to clipboard output to Automatically paste to the frontmost app and Mark item as transient in clipboard.

The uuidgen workflow is available on Github.

Other workflows #

Some other workflows I have installed since they save me time.

Calculate Anything #

I installed this for two reasons: to quickly translate cooking recipes using imperial units into metric and currency conversion. Super convenient and now I can finally get how much 16 floz is in ml (473.176) without needing to go online.

By Biati Digital and available in the Alfred Gallery.

Epoch converter #

There was a time when I kept looking at unix timestamps and needed to quickly get when it was, so copying and then ts <paste> gave me when it was andts without anything will give you the current unix timestamp.

By Julien Lehuen and available in the Alfred Gallery.

Tying it up and how I figure out what to add #

I hope the above gives you some ideas or inspiration for what you could do to improve your day-to-day computer usage. These are things that I’ve pulled together over years, and similarly I have a bin/ folder with other types of automation I’ve accrued, hehe. 😅

Now, how have I accrued these things? I generally try to reflect on the work I do and the biggest help to it has been scheduling 30min every Friday to reflect on the week. This session covers everything from updating my brag document to reflecting on what work I felt I repeated a lot and whether there’s anything there to spend time on in the future. Pretty much, what annoyed me when working and can I do something about it?

If I come up with something that I can’t deal with right now then I’ll record it in Roam under #hack-idea, whether it’s Friday or not, and when I feel like hacking on something I’ll look there. Because sometimes you just need something quick to hack on. 🙂

I’d love to hear what your favorite day-to-day automations are on Mastodon!