Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Mailbag: Should we just call them architects?
- RSS feed changing! Migrating blog in next few days.

Mailbag: Should we just call them architects?

A couple of days ago, I got another question about Staff Engineer, which felt worth digging into a bit:

I started reading your new book Staff Engineer and wondering if you can write about your thoughts on the difference between what we know as Technical Architect vs Staff Engineer. It looks like the big companies ditched the “Architect” title and invented the “Staff Engineer.” The more I read your book, the more I feel like Staff Engineers are plain old tech architects. Having set up an architect group that reports to the CTO office based on this: http://files.catwell.info/misc/mirror/2003-martin-fowler-who-needs-an-architect.pdf , I am now confused if I should rename the team :)

I hadn’t read the linked Who Needs an Architect by Martin Fowler, so I started by working through that. The core arguments I read were:

• The term “software architect” means different things to different people
• Despite that term confusion, there’s still software architecture to be done
• Some “architects” prioritize mentorship, others decision-making
• Despite the numerous definitions of “Architect,” the term is generally understood to refer to the decision-making oriented variety

I agree with all those points, and eighteen years later (the article was written in 2003!), the tactics are clearer: use the Staff-plus engineer titles rather than the architect title.

When I worked at Yahoo!, the career ladder went from Senior Engineer to Architect, and from there, the architect titles got increasingly fancy. Software Architect? Sure. Senior Software Architect? A good step. Distinguished Architect? Yeah, most definitely. These titles do a good job of conveying seniority, but they also suffer from artificial specificity. There are many folks out there doing work at the level of a Senior Software Architect who are not doing typical architecture.

The Staff-plus sequence of titles decouples seniority from archetype and is more durable for it. You can assess someone’s seniority from their title: Staff engineer, Principal engineer, Distinguished engineer, perhaps with some varieties like Senior Staff engineer thrown in for very large organizations. You can separately understand someone’s mode of operation by documenting someone’s archetype: solver, architect, tech lead, or right hand.

If you were feeling argumentative, you could have a title for every archetype, but I don’t think that would work well in practice. There are two reasons why this is hard. First, archetypes create clarity by creating distinctions, but reality tends to be blurry. Very few folks mix “tech lead” and “right hand”, but many “tech leads” spend some time on doing “architect” work. This makes evaluating folks a nuanced activity. Second. creating four useful career ladders is surprisingly challenging. It’s very possible to add specializing paragraphs to a couple of blocks explaining how a “solver” might create impact differently than an “architect.” However, I don’t know of any company that operates different ladders for each archetype successfully. Performance ratings seem simple but are nuanced and frustrating at scale across thousands of people.

Winding back to the specific question, I would ask the current tech architect team what they want. Long term, I think you’d be better off with the Staff-plus titles, but that sort of change needs to happen at the organization level and might take a while. Short term, it’s probably not worthwhile to change titles again if the change happened recently unless the team is already excited for the change. If you don’t make the change now, slot it into the organizational backlog and figure out when it might make sense later.

RSS feed changing! Migrating blog in next few days.

tl;dr - subscribe to RSS via /feeds.xml instead of /feeds/

The current version of this blog has been running for about four years, since I wrote Notes from fifth blog rewrite. It’s been running as a Golang service that loaded posts and files from S3, which has worked out surprisingly well for most purposes. However, there are a few things that have taken a bit of effort to keep working. In particular have spent a few hours each year on the GCP Kubernetes cluster, the Docker builds, and LetsEncrypt for SSL. My actual implementation ended up being quite similar to Hugo, and over the last bit I decided to bite the bullet to migrate to Hugo.

The new implementation is pure Hugo, served over SSL on lethain.com, hosted via a Github page, and continuously deploying via Github pages. I’ve always practiced a Cool URIs don’t change strategy with this blog, and I’ve done my best to keep the URIs consistent in this migration as well. There are a few URIs that don’t make much sense anymore, for example /all-posts/ will redirect to / since all posts are now available on / directly, but generally things are still where they were.

The one exception that’s been tricky is RSS feed, which more than a decade ago I decided to host at /feeds/, in addition to supporting a number of filters like /feeds/tags/os-x to only get an RSS feed restricted to a given tag. I stopped supporting the filtered RSS feeds some time ago, but still served the general RSS feed to any URI starting with /feeds/.

My migration plan is roughly:

1. Update the existing Golang service to serve the RSS at /feeds.xml in addition to the existing locations
2. Post this entry explaining the RSS feed has moved. My hope is this will support motivated folks to switch to /feeds.xml
3. Wait a day for various RSS feeds to retrieve this post, so at least they’ll have an explanation if this breaks
4. Hack the Hugo version to copy /feeds.xml to serve at /feeds/ and /feeds/all/. Redirect other known variants of /feeds/* to /feeds.xml
5. Live with the (hopefully minimal) consequences

I’m optimsitic this will work well enough, but I am hopeful that diligent readers will be able to read this as the last entry in my RSS feed and fix it manually. Apologies for the inconvience, and here’s to another decade or writing!

The overall look and feel is mostly an extension of the existing site, with some ideas borrowed from Julia Evans site as well on the story pages.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!