I’m trying something new here. Instead of waiting for fully-formed thoughts, I’m going to share more as I go: quick things I’ve learned, half-baked ideas, useful links. I’ve added some structure to keep things findable, but the main goal is just to share more often.

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.

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

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.

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.

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 use Roam Research as my primary way of thinking and keeping track of tasks. My current workflow has me creating a list of all tasks I want to get done, and then I drag them to either Done or some follow-up/waiting area for future action. So I only see things I can act on now.

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.

I just misplaced my Apple Watch in my apartment. Walking around looking for it, and getting frustrated, I was thinking, “There ought to be a way to make it make some sound, then I can play Marco Polo with the watch”. But my Google-fu failed me: no obvious way to “ping my watch”. There’s functionality for pinging the phone from the watch though.

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

I’m running an open source project called gocd-cli which is, well, a command line interface for Go continuous delivery. The intention is to make it easier to handle common tasks around Go. But this post isn’t really about that.

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.

I’ve for almost a year now been using Python as my day to day language as it’s what is used at my job. I’m starting to come around to really liking most parts of Python now, although there is definitely parts that are way more clunky than I would expect from a language so popular. And especially given how much talk there’s about the included batteries and to a small extent how there seems to bit of dickishness involved with hard core Python people. For an example of the latter just: