Working With Code: How Does a Software Engineering Manager Do Her Job?
S1: This ad free podcast is part of your Slate Plus membership.
S2: You’re listening to working the show about what people do all day. I’m your host Google Valley and I’m the director of technology here at Slate. And this mini series of working brought to you by Microsoft I’ll be talking to coders people who write software everyday to help you log into Web sites give you access to public data sets or figure out where satellites are in space. For this episode I talked to Mary melody an engineering manager at zero Maryann who slung code and a multitude of languages and now uses her skills to help manage hundreds of software engineers. We talked about what it’s like to write COBOL how she is coding to achieve her career goal of working for the State Department in her management philosophy. I also got schooled on one of my own lightning round questions. What is your name and what do you do.
S3: Hi. My name is Maryann bloody. I am an engineering manager which means I run engineering teams currently for a company called off zero and what is on zero do its identity as a service basically means we do Loggins for Web sites mobile apps all sorts of different clients on a given day.
S4: Do you write code for zero. Or you will see managing people who write code for all you.
S3: So when I first started running engineering teams I tried to do that. I tried to be writing code while also managing people and the power dynamics of that get really messed up really quickly. So I learned that lesson really effective and really quickly. So I do write code but I write code mainly for my own purposes and I’ve shifted sort of by professional code writing to things that run in parallel to what my engineers are doing rather than like part of their process. So for example I’m really big into something called formal specification or formal methods which is this idea of can you prove that a computer program will always do the correct thing regardless of inputs and outputs. That’s something that is not well adopted in engineering at large so it doesn’t conflict with anything my engineers are doing but it allows me to provide a different level insight and sometimes contribution to the same technical conversation. So while my engineers are working through problems I’ll often be modeling the same problems with the formal specification language as I like to use to sort of see if I can find different outlier events that we want to consider in those conversations.
S5: So we’re not entirely on technical but like the vast majority of our responsibilities are management and you said formal specification languages or these different computer languages than the rest of the engineering team would use.
S3: Yeah I mean that’s a point of contention among the formal specification community because there are some people that really don’t like calling them languages because then the people think of them as programming languages and they’re not they’re just it’s a formal syntax that a computer can pass in order to check that your model is correct it’ll run like you can think of it in terms of like scenario analysis so it’ll run like all the various possibilities of inputs and outputs that you given it and compare it to the constraints that you’ve defined and see if you can find a scenario where something that you’ve told it is not supposed to happen actually will happen. So it’s not a programming language per say but from a non-technical perspective the difference between the two of those is so thin and so narrow it’s almost irrelevant and what language do most of the people write in like what language Juniper reading the most of all zero were primarily a node j s shop. We’ve got a little bit of go and there’s a little bit of Java and various parts of the architecture but most everything is a node so javascript.
S5: How long have you been reading JavaScript or writing javascript and what were you what were you what were languages we were coding in before that.
S3: I was primarily python. I was familiar with JavaScript or we had built things in node I thought I think I probably thought that I was more familiar with node than when I came to an organization that had basically built it out professionally and the entire product on top of it. And then I was like Well all right. So like this is grown a little bit more robust a little bit more mature than the last time I really looked at it as a developer. So it’s fun. I definitely learn things every day from watching my engineers work at it. But I do like read and write JavaScript and that’s super helpful when when you’re managing an engineering team to look understand the primary function of the team in your years of experience coding in different languages.
S4: Have you found that it feels like the ground is always moving because you learn one language then you move on to another one and then you move on to the latest thing. I guess sort of like do you do you feel like that’s good bad or both.
S3: I feel like it makes the situation complex. Not good not bad. There was this whole conversation going on right now in the community about this idea of do you have to program in your spare time right. Can’t you just become a programmer. You think you don’t get your skills in online find a job do it for work and then do your hobbies in your free time. And the answer to that is yes but the industry moves so quickly that you have to sort of think about how you keep your keeping your skills up to date. And so I look at it this way like you can have whatever hobbies you want. You can balance your roller work and life however you feel is appropriate but you do have to have a certain level of passion because you have to be wanting to look at what’s coming next and a gradual incremental way. Otherwise you’ll turn around and the whole industry is moving in a completely different direction and you have to start from zero all over again. So the I don’t know that any programmer that thinks of it as just a job will ever be fundamentally successful. I think most programmers see it almost like a creative pursuit like art or music or something like that that it really has to be a medium that you’re passionate about expressing yourself in regardless of like whether you get paid to do it or not.
S5: And yeah I’m picturing the cellist coming back from the symphony and being like I’ll pick that up again tomorrow at 9. Exactly. So there is kind of a breadth and depth sort of argument there that some some software engineers sort of say I’m going to do Python and I’m just gonna get super deep on it and I don’t need to learn to use other stuff because I always have a job doing Python. And then there’s other folks who are like oh hey there’s a new language called Rust. I’m going to re implement my personal Web site in Rust to see what it does I guess. Do you fall into one of those categories. Do you think that there’s like I imagine it’s like a long spectrum.
S3: Mm hmm yeah. I’ve always been sort of more of the generalist versus the specializing in one particular language because I don’t know that I’ve ever really been enthusiastic about technology for technology sake. I’ve always been enthusiastic about what can I build. What can I do. What can I accomplish with it. One of the things that I like to tell people sort of inform how I approach technology is that I spent like the first 10 years of my career desperately trying not to be a software engineer like my dad was a software engineer. I grew up with computers like our first computer as a color 64. So I came into school knowing how to program and at a time when people did not know how to program and still a computer science when I was like the most boring idea in the world to me I was like No I want to like I’m interested in history I’m interested in anthropology I’m interested in the world and going out and seeing the world. And so like that that is still at the heart of how I approach technology I am less interested in like the gritty pedantic details of technology and more interested in its practical application. And so that means that like if we are looking at different languages and what is the best fit for a particular solution we consider a wide variety of factors we don’t look at that in the sense of like there is one right language that is perfectly optimized for this purpose like the fact that we have an engineering team that knows javascript better than anything else like is factored in to how we choose technology right.
S4: So if you end the history. How do you end a programming like you didn’t want to.
S3: Well the the industry shift right. So I am going to now date myself. I entered college in the year 2000 and there was no Facebook. There was no Twitter there was Google but Google was a search engine. I don’t even think Gmail was a thing at that point. So especially in the East Coast which is where I’m from from New York. If you went and you were a computer science student at that time you worked for either a bank or a hedge fund or a fortune 500 corporation and it was basically boring work. You fast forward to like ten years later the industry is completely different now you talk about social science and there’s like all sorts of interesting data and all sorts of stuff going on in the technology space and like really the social science stuff has moved into the technology sector. And so in terms of impact in terms of projects in terms of things that were interesting to me it was all suddenly now in tech and I was like Oh well I do know how to program maybe I should just like focus on that for a while. So I basically brushed up on my programming skills and got some people to give me a shot and started working on engineering teams and it was funny because like if you’d asked me when I graduated college what my career goals were I would’ve told you that I either want to work for the UN or the State Department and I spent a huge amount of time kind of running around the globe working for little non-profits an NGO is just tremendously rewarding but got me no closer to that goal. But when I finally sat down and started committing myself to the life of software engineer one of my friends like pinged me and said you know the U.N. is doing this project with this thing called C can it’s written in Python do you know anything about it. And I actually had turned out that I didn’t know quite a great deal about it and so I was able to go and work for the U.N. like I always wanted through doing software and then later when I joined United States digital service the first thing they did is sort of say hey do you want to go to the State Department and fix some problems and I was like OK cool now I need new career goals because I’ve just literally checked all the things off the list.
S4: That’s great. So there’s the two main industries that you program and was like once for the U.N. and then once the State Department.
S6: Yeah I did some startup work but I was mainly in kind of the public sector with non-profits and CEOs governments up until recently. I think my experience the USDA has made me really want to enter the private sector for real like not just with the small and person company but with a larger company and kind of try to see if I could apply my skills in that environment.
S5: And so far it’s been incredibly rewarding and for listeners you might not know what’s the U.S. Digital Service. Yes yes.
S3: So United States digital service is basically a SWAT team of technical experts that help try to resolve I.T. failures in the government. The highways daughter I.T. failures in government. So you may have heard of this thing called health care at all. GOV. That the government tried to launch and it went really really really badly. And so my old boss Mikey Dickerson was called in to see if he could help fix that and ran a team that basically kind of pushed it online and kept it up and running through open enrollment and then after that happened the Obama White House was like Well that seems like a good idea maybe we could be useful have these people around more often. So kind of pulled him in to start recruiting people to come in and sort of help the government with some technical problems. And I was part of the crew that got pulled him to do that which was a lot of fun.
S7: What is the oldest code you had to deal with half at us.
S3: Diaz I mean I had to do deal with some mainframes that were built in the 50s.
S5: So we’re talking about COBOL like really old COBOL is really old COBOL something you need to prepare for. How do you even. There’s no documentation online is there.
S8: So that was one of the fun challenges of it. That was one of the things I like the best is that you couldn’t like coast by on experience with one particular language you had to sort of take things back down to computer science fundamentals and kind of use a lot of deductive reasoning like what do I know and like what does this look like and then go from there. So it was always a really interesting challenge especially on the interviewing side which is something that I got really involved in USGS and carried over towards zero. It’s like how do you assess the skills of engineers when you need Java one day COBOL the next day Ruby the next day like something else the next day like language no one has heard of a tool that no one’s used in like 60 years. Like how do you assess the skills and abilities of software engineers in that environment. So that was really important question for USGS and I found that like fascinating you know. How do you assess people’s skills.
S5: People who are listening. You’ve never written a line of code can you think of something that you’d want them to know. Like one thing that you think you’d want them to know about coding or your job that it would be important for them to understand.
S8: I mean like I’ve been thinking lately that like the hallmark of a really good manager is willingness to be fired especially with technology. Wow. Technology is all about risk because it’s always changing and especially when you’re operating at scale. Eventually you get to a point where you know that old expression if it ain’t broke don’t fix it right. Well that doesn’t work in technology because it’s always changing it’s always evolving and especially on the security space. If you’re not keeping it in line with like not the cutting edge but like generally what’s current then you’re gonna have security vulnerabilities on your system really deep and complicated ones. So you have that this essential challenge with you have like millions potentially billions of people using a particular product. You need to change it sometimes in fundamental ways but changing it is risk. So like how do you manage that risk. And like a huge part of my job as an engineering manager is putting myself in the line of fire. So the my engineers can make those decisions smartly without worrying about what’s going to happen to them if things go wrong because we can’t perfectly predict like we do everything in our power to test. We do everything in our power to get in front of problems but we cannot perfectly predict everything that might happen as a result of the change. So a huge part of my job is the not so nice term for it is shit umbrella to like be the umbrella over the engineering team like keeping the shit for any down upon them and the people who are willing to do that are good managers in an engineering space and the people who are not willing to do that who are fundamentally thinking about their career and their safety are not good managers. This shit funnels they condense.
S4: Yes the kind of deal that layers so working on a product that is you know people’s most valued thing right is your password. Hopefully you have many many many passwords. But does that does that to you provide fear a challenge like Is it harder to sleep knowing that you’re responsible for a system that millions of people are relying on to be secure.
S9: Mm hmm. It would be if I was solely responsible for it. Right. And that’s the thing that I tell my engineers when they’re like backing off something because they’re scared is that this is a team. No one is going to let you make that decision by yourself and everything that you do is going to be reviewed. So there are multiple people that are going to have eyes on it and contribute to it before it goes live. And you should trust those people. So we have a team of I think about a hundred and fifty might be at 200 now 0 0 engineering and there’s some really incredibly brilliant people. And then on top of that we have a system that is designed to allow us to respond really quickly to problems like rollback changes as they turn out to be bad situations trigger incidences and get people on conference super fast. And so you have to understand that it’s never a scenario of like one engineer doing a thing that screws everything up. It’s a system failure. And that’s a whole part of what we call just culture and blame as postmortems. This idea that we don’t single people out for making individual mistakes because if you were allowed to make an individual mistake the system failed. We should never put you in a position where you’re allowed to make an individual mistake. So I don’t spend a lot of time worrying about that specifically because I trust my team and I trust to the larger team that we’re a part of.
S4: Is there some group of people out there that has like a constant threat.
S10: Yeah yeah absolutely. People worry about Russian hackers I don’t worry about Russian hackers so much I worry about like domestic white supremacists much more than I worry about Russian hackers.
S7: So what are your hours like when do you show up. When do you leave.
S10: I’m generally kind of roughly a 9:00 to 5:00 person. I have an engineer that’s in Bali. This was not something that I do by design. Generally speaking I like to keep everybody in my engineering team more or less time zone boxed within two to three hours of one another for maximum time. But this I inherited this team from another manager and this person who’s brilliant was on this team. And so that makes things more complicated. Occasionally I have to get up at 7:00 for a meeting or stay up a little bit later at a meeting so that we can all coordinate. But one of the I think one of the really important skill sets to learn as a manager is to be comfortable with not working right. Because if you’re not comfortable with not working then you’re probably going to turn around and micromanage somebody who doesn’t need to be micromanaged dried.
S3: So I have this whole philosophy about work where I’m like You know what if it’s like 2:00 3:00 in the afternoon and you’ve finished your work for the day go home see some friends some family put that in the bank because all my engineers are on call which means that for those of you’re not familiar with an uncle rotation if something goes wrong with 0 0 they may be paged and asked to come back to work at 3 o’clock in the morning or whenever it happens. So because of that I am very flexible about exactly what hours we work. And I would rather than rather than an engineer find something to do with his time for another couple hours that he go home and take that rest so that if he’s on call and he gets paid she has something in the bank. He’s well rested and can respond effectively. So I’m roughly 9 to 5 but I’m very flexible how.
S5: So you have a tutor engineers around there. They’re divided into additional teams. And then how do they all work together and communicate like what is the structure in which they manage to actually put code somewhere that other people can use it.
S3: Yeah. So that is an ongoing challenge regardless of the engineering team you’re on. And I think what’s really interesting and what attracted me to a company about the size of our zero is that about when you get to about 100 to 150 there’s no like card number on it. But when you get to about that range before that point you’ve mainly been collaborating based on personal relationship. Right. So I trust you because I know you we’ve worked together for a really long time. I know your strengths and your weaknesses. You send me a pull request. I accept the poll requests because like I trust you what’s a pull request. I’m sorry.
S11: That’s how you contribute code to my code base. So everything is based basically on personal relationships or can be based on personal relationship when you’re under 100 people when you start to get over 100 people. Now there are people who are working with you who you don’t have a personal relationship and you don’t have like a first or second degree of separation sometimes it’s like why not have a personal relationship with that person but this person that I trust trusts this person. So now you need to start developing two things you need process and you need hierarchy because that’s the thing that people are going to trust they’re going to trust the process and they’re going to trust a little bit of hierarchy. But in technology people are calling It’s bureaucracy. Get rid of bureaucracy is bad get rid of that. So it’s about getting the right amount of process and the right amount of hierarchy in order to facilitate trust and communication. And like to be at an organization that has reached that point and knows they have reached that point was like super attractive to me I was like Yeah this is what I’m all about. I love this stuff. So I spend a lot of time thinking about this. Like the way we’re broken down as an engineering org is that we have different domains. So we’ll have the product facing side of engineering. People are actually building the log in flows and then we’ll have my side of the organization that’s really more infrastructure the stuff that all that stuff is built on top of and making sure that it scales and then it’s secure and that it runs well and so within those domains you will then have separate teams that have separate responsibilities. And so we’re currently talking about within infrastructure as we look to mature how Austereo is designed like how do we break down responsibilities in a way that makes sense but also encourages collaboration when collaboration needs to happen across teams and it’s a huge challenge and there’s never a point where you like it solved. It’s great. Everything’s fine. Our engineering is fully distributed not all of the company is fully distributed a lot of the business sides are co-located in offices but engineering is fully distributed so slack is essential. Zoom is essential. And being able to understand when a conversation needs a meeting and when it needs to be in a sync conversation across one of those platforms probably a slack channel is like a huge part of that process. I could go on on and on on this forever and ever more than you ever wanted to hear about.
S4: If you worked in places where it was you know altogether semi distributed and fully distributed. Do you have sort of a preference in that group.
S3: I mean the hard thing about having a semi distributed engineering team is that a lot of work will get done in person. And if you have people that are remote you need to figure out a way to include them and keep them in the loop and make them still feel part of the team.
S11: So my preference is either the whole engineering team is distributed or the whole engineering team is co-located because it’s hard to do that half and half well but then you get to this this thing where like a lot of older organizations are in transition like they they want to bring that robot culture but they have the co-located culture and like how do you handle that transition as well.
S5: And a friend of mine who wrote an entire book on this subject so I was gonna ask do you have resources that you rely on for thinking about these sort of things that you could do trial and error for you know forever. But there’s also people who have done trial and error already. So you know where are you looking for sort of that that information.
S3: Yeah. So I’m going to plug my friend’s book former USSR John Edwin wrote a book called distributed teams where he talks through a lot of these problems that he faced when he worked at Mazzola and other companies and like working with him I learned a lot. Like before I started working with him I was the kind of person that turned off my camera when we’re on a video chat because I’m in the secure and I don’t want you to see what my hair looks like or whatever. And he was like really like no there’s so much communication that you’re missing when you’re not seeing a person’s face.
S9: And I thought about that and I went oh god he’s right isn’t he. OK fine. And then they started turning my camera on and I realized that the quality of those conversations was like dramatically better. And so I was like Oh OK.
S6: So I learned a lot from interacting with other managers and other organizations. There’s a great series of conferences called lead dev that take our place around the country. And also I think in there’s one in London one in Berlin where they bring engineering managers and lead developers from different teams to just give like short talks about challenges they face.
S12: And those are all online they’re all on YouTube and like sometimes on a Saturday night I will just lakes in my pajamas and load up the YouTube playlist and like watch a whole bunch of them all at once. And so it’s fascinating to listen to other managers talk about the challenges they faced and how they solved them. I really like that as a resource. Wow that sounds like a super chill sir it is I have like my a little jade roller and like a face mask and I’m totally going to do this to you in front of everyone like I could use it.
S7: Do you remember the Volkswagen diesel gate. Yeah the basic summary is that you know someone programmed the car to act one way when it was being tested and acted differently when it’s actually on the road and the programmer who is a lead developed one of the lead developers was sentenced to prison. Yeah I wondered how you feel about sort of the idea that the software engineer would end up serving time for it.
S9: Mm hmm. This is a hot topic right now like ethics in computer science particularly around you know what is going on with Facebook and Google and the impact of these technologies at scale like what form of accountability do people have. In this particular case I think it’s the right decision because it’s outright fraud right. Look it’s not like they didn’t know what they were trying to do. I don’t think you could make an argument that with some of this stuff that’s happened neuron A.I. it’s awful particular in racial bias but it was not the intention of the software engineer to produce something that was racially biased and in that kind of destructive manner.
S3: But this one it’s like they quite clearly knew what they were trying to accomplish by writing it that way. So it’s a different there’s a different layer of nuance with it.
S9: I think that if software engineers as a culture are going to run around talking about changing the world as often as they do then it’s worthwhile to be more thoughtful about that.
S3: I think you can’t have it both ways either like you’re just a cog in the machine or you’re here to make an impact and change the world and if you’re here to make an impact and change the world then you really have to ask yourself how are you changing it. And for whom. Right. So I mean ultimately we’ll see how the industry matures around this this question it’s going to be an interesting couple of years especially with an election coming up again. It’s going to bring all that stuff into the forefront once again.
S7: Yeah I’m sure. Floating out there there’s some Hippocratic Oath for software engineers that’s M.I.T. licensed but is that a good idea.
S3: That has been part of the conversation is it should there be some kind of version of the Hippocratic Oath for software engineers and I don’t think it’s a bad idea. Truthfully I mean in the security space you have the concept of the white hat the grey hat the black hat hacker like can you be a person who discovers and exploits security vulnerabilities ethically and like what kind of behaviors does that mean that you do or do not do. So that’s been a conversation that’s been going on in the security space since like the 90s probably before then and there is the general consensus about what is ethical behavior for a hacker. So I see no reason why that can’t be the same sort of general consensus in software community about what ethical behavior is.
S7: I have to do my lending questions Oh I got to bring them up. So I’m just gonna like ask him questions and he’d just like say the first thing that comes to mind and if you want to expand on it. Okay. Okay.
S13: Tabs are spaces Oh God tabs all the way. Oh I know it’s very controversial but like I have bad eyesight and I like separation and I feel like if you’ve got to use six spaces just use the tab oh oh six space tabs that’s even more controversial Oh whatever.
S14: I know you’re gonna you’re gonna put this part in and this is the part I’m gonna get people trolling you on Hacker News I think the rest of my thought.
S7: Well you wouldn’t you wouldn’t be the first. Yeah. I don’t know. I mean I’m curious. Yeah. We could dig into the tabs versus faces debate.
S12: Well this is one of the wonderful things about ideas is that I can set my ideas just to convert all of my tabs to spaces. What’s an idea I’ve got. Was that code editor integrated integrated development of irony.
S13: Yes. Yeah. I write right.
S15: This is one of the legacies when working in the federal government. I have acronym bankrupt. I no longer acknowledge acronyms I know or have new acronyms though. So yeah I mean like this is one of the wonderful things about code environments is that I can usually configure them to convert my tabs to spaces so we can decide whatever I mean I know that Python prefers spaces over tabs I get it fine like I’m not I’m on management now I know how to be in sync with the rest. But I can also like have my like obnoxious where I like do it and the technology will fix it for me so that everybody else on the dev team gets what they want to.
S13: We don’t have to have these arguments and we’ll never know. Yeah. I never knew save the file and it magically having all the time.
S7: Yeah it’s it’s sort of one of those coding industry things where there’s like a raucous debate about whether or not to use tabs or spaces and no one else cares. I’m surprised you didn’t ask me VMS vs. emacs I mean I can’t like I just that would be a whole different podcast right. We’d have to have separate a whole separate show just vim versus emacs emoji in code. Good idea or bad idea.
S16: Yes a bad idea. Favorite programming language Dakotan.
S9: Oh probably Python 80 character column widths versus other c.
S3: This is a fun fact. You know the 80 character column comes from.
S5: I mean it’s the old school terminal interface right.
S12: Didn’t have a resolution that required it is the size of punch card port or mainframe. Yeah I mean we’re gonna edit that out so my son right.
S13: Oh no she’s got to leave it. That’s fine.
S14: I’m comfortable with my lack of knowledge about punch cards so I don’t really care about column width within like normal non punch card the code but I’m very nostalgic. Whenever I hear that I’m like Oh I think you’re 80 columns. Yeah. Yeah. That’s a punch card. I actually had an engineer who had a punch card framed on his wall and I was like I don’t I don’t know what that says about you truth.
S4: We have an existing coal request in the Slate com code base to increase the column with two 120 characters and no one has even commented on it.
S7: I think I commented like this would be a good debate ticket and then just that fact. So let’s see. Favorite code.
S3: Ed I’m super super basic. I like Tex made sublime. I know. I mean that one and this is the indulgence of being an engineering manager is that I understand the power of like more powerful ideas but I just really like just something very very basic. I’ve been using Adam more and more lately so just something super super basic deploying code on Fridays bad idea or worst idea.
S14: No. So like this is actually a conversation we had at all. There are a couple months ago if you are afraid to deploy code on Fridays again we go back to. That’s a problem with the system right. It shouldn’t matter what day you deploy it on. So if an engineer wants to leave it until Monday. I don’t know that it necessarily gives them a lotta trouble on that one but as a general rule I think if you’re not comfortable deploying on literally any day of the week there’s something wrong with your system that needs to be addressed.
S7: Right. You need a rollback strategy that works.
S14: Yeah. On the other hand I would definitely recommend not deploying before everyone on your engineering team gets on a plane. Go to an off site.
S7: Been there. That’s when you’re fixing it on the bus till the offsite. Yeah. Do you have an opinion on the caps lock key. And if so what is it.
S14: I mean like as a person. That’s right. A non significant amount of COBOL sometimes the caps lock key is an important tool in the process. So for people who don’t know COBOL it’s basically all in caps lock that’s like an old terminal thing but like in modern day. Just like you’re yelling at everyone like oh yeah it’s a form of extreme programming screaming to get the screaming language.
S7: And when was the last time you updated your personal website.
S3: I don’t have a personal website. I have a medium blog that I guess sort of passes but I try to keep personal stuff off the medium blog for obvious reasons. I mean this is one of the benefits of being like a 90s script kiddie is I got all of my angst out on the Internet on live journal and the Usenet and like I burn that out real quick click. I have no desire to broadcast like my life to the world or who I am to the world anymore.
S13: Only the Russians have your life journal somewhere that they do read about script kiddie time like what was the first program.
S5: Do you remember writing that you liked.
S9: Oh God I don’t know like because a lot of what I would do is take code the other people had written an f around with it until it did something that I wanted it to do.
S3: I think I kind of had this weird side quest for lack of a better term where I found this old.
S10: I think it’s a Super Nintendo game called Game Maker or something like that where I found an emulator of it or something and I was fussing around with it and the first time I saw python I realized that there was a feature in that particular game where you could like you could do kind of a almost like a puzzle called Scratch. What’s the M.I.T. programming language for kids. Yeah. Scratch yeah you could do sort of that drag and drop interface for things but then you could. There was this button where you could just open up this Ed and you could see the actual code and so it opened the editor and write the actual code. The first time I saw python I was like oh wait that’s basically exactly the same thing I was writing code in Python I didn’t realize it that entire time so there was a period of time where I wasn’t taking programming very seriously or is building these little games in this this game program that I had found her mind and writing all of this code and what I eventually figured out was python. I was pretty entertained me for quite some time.
S13: I was pretty happy about that. Marianne thank you so much for coming in. It’s a great conversation. It was my pleasure. Thanks for having me.
S17: That’s it for this episode of Working. Once again I’m your host Greg LaValle. If you like the show please give us a rating review an Apple podcast. If you have any thoughts or questions you can e-mail us at. Working at Slate dot com. Breaking is produced by Jasmine Molly. Special thanks to Justin you write for the ad music. All three of these episodes of coders are in your feed now. So if you like this one goes into the other two.
