I find it a little grating when people talk about their jobs under the rubric of "personal news." No judgment if you feel differently, but in a perfect world, my personal life would not be meaningfully entwined with my job. That said, this post is all about how my job has affected me as a person this year and I will spoil it at the outset by saying the effect has not been good.
But in order to talk about how and why this year has been such an ordeal (beyond what you've probably already read about from other feds or news reporting about them), I want to back up a little and talk about my time in government more expansively.
A capsule history the last 6 years of federal government digital services
I joined government as a Consulting Engineer with 18F in 2019 during the first Trump administration. During that time, the White House's attitude toward digital service teams working to improve the public's experience of government services was one of generally benign indifference. I've heard stories of inflection points at which that attitude could've changed (more likely than not for the worse), but can't speak to those points with any first-hand knowledge. What I can say is that, except for a few high-profile projects, the White House mostly left us alone to do great, impactful work with our agency partners.
And while I definitely don't think Trump deserves special credit for being the one sitting at the Resolute desk when good laws happen to cross it, he is the one who signed the 21st Century Integrated Digital Experiences Act, and the Modernizing Government Technology Act (which created the Technology Modernization Fund) into law. These are still driving big changes in how feds build technology today. (Though it has to be said, as part of the contested budget driving the current shutdown, Trump's Republican colleagues are trying to zero out the TMF.)
Then President Biden was elected. Given the mostly listless back half of that administration, it's easy to forget how much promise there seemed to be at its outset. Remember when people talked about Biden being a new FDR? For those of us doing digital services work inside government, it's hard to overstate how excited we were. Key positions were filled with political appointees who either came from our milieu or clearly shared its vision and goals. And new sources of funding, like the American Rescue Plan, promised to be an engine driving the growth of new programs and platforms throughout government. The Biden OMB's Delivering a Digital-First Public Experience memo put real force behind implementing 21st Century IDEA.
Looking back now, it's hard not to feel like Biden's one term was a historically blown opportunity for creating the kind of lasting change that would've been hard for subsequent administrations to undo. Part of this is obviously due to the fact that, as we've all learned the extremely hard way, there's not much that the executive can't tear down—irrespective of laws or norms—if the putatively coequal branches can't or won't exercise their constitutional powers as checks and balances to stop it. However, while it's correct and important to point to the critical programs (like Direct File) and offices (18F, real USDS) the second Trump administration destroyed, one also mustn't overlook the unforced errors during the Biden era that prevented teams from moving the ball forward as much as they could have. (This isn't the space to litigate any of that but buy me a beer sometime.) Whatever the cause, it's impossible to deny how much has been lost in the first 10 months of the second Trump administration and how insurmountable the challenge of rebuilding any of it feels to many of the people who want desperately to do that.
2025
It seems hopelessly naïve now, but for those of us who were in government for Trump 1, there was at least a faint hope that things might go the same way this time around—that is, that maybe we'd be able to stay mostly under the radar this time too. Of course any such glimmer of optimism was thoroughly squashed after Trump's second election, and the clear signals that he was going to hand the reins of the administrative state over to Elon Musk and Russell Vought.
I was lucky. As part of a consulting project while I was still at 18F, I spent most of 2024 serving in an acting capacity as Engineering Lead for the US Web Design System. Then in October, just before the election, I was offered the chance to move into that role on a full-time basis. I jumped at the chance, not just because I loved the team and the products (though I emphatically did!), but because it seemed like a safer place to be than 18F in the event that the election went the way that it ultimately did. That bet paid off for me in a way that was even grimmer than I would've thought at the time.
Since January, the experience of being a federal worker has been a cavalcade of swords of Damocles, Chekov's guns, and precariously hung shoes waiting to drop. And unfortunately, just about every ominous sign did in fact portend real danger. At every opportunity, the people running the executive branch made it plain that rank-and-file feds were expendable at best and at worst, deserving of open contempt. There were multiple rounds of "fork in the road" emails from mysterious email addresses sent from insecure servers. Reductions in Force (RIFs), legal and otherwise, hollowed out still more capacity, and left those of us who remained in constant fear of sudden illegal termination.
At the beginning of the year, I was leading a small but amazing team of contract engineers working on USWDS. Shortly after the inauguration, that contract was terminated, so the USWDS team was down to four federal employee practice leads. Very soon after that, two of those dear colleagues left of their own accord. That left a team of two feds to steward the design system supporting hundreds of sites across the government web. The two of us were safe for the time being, but obviously we needed to drastically change our roadmap and the way we planned to go about delivering it. All around us, other similar contracts were being cancelled with little-to-no warning.
In the spring, I got notice that I was subject to RIF. Everyone who was in a position to do so reassured me that I wasn't actually at risk of being let go. I'm an engineer and the DOGE and DOGE-aligned tech bros running my corner of government value engineering over other skillsets. Still, it's not fun to have the legal process for termination hanging over your head.
Another of the administration's tactics to cull the federal workforce is the universal requirement to "return" to office. I use scare quotes because most of us were fully remote since before Covid. I've never reported to an office for regular work as a fed. None of the people I work with day to day work anywhere near me, so my going to an office wouldn't do anything to foster collaboration. The initiative is intended to force people out who can't or won't go to an office, and to discipline and surveil the people who remain.
These threats loomed over many feds, but one that threatened USWDS specifically is the executive order creating the so-called National Design Studio. This EO explicitly mentions USWDS, and we were left to wait to see what its actual impact would be on our team and the product. The early signals were extremely mixed. On one hand, the team got informal hints that we should have a wishlist ready to be able to say what we would need in order for USWDS to implement any directives that would come from the NDS and its director. On the other, we could see the NDS's early work, such as America by Design, The NDS's own website, and TrumpRx. None of these has much, if anything to do with USWDS. They also happen to be bad websites.
If these sites are any indication of what was coming down the pike as the future of government websites, it's a bad sign for the people who have to build and maintain those sites, it's a bad sign for USWDS, and it's a bad sign for you as a user and a member of the public. Prior to the shutdown, the USWDS team still hadn't heard anything about what NDS was supposed to mean for us or for the System. However, without delving into specific rumors, there have been indications that NDS's intentions for USWDS or its possible replacement would not be meaningfully better than the JavaScript-heavy, inaccessible, and AI-generated error-ridden sites than that office's early work would suggest.
Then the shutdown came, and the USWDS team was told not to come to work. This came as a bit of a surprise, since our team is not funded through congressional appropriation. The pot of money my last paycheck came from is still there. I've been through several shutdowns now, but this is my first furlough. The only thing that changed is the administration's choice to weaponize furloughs this time. As it happens, I was actually brought back from furlough, but only to work on a ridiculous website that, while it uses USWDS, is otherwise unrelated. I was also directed to spend no more than 5% of my time on USWDS (my actual job) until this other project is done or gets additional resources.
(Side note: if someone were inclined to look into the demographics of these discretionary furloughs as well as who was called back into work vs. who was left furloughed, the interested observer might find it lines up with other major personnel moves the executive has made this year.)
What's next?
It has been a deeply upsetting and at times traumatic year, but I've weathered it as best I could, and managed to stay employed. In the early part of the year when I expected to be RIF'd along with all of my dear friends and colleagues from 18F, I interviewed to the point of near-burnout. I even had an exciting offer to go work on a state digital services team that, after agonizing over the decision for a week, I ended up turning down to try and stick it out with USWDS and GSA.
However, things are a bit different for me today than they were those handful of months ago. Back then, the NDS threat hadn't yet appeared on the horizon. And I believed then I'd be able to avoid having to report to a random, decrepit building for RTO, which I no longer think is possible. And there's just the simple fact that I've been steeping in the accretion of this misery for that many more months, which has taken an ever-increasing toll. Finally, to put it plainly, the horrors that the federal government has been perpetrating in areas that don't have anything to do with me directly have nonetheless become impossible to shrug off and I don't want to have even a whiff of complicity with them.
So, some personal news: for all those reasons, I resigned. As of today, I'm no longer in federal service.
On the happier side of the ledger, all of those things also lined up with a terrific opportunity to keep working in public service and design systems. I'm going to keep the specifics of that role out of this post, since this is all very dark, and I'd like to keep a little distance between all of this and the new role. But suffice it to say, while I'm mourning my own federal service and the dire state of the republic, I'm incredibly grateful to get to keep doing work that's both personally fulfilling and technically interesting.
Before closing this out, I do want to say how grateful I am for the great years I had as a fed: for all the work I had the opportunity to do, and most importantly for all of the wonderful people I had the life-changing good fortune to work alongside. To everyone still there, thank you for your continued service. You deserve so much better.
It turns out that, at least for the time being, I work on a design system for a living. I also happen to really like working on them, so here I am (on the weekend!) blogging about some web component-based design systems I've come across recently.
generic is a cool idea in that it's a set of (mostly) unstyled components you can pull in and style however you like. And maybe you've heard that web components are hard to style because they use shadow DOM: well good news, friend, because generic's components are mostly light DOM. Where generic does use shadow DOM, it still exposes shadow parts or provides custom properties to make the component styleable (see the generic-radio for an example with both).
What's great about leveraging light DOM so much is that, in addition to being easier to style, it's also more accessible and performant. The more content that goes into light DOM, the less work the custom element JS needs to do, the more content is available immediately, and less depends on JS executing at all. This jargony name for this architecture now is HTML Web Components (although generic predates this coinage by a couple of years), but the basic idea is just that you should leverage semantic HTML for as much of a web component's content and functionality as possible.
Another web component-based design system I've been looking at this week is tyler forge, by Tyler Technologies. It's not unstyled like generic. Its design is based on Material. It's also not shy about using shadow DOM. Different strokes, etc. What I like about it is its modularity. The way it does theming by exposing custom properties and shadow parts is a lot like what I want to do with USWDS. It's also got CSS-only components that are, um, CSS-only. I think the thing that jumped out at me was the mixed Sass/CSS custom props codebase, which is what USWDS is likely to be for a long time. I'm not sure I have anything smart to say about tyler forge, but I wanted to jot down some observations while they're fresh in my mind. extremely Marge Simpson voice I just think it's neat.
One last thing: just going to drop this prototype accordion component here. I've been wanting to make something like this for USWDS (which is why the tag name here is usa-accordion). It's just an accordion made out of details and summary elements, and it's all light DOM, so the basic functionality will always work. The only thing the custom element adds is the exclusive prop which, if set to true, will add a unique name to all of the details child nodes, triggering the browser-native exclusive accordion behavior. Since the unique ID is generated per-component, multiple accordions won't interfere with each other.
My favorite project that I've ever worked on is one from my early days at 18F. It's the one that really helped me get what the work was. I'm going to talk about everything I was lucky enough to work on on this project and some of the things I learned doing it. I'd love it if you took away some lessons about how great projects work, but I'd be lying if I said I didn't hope you'd read it and think about what a shame it is that the group who did this work no longer exists.
I won't name the partner for this project, and I'll leave out some details so as to not identify them. Given everything, I don't really want to call extra attention to 18F's partners, and honestly I don't chase down all of the things I would need to get permission to go into more detail. Besides, the work and methods I'll talk about here would've been employed on so many different projects with so many amazing agency partners.
The background
This agency had a ton of data, going back over a century, scattered across multiple databases, in multiple formats, with multiple schemas. They needed to consolidate these in some way in order to make those data usable. In addition to the data wrangling, they also needed a new frontend to give their users access to those data. Naturally, with all of those data on the backend, and a new frontend in the works, they also needed an API to get data back & forth.
In addition to the technical challenges, this agency served a huge variety of users, including research scientists, internal customers, and members of the public who used the data for recreational purposes. Whatever solutions the agency deployed would need to serve these vastly different users and use cases.
The team
The team from 18F included a backend dev, a strategist, a visual designer/user researcher, and yours truly as the frontend dev. The backend dev and strategist also shared project lead responsibilities. On the partner side, we worked regularly with the product owners as well as two engineers. Since this was one of my first projects at 18F, it was also one of my first experiences working closely with career feds.
One of the first things that made this project such a great experience was having such engaged and empowered product owners on the partner side. They participated in all of our standups and sprint ceremonies. If there was a blocker, they would hear about it immediately and help get unstuck. It also really helped build a sense of shared ownership of and responsibility for the success of the project. I'll talk a lot about secret sauce in this post, but I think if there's one thing that can make or break a consulting project, this is it: having an engaged and empowered product owner work as closely as possible with the team.
The work
Backend
We had a good sample of a few data sources we were going to have to pool together, but not enough to make big conclusions about a schema for the whole system. Basically we had enough to start prototyping with. Our backend dev whipped up a simple Flask app as a first draft REST API. However, given the complexity of the data and the wide variety of queries the API would have to support, we wanted to test out alternative alternatives that might be more flexible, and landed on GraphQL.
This was my first time working with GraphQL, and at the time I had what I called "podcast knowledge" of it, meaning I'd heard a lot about it on podcasts but didn't know much else. Since there were bigger questions about what we were going to do with all of the data–questions better-suited toward someone with real backend chops–I took point on adapting our Flask API to support GraphQL. It ended up being a pretty straightforward job of adding graphene to the Flask app and wiring it to the existing endpoints. Out of the box, this gave us the graphiQL in-browser interface to demonstrate the kinds of queries the API could support so we could get confident that it would be flexible enough to do what we needed, to do user research on the queries with technical users, and to continue to get buy-in from stakeholders.
Frontend
The earliest designs were clickable wireframes, and these were what we used for the first user research sessions. At this point, I don't remember what tool they were built in (probably would've been Sketch or Adobe XD), but they were fairly low-fidelity. For user testing purposes, they were extremely path-dependent and so were very brittle. These artifacts were hard to test with and hard to iterate on, so we made the decision pretty early on to switch to a live in-browser prototype. I'd say this was another of those secret sauce decisions that really helped the project on the path to success (paths don't typically involve sauce but I'm leaving the mixed metaphor.
Once we made that decision, we had one last Sketch-based comp to get something slightly higher fidelity to work from, but the rest of the design happened in the browser, where the designer & I paired on everything. Having a great design system as a starting point made this process so much easier. From this point on, all of the user research happened with a live prototype, talking to a real (prototype) API. After synthesizing each round of research, we could immediately iterate and fold updates right back into the prototype. The dream.
User research
I mentioned before that the product was going to need to support a huge variety of users with vastly different expectations for what data they would need and how they should be able to get it. Given that, it was important to get representatives from as many types of users as possible into our research interviews. Recreational users would need to be able to easily get hyperlocal data and see it in a way that would be understandable and meaningful to them. Expert users would need to be able to get all and only the data they need, ideally through UI-driven queries. In the event that the UI didn't do what a user needed, we could test queries in the graphiQL interface to see what they needed that we couldn't yet do. And finally, for those who needed it, we added in bulk download options that would let users get everything and crunch it as they saw fit in their own tooling.
Making something that worked for all of theses users required lots of interviews, and thuse required access to lots of users. This is one of those areas where having a product owner closely involved was critical. First, having someone at the partner agency who knew exactly what we needed was critical for recruiting the right research participants. And having someone with domain expertise in the interviews themselves helped us drill down into questions we hadn't necessarily anticipated exploring, and this expertise was also super helpful when it came time to synthesize the research.
Takeaways
At the end of a few sprints, we had a great prototype of a new interface to this massive store of data. And we knew it would work really well for a wide range of users, because we'd asked a lot of them. All in all, this was about 90 days of work, and it helped the agency set a course for the next several years of development on this project. For me, it showed how much a small cross-functional team could do
Find a product owner who can be a real part of your team, and get them as invlolved as you can.
Get real, working code in front of users as soon as you can.
Do as many interviews as you can with real users. Until you get something in front of users, you might have ideas about what can work, but you don't actually know anything.
As excited as I was to join 18F, I admit that before this project I didn't fully understand what was so great about 18F's methods. Once I saw these practices in action and the kinds of results they could bring about, not only did I get it, but honestly I wouldn't shut up about it. I preached this gospel with the zeal of the converted. Maybe most importantly, I spent the rest of my time at 18F trying to put these lessons into practice and doing what I could to help the org keep doing this critical work.
I'm grateful I got to work on this project, and a bunch more like it during my time at 18F. And while I'm sorry to end this post on a bummer note, revisiting this just drives home for me just what how much was lost when 18F was shuttered.
Also, if you want to learn more about these pracices so you can use them in your own work, the former 18F team rescued all the 18F Guides and added them to 18F.org.
Over the weekend, 18F was eliminated, and all of its staff placed on administrative leave in anticipation of imminent termination.
I left 18F in November, so I wasn't directly affected by this massacre. But I was at 18F for over 5 years and these were some of my closest colleagues and dear friends, so it's not that I wasn't affected at all. The secondhand trauma is real. The survivor's guilt is real. Honestly, the small twinge of jealousy at the clarity of purpose my former coworkers now have is real, too.
When I left 18F to join the USWDS team, I moved from one dream job to another. But the move was, in part, a strategic bet that I'd be in a safer place depending on the election results. After this weekend, there's a sense in which that bet paid off. But there aren't any safe jobs in the federal government, and there sure as hell aren't any dream jobs. One of Project 2025's architects, and now chief of the Office of Management and Budget expressed a plan to put federal workers in trauma. That effort has been a wild and terrible success.
Why did this happen?
(Even though I'm writing this on a personal device on my personal time, I still work for GSA and am still bound by its social media policy as well as the Hatch Act. As such, I'm going to limit this to only public information and refrain from expressing certain political opinions)
Recently, one of Airbnb's cofounders announced he was working with DOGE to "to improve the user experience within our government." What if I told you there was a group of user researchers, engineers, product managers, and procurement specialists within the federal government whose job was to partner with other federal agencies, learn directly from them and the people they serve what problems they face, and come up with solutions tested with real users? Well there isn't. Not anymore, anyway, since they were all just fired. I'm being glib, but my point is that 18F excelled at doing all of the things DOGE purports to want, including dramatically eliminating waste. See here and here and here for just a few of so, so many examples.
So why did they kill 18F? If you ask me in my totally personal non-official opinion, it wasn't despite 18F's success but because of it. But don't take it from me, take it from 18F's last Executive Director:
The administration got rid of 18F under the cover of night. People who own skyscrapers are afraid of 100 people who make websites.
Not because of the latest tech fad, but because we proved the government can be fixed, the government can be made better and the government can work for the people. - Lindsay Young, on BlueSky
I joined 18F almost 6 years ago, during the first Trump administration. It was important to me to ensure that people could have good experiences of government services. At the very least, I wanted to help keep the lights on until it was time to build again. With the American Rescue Plan, Technology Modernization Fund, and other drastic interventions, it was once again time to build, and dammit 18F built. 18F built or helped build: IRS Direct File, get.gov, Federal Audit Clearinghouse, American Climate Corps (RIP), and so, so much else. But that's the rub isn't it? At the end of the day, you either think government can and should make people's lives better, or you don't. If you think government should be in the business of helping the public, you'd keep 18F and throw a bunch of resources at them. If you didn't think that, well....
Now what?
If you want to know what's next for everyone from 18F, stay tuned. I mentioned a bet earlier. Here's another bet: if you piss off nearly 100 of the most capable, driven humans around, I bet you're going to end up regretting it.
What's next for me? I really don't know. For the time being, I still have a job. I don't for how long that will be true. I definitely didn't expect to be looking for a new job anytime soon, so while I'd prefer to be more strategic about my next role, I may not have that kind of luxury. We'll see, I guess. I would really like to believe that, if I'm able to hang on, I can still do some good. But the disgraceful treatment of 18F makes it all too clear that doing good is not an option for the time being.
In the more immediate future, I'd like to write more about my time at 18F, so if you want to hear more about that, for now the best way to follow that is on BlueSky. (I'm an RSS guy and I'll make a feed for this site, but I'm trying to post things instead of yak shaving. Update: Ok I made an RSS feed, so I feel better about that at least). Right now though, I'm going to mourn just a little bit longer and support my 18F comrades however I can.
This was my second week no longer being at 18F and serving full-time as eng. lead for USWDS. I had big plans to make some progress on some ADRs I need to write. I made just slightly less progress than intended (read: none at all).
Not work as such, but it's been fun noodling on this website again. I like the colors. I like the octopus. Upgrading to Eleventy 3.0 was a breeze (probably because I'm barely using it so there weren't any breaking changes that actually impacted me and switching to esmodules meant changing, like, three lines).
Things I read
CSS Parts are saving you from a nightmare by Michael Warren. This is a response to some criticism of CSS shadow parts on an episode of Shop Talk. The criticism boils down to Chris and Dave wanting a "I know what I'm doing" selector for styling custom element internals. Warren's post argues, in essence: even if you think you want that, you really don't—at least not if you're using someone else's components. CSS Parts are part of the API surface of a custom element (along with any attributes, slots, custom properties, or public methods the component exposes). If you're using someone else's code and don't want stuff to break all the time, you should stick to using the public API!
Hobbies
Last week of the current block in this technique cycle. Next week's a deload (boooooo). But I did hit my old strict press 1RM for an easy triple!
I have also been running and I'm in a good place with that. It's a nice thing to do a few times a week and feel like my heart and lungs are in good shape.
I've been coasting on language learning a bit this week.
I'm working on a High Profile project I won't go into beyond saying that the portion of it I'm working on is a big Typescript/React project. I've been working on improving test coverage, and wrapped up testing a giant chunk of the front-end portion of the knowledge graph that drives the project.
Unrelated to project work, I had a big, stressful choice to make I'm being purposefully vague about. I was a wreck about it for about 24 hours, but once I had made a decision about it, I was serene as could be.
Things I read
Tailwind marketing and misinformation engine - I'll confess to having a strong anti-Tailwind bias. That said, I did recently go through the Frontend Masters Tailwind course course. I enjoyed it and came away with a better sense of when and why I might use Tailwind (for prototypes—it's for prototypes). So I have softened a bit in my opposition to Tailwind, but reading through this piece really drove home what a bizarrely toxic presence Tailwind's leadership is in the webdev ecosystem. Read the post and look at the keynote slides in there and come up with your own conclusion I guess but after seeing that stuff, it's not a mystery why online conversations about Tailwind are so pitched.
Training
I've been training olympic lifts full-time for 3 weeks now (5x/week, up from 3x/week + CrossFit), and I feel like I'm really starting to see some big technical improvements, especially in the snatch.
My conditioning is noticeably declining, though. That's something I need to address, but in a way that doesn't detract too much from my main training goals.
I always knew that <C-o> would let you jump back to the previous cursor position, even if it was in another file. (And when I say always, I mean always. Like Meno always knew geometry.) While I was backtracking around with <C-o> today, it occurred to me that there must be a way to jump forwards again, and of course there is. It's <C-i>. The one right next to o on my keyboard.
Bonus tip
I didn't learn this today, but it's still a good tip: similarly to <C-o> and <C-i>, you can jump to the last-edited line with '., and the last-edited part of the last-edited line with `. These marks are built into vim. But that's not the tip. The tip is that if you use which-key, which-key ships with plugins to display the current contents of your marks and registers when you hit ' or ", respectively. Marks and registers were both things I always meant to use more frequently, and this has helped me get there.
Lol ok another bonus
Ok this i really did also learn today--mere moments ago, in fact. If you want to escape a backtick in a markdown inline code block, use double backticks with space around them, like so:
The basic skill of programming is not writing code, it's solving incredibly tedious puzzles over and over every day for years to produce a new app that everyone will hate being forced to use.
Are you sick and tired of fighting specificity in your CSS selectors? Have you ever wished you could tell the browser: "hey, my components' styles should take precedence over competing design system rules"? Well friend, do I have news for you. Cascade layers are here, and they basically let you do just that.
I knew these were a thing, but hadn't had occasion to really do anything with them yet. Then layers came up on the most recent episode of Shoptalk, and since I have a web project in progress right now (this. It's this website), I thought "ok let's do this."
The layers usage here is pretty simple, which oughtn't surprise, given that it's a simple site, but I think it still shows some of what the feature can do. All I'm doing is putting the third-party styles (in this case, normalize.css) in its own layer, and my styles in a layer on top. Even here you can see the utility: if I'm overriding something in the third party styles, I can stack (pun not intended) the deck in my styles' favor without having to arbitrarily increase the specificity. And if I wanted to add another 3rd-party library, like OpenProps or something, I could give that its own layer between the reset and my stuff.
@layer normalize, mh;
@import 'normalize.css' layer(normalize);
@layer mh {
/* ...all of my other CSS goes here */
}