Platform Engineering for Social Good with Code for America’s Grace Huntley

Episode Transcript

Welcome back to the platform engineering podcast. Today we have an inspiring guest joining us. Grace Huntley, Director of Engineering at Code for America. Grace has over 15 years of experience in the tech industry. She's recently moved from the private sector to civic tech, where she's making a significant impact. At Code for America, she's at the forefront of blending DevOps, InfoSec and innovative solutions to address some of society's most pressing challenges. We're going to dive into her journey, the incredible work she's doing at Code for America and how her personal experiences have shaped her approach to technology.

Grace, welcome to the show!

Thank you, it's really nice to meet you.

Yeah, thanks for coming on. You have a background that I love. Sometimes you meet developers and it's like they do one thing. It's like I've done mobile development, I've done it for 15 years and I've worked for like Google. Or it's just like they've done one thing for real. I love meeting people that have just been in different roles. You've been a mobile developer, you've been CEO, you worked for large for-profit companies like PayPal, and now you're at Code for America.

Code For America

So I'd love to know just kind of what originally sparked your passion for technology. And then I'd also just like to share a bit about Code for America for people that might be unfamiliar with it.

Yeah, absolutely. To be quite honest, many of my friends call me Forrest Gump. I'm not from a typical background. I don't have the education. I'm actually a licensed plumber.

[Cory laughs] Nice.

So what drove me into software was my daughter was born with severe epilepsy. Android phones were brand new and they had these sensors and I was very excited. So I'm like, well, maybe I can figure out how to write an app to kind of learn and predict seizures. So that was kind of where my journey started.

I taught myself Android, started writing the first app–it was horrible, but it kind of collected data, so that was great. And then I kind of transitioned. I got my first job, because I realized I had to pay my bills, and I gradually moved up.

I really like to solve problems and learn what I need to solve a problem. I consider myself a fast learner. And I've kind of jumped around. I've gone all the way up. I've decided to go back as an IC at PayPal just because I felt I was away from the baseline for too long. And how do I lead people if I don't know what I'm talking about? So I'm kind of back in this kind of growth scale.

I felt I was away from the baseline for too long. And how do I lead people if I don't know what I'm talking about?

As for my transition to Code for America, you know, I've interacted with them over the time. I've been a volunteer judge at a lot of hackathons and I've always interacted.

I had no idea what they were. And this was a point in my career where I decided I was going to start moving into doing good with my experience because I could also afford to at this point in my life. And this opportunity came across and I was like, yes, please, let me work on this stuff.

It's really close to heart, which I mean, again, my daughter with special needs. I personally have struggled getting like safety net benefits for my daughter, not knowing what was available, going through the application process. It took about 16 years for me to get all the things that are available to her. And now today, I get to spend every day making it easier for others so they don't have to wait 16 years.

Yeah. So actually I truncated your title quite a bit. So your full title is Director of Engineering, DevOps, InfoSec and Safety Net Innovation Lab.

So I'm familiar with Safety Net, I was actually a SNAP recipient as a kid. But just for people that aren't familiar with SafetyNet programs, can you share a bit about those and how you're kind of blending that in with the work that you're doing as a Director of Engineering?

Yeah, absolutely. know, safety net benefits are really… it's an interesting title. So really what we cover is mostly the things that people need in a crisis that are provided by the government. That's kind of it in a short form.

For example, like SNAP, we built Get CalFresh in California, which simplified the application process for CalFresh significantly. We did a kind of experiment using a lot of human centered design, a lot of research, just to know–because typically forms were taking like two hours and we got them down to like sometimes 20 minutes. People can have an application in place, they're much more reliable.

We do get childcare assistance applications.There's a whole lot of safety nets benefits. Currently we're kind of transversing across multiple states to try and help them make access easier. A huge focus is accessibility, different languages that are more prevalent in those states to really make people have easier access. Everything we build is extremely mobile friendly, fits on a small phone and functions and is severely lightweight. Our applications can be filled out on really low grade older phones–people in a crisis don't typically have the most powerful devices.

Yeah, I feel like that's a place where you have a lot of folks that may not even have a home computer, right? So sitting there filling out an application for two hours online means you're sitting at like a Kinko's or on maybe like a low-powered or older android device or something like that. So getting that down really does probably significantly change the number of people to get through that program or at least apply to it.

The Intricacies of Working With Government

So as far as working with the government, how does that work? Is Code for America a separate entity that works alongside a lot of government agencies? I'm not really sure what the word is here, is it more ingrained with those agencies or is it a completely separate entity?

Yeah, so we're quite an interesting organization. We are a nonprofit. We're non-governmental. We kind of work outside. We have a lot of researchers. We have program people. We have people in all the areas where we kind of look at different states and often we look at the lowest hanging fruit that has the biggest impact because a lot of what we want to do is show the states that it can be better. You know, that what they're providing for people can be better.

It's not necessarily that we're going into the government and we're fixing them. We're demonstrating. We're building prototypes. We're sometimes building products in front of their product which makes it easy, and then ships into their complicated product.

A lot of our funding is philanthropic.We also do individual donors. Sometimes we do gain revenue from governments when we build something for them–like, “This is great. We want to support this longer term.”

We do work with government entities. We work closely with different states when they come on board. We kind of work in cohorts right now, typically four to five states. Some states were just doing advisory research. Some states were actually building products for them. So there's a lot of variances.

So do you work with all levels of government, like local, state, and federal, or is it all at the state level?

Right now our biggest aspect is state. We do have a local initiatives program… again, it's interesting to go back to my role, so technically I lead the safety net product engineering department but since I also lead DevOps and InfoSec, I kind of touch across all of our organizations.

We have a criminal justice organization, which Clear My Record is one of our products where we simplified and made it much quicker to actually clear criminal records for marijuana convictions.

Nice.

We do a lot of tax. We're doing free tax filing for low-income people, like file your state taxes, get your refund. Simplifying it, helping people get credits they never knew they were eligible for.

So I do touch across all of those orgs, but I would say the biggest part of my work is safety net, since I'm like intersectional in multiple areas of it.

So doing things with free tax filing–I think probably everybody agrees that that should just be free. We shouldn't have to pay money to give money away–Does Code for America come up against lobbyists in scenarios like that? Are you actively working against them or is it just simply building a product to show a local government or state government how this could be used? Are you struggling with external forces like that?

The interesting part is, we've gained a lot of interest with Direct File coming out with federal income taxes recently. I'm not sure if you heard about it, it's been all over the news. I'm not sure the exact number, but it's free federal tax filing for low income people. So we've got a lot of support and that's why we've been able to expand across states. We're moving more and more states to support with the state taxes.

I'll be completely honest, I won't give names, but there are definitely organizations that do taxes for profit that have hired lobbyists. Not so much against us, but it's against the government in general kind of going this way. So, you know, we don't get that direct effect, but we do have to do a lot of influence work, really kind of like making the case. Which is sometimes surprising because it seems pretty obvious that this is something we should just do.

Yeah.

But there are always these kind of competing motivations.

So going from the private sector to government, I would make the assumption that that is a pretty big shift in like practices and age of technology. Like what is that like going from working for a behemoth like PayPal to working for a not-for-profit?

Yeah, you know, it's quite interesting. There's multiple aspects to it.

One is, you know, with an organization like PayPal, we typically have a lot of money and with everything we do, we make more money. So, you know, we can kind of like play with things. We can buy the most expensive thing off the shelf, if need be, to get these out the door.

Whereas, you know, the combination of working in nonprofit and with government…So nonprofit, obviously we are tight, we don't have all this extra money. Every bit of money we have, we spend on solutions to help people. But on the other side of the story, a lot of government systems are dated. I'll be nice, I will say dated. With us having to interact with kind of these older systems, right, we do our best to meet them where they're at. But at the same time, we are always trying to find opportunities and influence to advance and kind of bring them closer to their future.

So we have to kind of wrap ourselves around the fear aspect about new technology. You know, I'm sure we'll talk later about AI. There's a lot of fear around it, especially in government, which is understandable–bias, et cetera, privacy. So we kind of have to really

show them what we can do at the lowest level of technology. Then we have to try to figure out how to introduce higher levels of technology.Do we create gateways? So like we can have this modern stuff touching the old, which is definitely interesting.

There's a lot more thinking than doing in this world. We can't really just kind of hack away at a problem and then put it on paper after. We're kind of the opposite.

Sometimes we do handoff work - we build prototypes, we hand it to the government. So a lot of times we'll try to build it in the language of their choice. Like who do they have the most resources for? Which more often than not are not necessarily our favorite languages, but we do what we can to kind of get in the door and kind of make proof of concept.

COBOL

Are you doing COBOL?

Sorry?

[Cory laughs] Are you doing COBOL?

I'm not listening to you right now.

No, I mean I've heard the word come up a few times. So far I have not. I've heard stories in the past that there have been moments they've had to kind of go in there. I mean, you know, COBOL is a great language. It works, it just works, right?

I tell most engineers right now, especially ones that are looking for jobs, learn COBOL. You're guaranteed a job for life. There's always going to be a government entity that will hire you and pay you a lot of money if you can do COBOL.

I have friends that actively develop in it. They're just like, “All these newfangled things that you have, I don't need that. I've got myself a COBOL and I'm good.” It's like that is…

It just works

It just works… I guess.

Not exciting, but it works.

Oh my, sorry. That was funny.

Security and Compliance

So with all the different agencies that you work with–we'll get into AI in a bit–but like I think the base layer, the concern always boils down to security and compliance. So, what is that like at your organization where you're building a lot of prototypes and sometimes you hand it off and sometimes you're building things for them? Like in your approach to security and compliance and your role that is DevOps and InfoSec, how are you bringing those together to help build more secure and compliant government services?

Yeah, you know, it's definitely interesting. And honestly, it's the biggest top of mind thing for me right now. Because we work with so many different state, federal…we have so many different compliances. We have things like NIST, we're going for SOC 2, some states have a subset with an expansive set of compliance very specific to the state. And there's just so many areas that we're trying to understand.

So, as part of my joining, I've been trying to simplify and restructure compliance to make it kind of its own position, its own role. And then figuring out how we optimize and simplify compliance.

One of the experiments we're working on is like, how do we look at all of the most common compliance models or frameworks that we would ever encounter? And what is the one list of things that would really kind of check off most boxes? And we're starting to kind of build in that philosophy.

And then we're also kind of looking at IAC and automation. As we move into microservices, the concept is we really cut down on the complexity of a solution. Like, say this is a function that uploads a document, right? In a dream world, I could say to an AI chat bot, I want to build this document uploader that does this, this, this, this, and this. And automatically we're going to pull in all the policy documents into this folder. It's going to be stamped with this service. It's going to wrap the service. The IAC scripting is actually going to build this in a compliant manner. By doing things like that, it actually lets us scope lower. It also lets us realize if there's changes in compliance, we can go back and look at the smaller piece without going through 10,000 documents or, you know, a full review.

So we're trying to break it down into smaller pieces and spread it out. But also identify how can we do it once and solve it all? Because it's a huge… like it's a full-time job, compliance, especially working in these different areas.

All engineering should technically be Platform Engineering. We should be building things in these kind of little pieces that are reusable, movable, and interchangeable.

Are you kind of shifting as part of the Platform Engineering work? You said it's like its own role. Is that like a role on the team that is doing the platform work? And it's like they're trying to build that as a part of, I guess, the product there? Or is that more of an education role where you're kind of pushing that knowledge? Because compliance, like it's partially infrastructure but it's also logic in your application. So, how is that role acting?

That's part of the bigger transition as I'm trying to kind of go as more Platform Engineering. In the past, we've built solutions specifically for states or governments or whatever. When I came and I looked at all the products we've ever built, fundamentally they're all the same. Each application is a sum of many solutions. So we're kind of moving a lot of reusable solutions in smaller pieces. And I'm migrating our DevOps, InfoSec, and our newest hire, which is a compliance person, to be more advocacy, education, and kind of the guardrails and the governance at higher level. Obviously, they're going to personally do some of the bigger lifts.

I come from an area where, you know, in the olden days we knew how to do almost everything. You know, we could spin up our own servers. We could do this and then write the code on top. Where nowadays we’ve kind of moved to this like full stack methodology, that's not really the full stack because like they build this application and then they say, “Here DevOps and Security make it actually work.”

Yeah.

When it doesn't work, “Oh, it's broken.”

I'm trying to move more to people that are working on much smaller solutions and actually understanding and being enabled. You know, with the assistance of IaC that they can actually go from bottom to top there. They are educated on security, we've also automated some of the security. They're educated on DevOps, they can run that. And they have a support system. And then, you know, DevOps, cybersecurity, these other people can really focus more on research, teaching them what are the newest advancements instead of really sitting in the trenches all day just spinning up servers.

Really my idea is like all engineering should technically be Platform Engineering. We should be building things in these kind of little pieces that are reusable, movable, and interchangeable. And maybe junior engineers, their first entry level is actually being the assembly person in the middle, and that way they get kind of insight.

Junior Developers

Back in the olden days, you’d come on as like a junior on a team and you’d have like this true like full set… might be like the LAMP days, right? You're literally standing up the machines, you're standing up Apache configurations, right? And so you're seeing kind of all this, but today… it can be intimidating to be a principal engineer that's joining a team.

The amount of services that we're using in the cloud is just massive. You know, we've got a number of microservices and so the idea of a junior coming into that and seeing so much can be pretty intimidating. But at the same time, like the advocacy for why we're doing this and that documentation about how we're doing this, I think is really important for them to be able to level up.

We're seeing this kind of as a problem across our industry as a whole, relative to the amount of people that we're making that are software developers, tons of junior developers are coming out of boot camps. We're not keeping up with keeping them informed on how to manage the cloud. And so we're getting a very large knowledge gap between people that do understand how to do it and people that don't have that experience, and crossing that chasm is pretty difficult.

Right, it is. And I mean, of course, you know, there's so much more to learn now, right?

As we've had so many more advancements, it's hard. It's kind of like doctors, right? Everyone is a specialist because there's so many things. But, you know, if we, instead of focusing them on a specific technology, we focus them more on a specific function. You know, what is their specialty? Are they a document specialist or whatever? You know, they can learn all the aspects around that, really master that and advance upon it. and be able to touch multiple languages, become a polyglot. Actually be able to kind of build all the pieces and then they're easier to transition. They can jump, they can pivot much easier, instead of becoming siloed in this very specific track.

Microservices

Yeah. And so the junior developers that you have working, you're starting to move towards microservices, giving them these smaller worlds that they can fully understand. With that, I guess, transition from more monolithic systems to microservice systems, I would love to know–especially if you're working with so many different government agencies, different services–how do those look? Are they systems that you're building that you can essentially repackage and ship for SNAP versus another program? Or are they actual services that Code for America kind of runs as a service for those government entities to tie into?

Yeah, so we're very early–early saying that we're about to finish our first two. The way I kind of entered this–because like I said, we kind of have to ask for forgiveness, we have to kind of push our way in slowly–so we're building them in such a way that we could literally hand them a Docker image. And give them the support, the training, the handoff. Building it very self-explanatory, very simple as possible, good run books.

The other alternative is we can host it. We can maintain it. We can run it either as an individual or we can run it as a multi-tenant if it's a function that let’s say uploads documents or validates or fixes government documents, whatever. We could have a multi-tenant solution because there's less worry about PII because it's kind of like grabbing a document, cleaning it up and putting it back and wiping the existence of it so that you don't have to worry about the interchange or exchange as much.

We're building it flexible, because everything we're doing is kind of experimental and a learning process.

We're trying to build these in a flexible way because some states will be like, “Please run this, do it for me.” And some will be like, “We want to run it ourselves, we want our own engineers.” But then, at the same time, sometimes we will just kind of take this thing and package it in, because some states just want this solution. So we're building it flexible, because everything we're doing is kind of experimental and a learning process.

What was the rolling out of the idea of moving to microservices like for the organization? I mean, it's a contentious topic. People are like, “I gotta do the monolith and you gotta move it back to metal.” And people are like, “Microservices are great.” There's just like this big divide. And so, for a team that had been working in monolithic systems, was that something the team was excited to move towards or was that also something that took a little bit of politics to get it moving?

I mean, there was a significant amount of people that were excited and people that have been trying to drive this long term in the past that's never really made it anywhere. You know, I've done change management in the past, literally as a job. And I've kind of learned that, you know, you can say the what and the why, and that's not necessarily going to convince.

So the first phase was like, let's pick this really small spot. Like, okay, there's a team that's behind on their work. They don't have the capacity. I mean, they're not behind because of their reasons, but because, whatever, we don't have the capacity in that language. I'm like, well, my DevOps engineer has bandwidth. It's a different language, but he's going to build this kind of agnostic service that solves this problem. You're going to get delivered on time and then people are going to see the value of this.

It turns out that document uploading has been built a million times and they keep struggling with it. It's never getting better because you're building it from scratch every single time, right? So the idea that we have this one service that we can actually evolve and make it better and stronger and more reliable, or changing with the times, whatever. And it frees them up time. We can deliver faster.

We're not trying to automate and make things more efficient so we have less engineers. We want engineers to focus on innovation rather than doing the same things over and over again. And through that lens, you know, people have become way more excited. It's really kind of… the message was delivered on its own. I didn't have to go and beg people to start doing this, I showed them. And you know that's really got a lot more buy-in.

Yeah, I think that is one of those things. Like showing it, seeing it, like doing that experiment, that like people can really get like… it's not hand waving, right? It's not like a list of bells and whistles. It's actually seeing how you can impact the organization by making this change.

I think that's one of the things that many orgs struggle with. It's so much like, we wrote a white paper on why we should do it. Okay, like spend a portion of that time and illustrate it versus just talking about it at length.

Right.

You know, as you're kind of rolling these services out and you're designing them, are these like net new things that you're starting to build or do you have strategies for like taking some of the monolithic work that you've done and kind of starting to split that up into newer services? Or is it all just kind of net new development that you're doing there?

It's sort of net new.

I mean, we've always had this kind of centralized big lift piece in the middle that we've kind of built our apps off of. Like it was built internally. It's like a library we built, which does a lot of the heavy lifting. But it was very monolithic, you know, and there's some pieces of it that weren't so great. And that's like the first thing.

This document upload, like we can do this and then eventually we can expand upon the document uploader with maybe some AI. You know, what can we do behind the scenes? And really focus. Like this thing, all it does and cares about is receiving a document, validating it, fixing it, giving feedback, categorizing it, and that's it. It's done.

We want engineers to focus on innovation rather than doing the same things over and over again.

A lot of application failures for government benefits are just bad documents or not even understanding what the document is. You have caseworkers getting this stuff and proof of income could be like 20 million different varieties of documents. So the idea of simplifying that and having this kind of consolidated approach and a small function takes care of it.

And we can have people like, “Okay, next week you're going to work on the uploader.” They go in with a very focused context. I'm sure you know–you've gone in to fix a bug in the monolith and you found 40,000 bugs and you never actually got to what you were trying to do.

Oh, yeah.

Because you have to go through everything to find it. Whereas the smaller the focus, you can get in, do it, fix it, and maybe optimize on the way.

What are your criteria for what is a good size service? Like, are you doing more like domain driven design? Like this is a good domain, it's the uploader and like that is how we're deciding on what should be coming out to be its own service. Or do you have more of like a scale or deployment cadence kind of approach to it? Or, you know, decent mix of different criteria?

Yeah, I definitely prefer domain. You know, I've been in organizations where there's a microservice for every tiny little function. As I'm sure you know.

Every database table is a microservice. We're good. [Cory laughs]

Microservices are great, but they do add complexity, they add risk, they add surface area, all that fun stuff. So really I want to look at, where does this solve the most important problem? And you know it really gives us this opportunity for usability.Where is reusability most valuable? Document uploading or other certain factors that we can work upon.

Also, like what are the pieces that are the most challenging and changing the most? What are we constantly going back and changing? Those are the things where, I feel, it's much better to isolate.

Microservices are great, but they do add complexity, they add risk, they add surface area, all that fun stuff

I'm not one for saying, “Microservices are cool. Everybody's talking about it. Let's make everything a microservice.” I actually think the least microservices, that have the most focus or domain focus, are more valuable than having a whole bunch of little tiny things because then you have all this cross intersection and communication.

I also prefer fire and forget microservices.Not necessary ones where I'm going to sit and wait. Anything where it's like, you put a document in S3 bucket, trigger happens, the service picks up the document, does its work, puts it back ready and sends off a notice somewhere else. I don't care as an application, you upload a document. I might email you later to say, hey, sorry we tried, it didn't work. But, you know, I don't really like waiting necessary microservices if possible.

On-Prem or Cloud

So introducing microservices to the government. One of the other things you see frequently in government systems is mainframes, a lot of on-prem. Are you seeing more cloud adoption? Is Code for America pushing cloud, or are you seeing a lot more on-prem running in government facilities?

There is more cloud for, I would say, more the kind of person-to-caseworker kind of model. Where literally at the end of the day, everything you do is being printed out in the hands of a caseworker. Cloud is being utilized. You know, there are still a lot of things like the IRS and Unemployment that are still using these mainframes, because at the end of the day it's really a lot of these really old COBOL algorithms that are doing all the math.

Yeah.

At some point an auditor will go along and say, “Hey, I found something wrong in that.” Those are the systems that have just always worked for them. They're not necessary, so why would they go to the cloud at this point?

But there is more and more advancement. The government is really kind of digging in a little bit more into technological advancements. I think they're starting to realize that, not only the cost savings, but like how do we deliver things faster and act faster? And you know, as global warming and more catastrophe and disaster, like are we going to rely on this computer sitting in the basement of one of our old office buildings? I don't know.

Hopefully not. I had one of those… 24 years ago now we had one of those in a healthcare facility I worked in. I was a HIPAA security analyst and worked in healthcare data centers for a while. And we had this doctor's office that was literally in a strip mall and one of our data centers–it was a nice room, it had great AC, but it was in this doctor's office and it was at the back of the building. And somebody backed a truck into the building, put a hole through the wall and stole our servers. Like it was a threat model that like we did not have planned out. But yeah, we definitely don't want Social Security running in a basement somewhere, let’s get that in the cloud.

Right, right, right.

AI and Bias

So with adopting cloud services, adopting some of these newer initiatives, you touched on this earlier, government and AI, right? They're intrigued by it, they're scared by it. How is Code for America using AI in its products and what kind of interest or resistance are you seeing with the agencies you're working with?

Yeah, so we are at this moment, we are working a bit more in the background in AI. We're not touching anything in production right yet. We are doing experiments. We're really just starting to launch our first AI product that we're working on. We've done a few like proof of concepts in the past, but we're doing our first phase. Part of our inching our way in is we're identifying an AI solution that really has no concern or needs no PII. That's the simplest thing.

For example, classification of documents. We're trying to train on blank documents, right? So we're trying to get a bunch of empty paste-ups and all these other things. And so we're training language models purely on empty data. So, when a document's uploaded, we can automatically de-identify and do the comparison or identify what kind of a document this is and what purpose does this document serve? Is it proof of income? Is it proof of employment? Or whatever. So there's literally no PII in the system at all, which makes things easier.

PII there is personally identifiable information for anyone who's not a government or healthcare employee.

Yes, it's not blueberry pie.

No, unfortunately not. It's the less interesting PII.

And the other side is we are also trying to make sure our first approach is things that are not really making decisions that could demonstrate bias. While classifying a document, you're not making a decision that's affecting anybody. So we're kind of testing the technology and how this technology can make life easier.

A lot of problems happen when people upload documents. They go to the state agencies and they go in buckets. And when a caseworker is looking at this application they may see no proof of income because, for some reason, the client mislabeled that document and it went into the wrong bucket. They're going back like, “We don't have all the information.” So by simply being able to properly identify and not relying on the person in need of benefits to identify it we're actually taking away that hurdle. And it's a very simple solution, but it's a great proof of concept of how AI can be valuable and how we can avoid bias and all these other things in this stage.

Yeah, it's subtle, but it's also a usability thing, right? Like that person that's sitting there for two hours filling out that form… I don't know how many times I've been on something and I'm looking at the list of limited drop down items and I'm like, “It's kind of two of them. Like which one do I pick?” Just being able to say this is how much income I make and not have to think about it. And not only the fact that I can put it in the wrong place, but the amount of time it takes to Google that word to see if this is what it means. I feel like it is another small nicety.

With AI, there's obviously bias in many models. We've seen this so many times with just different products that have been released, just like weird biases. It can be difficult to understand that you're introducing bias into a system based on the data that you're training on it or whatnot. So, with the work that you're starting to do, how are you starting to think about ensuring that the systems that you're building aren't introducing any biases?

As you get to some more of this more data intensive stuff, are you starting to build some strategies there for detecting or determining if it might be biased? Or having multiple people involved so that there's just different perspectives on the model? How are you thinking about that challenge?

Yeah, I think the first phase is avoidance. So we're really trying to avoid areas that could have bias. So we can really understand, you know, what value we can use AI for, right? I feel like even the simplest form of AI can really take us so much further in the work we do and how we help people. But there's a lot of factors in how you're training models, what data you're training it on.

I feel like even the simplest form of AI can really take us so much further in the work we do and how we help people

When we're training on the worldwide web, we know that a lot of the times the loudest voices are not necessarily, the most voices everybody wants to hear. And if we're training on, you know, open information, we're grabbing a lot of that. We're going to get all of that. We're going to get troll information. We're going to get fake news. And then suddenly we're having bias, right? Where our opinions are based on this information.

So, in a sense, I could say we could be selectively training, but again, that could introduce bias as well. So it's kind of like catch 22. Cause if the person selecting what we're training is biased, there we go again.

I actually had this conversation recently with a startup that's trying to create an AI model that actually solves that. The whole purpose of this AI model is identifying bias.

That's cool.

It's kind of this cross-reference, like what you learn here, we've run it through this other model and actually can identify and strip out bias. Which would also be good in like decisioning, government decisioning. Like, let's take a bunch of opinions of people that have to vote on something and add logic, add empathetic thought and the human touch to that decision and shoot it out. Instead of we have a vote, or the loudest person in the room suddenly has encouraged other people to change their mind, we're actually using this kind of unbiased selector.

Yeah. And are you building your own models? Are you using some of the models that are out there? What type of technologies are you looking at for AI?

Currently we're experimenting with BERT because it's lower level and of course we're non-profit. We don't have the hardware to really train up too big of a model right now. We are exploring a lot. I'm personally trying to stay in touch a lot. I was at the Lama 3 release trying to learn more about that. Obviously that's a lot for what we're doing right now. But I'm really interested because, like I said, a lot of our products have to be able to work on a device as much as possible because of low internet connectivity.

So I'm trying to look a lot into like quantization right now and like how do we actually make these models small enough? Can we run them on device? Or can we have much more closer context models for the purpose at hand?

That's something like I'm really looking into a lot right now because in our line of work we can't have a whole bunch of GPUs and really powerful systems behind every little thing. So we need to really identify optimization.

Support for Not-for-Profits

So, I have a question that's very like… I don't know if it's a weird question… but outside of the podcast, my company tends to work with a fair number of not-for-profit companies. What we've noticed, particularly on like the startup end of the world, is they have a very hard time raising funds, but there's also just not as many Credit programs from the clouds for not-for-profits. It's just like, “You're here to make money. We'll give you a ton of cash.”, “You're here to do good, good luck.”

At Code for America's stage do you still… I mean, I know you're always looking for donations and a not-for-profit… but do the clouds offer programs to an organization at your stage to give you some baseline compute or is that still a struggle there?

Some do. We actually are very lucky and fortunate that there are many organizations that do give us in kind services, credits, or larger discounts, some completely free. I'm not going to obviously mention any names, but you know some really large providers give us like everything they have, it's free for us.

Awesome.

You know, we've had a long history obviously. That's changing with the current economy, of course, I think organizations are less generous because they're being tighter. Obviously we have to balance. There are some organizations that offer things for free, but we just don't feel that product serves our need best. So sometimes we do actually have to be with the one that costs more or just gives a discount, because, at the end of the day, our priority is serving the people that we do the work for. We don't want to degrade our quality just because it's free.

At the end of the day, our priority is serving the people that we do the work for. We don't want to degrade our quality just because it's free.

But we're always open. We love the opportunity to work partnerships or in kind. And we do a lot of research, we get a lot of data, we learn a lot. Partnerships can be very valuable. Civic tech is a very cottage industry, it’s greenfield and a very open opportunity for a lot of organizations to see what they can build to help. And we really love to kind of be at the forefront of learning what that is. And in turn, we love free stuff.

Send them some credits. If you're listening, send them some credits.

Yeah, us some credits.

Have a good product and send them some credits.

Civic Tech and Social Good

Looking ahead, what would you say are some of the biggest challenges or opportunities that you see in the civic tech space? And how is Code for America positioning themselves to address those?

Government's becoming more and more digital. In my lifetime… I remember everything was paper forms everywhere, there was no go online and apply for benefits. As the government becomes more digital, it's opening up a lot more to solutions. We're really exploring the landscape about how do we expand.

We received a very large philanthropic donation a few years ago from The Audacious Project and Blue Meridian Partners, which is really kind of funding a large amount of work on safety net.

Right now we're really kind of doing a lot of low-hanging fruit. How do we fix forms, right? But there's much more to that, because currently caseworkers are overloaded. I know personally, like caseworkers come to my house to do things for my daughter and they have a file folder like this big. They're going to see 100 patients that day somehow and they're not able to work the case, right? They're just filing paperwork. That's all they're doing. They're not actually doing the best part of their jobs.

So I think there's a lot of opportunity for us to kind of move past the application and into like, how do we simplify the caseworker's job so they have more time to commit to their consumers? Things like navigation, for example. It took me 16 years to find all the benefits that are eligible. Imagine if I applied for one benefit and something said, “Hey, based on the information you gave us, we know you're eligible for all these benefits. And by the way, we already sent your applications in. You're good to go.”

Yeah.

So imagine being in a crisis, you know, like so many of the population in the United States are… like one bad choice or one bad day away from being homeless. And okay, there are all of these benefits available, but someone in that situation in their life, how are they going to get to it all? They have a choice of just scramble to try to eat or fill out a thousand pieces of paper to try and get what can help them get back on their feet.

Yeah, and I feel like you'll probably find better information on Reddit about how to get those services than the FAQs of a government site, right? Then you also might find completely bad information on Reddit. But it could be hard to even find information. You might know about a program, but then you get into a site and it's like 16 pages deep before you find that you have to email somebody or you have to go to this specific office like in your city to move forward with this. So it's not just the discovery. It's like once you know what it is, how do you even start to apply for this program?

Right. And there's also a level of pride, right? It takes a while for people to start asking around when they're in need. Because a lot of people don't want to admit it. It takes a while. So if they can just kind of… in this little spot just get everything they need to help them get by without necessarily having to expose their challenges and then feel worse about themselves.

Yeah. Well, I have to say that the work that your team is doing is honorable. It was super awesome to have you on the show today.

Thank you!

Is there anything that our listeners can do to help?

Of course, as we mentioned, credits, we love credits.

Dish them out.

Partnerships, we have donation opportunities on our website. I love to talk to people who are doing cool things, you know, how can we work together and really kind of advance with the work we're doing. That'd be amazing.

Yeah, and at the very beginning, you mentioned that you had gotten involved as a judge for hackathons.

Yes.

So is that still something that your team's actively doing, that people can…?

Not so much. We used to have volunteer brigades, which some of them still exist on their own, but, you know, we wanted to have a bigger impact so we had to move much more to a structured organization.

We are trying to do more and I'm trying to kind of identify how do we really get out in the community more. Obviously, if you think about a volunteer organization and managing the kind of open source and like, you know, evaluating with compliance and security… it's really hard.

Every day I work, I'm helping people eat. You know, not many people can say that. It's amazing!

We also want more people from industry kind of coming over to Civic Tech. I mean, we have a balance of people that have been Civic Tech forever and some people from industry. I think there's a lot to learn from industry, a lot of value that can be brought over as we're trying to advance. And Civic Tech's not that scary. I work really hard. My title makes me tired just thinking about it but the work we do, just the energy I get every day… that's what I wake up and I breathe, eat and sleep. I love like every day I work, I'm helping people eat. You know, not many people can say that. It's amazing!

And when you have commas in your title, like you know you're doing a lot of work.

Yeah, I'm trying to think of how to recreate that. Like how do I put a couple, you know, letters together or something, to make it sound less long.

Awesome, well I really appreciate the time. Where can people find Code for America online and where can they reach out to you?

Yeah, so codeforamerica.org is our website. Lots of information there. Soon we're relaunching our tech blogs, where we will be talking a lot more about the actual work we're doing and the learnings. And yeah, I mean, my profile is on there, my contact info. Grace Huntley, LinkedIn, reach out if you want to chat. I'm always open to chat to people.

Awesome.

Well, that's it for today's episode. I hope you enjoyed our conversation with Grace Huntley from Code for America.

If you found this discussion valuable, please take the time to rate, follow, or subscribe to the Platform Engineering podcast on your favorite podcast platform. Helps us reach more listeners like you. And don't forget to check out our recent five -part series on the foundations of the cloud. We met with Mitchell Hashimoto of Terraform, Brian Grant of Kubernetes, and Adrian Cockroft to talk about how we got to where we are with the cloud today and all the tooling that has come along the way.

So thanks so much. Thanks for tuning in and we'll see you next time.

‍

Important Links

‍

Featured Guest

Grace Huntley

Director of Engineering, DevOps, InfoSec and Safety Net Innovation Lab at Code for America

Episode Description