Working With Code: How Does a Back-End Engineer for the FEC Do Her Job?

Listen to this episode

S1: This ad free podcast is part of your slate plus membership.

S2: Hi, I’m Greg Lavallee, director of technology at Slate. You might remember me from a few episodes of Working in the fall of 2019 where I talk to people who write code. We have a little time between seasons of working and we had an unheard episode from those sessions that we really wanted to share in the interview. Laura Buford talks about her experiences as a back end engineer at the Federal Election Commission. I love learning about the work the government is doing using some of the same tools as big tech startups. And I hope you enjoyed this conversation as much as I did.

S3: What is your name and what do you do?

S4: My name’s Laura Buford and I’m a back end engineer for the Federal Election Commission.

S3: Some of our listeners who don’t know anything about code might not know what. Back end engineer means. Do you think you could expand on that a little bit?

S5: Sure. So I work on the code that goes into dot gov. We have a open source campaign finance data API and front end web site. And when I say API, it means there’s a interface that anyone can come and get our data directly. And so when people talk about back in code usually means the underlying engine that produces the output versus the front end side, which might make it more user friendly or design an interface that looks good. The I work on the numbers and the performance and make sure that the the front end site has the information that it needs and that it’s accurate.

S3: So who who might use that code that you write?

S4: So our front end site also uses the API.

S5: So anyone who comes to FEC dot gov to explore who’s running for office, how much money they’ve raised, how they’re spending that money, they’re actually using the API under the hood. And then any developers or data scientists, students or anyone who’s interested in getting directly to the data can go to our API site, API that opened dot FEC dot gov. And you don’t have to write any code to use the API. We have an interface that allows you to try out some different queries, but I’ve seen folks, students and hobbyists say I met a woman who built a Twitter board that tweets every time someone registers to run for president. Those are the types of folks who might want to use the API directly instead of going through our front end site.

S3: One thing that I’m not sure that people who don’t write code understand about code is how collaborative writing code can be. You said that the front end uses your code, which means that other coders write code on top of your code or with your code. How does that does that work?

S5: Absolutely. So, yes, we have a front end team who works on it’s like a a different site. So FEC dot gov is what we consider our front end site. They write the code that ingests the data. We have a designer and a front and team that builds visualizations to see not just, you know, raw output of who’s running for office, but maybe put them in order and put a bar chart with it and see what party has raised the most. And and given an election making that data easier to understand and tell a story with the data and then the code that you write.

S3: Does anyone see that code or is it just producing data and then people get the data?

S5: Sure. Our site is open source since that what that means is that all of our code is public, which is a pretty cool thing to work in government. We work in the open. So if you go to FEC dot gov and the footer, you can see links to how to get to get hub is where we store our code. So if you wanted to see the code that goes into the API that I primarily focus on the API with a code that goes into the front end site, all that code is publicly available on GitHub and there are some myths around open source.

S4: Not everyone can go in and change our code. People can propose changes and we can then decide to accept them or not. But all of our code is publicly available on GitHub.

S3: What led you into coding?

S5: I’ve had a kind of this my third shot at being a person who writes code. I started off as a computer science major in college, but then for various reasons I didn’t feel like that was the direction I wanted to go. Writing code is really hard, especially if you don’t have like a really strong math background.

S4: And so I was also D-1 athlete at the time and one of my strongest memories is I was up late trying to debug my code and my alarm went off to go to practice and I was like, well, I guess I’m going to practice now. So I thought I didn’t want to write code for a long time. It was a political science and history major and was really involved in American politics and American history. And my first job out of college, someone suggested I go look at a local tech company that works here in D.C.. They basically built campaign finance software for filers to disclose their information to the FEC. Kind of like a TurboTax for your campaign finance reporting information. And there I really. I worked in client services doing some tech support. And I really fell in love with this kind of all the rules and the laws and regulations that were in place to try to add transparency and accounting. Guilty for campaigns, and I worked in tech support there for probably three or four years before they asked me to move onto the development team and write software, because I got to the point where if a caller reported a bug in the software, I would send the developers the line of code where the bug was occurring. What do you just come on over here and help us write the code? And I did that for about a year and a half and then for no reasons, didn’t feel like it was the right fit. I think in hindsight, I wasn’t feeling as challenged, but recognize that this was before I found like the women in tech community, I just feeling a little bit like not sure how I could grow my skills and feeling like I was a little bit stuck. So I actually went to go work at the FEC and in a less technical role, I. I was in more again, more of a client services tech support type role, the FEC. There’s a really great job where I got to help campaigns comply with the law and disclose their information and help them respond. When the FEC said, hey, what’s going on here? Please explain the situation. Help them respond appropriately. And I also did tech support there for the FEC is free electronic filing software, which is very much something that we’re working on, trying to modernize. At the time, it was I would say it’s free government provided software and everything that implies. So. So there’s some usability challenges. There are some some technical limitations there. So after about five years of doing that, that role, I was looking for a challenge. And I met the folks at the FEC that work on the Web site project and was just really excited by it. The FEC had partnered with 18F to build a really modern open source site. And having been in technical roles in the past, I was wanted to look at the code even if I wasn’t writing the code myself. I always found it very interesting. So I started researching this project and got really excited about it and decided I was going to teach myself python and apply to work on the Web site project team. And I managed to talk my way onto the team and really quickly was super lucky to work with folks at 18F or Stohl on the projection. I had amazing mentors there and they really got me up to speed on what I needed to know and the the team environment and the work challenge and the way we work out in the open and in a agile way. And I can talk about what that means to us. It was just a really exciting project to be a part of.

S3: You mentioned a couple of things that are I’m I’m wondering if people will know what they are. One is just Python, which to some people is a snake you see at the zoo and to other people as a programming language. And I guess you also mentioned teaching yourself, which I think is something that might not be something that immediately comes to mind for people. When you think about a language like I wouldn’t go out and teach myself Swedish. I would use to lingual or I would go to take a class. So you think you could expand a little on what does it mean to like teach yourself a language that is called Python?

S4: Sure. So Python is a programming language that’s very beginner friendly and that it reads a lot like the words you would use to describe what you want to do anyway. So there’s a in my mind, a pretty low barrier of entry to getting started with Python. When I say teach myself, I have to make sure I give credit where it’s due. I found I learn better in person. So I found an amazing nonprofit here in D.C. called Here Me Code that taught free python programming classes for women. And it was the quality of instruction there was just really fantastic and really helped me get excited about the possibility of continuing my learning with Python and the possibility of trying to get this job at the agency. There are a lot of free resources available if you’re interested in learning code.

S5: If you just kind of Google like free Python courses, some things that might come up might be code academy. I found their classes to be very beginner friendly. They kind of walk you through with interesting examples. And for me, learning the basics was I had the foundation of having had some computer science classes in college and then having worked as a developer for a year and a half in the past. But I was pretty rusty. So it was really helpful to basically start from scratch and try to learn the basics. When you’re learning through some of these platforms, they have, you know, hands on exercises where you can practice doing the thing and they give you over time they’ll give you, you know, less and less hand-holding and you start helping you develop those critical thinking skills.

S3: What other jobs did you have before coding? And like I guess maybe if you can compare a sort of like what how coding is different from other occupations you’ve had?

S4: Yeah. So I mean, besides like summer jobs and internships, my first job out of college was at the political technology company where I worked. We did I had tech support there. So people would call in and, you know, they would have, quote, basic questions about how to use the software. They would report, you know, any challenges they were having with with usability or bug Yoenis. And then some of my favorite things about that job were was I would do some like custom built reports for folks like if they had one to analyze their data in a way that wasn’t already being done. I could build like a custom analysis of their data for. Phone support is a hard job. It’s exhausting. Phones always ringing, you always have to put your smile on your face, even though people can’t see or smile. So I’d say that was a pretty hard job to have as my first job, but I learned so much. And, you know, we would find ourselves supporting small products that weren’t as highly used and we didn’t really know how to use it either.

S6: So we’re calling off the question and I would always say so walk me through the steps you’ve taken so far. You know, I could follow along with how far they’d gotten and then be like, oh, this this button here looks promising, like, let’s try this button here.

S4: So I learned so much in that job, but it was it was probably time for a change. I think burnout in tech support type roles is pretty high. Nothing quite like a 24 hour outage where you have to answer phone calls the whole time apologizing for it. I’m so sorry I couldn’t get the system back up as soon as we can. So I that was my first job out of college before they had asked me to move on to the engineering team. And then after that job wasn’t quite the right fit. I thought I didn’t want to be a developer anymore. So I was looking around like I was going to be a firefighter, like, am I gonna be a teacher? I wasn’t. I was really having a career crisis, but it always really enjoyed campaign finance as a subject. So the FEC has these conferences where you can learn about campaign finance rules and regulations and reporting. And they used to have FEC Jeopardy and I used to get so excited about like, oh, you know, under what circumstances can you. Can you make an in-kind contribution or, you know, just gifts of goods and services in or or what’s the timeframe for a candidate paying down their their loan before it turns automatically into a contribution? These are the types of rules I got really nerdy about. So like, well, maybe I’ll go work for the FEC. So at the FEC as again and more of a client services technical support type role and it can be very fulfilling when you can help someone figure out a problem. And I had I think over 350 political committees assigned to me directly who when they called for help, they called me so I could build relationships with those callers. And towards the end of my time there, I was reviewing presidential reports. And if there were excessive or impermissible contributions that were reported, I’d send a we called them letters, but they went out as emails. We would send correspondence on the public record saying, please refund these contributions within 60 days or whatever. The the rules were there. And so sometimes some local news agencies would say, oh, FEC employee Laura Buford is asking this presidential candidate to please refund their excessive contributions. So it’s pretty neat. But over time, again, I think the answering phones and feeling like I kind of had the hang of things and wasn’t really sure how I could grow led me to where I wanted to explore challenging job. And in my job on the website team, I’m never bored with lots of things to do. If you check out our GitHub repository of all or open issues, I think there are like 200 open issues. And there always coming up with new ways of making things better. And I’ve really, really supportive leadership where if we have an idea about like, oh, you know, we’ve been really reactive in this way, what if we were proactive and tried to catch this sooner by, you know, analyzing the data this way and alerting us if it was, you know, not matching up properly in leadership will be like, go for it. That sounds like a great plan. So it’s a very creative job for me. So that’s so far it’s been a really good fit.

S3: And you feel like the tech support thing has prepared you for certain aspects of the cutting job, too.

S4: Oh, yeah, absolutely. I think being in tech support made me a better developer. I mean, first of all, I’m fundamentally offended by bugs because I know there’s someone out there on the other end of a phone saying, I’m so sorry, we’ll fix that as soon as we can. And they hang up the phone and they log the phone call for the records and then they there’s not a whole lot they can do to actually get that thing fixed. So I know that’s a really difficult job to be the person on the phone who’s apologizing for the bug. And so one of my special to use it on my team is is fixing bugs. I think my co-worker called me the bug exterminator, which is like maybe the nicest thing anyone’s ever said about me. Lots of developers enjoy building new things, which is also very exciting. But I love the satisfaction of fixing something that’s broken. So being in tech support definitely helps me empathize with the users and recognize when something’s not friendly. And then also just those creative problem solving skills have really made it easier for me to figure out like all the different moving parts and how to fix problems and maybe if you can’t fix it the perfect way. Coming up with a way of getting it usable, having a workaround option. Maybe you can get that out the door faster while you work on the perfect solution. Just make sure you’re reducing the pain for the users as much as possible.

S3: What does your day like? What time do you get to work? What do you do when you get there? And when do you when do you leave?

S4: I usually get in around 8:30, 9 o’clock. We’re pretty flexible, even though government doesn’t always have a reputation for being flexible. I’m lucky in some agency as you can have a pretty flexible work day. When I say we work on an agile team, that means. Things to different people, but for us, it means instead of planning out the entire project from the very beginning and waiting until the very end to release a product and hope that people like it. We try to shorten the feedback loop between when we’re working on a new feature or making changes that we get out to the public to look and give us feedback on us as quickly as possible so that we don’t try to imagine every amount of feedback they might have ahead of time. We try to let them tell us what’s working well, what’s not. And we have a really amazing user experience designer on our team that will go out and do interviews with users to see if if they’re able to get what they need with the new features and existing features. So when I get to work, I usually have tickets that are assigned to me when I say we work in the open. All of our active issues are in our public GitHub repository. So you can see we call them sprints where there’s a a two week increment where we’ll try to take on a chunk of work. We all sit together in a planning meeting. We say, okay, who wants to work on this? Who wants to work on that? And when I get a ticket, it’s not telling me exactly how to fix something. It’s tells me what the problem is and what the end goal is. And then it’s up to me to try to figure out how to address it. So I usually look at the issues that are assigned to me as my kind of guideline of what I want to be focusing on and start from there. If I’m lucky and I have a whole day that goes kind of according to my plan. These things do come up on a last minute, which I have to rearrange my schedule if I have a whole day. That’s kind of it goes the way I expect from start. Which sounds also silly to say out loud, because that doesn’t happen too often. But I will take a look at my ticket and depending on what status I’m in with it, I’ll go ahead and try to work on it. So some of the things that I am really interested, I really enjoy working on bugs. So when I say a software bug means something that’s not working as expected to me, it’s kind of like solving a mystery. So I’ll start by just trying to reproduce it on my local machine. So what that means is I take all the code and it’s I’m running it on my own computer and sort of looking at it on a public site. And that means I have a little more control over how to how different elements are interacting together. So I’ll go ahead and run the code on my on my own computer. And if I can reproduce the issue, then I know that’s my starting point. Once I can actually say, OK, yes, I can see this is still not working as expected. Then I can start to try to tinker and see where the problem arises. I talked earlier about how the API feeds into the front end site. Sometimes we have to figure out is this a front end display issue or is it API not providing the front end with the proper information? So kind of figuring out what layer the problem arises. I usually start at the top and work my way down. So if it looks like the front end side is getting what it needs from the API, just not spitting it out properly or displaying it improperly, then I know that’s where I need to focus my efforts. But if sometimes, often the API isn’t giving the front end the correct informations, then I need to dig down as this a data problem. Where’s the logic? Not providing the correct information?

S3: Do you remember that the first piece of code that you wrote that you liked?

S4: I do, yeah. It touched on a lot of fundamentals for me. The first piece of code I wrote at the FEC, we have these election profile pages where you can see, OK, I want to see everyone who’s running for Senate. If you want to look at a given election, who’s running in that office, then it’s pretty intuitive. You kind of come you you look up your election, it shows you who’s running, how much they’ve raised.

S5: But we can get a little funny with Senate elections usually are every six years and they’re staggered.

S4: So not every state has a Senate election in a given year, except sometimes there are special elections where, you know, there wasn’t a scheduled election for that timeframe, but someone resigned or was appointed to a cabinet level position or something. So there’s an additional election held. And so our normal logic won’t we’ll have to like figure out how to add that election year to our list of available options. It kind of breaks the pattern. So my first piece of work they did on the project was to make that data driven and kind of have the front end go check in. What year are their Senate specials and let’s add those years to the list of available elections that people can see who’s running in this, you know, Alabama Senate special, for example.

S3: Have you ever introduced a bug into production and then had to fix it?

S4: Oh, absolutely. Yeah. One of my great mentors, the 18F, always said the more important work you’re doing, the more likely you are to introduce bugs into production. So over time, as I started responding to a lot of the existing bugs and kind of getting my hands into different parts of the code base, I absolutely. You handle nine out of 10 scenarios and then that one edge case, as we’ll call them, comes and bites you hard. So what we do is we were it was a team effort. So one of my favorite things about working in the open is that we’ll share in. We use slack as our internal messaging system. And we’ll say, hey, you found this bug. We go to our product managers and we say, how urgent is this? Is this hotfix worthy? And, you know, we’ll kind of look at the scope and the impact of the bug like recently. This is just happening a couple days ago and you can see it all on GitHub. We found a bug that we were trying to address and we wanted to fix it on short notice. And so I thought I’d found a change. And I was able to push the changes up to a development sandbox environment so anyone could kick the tires on it. And I said, you know, we’re trying to get it out quickly. And I said, hey, team, you know, can we all get together and kick the tires on this change? You know, when everyone logged in. Everyone. It’s public site. So everyone went to the the development environment site and was poking around and making sure that it looked like it was addressing all the issues. And so once the code was ready, we always have another team member go ahead and deploy the code. And we always have a review process where if I want to make a change, I’ll need a team member to go ahead and approve the change before we push it live. So I’ve made my own mistakes for sure, but we’re we’re really good as a team as having like a blameless culture and just kind of like a bug was identified. Let’s call a swarm on it and get it addressed without spending time on. Could it should or what a sort of thinking.

S3: I mean, like the software that you use to review other people’s code and keep track of it allows you to know exactly who changed what line whenever you want. But even our team at Slate has always said that the only person you can get blame is yourself, because it almost always gives you when you got to look at who did who did this. It’s probably me. I’m curious a little bit more about just sort of like your work life in general and kind of I guess we talked a little bit about a team of a team that reviews your code. How big is the team that you work on and how many teams are there that are operating and how do you all work with each other?

S4: I have an awesome team. We are all federal employees. It’s what we call a cross-functional team. So we have people from not just I.T., but from other offices within the FEC working together. We have eight developers working on the website and I always say website doesn’t quite encompass the work we do. We build like a giant data application. And so there’s a lot of moving parts that go into keeping that fast and available and accurate. And we have a user experience designer. She is closely coupled with the developers. She’s the one who makes sure that our features that we’re designing are user friendly and they can help our users accomplish their goals. And then we’ve got a content team from a couple different offices that works on building out the content on our site and two product managers that kind of help us guide our priorities and stay on track with further goals.

S3: How many meetings do you have like a given week?

S4: We used to have more. So when people talk about like agile software development, sometimes they focus a lot on the rituals around that one you may have heard of before as standup, where people get together once a day and say, you know, here’s what I did yesterday. Here’s why I’m working on today. Here any blockers that I have. I’m here at the things that are preventing me from being able to move forward. So we do have a half hour standup every day. And we used to have more meetings and we realized people on our team felt like we had too many meetings. So now we have our sprint planning meetings. So those are our two week increments of work. The angles are only scheduled meetings. So I guess I’m pretty lucky I get to spend a lot of time actually working.

S3: But meetings are work, aren’t they?

S4: They are working sometimes. They’re very valuable. We can see sometimes we’ll do innovation sprint or we focus on, you know, everyone takes a topic that they think they want to learn more on or improve our processes or our code. And we don’t tend to do stand ups every day during innovation sprint. And you can see that we don’t always proactively communicate with each other and things can get a little bit out of sync, even missing, you know, every other stand up. So meetings can absolutely be valuable. I think you’ve to ask yourself, I think the burden of proof should be on having the meeting, canceling the meeting, if that makes sense. Like what are we trying to accomplish here? And could it just be an is is it just an announcement that could probably just be sent over slack and then people have follow up questions. Maybe that’s when you can decide whether you need to have a meeting to discuss something.

S3: What about remote work? Does anybody work from home or has already come to the office every day?

S4: So our agency has an official policy of two scheduled telework days per week, which I think is pretty good for government. We worked closely with 18F there now rolled off the project, but 18F is very remote friendly, so they helped us set the culture of having video call meetings kind of by default. So it makes it much more flexible for folks who might have an unexpected reason they need to telework. So we also have an episodic telework policy where. With manager approval, you can have additional telework days off for whatever reason, it works better for you to work from home. So I’d say it’s a very remote, friendly team, but my agency right now doesn’t let anyone go full time telework unless there are medical circumstances.

S3: Some people and programming talk about, I guess in every discipline. People talk about the concept of flow and sort of being concentrated in your work. Is that something that you’re familiar with? Do people actually use that word at work? Have you felt what that might mean?

S4: Yeah, definitely. I think that’s one of my favorite things about being a developer is when you’re just kind of in the zone and you feel like sometimes I feel like I have all these moving pieces up in the air and I’m trying to rearrange them. And if I get interrupted, all the pieces fall back down to the ground and have to start again. So for me, yeah, a flow is absolutely one of the things I love about my job is when you just feel like you’re totally in the zone and you’re making all these connections and moving towards a solution for that reason. I think Slack can be or email or whatever. Chat messaging systems that folks use can be a big barrier to flow. So I’m very particular about turning off all my notifications unless someone specifically tags me in something. So I don’t get like all the dings and all the pop ups and because I there’s no way I could achieve flow if I had those constant interruptions. So I think setting boundaries, right. Check my email on my schedule, not want and get a pop up that there’s a new email has been really helpful. And I found that I’m still able to be quite responsive if I wait until when I’m in a good stopping point to to check up on messages. I feel like those little red dots are the flow killer. They’re really hard to resist. So I turn all of them off.

S3: So what is the thing that you wish that you could program that you cannot program?

S4: Oh, I’ve always said I would like a robot to make me a sandwich because I think sandwich is made by other people.

S3: Always taste better than the ones you make yourself some. That’s a really good one. What is an important thing that computers do poorly, in your opinion?

S4: I think computers are very literal, so they do what you ask them to do. And so if you give instructions, say you’re like, oh, yes, we do a, b, d, e, F and C is implied. Computers aren’t going to like, you know, just think, oh, and she meant C in there, too. They’re gonna just skip that step. So I think the software is only as good as the way it’s written. And I think if you’re looking for like nuance or judgment, teaching a computer to have good judgment, I think it’s very difficult to do. I’m not as involved in the machine learning space or artificial intelligence space, but I have read stories of algorithms being biased in ways that the people who are creating algorithms didn’t anticipate. So I think that’s something that computers don’t do well. It’s kind of have a conscience and have good judgment.

S3: What about when you watch movies and there is code in those movies? What is your reaction to code in movies?

S4: I think some of the most exciting stories are around hackers. I’m just starting to learn more about what that means and how to write secure code. So anytime I see any depiction of hackers or software developers, I get really excited. I used to be that way when I was a rower, so any time I saw rowing, I literally say rowing.

S6: So if I see I think there was a episode of Russian Doll or the main character is like doing a code review and like I could just watch hours of that sort of interaction. But I’m guessing maybe it wouldn’t be as entertaining to the general population, although there could be an untapped market there. So I think it’s cool.

S4: I think a lot of times there’s some funny stuff that happens that doesn’t couldn’t really exist and some come suspension of disbelief. But I enjoy just watching the stories and learning about the different ways people can use technology. I would consider myself in a lot of ways still pretty new. So I’m not at the point where I’m going to like snark on someone’s, you know, Linux commands that use things.

S3: What do people not understand about coding that you would love to explain to them?

S4: There are lots of different ways to be involved in writing software, and it’s okay if you don’t have computer science major. There are so many different ways to get started and there’s only different skillsets that are needed in the world of software. So I doubted myself a lot throughout my career and whether or not I was good enough or smart enough. And I think ultimately one of my mentors said like the most important thing is that you get shit done and that’s not always easily measured in job interview. The tech industry interviews are notoriously difficult. They focus on a lot of fundamental skills that you may have learned in an undergraduate class. Algorithms. Well, really, really weak on those. And it can be hard to get your foot in the door in tech. But if it’s something you’re passionate about, I would absolutely encourage folks to keep working at it and to talk to people in different types of jobs and see what might be a good fit. Because I think there’s room there’s room here. There’s room here for you if you’re interested in the space.

S3: Laura, thanks so much for being on the show. It’s a pleasure to have you.

S4: Thanks so much, Greg. It was great to be here.

S7: That’s it for this episode of Working. I’m Greg De-value. Thanks to Jessamine Molly for producing Rosemary Bellson for engineering and Justin D write for the ATV’s. Please remember to rate review and subscribe on Apple podcast. Remember, you can always e-mail us at working at Slate.com. Thanks for listening.