And I know that you went from that agency to working at IBM as a front end architect. I don't think I've heard of a front end architect before. I'm used to hearing a front end developer, but what's a front end architect? What's that

about? So this was sort of an accidental thing. I got hired as a staff level or one of the senior senior folks on the front end team. And what happened when I showed up is I realized that IBM cloud, which was the product that I worked on was made up of a few dozen teams. And each of those teams had a lot of shared code, but it wasn't shared in a way that was particularly efficient or really scalable, which is troubling when you've got 30 something teams. So I started looking at what everybody was doing. And we had, for example, if you were a day one developer joining IBM, you would get handed your laptop and they would say, okay, now install engine X. Hold on. That's not front end. Like, then this is way out of my, and then after that, you got to configure firewall. And then you got to set up the mock databases and it's like, well, hold on, this is too much. So what I set up for? Yeah, right. I've been doing this for a long time and it was still a lot for me. And we had IBM design ran a front end boot camp where people were coming out of 12 weeks of like, I just started coding 12 weeks ago. And their first day when they came out of boot camp was this. And I was like, this is not okay. We got to make this better. So I started looking into what are the common pieces? What are the things that are important? Like why do we set it up the way that we set it up? And so there were considerations around staging and security and general compliance. And we had a design system and all of these different pieces. So I started looking at how can we build the right pieces into the front end of our app so that all of these microservices that run the IBM cloud front end can be spun up by somebody on day one, regardless of experience level, so that they're actively contributing. And also so that when we have updates in the future, it doesn't require somebody to go around and manually copy paste code between these 30 something teams to get compliance solved whenever we get a new requirement. And so in doing that, when I started doing that work, I just started de facto acting as an architect there and ended up rebuilding a lot of internal tooling to simplify and work on the developer experience, work on the normalization of our development workflows so that people could actually follow it. So people weren't having to DM environment variables back and forth on Slack and all these other things that kind of happen as a code base gets big and unwieldy through some thoughtful design, you can eliminate the need for how that works. I called it a front end architect at the time. And what I realized was it was an internal tooling team

before I realized that internal tooling was a thing that you could be.