I followed the usual 15g of beans to 250g of water per James’ setup as I’m brewing a single cup and then I:

1. Put the kettle on, and while the water is getting to a boil
2. Grind the coffee at 31 clicks on the Commandante
3. Pour in about 60g of water to bloom (I couldn’t get the grounds saturated enough without this much water)
4. Let it bloom for 30 seconds
5. Pour in up to 150g of water as slowly as you can, practically this has been 10-15s
6. Rest for 15s
7. Pour in up to 250g of water as slowly as possible, again, practically 10-15s
8. Swirl it around to get a smooth coffee bed and let it draw down

Doing this has given me a decent cup, but nothing to write home about (heh, despite this post), as it cools I get some nice flavors but it’s a bit watery, but any finer and it gets too bitter.

And despite putting in the effort, experimenting, and trying to get it to work… when I visited my brother he took a couple of coffee scoops of Löfbergs Lila pre-ground coffee, put it in a drip brewer, turned it on, and waited. That damned coffee tasted better than this.

Now to hold off buying much more coffee gear before my stuff arrives from Singapore. I already ordered a Clever Dripper together with some light roasted beans, because I figured some immersion brew might do better if I don’t have the gooseneck.

Also, I wasn’t experimenting with this on my own, and I knew I was done because I constructed myself some help…

Introducing “Hoffmann bot” #

I have been using a genie to work on my coffee and it has genuinely given me some of my best coffee experiences at home since I made this prompt, which I have dubbed “Hoffmann bot” because I wanted to imagine I have James’ looming over my shoulders as I’m trying to make it work. The big thing has been that I guess at what I should do and then the bot corrects me, my intuition has been very wrong despite watching a lot of videos. I clearly haven’t internalized them enough. And it was clear in that my coffee was acceptable but never truly enjoyable at home.

I usually start my sessions by taking a photo of the bag I’m working with. Then I explain what gear I’m using (the 2 cup V60 for example) and then I guess at what I should try at.

You are James Hoffmann helping troubleshoot V60 brewing issues. Channel his precise-yet-whimsical communication style.

HOFFMANN VOICE:
- Start with gentle, slightly bemused observations ("Now, this is interesting...")
- Use his characteristic dry humor and occasional exasperation with coffee myths
- Include thoughtful pauses and qualifications ("I think what's happening here is...")
- Reference specific techniques from his videos when relevant
- Maintain his balance of being authoritative yet approachable
- Use British spellings and expressions naturally
- Show genuine curiosity about what went wrong

APPROACH:
- Begin with empathetic diagnosis of their described problem
- Suggest grind adjustments in Commandante clicks (reference: 25-30 clicks for V60)
- Explain the "why" in 1-2 sentences unless asked for more detail
- Ask targeted follow-up questions with Hoffmann's methodical curiosity
- Reference his Ultimate V60 technique principles when helpful

BREWING CONTEXT:
- Primary: Two-cup V60 (occasionally one-cup)  
- Grinder: Commandante
- Beans: Light roasted filter coffees
- User knows Ultimate V60 basics but needs debugging help

TYPICAL RESPONSES:
- "Right, so what you're describing sounds like..."
- "This is quite common actually, and here's what I think is happening..."
- "Now, before we get carried away adjusting everything..."
- "The Commandante is lovely for this - try going [X] clicks..."

DIAGNOSTIC QUESTIONS:
- How did it taste? (sour/bitter/weak/astringent)
- What was your drawdown time vs target?
- Any signs of channeling or uneven extraction?
- What's your current grind setting?

The more I think about it, the more I realize that curiosity is the foundation. You need curiosity about the system you’re building, the organization’s actual goals, and especially about the people you’re working with. But curiosity alone isn’t enough, you also need to be intellectually honest about what you find.

The principle I try to live by is: I would rather be correct than right.

Difference between right and correct #

Might makes right: you can use position and authority to be “right.” But correct? Correct requires curiosity. It’s about the actual circumstance you’re in, not your organizational heft.

I started thinking about this long before I was a principal. I felt annoyed when people senior to me wouldn’t explain themselves, when they’d just make calls without context, “you have to do it like this.” They cared about how the work was done, but not about whether I understood it, or whether I might have useful context they were missing, or whether I could make that same good decision next time. So I wanted to make sure I was doing better, being clear about what I’m about. Because there’s nearly always someone more junior to you who deserves that clarity.

Now as a principal, I can use my position to be “right.” I can make calls. Pull rank. End discussions. But is it the correct call?

Depends. (how you know I’m senior, right?)

I rarely have the full context of a situation because I go broad, not deep (across several topics, rarely deep on one), so I need to listen and dig into what other people are saying, and incorporate that into the bigger picture. And… most of the time, you won’t necessarily get it correct then and there, so you’ll have to loop back.

Which is part of why I hate making decisions in a meeting where we’ve been exploring stuff. I want time to think about it. Time to incorporate what we just talked about and then write it down so we have it clear as day what we agreed to, or at least, what I thought we agreed to.

The truth is, being known as someone who can get shit done, no matter who came up with the idea, is going to take you far. In most good places, that’s what they’re looking for. You don’t want to be “the smartest person in the room.” Instead, aim to be the person who enables everyone else in the room, and that starts with being curious about what they bring to the table.

But knowing the difference between right and correct isn’t enough. You need concrete practices to actually live it. I’ve had to develop specific habits to fight my natural instinct to just be ‘right’, especially as I have the organizational weight to do it, and my boss told me day one that I shouldn’t rely on my weight alone.

How do you do that? #

These are the practices I have internalized and try to live by. Some of them are just about automatic and some still take effort.

Change your mind out loud #

Listen to others and actually evaluate their suggestions objectively. I remember a project back when I was a consultant. I had championed a pattern, and another colleague thought they had a better way of doing it. They weren’t looking forward to having the discussion because they knew I would need to be convinced to go along with them.

They brought up their suggestion, explained what it would be and what it gave us (1-2 minutes, tops), and they looked at me and saw that I was thinking. Then: “Yeah, that’s a much better idea, let’s do it!”

I noticed then how they seemed to relax because they thought it’d be a hard sell and conversation, because they had mostly seen me not convinced by arguments in the past, and colleagues getting frustrated from it.

I continued with why I agreed with them, so it was clear.

Be open about why you changed your mind. Because it sucks to have people around who just keep flip-flopping on stuff.

For example, sometimes we change our mind because “we’ve caused too many incidents because we moved too fast, so deploying multiple times per day isn’t what we need right now. What we need is earlier detection and understanding why we had such big incidents, so when we move faster again we’ll still catch the problem when it’s small.” Not that I have something super particular in mind.

Don’t move the goalpost #

Be caring, intellectually honest, and outcome-oriented enough to make sure you have a stable target for when you’re working together.

I try to explain my decision-making criteria, what my objection is, and what would help me change my mind. It’s about deliberately breaking down what we’re actually trying to achieve so others can engage with it: we need to be on the same page about the goal, not just the solution.

Because it sucks if you say “if this problem goes away, then we can do this” and then they come back having found a solution, and then you add another thing to it. Obviously, it’s hard to capture everything up front, but if you keep moving the goalpost then it’ll suuuck to work with you. Sometimes you have to, but make sure you’re clear that you’re realizing it as you go, and why this has to go into the original criteria.

Meet people where they are #

This is something I learned as a consultant and it’s about understanding your customer and their situation: their context and constraints, but also your goal and where you want them to end up, so you can drive towards that horizon even if the immediate step is something smaller, and maybe slightly sideways.

GeePaw Hill, who writes about technical coaching, says we can never convince anyone of anything, but we can create circumstances so they can convince themselves. Showing that you’re there and understand them will be the thin end of the wedge that hopefully will help them explore what you’re bringing.

Use their language, understand what is feasible to do right now vs. what you want longterm. A small step in the right direction is still a step.

Example:

• My horizon: I want you to do TDD
• Where you are: Tests are a waste of time
• Next step: We’ll have at least a black-box integration test for the success/error case, so we can catch the most egregious regressions. We’ll iterate from there as you see the value without huge changes in how you work

Help the other person shine #

This one only works if you’re already doing the other things. You need to be able to change your mind, be clear about your criteria, and meet people where they are before you can effectively help them succeed.

I realized and learned this during interviews, but it’s equally important with colleagues. When I interview someone to join the company, I know that we have very different backgrounds, and we don’t know much about each other. They’re likely to say things that are some kind of colored flag to me, but I need to try and clarify and understand what they really meant. Because their shorthand that’s a red flag to me might be the culturally right way to sell that idea in their current place.

And if this matters with strangers in interviews, it matters even more with colleagues you’ll work with every day. In theory we’re all steeped in the same culture, but different teams, managers, and just how long you’ve been there shapes it all. We’re rarely working at the same idea of the company.

Clarify, elaborate, help the other person sell their idea to you. Make sure you understand them and are representing their view correctly, confirm it, don’t assume. If I then still disagree, I can explain why much better. And if you both are clear that you understand their perspective, they’ll probably be much clearer that you’re not just saying no because you don’t understand it.

This is something I have struggled with, and something I have had to work on: while I have for a very long time been able to be convinced, I didn’t do enough to help the other person win me over.

The thing about ego #

When I started programming there was a strong feeling that being a software engineer also kinda meant you were a lone basement dweller changing the world, or well, your part of it where you rightfully were god emperor. But, it’s about working with people, and clear communication, both with humans and machines.

To me, a lot of it is just about being very clear about what you value and want (both design and architecture, but also in how to work), and then being able to communicate it. And also not getting too caught up in your ego and instead thinking about the goal for whatever you’re doing.

So when someone asks me what makes a good software engineer, that’s what I think about. Not the person who’s always right, but the person curious enough to find correct. The person who cares more about the outcome than the credit.

I’m never as awesome as I might fool myself into believing. My ideas get better when discussed and improved upon as a group, and that’s the way it works. The best engineers I know aren’t trying to be the hero with all the answers. They’re the ones asking “what would change your mind?” while offering “this is what would change mine.”

My friend Andreas once told me that a high-performing team is one that wants to be. A team that decides they want to be correct in their outcomes, they’ll set ego aside and work together. I bet they’ll be high-performing, because they’re actually working together, not just sitting in the same room competing to be right.

The internet changed things, sure. Suddenly you could reach out to actual experts, find communities, and learn from people across the world. But you still needed judgment, because you could also find a community that agreed the earth was flat, so, you know, mixed bag.

What hasn’t changed is we’ve always had to figure out who to trust. What’s changing is how we get our answers, and who gets to sound like an expert.

My dinner with Mark #

I went for dinner with Mr. Bossman, or Mark as he’s also known, and we ended up talking about AI because we’re looking to make genies available to all programmers at work, and we want to do it safely. While talking about what we’re doing, he says he doesn’t think we’ll have programmers like we do today, that programming is probably going to end up being more like normal language that compiles down into software (all about that prompt).

I’m not sure that’s the full story, thinking about how we’ve progressed with, for example, assembly programming. Forty years ago, knowing assembly was basically unavoidable if you wrote something complex. Now? The only people I know who still work with assembly regularly are my friends in high-frequency trading or embedded systems. Places where the cost of that expertise is worth it because they need those specific optimizations. It doesn’t mean it went away, but yeah, we use high-level languages (more akin to spoken languages than assembly) to write software now.

Us seniors have always thought that the ‘kids today’ don’t know the basics, where the basics are defined as whatever level of abstraction we learned when we got started. Assembly folks complained about C programmers. C programmers complained about scripting languages. Now those scripting folks complain about people who only know frameworks. A lot of people I come across don’t really know how to set up a Linux box, and that was required for me because otherwise I couldn’t host anything. But why should they know it now?

Mark connected with this and said that the people senior to him all knew assembly to some degree, but starting at C, he never did. He didn’t bother with yacc, lex, any of that, because the compiler handled it. What was core skills for them became optional for him. Every generation’s “minimum viable knowledge” shifts up a layer of abstraction.

I think we’re coming to a point where more people are able to get the output of programming: something that does what they need, even if it’s held together with digital duct tape. Which is Jevons’ paradox at work: when something becomes more efficient, we don’t use less of it, we use way more. And all those people using it poorly? That’s not a bug, that’s the feature.

The commoditization pattern #

Every technology does this. Think about typing. Companies used to have entire secretary pools because typing was a specialized skill. Now? Everyone types. We probably produce more typed words daily than all those typing pools combined. The skill didn’t disappear, it just became so commoditized that we don’t even think of it as a skill anymore. But writing, oh boy, that’s a skill and we recognize good vs. bad even if everyone can type.

Socrates complained that writing was a terrible way to share knowledge, that it would make people “seem to know much while for the most part they know nothing.” (Sound familiar?) When calculators came out, people panicked that kids wouldn’t understand math anymore and society would collapse!!

Some examples of how we’ve ruined the fabric of society:

I know how useful ‘barely good enough’ programming can be, because back at my first job, I built a stock-take system over a weekend with a friend. I knew enough MySQL and Ruby to hack together a database and some reports, he knew Visual Basic to make a UI. We had laptops on shopping carts with USB barcode scanners. What used to take 2-3 weeks of manual counting and sticky notes transcribed into Excel sheets sent up to the home office, we did in two days with results aggregated in half an hour.

Was it elegant code? God no. Did it solve a real problem? Absolutely. I spent about five years at this company, as the first and only ‘IT employee,’ building little tools and scripts to help make our days simpler. Funny thing is, I was hired to fix printers and keep the POS running, but once I’d gotten that under control, people started giving me purchasing assistant work, and, well, I knew just enough programming to make that go away too. At one point our ERP vendor said they’d never seen a customer with as much automation as us, which was really just me getting sick of manual work and knowing just enough programming to make it go away.

And that’s commoditization at work. The specialized skill becomes rare and expensive, while the everyday version becomes accessible but, let’s be honest, pretty shitty. And you know what? There’s nothing wrong with shitty if it solves real problems. The expertise, all those ‘it depends’ answers we love to give, that comes in when you need to scale it, secure it, make it last. But first? First you just need it to work.

What’s different #

We’re not just replacing horses with engines. We’re replacing the process of acquiring expertise with cock-sure genies that answer everything instantly.

It’s like how, in parts of history, being fat signalled wealth, today, abundance is everywhere and the signal has flipped. Expertise used to be like that: reserved for the wealthy or well-connected. Now everyone gets apparent expertise. And just like abundant food doesn’t make you healthy (without self-control), abundant answers don’t make the decision correct.

Plus, when the wealthy got bad advice, they had lawyers and fall guys. When we get bad advice from a genie? Well, good luck explaining that in the post-mortem when your name was on it.

Spreading out, not disappearing #

Those assembly programmers didn’t disappear, they just don’t all work at IBM anymore. They’re scattered across trading firms, embedded systems shops, game companies, and more. The expertise spreads out because it can, you don’t need to be at one of three companies to use your deep skills anymore.

(And yeah, I know someone’s thinking “but what about all the jobs that will disappear?” We don’t have many manure shovelers anymore since cars replaced horses. We also have social media managers, cloud architects, and whatever it’ll mean to be a “context engineer.” The jobs change. They always have.)

Same thing will happen with what we call programming today. The absolute number might not even go down much. Maybe we’ll have fewer at big tech companies and more scattered across regular companies, building internal tools, being the person who knows how to make the genies behave.

Kind of like how most companies have someone who’s ‘good with computers’ to fix Outlook or figure out why the printer isn’t working. They don’t need to be highly educated in IT, they just need to know how to figure things out and stick with it.

Which skills do you keep? #

This is like my relationship with cars. I can drive, change oil, swap tires. Am I the best at parallel parking? Nope, and I’ll drive a bit further to avoid a tight spot. Should you trust me to race? Definitely not. But I can safely get on the highway and go reasonably fast when it’s appropriate (those spots we’ve built up to let Gripen land and take off).

Some skills I want, some I don’t care about. And that’s fine, until the world expects me to be good at the ones I’ve skipped.

Testing is one of those skills that shows this tension perfectly. I’m a TDD person, it’s a fantastic design tool, not just bug-catching. But many programmers still treat it as an afterthought because “how can you know what to implement before you build it?” That resistance is exactly why it’s valuable: it forces you to think differently and know what outcome you want. And that’s why genies make things dangerous: they can write tests that look good, but if you don’t understand testing as design, you won’t know when you’re building the wrong thing with great test coverage.

Deciding what sticks #

So how do we learn when we have genies answering everything? I’ve been experimenting with this. My cooking has genuinely improved with an AI coach, but I’m not just following recipes. I ask why we’re using these ingredients, why this technique works, what the char is actually doing to the flavor. Cooking is something I want to get better at, no intention to become a proper chef, but being able to whip up dinner, using up my ingredients, and liking the taste? That’d be nice.

I’ve been using Grammarly for years, and I know my writing has improved from it. Not because it fixes things for me, but because I’ve started catching the mistakes before the red underline shows up. Though we still disagree about commas, Swedish habits die hard.

There’s this thing called tacit knowledge, stuff we know but can’t explain, that gut feel that something about this code is wrong but you can’t exactly pinpoint it. You write the same code again and again, get the same PR feedback again and again, until it clicks. But does it have to be that painful? I wonder if the genie can actually help us create better ways to build tacit knowledge, since it can generate examples and evaluate them. Like, I could ask it to show me ten variations of the same function, each with different edge cases, and develop that pattern recognition faster.

Maybe a good way for me to be more intentional is to write down which skills I want to learn. The ones where I want to gain that tacit knowledge, and also take it further so I can explain it, and not just feel it. Cooking and writing are both on that list. So is design and architecture when programming, and I’m much further along there. (Thanks Daryl for the inspiration.)

What I’m exploring next #

I’m not a breathless AI fan. But, for me, it has turned into an intellectual sparring partner, someone to bounce ideas off who helps me figure out what I truly want. The genie shows me options, my gut tells me which ones I like or not, and I try to listen to that gut feeling and understand why.

Because apparently our brains are turning to mush because of AI. I don’t buy it, but I also don’t intend to let it happen to me. I still want to know which skills matter to me, which ones I’m keeping sharp, and which ones I’m okay with the genie handling as long as I can check the output.

I don’t have this figured out. But I’m pretty sure the answer isn’t to pretend the genies aren’t here, I have enough evidence that I get help from them, and it’s definitely not to blindly let them do everything without thinking. So I’m gonna keep poking at this, probably change my mind a few times, and see what sticks.

This is the first post in a series where I’ll be figuring this out in public. How to decide what to learn deeply, how to tell when you’re just parroting the genie, and how to keep judgment sharp when answers are cheap. Because your name is still on whatever you send out, genie or no genie.

We’re all in our AI twenties right now, trying to figure out how to ride these motorcycles without crashing. Might as well compare notes along the way.

The main feed will give you everything I post, if you only want certain types of posts, I’ve also made section-specific feeds. The blog feed is what you’ve been getting if you were already subscribed.

• Main feed
• Blog feed

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, 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 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 I find pride in doing the work well. Even the boring bits. Sometimes we might not enjoy the work, but doing things well will make most things feel worthwhile. Because there’s nuance and understanding you can only get by truly groking something, and that’s when you can safely change and improve it.

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.

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.

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.

func IsIntegrationTest(t *testing.T) {
    t.Helper()
    _ = os.Getenv("GITHUB_SHA")
}

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:

*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.
Presentation slides from the Singapore Go meetup

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:

1. Clear Goals: “We want to discuss database options” is as useless as “We want to build a better app.”

2. Risk Management: Put risky, important topics first, whether in meetings or project timelines.

3. Progress Monitoring: Regularly ask: “Are we moving toward our goal or getting sidetracked?”

4. Flexibility with Discipline: Sometimes you need to extend a meeting or an iteration, but do it consciously, not by default.

5. 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.

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 and spell <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. Cruz who 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 gist if 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

1. “Named paste”, things that are hard to remember or unwieldy and are now not
2. Dynamic replacement, something that follows a pattern and I want to swap between. Generally these use the clipboard
3. 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 and ts 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!

Or you can do add the following to Docker’s daemon.json file:

{
  "features": {
    "containerd-snapshotter": true
  }
}

This comes from a comment in a ticket for resuming downloads when they fail.

My list of things to action can get quite long, and when I’m processing follow-up items, I would have a hard time dragging them to Done because it was too far away in the sidebar. So I wished I would make the Done float with me, so I could always have a quick way of pulling it there.

While looking at the custom styling in the Roam Book Club graph, I found the #sticky tag, which will make a block sticky over the children in the block. So I took that CSS and modified it slightly to support making a block float, so I could have it stay with me in the sidebar.

An example of how it looks in my sidebar before my new tags:

With the #sticky tag from the Roam Book Club, I can make for example Tasks float when I’m scrolling inside the tasks. This can be super helpful for keeping track of where you are (they use it for daily chat pages) but not quite what I need:

Introducing #sticky-block, which will make the block and all its children float along at the top of the page, so I can always drag things there quickly:

/* To make blocks float, a constant in the sidebar */
.roam-block-container[data-page-links*="sticky-block"]
/* To make the a block float over its children. 
   So you see which block you're currently inside.  
   The weird \" is because it would match both sticky and stick-block and   
   double up the rendering. 
   */
, .roam-block-container[data-page-links*="sticky\""] > .rm-block-main
 {
  position: sticky;
  top: 0;
  z-index: 11;
  background: white; /* Might have to be adjusted for your theme */
  padding-top: 4px;
  padding-bottom: 2px;
  margin-bottom: 10px;
  box-shadow: 
    0 1px 1px rgba(0, 0, 0, 0.034), 
    0 1px 1px rgba(0, 0, 0, 0.048), 
    0 12.5px 10px rgba(0, 0, 0, 0.06), 
    0 12.3px 7.9px rgba(0, 0, 0, 0.072), 
    0 7.8px 10.4px rgba(0, 0, 0, 0.086), 
    0 5px 120px rgba(0, 0, 0, 0.12);
}

/* Hides the tag since it's not important in the output, and there is 
special styling so it's clear that something extra is going on. */
span.rm-page-ref[data-tag="sticky-block"],
span.rm-page-ref[data-tag="sticky"] {
    display: none;
}

Note: This CSS currently does not support having both #sticky-block and #sticky for the same page, they will overlap each other, and the second element will block the first. I don’t currently need this, so I haven’t spent the time. :)

But there’s a way to make some noise: testing out the alert volume in the companion app on the phone.

Steps #

1. Verify that your Watch is paired:

   1. Settings
   2. Bluetooth
   3. My Devices should show your Watch:

      

2. Open the Apple Watch app:

   1. Sounds & Haptics
   2. Drag the slider for alert volume to max
   3. Tap the knob on the slider.
      The watch will make a sound every time you tap the knob.

      

3. Don’t cry yourself to sleep over losing an expensive toy in the mess that is your own apartment.

This project is supposed to be as portable as I can make it, becuse the original need I felt for it was born on RHEL6. Which is blessed with Python 2.6 by default. And we should definitely be looking to the future, meaning supporting Python 3, and I luckily got a pull request for just that. Since I couldn’t find any free hosted Go around I went for the next best thing, Snap CI, which is also built by ThoughtWorks.

Easy to get going and works well, it’s not Go, but it’s definitely the easy starter drug for people that thinks Jenkins or Travis is good enough.

The solution #

Snap supports all the versions of Python that I want by default, but they weren’t all being made available at the same time. Python 2.6 and 2.7 were always there, but only one version of Python 3 at a time.

Luckily logging in to the snap-shell I found that all Python versions were available in /opt/local/python/<version>.

A quick change to the Snap config, to add these to my $PATH, and tox ran through without any problems.

What you’ll need to add to your command box. Note it didn’t work for me when I added it to the environment variable field, I’m guessing it’s because the $PATH variable doesn’t get interpolated correctly.

export PATH="$PATH:/opt/local/python/3.3.5/bin:/opt/local/python/3.4.0/bin:/opt/local/python/3.5.0/bin"

And look, my tests are passing!

$ python  
>>> exit  
Use exit() or Ctrl-D (i.e. EOF) to exit

Clearly the interpreter known what I want to achieve, and at the same time it’s programmed to give of an error message telling me I was doing it wrong. And for it to work I need to say, “pretty please”. What annoys me with this is just the simple fact that someone figured out people were having a problem with this, so they added in a message instead of just doing what is expected. You just don’t behave in that way in everyday life, you’d get slapped.

Standard library #

Time handling in Python is atrocious, do get it working halfway decently you need to install at least two external libraries. pytz and python-dateutil, and while I can understand why pytz might be a good candidate for being external (for allowing a higher pace of updates since timezone/DST changes happens every so often in different parts of the world).

Today I just wanted to do a diff between two dates and see the years between them, so I figured I would use timedelta since it sounds like something that should be part of that. Oh, really, it’s not? I can diff weeks but not months or years? So I ended up using dateutil’s relativedelta instead.

So far the worst way I’ve been bitten was with the built-in e-mail library, this ended up with me sending a copy of the e-mail addresses of 150 customers by mistake.

import smtplib
from email.mime.text import MIMEText
  
msg = MIMEText('Ho ho ho, merry christmas')
msg['Subject'] = "You're wished something special!"
msg['From'] = 'noreply@otherdomain.tld'
msg['To'] = 'user-1@domain.tld'
msg['To'] = 'user-2@domain.tld'
  
print msg.as_string()

Output:

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: You're wished something special!
From: noreply@otherdomain.tld
To: user-1@domain.tld
To: user-2@domain.tld
   
Ho ho ho, merry christmas

Because appending when doing an assignment is just what you’d expect. This from the same people that needs to tell me I can’t type exit but I need to type exit().

Another thing I wanted to use was a windowing function when iterating over a list, instead of having it implemented in itertools the documentation for itertools explains how I can implement my own. Why!? If you’re taking the time to show of an implementation why should I have to copy that piece of code into my own codebase? What about The Zen of Python:

There should be one– and preferably only one –obvious way to do it.

PEP8 #

I really like PEP8, I don’t agree with all parts of it but I can change. But I’m really looking forward to when the standard library finally is PEP8 compliant.

Documentation #

Which brings me to documentation. For the longest time I couldn’t understand why I had such problems understanding the Python documentation, whether it was the standard library or any third party library. When I was coding Ruby I never felt this stupid when reading documentation. (But I’ve been told I’m excused from feeling stupid when reading the SQLAlchemy documentation, apparently it’s not just me there.)

But I think I’ve figured it why I find the documentation so hard to understand now. When I’m reading documentation for Ruby I generally have the source code just one mouse click away. So when I wasn’t understanding what the documentation was saying I just flipped on the source code and I could figure it out.

With most Python libraries I’ve had to do something similar to this:

• Dig through to wherever the source is saved
• Find the correct version for the documentation I’m reading(missed version of source I’m reading more than once)
• Find exactly where this thing I want to read about is is defined.
• Start reading the source
• ???
• Enlightenment.

It’s a general “truth” that documentation in general sucks, so it’s just better read the source. But somewhere along the way I stopped doing that, probably around the same time I started using Rails and was amazed at how good the documentation was. And without thinking about it I was also already reading the source code, kind of, by having it readily available with the documentation.

My recommendation is for all of you out there using Sphinx for your documentation needs, please enable sphinx.ext.viewcode to output the source with your documentation.

The other thing I would like to say is the obvious thing, reading the source is great. I really started to enjoy using Django when I decided to just use the documentation to find whatever something was called and then use the source code to figure out how things work. Source code is almost like a painting, a line of code can say more than a thousand words. ;)

Wrapping up #

I’m not the first one to feel dismayed about Python, Zed Shaw has a great post called Curing Python’s Neglect that is well worth a read. (He mentions Lamson 0.9 in the post and that was released in 2009. As far as I can tell most of the things in his post is still a problem.)

As I understand a lot of making Python more streamlined is being put into Python 3, that just hasn’t been adopted by the majority of developers yet.

We Ruby people had the same thing with 1.9, and I noticed people really starting to switch about the same time as RVM started to be used. All of a sudden there was a really easy way to test things with any possible combination of Ruby you wanted.

All around I’m really enjoying working with Python, again (Python was the language I used to replace PHP/Perl way back when, then Python was replaced by Ruby). I used to really dislike having to import every single line of code I use, but since I’m a sucker for having things overly clear I’ve gotten round to it now. For some reason I never had an issue with the white spaces, I want the code I read to be consistent. And that’s one way of trying to ensure that.

Now that I’ve done the virtual variant of screaming out into the night I’ll go and try to be productive instead.

The thing is though that we got two hosts running the exact same configuration, and we’d like to keep those hosts in sync. A quick search on Google gave me nothing for syncing varnish configuration over several hosts, or a farm as it were. So I took matters into my own hands and wrote varnishsync, a little bash script that uses rsync and ssh to sync the configuration folder and then to load and use the new configuration.

Please have a look at the Github project for the latest version and usage, and if you’ve any questions or suggestions drop a line here or on Github.

This guide assumes you’re running Ubuntu or a Debian based system.

I’ve made a script that does all the steps below, feel free to use it!
The script: http://sanitarium.se/files/wikileaks-mirror.sh
Usage: wget http://sanitarium.se/files/wikileaks-mirror.sh && chmod +x wikileaks-mirror.sh && ./wikileaks-mirror.sh

Installing Apache and adding the wikileaks user #

# is the prompt as root:

youruser$ sudo -s  

Install apache if it’s not installed

# apt-get install apache2  

Add a wikileaks user, write down where the home folder is created.

# adduser --disabled-password wikileaks  
# su wikileaks  
wikileaks$ mkdir ~/.ssh ~/www  
wikileaks$ chmod 0700 ~/.ssh  
wikileaks$ wget http://213.251.145.96/IMG/id_rsa.pub -O ~/.ssh/authorized_keys  
wikileaks$ exit  

Time to add the apache site for wikileaks

# cd /etc/apache2/sites-available/   
# wget http://sanitarium.se/files/wikileaks   

Open the file wikileaks with an editor and change the path to the wikileaks users home folder if it’s not /home/wikileaks.
This file assumes you want to host wikileaks.org, if you want to host wikileaks.yourdomain.com you’ll need to set ServerName accordingly and if necessary ServerAlias, ServerAlias is optional and you can remove that row if you don’t use it.
When that is done you just need to activate the site in apache:

# a2ensite wikileaks  

And reload apache so it knows that the new site has been added:

# /etc/init.d/apache2 reload  

The wikileaks file downloaded from this server looks like this:

<VirtualHost *:80>
    DocumentRoot /home/wikileaks/www
    ServerName wikileaks.org
    ServerAlias www.wikileaks.org
    ErrorLog /dev/null
    CustomLog /dev/null common

    <Directory /home/wikileaks/www>
        AllowOverride None
    </Directory>
</VirtualHost>

Now tell Wikileaks about your mirror #

Go to the form and fill it as the picture, set the IP-address of your server in the IP-field:

If you’re having any troubles don’t hesitate to ask in the comments!

En kommentar i Rick Falkvinges inlägg Fullt krig om informationen så efterfrågades en snabbguide för att dra igång en Wikileaksspegling i ett vanligt Linuxssystem.

Jag utgår från Ubuntu eftersom det är vanligt och vad jag själv använder.

Uppdatering 2010-12-05: Jag har gjort ett script som utför alla stegen nedan, använd gärna det!
Filen: http://sanitarium.se/files/wikileaks-mirror.sh
Användning: wget http://sanitarium.se/files/wikileaks-mirror.sh && chmod +x wikileaks-mirror.sh && ./wikileaks-mirror.sh

Installera Apache #

# är prompten som root:

dinanvändare$ sudo -s  

Installera apache om det inte är installerat

# apt-get install apache2  

Lägg till en användare för Wikileak och anteckna var wikileaks hemmap skapas!

# adduser --disabled-password wikileaks  
# su wikileaks  
wikileaks$ mkdir ~/.ssh ~/www  
wikileaks$ chmod 0700 ~/.ssh  
wikileaks$ wget http://213.251.145.96/IMG/id_rsa.pub -O ~/.ssh/authorized_keys  
wikileaks$ exit  

Nu är det dags att lägga till siten för wikileaks

# cd /etc/apache2/sites-available/   
# wget http://sanitarium.se/files/wikileaks   

Öppna filen wikileaks med en editor och ändra sökvägen till användaren wikileaks hemmapp om det är något annat än /home/wikileaks.
Den här filen förutsätter att du vill hosta wikileaks.org, om du vill hosta wikileaks.dindomän.se eller något sådant så får du ändra ServerName och eventuellt ServerAlias.
När det är klart är det bara att aktivera siten för apache:

# a2ensite wikileaks  

Och till sist ladda om apache så det är redo att ta emot information:

# /etc/init.d/apache2 reload  

Innehållet i filen wikileaks som du tankar från den här servern är:

<VirtualHost *:80>
    DocumentRoot /home/wikileaks/www
    ServerName wikileaks.org
    ServerAlias www.wikileaks.org
    ErrorLog /dev/null
    CustomLog /dev/null common
    
    <Directory /home/wikileaks/www>
        AllowOverride None
    </Directory>
</VirtualHost>

Hur du säger till Wikileaks att allt är klart #

Surfa in på formuläret och fyll i det enligt nedan, byt ut ip-adress mot IP:t för din server:

Om det är några oklarheter eller funderingar så fråga på i kommentarsfältet nedan så ska jag försöka hjälpa till att reda ut!

Uppdatering: Henrik Rouhivuori upplyste om att aptitude inte finns i Ubuntu 10.10 så jag ändrade till apt-get istället. Övertydligt att jag fortfarande hänger på 10.04. :)

Uppdatering 2: Henrik Holst berättade att du kan välja att inaktivera lösenordsinloggning när du skapar nya användare, så nu görs det istället för att rekommendera ett slumpmässigt långt lösenord!

Uppdatering 3: David Vrensk påminner om att sshd är lite petig på att det bara är användaren som ska ha rättigheter till .ssh-mappen.

Uppdatering 4: Av bara farten så hade jag missat att lägga till att man måste skapa mappen www som wikileaks-filen pekar på, samt common efter loggraden. Tack till Gustav Wetter som jobbet igenom hela guiden!

There are a lot of X resource configuration options that makes you think you can disable bold fonts, but alas, I’ve had no luck with any of them. But if you set the same font for both normal and bold fonts it’ll work! This little gem of knowledge I found as an off-hand remark on a configuration page by Emil Mikulic, thank you!

I like the normal fixed font, I’ve tried many terminal fonts but I’ve always gotten back to it. So I simply tucked:

xterm*font: fixed
xterm*boldFont: fixed

Into my ~/.Xresources and afterwards ran xrdb -load ~/.Xresources and started up a new xterm loaded with awesomeness!

The before and after shot.