It’s been said that the current state of generative AI is similar to the late 90s internet: definitely a bubble that will pop, definitely something that will fundamentally alter the way we live and work. Maybe that’s true. But it’s hard to explain the early internet days to people who weren’t around to experience it. All of a sudden, you could write something and share it with the world, correspond with a far-away friend sans post office, or join a group dedicated to a esoteric interest. I had my own little corner of the internet in the form of a personal blog, where I wrote fake art reviews and shared stories about life in Philadelphia without worrying about surveillance or scraping. That silly website led to a job, a husband (who found the blog via a work-related Google search), and real-life friends. At its best, the internet was (and still is) a convener of humans, and that’s where the comparison to generative AI breaks down.

The newly-released source code for IRS Direct File is a truly important artifact for: * anyone who has tried to express the U.S. tax code programmatically * anyone interested in how teams make technical decisions. The former group should check out the Fact Graph, which deserves its own post (IRS DAG, anyone?). For the latter, the repo’s docs directory has all kinds of rare treats. If you’ve ever worked in government, you know how hard it is to publish _anything_ , let alone something that describes your thinking or lessons learned. Much respect to the Direct File team for including artifacts about their research and decisions. The themes of the project’s architectural decision records (ADRs) are pragmatism and simplicity. Which isn’t to say that Direct File is simple. My impression is that the team rightly chose to spend more time on unsolved problems (_e.g._ , representing the tax code as a graph) and less time on solved problems (databases). These ADRs were some of my highlights, but they’re all worth reading. ### On simple databases > The data we are planning to store is not so large as to cause a problem for any common RDBMS provider. There won’t be any particular slowdown or read issues associated with reading the data out of the database. > We can architect around having the database be a single point of failure in our system… If our database system does go completely down, our system will go down as well. Introducing another system doesn’t solve that problem, and it in fact compounds the problem. **Spoiler:** They went with Postgres ### On choosing programming languages I confess to pouting a bit after realizing that DIrect File is Java-heavy, which is why I really appreciated this ADR. In addition to noting that the IRS is already a Java shop, the document lists a number of other technical considerations, many of which aren’t obvious to someone without tax domain experience. For example, Direct File needs a language that works well with WSDL/SOAP because that’s the basis of the electronic filing system it integrates with (IRS Modernized e-File system). There’s also a lot of Scala in Direct File, an unexpected choice for government. However, Scala has strong support for graph concepts and also runs on the JVM: > All of the support systems are already in place within the IRS to update and manage Java systems. Except for the code, our systems will appear no different. They will use common Java libraries, common java tools, and require the same sorts of maintenance. Regarding Python/Node/Ruby, the ADR is tough but fair: > we don’t want to have to go through open source package management nightmares in a production application ### On deciding against microservices for the data import system > Philosophically this works, but it adds a lot of failure points for very little gain at our current scale and set up Also: > I would like to hear a solid reason why breaking this into multiple applications is worthwhile. Shout out to the old _Software Architecture: The Hard Parts_ book club at Trello!

Some of the deaths of Direct File.

Today is one of those perfect spring college campus days. The trees are flowering, the sky is blue, and every open space is filled with students enjoying the sunshine. I’m writing this while sitting in one of the many Adirondack chairs scattered around the lawns. Someone is blaring country music, Rhinestone Cowboy. I’m not sure how—what is the 2025 equivalent of a boom box? Anyway, I just turned in my UMass laptop because my job here was largely CDC-funded. There’s a good chance the grants will work out, and I hope they do. But in the meantime, I have a family to support and can’t really wait around to find out. [we’ve moved on to Dancing Queen, and now there is singing—some things never change] I’m lucky. I had the time for an orderly wrap-up and the time to find a job I’m really excited about. But I’m still mad. For myself, because I had more to do here, for my erstwhile colleagues who are seeing their life’s work maligned and threatened, for the guy sending the voice of Elvis across the steps of the campus center, for all of us.

I’m wrapping up an eighteen month stint as a research fellow/research engineer at the University of Massachusetts. Specifically in the Reich Lab, a research team within the School of Public Health’s Department of Biostatistics and Epidemiology. After six-ish years at a tech company, academia was quite the culture shift. A few former colleagues have asked about making the transition, so what follows are some 100% personal thoughts about the work (which I loved). Unlike engineering at a company that sells software, research engineering is a supporting role—a means to an end. You’re on someone’s grant to help them accomplish their research objectives. No one will open a JIRA ticket with a user story about tracking MAU. Instead, the smartest people you’ve ever met will walk into your office and start writing on the white board. If there’s no white board, they’ll grab your pen and start writing in your notebook. Sometimes the problems that need solving are in familiar territory: optimizing code, moving things to the cloud, GitHub security. And sometimes the problems that need solving are miles out of your comfort zone, like applying past versions of a SARS-CoV-2 phylogenetic tree to the latest batch of available genome sequences. If you don’t have the background to jump in immediately, your colleagues are generous and patient teachers. Your communication skills will improve because you’re no longer on an engineer-only team, and you can’t fall back on engineering jargon to explain your work. Your technical skills will improve because you’re working under a different set of constraints. Peer review is ingrained in academia. LGTM is not a thing, so you’ll start writing clearer documentation, issues, and commit messages. You’ll get questions that force you to sharpen your thinking. There’s no product owner, micro services platform, logging service, event pipeline, identity management, or security team. Tech titles like staff and principal don’t mean anything. You can make yourself valuable by going broad, encouraging industry practices where they help, and letting them go when they don’t. What’s next is exciting, but I’m beyond grateful for everything I learned at UMass and the brilliant people I met there. See y’all at the Blue Wall!