Feeding The Machine · Tech

Switching From Hugo to Astro

Mon, 31 Aug 2026 18:00:00 GMT

This site used to run on Hugo. As of last week it runs on Astro, and the switch took an evening. Two things about that are worth writing down: why I left, and how the leaving went, because the second one is the part I did not expect.

The honest version of why I left is that I never got comfortable with Hugo. I used it for a couple of years, it worked, it was fast, it never lost a post, and every time I opened the repo it was with a small feeling of dread about what I was going to have to look up to get a post out.

The clearest evidence sat in my own content folder. There was a draft post called “Hugo / Obsidian Blog Workflow”, dated February 2025. Title, date, tags, draft: true, and then nothing. Eighteen months of not writing the post about how comfortable I was with my setup. The workflow I was trying to build just never came together, and nothing else managed to take its place. That is a review in itself, if you are willing to read it as one.

The specifics are unremarkable, which is the point. The site was a third-party theme pulled in as a git submodule, which makes customizing it a negotiation with someone else’s markup. The config was a 152-line YAML file, of which 84 lines were keys with no value on them: blank settings for a theme’s features, sitting in my repo, doing nothing except being things I might be supposed to understand.

My favorite artifact of that file is that comments were turned off, and it still enumerated eight different comment providers. Disqus, DisqusJS, Utterances, Remark42, Waline, Twikoo, Giscus, Gitalk. Eight blank configuration blocks, in version control, for a feature I had disabled. None of which is really Hugo’s fault; it is aimed at people who want that surface area. It is just more machine than I need, and I never built the fluency that would have made it worth it.

The second half is the part I actually want to tell you about, which is that I didn’t really do the migration. Claude did, and what could easily have eaten a month of weekends landed as one commit on a Sunday evening. 191 files, about ten thousand lines added, six hundred deleted. Twelve posts (well, eleven posts and one shameful draft) and three pages carried across, the theme submodule gone, the 152-line config replaced by a src/lib/ directory where the logic is code I can read.

At this point, with AI’s help, speed is a given. The part that surprised me is which work got done because of the speed.

Think about migrating a blog by hand. You know the real risk is URLs: search engines and other people’s links point at the old paths, and Hugo was emitting paginated lists, per-tag pages, per-tag feeds and legacy aliases from an even older version of the site. You also know that cataloguing every one of those before you delete them is an hour of tedium standing between you and the fun part. Reader, on a Sunday evening you are not doing that. You are going to eyeball the homepage, click three links, and ship it.

What happened instead is that Claude audited 73 old URLs that went into a fixture file first, and that became a test that fails if any one stops resolving. Then a crawler that fails on any internal link, image or anchor that does not resolve. Then invariants on the content itself: every tag has a glyph, every post has a hand-written excerpt, no unconverted Hugo shortcodes anywhere. The suite is up to 331 tests, and it runs before every deploy.

That is the leverage that Claude brought. Not the speed directly, the confidence that I could cut over without breaking things. The boring, risk-reducing work is exactly what a motivated human skips at 7pm on a Sunday, and exactly what costs a machine nothing to be thorough about. I got the diligence I would have talked myself out of, and without it I probably would never have made the leap because it felt too risky.

There is a second-order effect too. Once building a small thing properly gets cheap, you build other things you would have put off: a JSON Feed alongside the RSS so the Bluesky cross-poster I also built reads structured data instead of scraping Open Graph tags out of my HTML, a scaffolder for new posts, a search index. None of those were really on a list anywhere, but I had the bandwidth to build them because my comprehension of the minutiae was no longer a blocker.

The stack now is Astro, MDX, static output, on GitLab Pages. The RSS feeds are unchanged, full content and all, because that was the one setting in those 152 lines I actually cared about.

I have no thesis about whether you should use Hugo; plenty of people are fluent in it and well served by it. But the tool I could not get comfortable with was costing me momentum on the very task I had brought it in to simplify, and the price of finding out if something else might work better had dropped to one evening.

Information Flow in Three Work Cultures

Mon, 10 Mar 2025 06:00:00 GMT

This article is an entry in a topic I’m calling Reprints, where I’m collecting works that I have written in the past but published on other platforms in an effort to collect my work into a single place. Wherever possible I will be linking to currently available locations online of the original publications. In all cases there will be what I consider to be appropriate attribution and usage within either my explicit rights or Fair Use. If you think I’ve misstepped, please contact me.

This piece was originally written while I worked at Guild and published in August of 2020 on their Extra Credit tech blog.

Art by Erin Rhodes.

Nothing defines a group of people more than its culture. More than anything else, culture shapes what it feels like to be a part of that group. “Culture” is an expansive concept, and can include everything from the most foundational beliefs and major ceremonies of a group, to the most mundane little details of daily life. Art, music, food, speech patterns, clothing, architecture… the list could go on. But what does culture mean in a business context? What is your culture at work? How does the culture at work affect your ability to work?

Work cultures are distinct from other cultures in that they are much more narrowly focused, and are often created with a lot of intention. If culture in general describes how a group lives, culture in business describes how a group works. A lot of scholarly effort has been put into studying and defining work culture. One of the most useful models of organizational culture was put forth by Ron Westrum in his 2004 paper “A Typology of Organisational Cultures,” where he defines the three cultures model. The cultures are pathological, bureaucratic, and generative. Westrum found that one of the most telling attributes about the dominant culture is how the people and processes within an organization handle information. Especially telling is the handling of information about failures, flaws, weaknesses, or other shortcomings. Let’s call this Toxic Information.

A pathological culture is as negative as it sounds. This culture is focused primarily on the acquisition and retention of power by individuals within the organization. One of the primary means to maintain this power is to control the flow of information, especially Toxic Information. In a pathological culture, Toxic Information is frequently weaponized. It is used against others in the organization to ensure the person who has the information maintains their power.

It’s also common in a pathological culture for information to be suppressed. When it can’t be suppressed, a scapegoat is found to “take the fall” for the organization. This results in a large number of other negative behaviors, including low cooperation, blame, siloing information, hiding failures, and fear of innovation. These traits are particularly dangerous for creative work like software development. They encourage people to always choose the “safe” paths, which hinders innovation. They create adversarial social patterns between teams, which leads to infighting, and known problems getting ignored until they cause issues in production.

Strongly pathological organizations can be effective for short periods of time so long as they pay very well or have some other amazing upside for the individuals, but people tend to become unhappy and burn out or become disengaged quickly. As a result, these organizations tend to have high turnover rates, and there is a strong correlation with markers for corruption. In fact, organizations that go too far down this road often collapse because they are held together only by individual self-interest, and fundamental problems are rarely addressed.

A Bureaucratic culture, on the other hand, focuses primarily on rules. Almost every large organization has some element of bureaucracy in its culture. Virtually any time you see a standard form, or have to look up a process, you’re seeing bureaucracy in action. Some amount of it is necessary, even healthy, for organizations to scale efficiently. However, there are pitfalls. Bureaucracy can often lead to “not my problem” attitudes because areas of responsibility are very narrowly defined. Communication between groups is often limited, and sometimes discouraged. This can be because an “us vs them” attitude has arisen because people have begun to identify with their immediate coworkers, but not the organization as a whole. It can also be because the “proper channels” for that communication are too onerous. The novel or interesting tend to be actively discouraged because change of any kind is seen as too risky. Individuals are disempowered to make decisions unless they are formally part of the leadership group. All this leads to Toxic Information being ignored or shuffled from place to place, allowing problems to go unaddressed for extended periods of time.

Bureaucracies also tend to be strongly justice seeking. When Toxic Information does finally come to light, they will not generally try to suppress it or dodge responsibility, but they will be quick to find some form of punishment or restitution to execute “justice.” This leads to a feeling that the issue is “dealt with,” but will often fail to address the root problem. Perhaps worse, bureaucratic thinking will cause people to be overly reliant on “proper channels” in a crisis. Westrum points to the communication failures between police and firefighters responding to the September 11th attacks as a catastrophic example of this force in action.

Bureaucracies can be very effective, however. A great example of this is a military organization. Most world class militaries are very effective at meeting their objectives, but most of the people who are there aren’t performing creative work, and relatively few of them are likely to be happy enough to stay there long term. Their biggest weakness, though, is their inability to adapt and act efficiently. The often onerous process to get changes approved takes time and effort away from actually implementing those changes. This is not a good environment for developing software, where the pace of change is constantly accelerating.

Finally, generative cultures are fundamentally mission and performance focused. The high-level goals of the organization are clearly articulated, and individuals are empowered within their spheres to contribute to that mission. Cooperation and collaboration are encouraged. Novel ideas and experiments that are likely paths to better outcomes are encouraged. Most importantly, Toxic Information isn’t seen as toxic at all: it’s an opportunity for improvement. As a result, strongly generative organizations will actively seek out Toxic Information as a means of self-improvement. When Toxic Information surfaces, they will look for contributing factors and work for true fixes to underlying problems. Justice seeking, scapegoating, and suppression should all be very rare, and ideally, entirely absent.

People in generative cultures tend to be happier on average than in other cultures because they can clearly connect their work to the higher goals of the organization and are empowered to make a difference. This clearly is the best environment for creative work like software development, but it’s not without its risks. The biggest challenge in a generative culture is scaling it to large numbers of people. As people know each other less, trust is more difficult to maintain, communication is less frequent, and efficiency can be lost as people lose track of what others are doing and overlapping work starts happening.

At Guild we’re working towards a strongly generative culture, even in the face of our rapid growth. Not only does this cultural model provide for the healthiest and happiest environment for the people that inhabit it, but there are also strong correlations between generative attributes and effective organizations. We’ve already established that the handling of Toxic Information is a strong indicator for the kind of culture that exists in an organization, but it goes beyond that. The way that all information flows is important. In a generative culture there is a strong emphasis on getting the right information to the right people at the right time. That is a challenge at the best of times, and in an organization that is growing as rapidly as Guild is, that challenge is magnified.

At the highest level, Guild is meeting that challenge with a focus on transparency and candor. Frequent communications about the state of the business, progress on initiatives, and upcoming challenges are all topics one can expect to see. But several less obvious efforts within the technology organization also promote a generative culture.

The establishment of the QA, Security, and DevOps teams this year are prime examples of organizational changes that have deep cultural importance. On the surface, these teams are centers of specialized skills and considerations that are fundamental parts of building and delivering software, but they are also key actors in facilitating information flow and cooperation across teams.

DevOps is most directly and obviously engaged in helping information move around and fostering cooperation. It’s right in our team mission statement. We spend a large portion of our time interacting with developers from all over the company, supporting their work around automation, observability, and infrastructure. We bring our own skills to the table, helping squads make stronger and more consistent decisions, more quickly. Our goal here is to be a super responsive first line of support to get developers unblocked. But we would be making a big mistake to think we have all the answers. We are also collaborating with the individual dev squads. We are collecting good ideas that we find in one squad and sharing them where they might be useful on another. Sometimes, we even integrate them into our core patterns. The observability efforts that we are shepherding are entirely about surfacing the right information to the right people at the right time.

QA’s role here is also pretty obvious. I know the joke is that all QA does is find creative ways to break things, but really, it’s about making developers aware of ways the software we create might not do what we expect. Ideally, it also creates that awareness as quickly and easily as possible using sophisticated testing and automation tools. The benefit of focus here is twofold: we have better awareness of flaws, and we can spend less total effort finding them. Once the problems are found, QA also makes sure that loops get closed with the project managers and devs who own that code so that decisions can be made about how and when to address the issues.

Security helps information flow through auditing and compliance efforts. The relationship here isn’t obvious, but it becomes apparent if you dig below the surface a bit. Audits are fundamentally about discovering where we can be better, and compliance compares us to recognized standards for good processes and practices. When we’re proactive about compliance and can show evidence that we meet these standards when partners ask for it, we protect ourselves from disruptive audits being imposed on us and we make it easier to get contracts for new deals signed. Our security team is also engaged in this effort through a formal Application Security program that is being spun up. At its core, the program aims to ensure that developers know about secure coding best practices and that they are warned about possible vulnerabilities in their code before it makes it into production.

It takes a lot of work to create an organization with a great culture. There are countless aspects to be considered, but perhaps the most important one is how the organization handles information, especially information we’ve called Toxic Information. Is it hoarded to be used as a weapon for personal gain? Is it hindered by bureaucratic roadblocks? Or, does information flow freely to where it’s needed when it’s needed? The latter is what we’re aiming for at Guild. It’s a major component of a generative culture, where people are happy and the organization is able to meet the high-level goals at the heart of its mission. Information flow is only one part of what it takes to get there, though. What else can you do in your role, with your teammates, to get your organization closer to that strongly generative ideal?

CI/CD: More Than Commit -> Deploy

Mon, 24 Feb 2025 07:00:00 GMT

This piece was originally written while I worked at Guild and published in April of 2020 on their Extra Credit tech blog.

Photo by Pablo Lancaster Jones on Unsplash

CI/CD is a central topic of DevOps. Usually, “CI/CD” is understood to mean “Continuous Integration / Continuous Deployment”. Its importance to DevOps adoption projects has led to the creation of dozens of tools designed to make that process easier. There’s lots of nuance and detail that should be part of this process, but unfortunately it’s frequently simplified down to “Commit Code -> Deploy Build”, and therein lies the danger.

Many people see that simplified process as the pinnacle of DevOps value, but lumping it all together like that can lead to problems later as your organization works to mature their DevOps practice. Why is that?

CI can be described as the process which consumes freshly committed code and runs a variety of tests and performs a “build”. Depending on the technologies involved and the maturity of the practice the details can vary widely, but at a high level, that’s pretty much it.

CD is the next step in the process, wherein that fresh build is deployed into a server environment so people can use it. Usually, this is a testing environment of some kind so the changes can be validated beyond whatever validation is done during the CI process, followed by a deployment into production.

Treating these two separate concerns as a single process prevents either of them from being as efficient or flexible as they should be. What happens when you need to move that code to another environment? In most cases, the answer is to merge those changes into another branch which will deploy there. But why would we do that? We should already have that code built and tested, why do we need to do that work and spend that time again?

How do we know for certain that the tests we performed in one environment accurately reflect what we can expect when the code is merged, rebuilt, and redeployed in another environment? If we have good automation we can be pretty sure it will be the same, but there is a chance that the merge and rebuild process could introduce changes that weren’t there before. This is especially true on teams where there are many people working fast on parallel projects. Why would we allow this risk to exist in processes that are supposed to be reducing risk as they progress?

This extra effort and risk can be significantly reduced by logically separating CI from CD, and treating them as separate processes. The most straightforward way to do that is to have the CI process create an artifact of some kind, which is then consumed by the CD process. This artifact could be a container image, a webpack, a serverless code archive, or any number of other kinds of packages that wrap up software. Whatever form it takes, the creation of this software artifact allows us to decouple the CI process from the CD process, which lets us do some pretty amazing things during CD.

It gives us much improved confidence that what we are currently deploying is the very same thing that we had previously tested. It allows us to “shift left” the risk and effort of code merges. It allows deploys to downstream environments to be faster because we’re not repeating the CI process when we don’t need to. It allows us to easily deploy the same code in multiple environments, or easily re-task an environment for testing different things by deploying a different version of some code to it. It allows us to adopt tooling around deployment that can be easily used by non-developers, eliminating developers as a bottleneck for deployments and moving the decision of “what should be where” closer to people who focus on business concerns. This list could continue, but that should illustrate well the benefits of decoupling CD from CI.

The benefits don’t stop in CD though! If we don’t have to run the CI process as often and have it be a blocker for CD, the cost of the time it takes is reduced. This gives us the space to add more thorough automated tests to the CI process, which can give us even more confidence in the build and reduce the need for manual QA later in the process.

I really believe in the value of separating concerns. If processes are designed to create bright lines or explicit handoffs between areas of concern, it makes the overall process much more powerful. Separating CI from CD is a great example of that effect, and one that I hope we will embrace at Guild as we progress in our DevOps journey. If you’d like to learn more about this space, check out Continuous Delivery by Jez Humble, it’s an amazing resource!

The Dangerous Appeal of Absolutism

Sun, 16 Feb 2025 23:14:00 GMT

I use Airgradient air quality sensors in a couple places in my home to keep my eye on indoor air quality. One of the reasons I chose them is their open approach to data sharing. I got a note from them this week asking my opinion on how they should handle a situation where another org they work with is refusing to share data in a similar way. They’ve detailed things in a blog post if you want to get the nitty gritty.

It got me thinking though that Airgradient got themselves into that situation because they took a maximalist approach to openness, and didn’t think through additional controls that might be needed if they cared about whether or not someone else didn’t “play nice” in a way that they implicitly were saying they expected them to. They just assumed that other folks wouldn’t take advantage of them. To be clear, I think Airgradient will navigate this well, and in this case it’s not a particularly sticky situation, it’s just the thing that got me thinking.

This kind of thing comes up frequently in Open Source. A particularly ugly version of this is playing out in the Wordpress community as I write this, and shows no signs of wrapping up anytime soon.

Taking a maximally open stance like this is appealing in its’ simplicity, but I would argue that kind of position is almost always wrong. To actually achieve the goals that a maximally transparent, open, or socially-beneficial position is trying to achieve controls need to be put in place to curb the actions of bad actors.

It’s why open social communities need conduct guidelines to keep hate speech at bay. It’s why capitalism needs regulations to keep abusers of all kinds under control. It’s why Open Source licenses continue to proliferate and get increasingly nuanced. The need for being explicit about things that it may have been safe to make assumptions about in the past has never been more clear.

It’s really a systems design problem at the end of the day, and looking around right now I can see the problems with the design of our social systems cast in particularly frightening relief. It’s clear that there were a whole lot of assumptions about how people in power would behave underpinning the design of our most important social and governmental systems, and that capture at the scale that we’re experiencing simply wouldn’t happen.

As we’re trying to hold the existing systems together to keep people safe and healthy, it’s important to be thinking about the non-obvious design assumptions that are embedded in our systems, and how we can avoid those problems when we get the chance to build what comes next. Don’t fall into the trap of the toxic appeal of a simple and maximalist position. It will almost certainly not do what you hope.

Good luck out there.

The Enshittification of Game Dev

Fri, 15 Sep 2023 01:49:34 GMT

Whew. It’s been a week. Unity announced their new pricing model and, boy, the internet was not happy about it.

If you haven’t been paying attention, the long and the short of it is that Unity has decided to change the terms of their license agreement such that the more “successful” a game is, the more the developer will owe Unity. The (biggest, but far from only) trouble is that the size of that debt is determined by “installs”, which is apparently being used as a proxy for sales. I’ll write about what I think of metric proxies at some point, but suffice it to say that this is a particularly problematic proxy. Especially in the age of F2P games.

I’ve been waiting for them to do something like this ever since their IPO and they hired that guy from EA just a few years later. If I’m being really honest, I’m mostly surprised it took this long for the other shoe to drop. It struck me though that Unity is entering the final phase of Cory Doctorow’s enshittification process. Unity really is following the script to a T.

You can see the arc of Unity’s history in detail on Wikipedia, but to summarize:

Unity is created in 2005 with the goal of “democratizing” game development. They did a lot in furtherence of this goal, and made themselves valuable to a whole lot of users. And it worked, Unity because the de-facto first choice among hobbyist game developers. This is phase one of enshittification. The value and surplus went to the developers, getting them locked in.
Somewhere around 2012 Unity achieves a level of critical mass where it is regarded as a top game engine, especially for mobile platforms. So many people had learned how to use Unity that even the largest studios start working with it because of the ease of acquiring talent and the very healthy ecosystem of add-ons and assets. It’s somewhere around here where phase two of enshittification really got going. More and more features were locked up behind Pro licenses, transitioning the value from the individual developers to the studios they worked for. This continued for some time, as Unity focused more and more effort around supporting the larger studios with features only they needed. Here’s the surplus going to the studios, getting them locked in.
This week we saw indisputable evidence that phase three is in full swing. Here’s where the value starts shifting to the shareholders. With this new agreement Unity will start taking a much bigger cut of the value that developers create using their tools. Here’s a great collection of responses from a variety of prominent indie studios to get a deeper sense for how this is being received.

It’s such a perfect example of the enshittification cycle you’d think they did it on purpose. This article points out that their growth has been tanking which has whacked their stock valuation. This is likely what pushed them to try to grab more revenue. Late stage capitalism rearing it’s ugly head yet again. Another great thing is getting destroyed because investors demand infinite growth so they can get their infinite payouts. Speaking of payouts and maybe doing it all on purpose, it seems like our aforementioned CEO unloaded a bunch of stock right before this announcement. Almost as if he knew this move was going to turn the company into the titular PoS, but decided to do it anyway.