Logo

Software Developers Journey Podcast

#261 Chelsea Troy from ~lacking intellectual firepower~ to rocking at Mozilla

Resources

Highlights

Early Challenges and Overcoming Obstacles (05:12)

Chelsea Troy begins by discussing her initial encounters with programming and the struggles she faced. Despite being discouraged by a teacher who told her she lacked the 'intellectual firepower' for programming, she remained determined and pursued her interest. She learnt that adversity can fuel one's determination to succeed and that naysayers shouldn't determine one's future.

Moving towards Data Science (10:55)

Chelsea then segued into data science. She felt it was a natural transition from her studies in neuroscience. She emphasized the importance of being open to new avenues and the value of applying skills from one domain to another.

Tech Industry Culture and Diversity (19:40)

Chelsea critically analyzed the culture within the tech industry, pointing out the lack of diversity and inclusivity. She suggested that individuals, especially underrepresented ones, should find a supportive community, where they can grow and learn without feeling isolated or marginalized.

Teaching and Pedagogical Approaches (22:23)

As a teacher, Chelsea spoke passionately about her pedagogical approach. She argued for the need for accessible pedagogy and maintaining a learner-centered approach. She advises teachers to design classes that are accessible to students who find the information challenging, as it is these students who need teachers the most.

Dealing with Imposter Syndrome (32:11)

Chelsea provided insights on dealing with imposter syndrome, which many junior developers experience. She suggested creating a personal "brag document" to remind oneself of achievements and competencies to overcome feelings of inadequacy.

Book Recommendations and Continuous Learning (40:58)

In the realm of continuous learning, Chelsea offered various book recommendations, from 'Working Effectively with Legacy Code' to 'Living Documentation' and more. She stressed the importance of considering the context when introducing patterns in coding and the need to balance the benefits and drawbacks. She strongly advocates for continuous learning and exploration of different perspectives.

Advice for Students and Teachers (46:22)

Finally, Chelsea offered advice for both students and teachers. She advised students who've been discouraged by a teacher to seek out better educators who prioritize accessible teaching methods. For teachers, she emphasized the importance of designing a classroom that's accessible for all learners. She believes that when we design for those who have the hardest time accessing something, we make it more accessible for everyone.

Enjoyed the Podcast?

If you did, make sure to subscribe and share it with your friends!

Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.

Become a supporter of the show. Head over to Patreon or on Buzzsprout.

Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.

Thank you for tuning in!

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Chelsea Troy 0:00
When you build a class specifically designed to be accessible for the people who have the hardest time with this information, you're not favoring those students at the expense of students who have an easier time learning Peter, Michael took an exercise that dads do with their four year olds and put it in a classroom in one of the most reputable institutions for engineering in the country in the world, and that class loved it. more accessible resources aren't just better for the people who absolutely need them. When we design for the folks who have the hardest time accessing something, we tend to make it more accessible for everyone, including the people who would have had access to it the standard way, when we're specifically designing something for somebody who has the most trouble accessing it, it tends to get better for almost every one. I really believe that I think about that every time I teach. And I believe that if everybody who taught thought about that more, we would have better educational resources for everything. That's my soapbox.

Tim Bourguignon 1:04
Hello, and welcome to developer's journey, the podcast bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host team building. On this episode, I receive Chelsea Troy. Chelsea is a staff data engineer at Mozilla focused on the role of data privacy, and scientific rigor in automation. She's maintained her for the rock programming language and mentors, formerly incarcerated technologist through emergent works. She also teaches Python and Mobile Development at the University of Chicago hosts workshop for Riley and writes at Chelsea droid.com. Oh, and she flings barbells around for fun, for fun, and she drives an ebike named GT because we might, Chelsea, I hope we'll hear about this. Welcome to Dave journey. Sure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew and help me spend more time on finding phenomenal guests then editing audio tracks, please go to our website, Dev journey dot info and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. As you know, the show exists to help listeners understand what your story looked like and imagine how to shape their own future. So as usual on the show, let's go back to your beginnings. Where would you place to start off your dev journey?

Chelsea Troy 2:48
Let's see. So I would start my dev journey. I was in an undergraduate classroom. This doesn't go the way a lot of stories start in undergraduate classrooms. But I was in this like 60 person introduction to computer science lecture hall. And this guy gets on stage. His name was Peter, Peter, Michael. Oh, Sarah. And I'm pretty sure Peter Michael Oh, Sarah does not remember who I am and would not know me from Adam. If I were to reach out to him now. In fact, I think I did reach out to him a couple years ago, and tell him what I was doing now. But so he gets on stage. And he's got no slides. At the beginning of class. He's got no PowerPoint or anything like that. He looks out at all of us, he introduces himself, he says he is going to introduce us to the idea of how computers work. And the way that he's going to do this is he is going to play act as a computer. And we are going to tell him what to do. And then he rolls out this food grade kitchen table on stage and it's got a bunch of bread and peanut butter and jelly. And he says I want you to tell me how to make a peanut butter and jelly sandwich. I need the instructions for how to make you a peanut butter and jelly sandwich. I'm gonna make you a sandwich. But I need you to explain to me how to do it. And so people start kind of tentatively raising their hands and somebody says Well, first you got to get the bread. So he grabs the bread and is like get two slices or something like that. And he says you know I can't get to the two slices and takes his his hand in like pokes it into the bag, which is not open. And so this proceeds about the way you would imagine different people are giving different instructions and you may have seen like these tick tock videos or instagram videos where dads like do this to their four year old children and the next thing you know, the peanut butter is all over somebody's face and the knife is in the jelly and that's exactly how it went just exactly He was excellent. We spent 25 or 30 minutes on this. Um, and I remember at the time being like, this is how you start a computer science course, because this was not a guy talking to four to four year olds, he was teaching 60 undergraduates at like a relatively reputable institution. And he was still using this peanut butter and jelly method. And it hooked me on the cloud. And his all of his pedagogy was like this. The class was absolutely excellent. I loved it. After I came out of that class. I was like, I want to be a programmer. And we're gonna come back to that because my story takes a big winding loop. But I do want folks to remember Peter, Michael, oh, Sarah, because it does come back to him. I did. I did not get his permission to talk about him in such glowing terms on this podcast, but I hope he's okay with it. That's his real name. Sorry, Peter. But so then I get to it, I'm like, I want to be I want to do this. So I go on to the next class in the car got an A and Peter Michael Oh, Sara's class, I earn the A I did wasn't just that he liked me. He doesn't know who I am, I will repeat. I get to the second class. And I won't, I won't say the name of this instructor. It was a very different experience. It was a lot of PowerPoints. It wasn't an immense amount of this wasn't 120 person lecture, I believe. It was an immense amount of all of us staring at her while she tried to debug a thing that wasn't working. And then as the final bell rang, and we all laughed, she was like, well, you get the idea for how it's supposed to work. And then I went to her, I was having a lot of trouble in the class. And I went to her office hours, and talk to her about what I could do, and why I was having so much trouble. Because when I had been in high school, in college and everything, office hours, that always been a key role for me. Like if I went to office hours, I was able to get the help that I needed. And it just always been a no brainer for me, oh, if you're having trouble, don't give up, go to office hours. And that was what had been drilled into I went to a high school that, you know, I was very privileged to go to a high school where the teachers felt that way and where the teachers stood behind that. And so now I'm in undergrad, and I go to these office hours. And in these office hours are where this instructor informs me and this is more or less a direct quote. Maybe I just lack the intellectual firepower required for a profession like this, and that that wording intellectual firepower has stuck with me forever, because I make fun of her for when I'm like on stage talking and stuff like that. But at the time, it really hit me very hard. And I quit. I did not further pursue computer science in my undergraduate education. It took me a very long time to come back to it. I pursued international relations, I was training to be a spy. I didn't understand at the time, all of the ethical and political implications of being a spy. I learned Arabic. I learned counterintelligence, I learned counterinsurgency, you know, very easy topics that I had the intellectual firepower for, like, unlike computer science to or whatever the glass was. And so then I graduated, I graduated into a recession, there was a government shutdown. None of the intelligence community in the United States was hiring. So I was mercifully saved from being in a career that I probably would have found out a couple years later was completely against everything that I stood for ethically and personally. And I did other odd jobs. In the meantime, I was a blogger for an equity crowdfunding startup before. Before equity crowdfunding was completely legal in the United States. I edited a quack psychology magazine, I worked as a rowing coach, I worked as a stand up comedian, I ended up getting an internship that was sort of adjacent to the field that I had studied. In undergraduate. My job was to do open source intelligence gathering, which is a fancy word that we use for look at images from Google Maps to figure out who has a lot of airplanes and and look at images taken on publicly available like customs websites, and read the Farsi on the bags to determine what's in the bags. I didn't I didn't speak Farsi, but I could read Arabic lettering because I knew Arabic, and I knew enough French from having grown up in Louisiana, the between the Arabic and the French. I still didn't know Farsi, but I could figure out what a bag said in Farsi usually. It was interesting, paid terribly and eventually I realized like, what I,

Chelsea Troy 10:05
I miss what I experienced and Peter Michael is here as class, I really enjoyed that. And transparently, I wanted some job security because I was doing all these weird jobs. And it looks to me, like if you could write code, usually somebody wanted to hire you. So I reached out to the CTO of the equity crimefighting startup, which I had long since moved on from it turns out that if your main line of business stays illegal for long enough, you have to lay everybody off, which, which is what had happened to me. But I reached back out to him, and I was like, Hey, do you have any recommendations if like a person wanted to get started in coding, he introduced me to his friends, Jay, when grow, who at the time was starting a coding boot camp, this was a long time ago at this point, folks, it feels like, at the time, the boot camp was called, anyone can learn to code and I was like, you know, I don't, I can't quit making income and pay $17,000 for boot camp. This is what people were doing with Dev Bootcamp at the time, and I just couldn't do it. Jay was starting a night and weekend thing that somebody could still do around a day job. So I talked to Jay a little bit, Jay and I did some tutoring together. He taught me a few things about Ruby on Rails. And it was a lot of fun. And it reminded me of all of the things that I had really enjoyed about Peter Michael of Sarah's class. And I asked him, like, what would it take to do this boot camp scenario. And he explained to me the night and weekend idea, and we talked about whether it would be a good fit for me, and decided it would be a good fit, what I was going to do is I was going to come to Chicago, I was going to do the boot camp, I was going to help because I had a little bit of a head start from the tutoring, I would help sort of TA my group through and that was going to help on on the tuition side for me. And once once we decided that that was indeed what I was going to do, he was like, alright, the only catch is I was living in DC at the time doing this, doing this look for airplanes on Google Maps job. And he said, I need you to be in Chicago in 10 days. I was like, Okay, I mean, it's quick. Luckily, at the time, I didn't have less stuff. So I packed all my bags, I came to Chicago, it was summer, I came in June. And everyone had told me all you know, the Chicago winter is terrible. You're gonna die out here, blah, blah, blah. So I was terrified. And I figured, well, I'm going to take the summer I'm going to learn to code over the summer. And then I'm going to get a job somewhere with a more temperate climate and I'm gonna leave and I did my did my immersion program. And that immersion program is now by the way if folks are looking for it online, it's not called anyone can learn to code anymore. They decided they needed a name that sounded more Harvard. And so they chose actualize so now if you're looking for it, the program is called actualize. I believe the logo is now a sort of like mountain looking thing. It used to be a penguin. J is fantastic. J gave me my start in programming. Jay gave me the best piece of advice that I received as a software engineer, which I will tell you later, however, j if you're listening, the logo used to be a penguin and that was better. I liked the penguin. Tim's like, Why did I get

Tim Bourguignon 13:27
them laughing my ass off. That's good.

Tim Bourguignon 13:29
Um, so anyway, I do my immersion program and I graduate. And I will come back to that piece of advice that Jake gave me. But I got a job offer at Pivotal Labs, which was just starting its office in Chicago. That job offer was given to me by Austin Vance, who I think made a mistake. Um, well, I can get to that. But yeah, so that kept me in Chicago. And now I've been here nine years. I don't work at Pivotal Labs anymore. But I worked there for a while got me my start in programming. I said I would come back to a few things. I'm Peter, Michael. Oh, Sarah, I'm still going to come back to but, um, first Jay Jay gave me the best piece of advice that I received for my career, which was consider starting a blog. Now, here's what I'm gonna say is that was not advice personalized. For me. I think Jay was giving that advice, more or less to all students at the time. For me personally, that piece of advice worked out really, really well. I started that blog in June of 2014. That blog is going to hit its ninth anniversary. In June of this year. There's something like 420 posts on that blog. And I have said in a number of public fora that when that blog hits 1000 posts, I will retire No one believes me, everybody thinks I'm joking, I maintain that I'm not that that's going to be my metric from when I quit this career. But the nice thing about the blog for me has been that the reasons that I have kept the blog have changed over time. But there's always been a reason that's kept me in it at first, when I first started learning, that blog was a way for me to record what I was learning, because I found that if I had the opportunity to try to teach it to somebody else, that helped me retain the information much better. And I think supercharge the immersion program for me, in a way, that doesn't always happen for folks, because if I was, if I was effectively teaching my cohort, which meant everything that everybody else was allowed to be a beginner on, I had to be able to teach somebody else right away. And that meant it meant a lot of studying, it meant a lot of time commitment. I think probably if I had dependents, if I had children, if I had, like a really demanding full time job at the time, it would have been very difficult. So I came from a place of a lot of privilege that I had the opportunity to work as hard as they did in that immersion program, and also in my first few months at Pivotal Labs, which we will get to. But in the beginning, I was using the blog to learn. Then eventually I was using the blog to record when I got into my job, I would find occasionally there were things that were very poorly documented online, I needed to learn how to do a card flip animation and Android at one point for a project that I was working on. And at the time, the documentation for how to do that was not good. The documentation for how to do that was not good. I was doing generally mobile development at the time, and documentation for how to do test driven anything in any mobile framework. But particularly iOS was not good. And so I found that if I learned to do something that was poorly documented, and I wrote a blog post about it, people would use it. And so it gave me an opportunity to add to the programming conversation in a way that my early posts like how to write FizzBuzz, or whatever that wasn't adding to the conversation. Those were for me, this was where I started to write posts that had an audience that wasn't just me, and it was fine. And I want people to understand this. If you have a blog and the audience is you and you're enjoying it, that is fine. That is enough, you are enough of an audience to make a project. It does not have to be for somebody, nobody else has to like it. If you're getting something from it. That's all that matters. And maybe it'll be for somebody later, like my blog was, or maybe it won't. That's okay. You're enough of an audience.

Tim Bourguignon 18:23
The the experience of writing somebody something for somebody else, and years down the line, Googling it, and finding your own blog posts and saying, Would I wrote about this company? And you have your own answer as documentation of what you should do now?

Chelsea Troy 18:41
Yes, that has happened to me. So there's a blog post that I wrote called, if I had a quarter for every time I received this damn dagger error. I have. I have googled that title, specifically, knowing that I would be the best person to ask about that. But I have also had the experience where I googled it and been like, oh, my gosh, I wrote about this, and I'm gonna help myself. Get out of this. Wonderful. Um, yeah, it's a wonderful experience. I've also had the experience of somebody one time arguing with me about how to test drive something in Android, and I was of one position and they were of another position. And they were like, No, you're wrong. I'm right. I can find someone who can back me up. And so they go look up a blog post online, and I was like, Rob, what's the name on the top of that blog? Rob, what is my name?

Tim Bourguignon 19:46
This is this is indeed indeed, blogging is really a superpower. If I if you if you allow me I want to pick just one word you say when you gave the advice, the beginning you didn't say stop. to blog, so consider starting a blog. And is there a difference?

Chelsea Troy 20:04
I would say. So I think the difference is that writing is a medium that works well. For me, I have a relatively easy time expressing in words, what comes out of my brain. And so for me, writing was a really great way to leverage a skill set, I already had to help me build this other skill set, which was first programming, and then software engineering. And then sort of the whole variety of skill sets around that it helped me with data science, it helped me with sort of managerial and organizational tasks and those kinds of things. And I was able to access all of those through the skill that I had, which was writing, writing does not come easily to everyone. And writing is not the medium that everybody finds the most enjoyable for figuring out how to learn. And so I think a blog is a way to access what I accessed, I think starting a project that you're excited about might also be a way to access what you access my students. So I teach at the University of Chicago now, and I encourage students to do final projects about topics they're interested in. And I've seen apps about Pokemon apps about mushrooms and all kinds of things. Chicago tends to be a pretty civically engaged town. And so I've seen a lot of students do like, I use Chicago open data to figure out like how long maintenance projects are taking on these various streets and those kinds of things. And I think for some people, it's programming. For some people, it's writing for some people, it's kind of I did sort of a writing and programming combination. Some people find it through art, there are some really interesting projects out there folks who have made like an LED skirt, and they've programmed the skirt. I've seen cool stuff, like, there's this really awesome project, and I'm gonna remember the name of it. The second I get off of this podcast, but the person effectively made a little interpreter for a programming language that allows you to create techno music, electronic music, in code,

Tim Bourguignon 22:12
Sony pie. Yes, that's it. From our own, I don't have his last name with Aaron, I saw him at a conference in Paris, doing a live performance. With Sonic Pi test, it's mind blowing, it's awesome. It's

Chelsea Troy 22:27
incredible. And for somebody who's very musically inclined, writing stuff in Sonic Pi, is might be a great way for them to access an understanding of programming because they don't know the code yet. But they understand how music is supposed to work. And so if they can write code that creates the kind of music that works in their understanding of the way that music works, then then that might be it for them. So I think starting a blog ended up working really well for me, and is an option for somebody finding a way to help themselves learn and finding a way to stay engaged in programming with an audience of themselves. But I do think there are probably other options out there. I think there are definitely other options out there. And I've seen people use them to to access tech in a way that was meaningful for them.

Tim Bourguignon 23:18
I agree with with this holding. That is really though, the what you want to do not the how that isn't really important. And so learning in the open, consolidating what you learned, trying to rephrase it and see if you understood it, trying to teach it to somebody else. All this doesn't seem the same category of how to this, what consolidating for you so into that. When you talked about people tell you said they made a mistake.

Chelsea Troy 23:49
Oh, yes. I can. Yes, I absolutely will. So Pivotal Labs. At the time. Now it's a little bit different now. But at the time, Pivotal Labs was a consultancy, that I think operated chiefly here in the United States, and did immersive sort of pairing engagements with clients. Now, this was a little bit different than your typical staff augmentation consultancy job. It was an XP shop, it was an extreme programming shop. So what we would do is we would pair with client developers from the client company on a rewrite or a greenfield project that they had. And we did 100% Paren 100% test driven development, continuous integration, continuous deployment, though, just everything out of the Extreme Programming playbook. We were doing with these clients, we would do three to six, three to six month engagements at the beginning. Pivotal Labs had operated with a lot of success out of the west coast. They had done things with like square and Google and a number of cloud is big and small, out on the West Coast. They then had opened a shop in Denver, and they had done a lot of Ruby on Rails projects from scratch for smaller companies in Denver. Now they were opening an office in Chicago, they did not have their own office space yet, they were working out of 1871, a co working space, the same co working space that the immersion program that I was in was working out of. And we happen to run into this, my instructor and I happen to run into the office director of the brand new Pivotal Labs Chicago outpost, and the cafeteria area, his name or the shared kitchen area. His name was Austin Vance. And I think on a whim, he suggested that when I graduate, I should apply to Pivotal Labs. And so I did. The interview process for Pivotal Labs involves first and RPI. Rob's programming interview is what RPI stands for named after rob me, one of the original founders of Pivotal Labs, it's a one hour programming interview, you don't drive, the interviewer does the driving. And the idea behind that is to help you get concepts out of your head, because they want to hear what you can do conceptually, it is a specific programming problem, and you get a specific score, they actually train pivots to give this interview and they don't allow you to give it until your score is falling within a certain margin of error of everybody else's score, theoretically, to create an impartial experience. And if you pass that, then the next part of the interview is a day long interview. But you don't get specific interviews, what you do is you come in and you pair with programmers on their day to day work. You do that for two sessions in the morning, then those two developers actually go to the HR person, and they say whether the person should go on or not. And if the person should go on, then they take you to lunch, they bring you back, and you continue to work pairing with other programmers until five, if it's already a wash, if we're already not gonna hire the person, then we don't waste the rest of their time. And I think I think we still bought them lunch, I don't remember 100%. But I'm pretty sure they still got lunch, and then they were sent home after lunch. So this was the process. And what may go without saying at this point was that Pivotal Labs was looking for relatively senior engineers, because you needed to be able to work at a consultant level relatively quickly on these projects. Moreover, the labs office in Chicago was just starting. So they didn't really have bandwidth to train up junior engineers, they needed people who like, could more or less, make money for them and convince clients to keep working with them very early on. And this is where I think the mistake got made. So I did my Rob's programming interview. I believe I scored one point away from passing, which was not passing. But it was the highest score that Austin had ever seen a junior engineer score, he moved me on to the full day. And that was where I think Austin made the mistake, because that gave me access to all the other programmers who I could then convince that it would be great to have me on board, because I was very beginner relative to the level that they were looking for at the time. But I was very engaged in the pairing process and interested in what was going on and participating. And then after I did my day long interview, I was not expecting I should say this I was not expecting to get an offer from Pivotal Labs because I knew I was many many many years under what they actually needed. I knew this going in I had been told this going in. And even after my RPI Austin had been like, to be honest, if you want a snowball's chance in hell, you need to read these five books before the interview. And he literally handed me he didn't even give me the titles. He was like, here's the physical books, he handed them to me, like a librarian, who's looking out for you was like, take these home, please know the stuff in these by your interview for the love of God. And so I show up, I'm read my book, some very dutifully. Anyway, so after the interview, I wrote a blog post about everything I had learned at, at my interview, and I sent the URL of my blog post to the people who had interviewed me as a thank you as sort of like a Hey, thanks for doing this. I really appreciate it. I know you took time out of your day to interview somebody who you're probably not going to accept. But it was still worth it to me. Here's what I learned. And a couple of weeks later, was it a couple of weeks it was it was sometime later I guess A call from Austin. And he's like, so we got enough fight in your interview evaluation. Because because, like, transparently, you don't have the amount of experience that that this job requires. But the engineers love you. And this one I won't mention in my name, because I suspect he really wouldn't like it. But there's one in particular, who apparently, like, made a big case in the interview, basically. So he was like, This is what we're gonna do, we're gonna bring you on contract. And we're gonna do a Contract Hire situation. Now, am I endorsing Contract Hire situations? I am not. They are in a lot of situations exploitive in this particular case, I understand why they did it, because probably what they should have done was reject me. And what they did instead was this Contract Hire situation. Um, and honestly, that Contract Hire situation was hell on absolutely all of us. Austin's trying to grow this office from scratch, he's trying to get clients. And in the meantime, he has this like junior programmer who sort of like, can't pull the weight of a senior engineer that is required in this consulting gig. So I'm like, not, you know, no matter how good I am, no matter what, I don't have the intellectual firepower, to be a senior engineer when I'm a junior engineer, and like, nobody was convinced, right, because it's very, you can't do that. And it was, I think, seven months before I got my full time offer at labs. And in that seven months, um, I spent a fair amount of time taking sort of like a not a 100%, direct and steady track, and not quite figuring it out. And when I finally figured it out, when I finally like, I was, I had this moment where I realized, like, I'm not necessarily going to get hired here, this is going to have been an internship, you know, like these Google and Amazon internships, where they bring, bring an undergraduate or graduate student on and they're like, okay, this person is not actually like, caliber for what we need, we're gonna bring them in here, they're gonna have a great experience, they're gonna have us on the resume as an internship. And that's fine. That's what pivotal was going to be for me, if I didn't step out, basically. And by step it up, what was meant was performed at the caliber of a senior engineer with way less experience than a senior engineer actually has. This was the point where I needed to figure out how to level myself up at a truly wild rate. And in order to do that, what I started doing was coming in, in the mornings before work, finding a commit where a developer on my team had done an end to end change on the application I was supposed to be working on, and trace that commit. And by trace that commit, I mean, take a pen and a piece of paper, and copy down the change set by hand in blue pen, and then go back through it and highlight anything I didn't understand and go and research it. And if I could figure it out from research, write down the answer in a different color of pen. And if I couldn't find the answer, write down my question in a red pen. And then go find the most experienced engineer on my team and corner him and answer it, get those questions answered. I did this for

Chelsea Troy 33:36
months. I did this for months. And then in the evening, I would do all your normal, like read programming books, and that kind of thing. I did this job, I was tracing commits. And then I was pairing for eight hours. And then I was studying and then I was sleeping. Again, the amount of privilege required for me to be able to do this was immense. I didn't have dependents, I didn't have other things that I that I had going on. I did that for months. And even after I had the full time job at Pivotal, I did that for a really long time. And I think probably if it had been any other office director, I would not have gotten that job. But Austin decided to take a chance. And it was extremely emotionally heart rending for all of us. But eventually I earned my spot on the team. And I stayed there for several years, I really enjoyed Pivotal Labs, and I would absolutely do that kind of work again,

Tim Bourguignon 34:32
which is you still do some a version of this exercise that you could just describe of finding something and really going deep into it sequentially. Learning all there is to learn about this and not letting go until you really fully understand it. And then he'll do that again and again and again.

Chelsea Troy 34:52
I do it's one of the techniques that I use. So for a while I did not use it. And I started working you know I I mean, one of the one of the nice things about Pivotal Labs is you're typically working on Greenfield code bases, which is a lot of fun for an engineer. Now, there's a whole skill set associated with working on legacy code bases that you don't learn when you're constantly working on Greenfield code bases. And one of the things I think labs started to realize, in this office in Chicago, we started getting bigger clients, we were getting giant health insurance companies, giant banks, those kinds of places. And at first, they needed a greenfield mobile app. But then, once they liked our work, they wanted us to help work on their legacy systems. And what we were discovering was that some of our hardline XP policies didn't work particularly well, for larger older companies. They didn't work on legacy code bases, and we were having to start to learn if XP by the book doesn't work everywhere, in what context does it work? And why? In what context? Doesn't it work and why and what should we do instead? And that was a question that I do think that Pivotal Labs was kind of avoiding, and was starting to contend with around the time that I left, I went to work at a product company for a little while. And then I did independent consulting for a little while now I work at Mozilla. And in that time, ended up working on bigger and older things and starting to answer some of these questions. For myself, and for my teams. Now. I give workshops on working with legacy code, and handling technical debt. And one of the big things that we talk about is how do you gather context, when context has been lost? I think the the cause of a lot of the frustration that we experience in code bases is that there's context about how this works or why it works, that has been lost because the original developer left and it wasn't sufficiently documented or something like that. So what do you do about that situation, I think first you name that situation and disambiguated from quote, unquote, bad code, I think they're different. And the second thing you do is start explicitly naming and practicing and rewarding skills associated with recovering context. And I maintain that that can be programming work, I think we think of it as this like metal work that people don't want to do. But there's absolutely technical skill associated with it. And one of the skill sets within that is recovering knowledge in code bases, where it is not recorded anywhere. And one of the ways one of the techniques that you can use for that is take a file, take a change set, literally copy everything down, it's 2023. So I don't usually recommend that people do it by hand unless they're really hardcore, because people just won't do it. But I recommend that they use a code annotation tool created by Felina. Herman, who is also just a powerhouse in programming education, take a look at everything, she writes and says she's amazing. But she made this code annotation tool, what you do is you take a permalink, from GitHub, and you paste it into her tool, I'll find the URL for the show notes. And you can annotate it, you can highlight things, you can make little notes on it, those kinds of things. Or if for some reason, you can't use that you can always Paste the code into a Google Doc, it's not going to work as well, because the code formatting and stuff is going to be all jacked up. But you can use the comments feature on there for the same thing, and effectively annotate code. And I find that that annotation procedure is extremely valuable for recovering lost context. Because it turns out that code, we can take steps to make code self documenting to make code an artifact for its own onboarding. And that is a skill. But even in code where that hasn't been done. Often, the explicitness required for for for a program to work is is still enough that if you dig, you can find clues code, although it is not always well documented, formats itself well for some archaeology to be done on it. And I think that that skill of archaeology is helpful. And one tactic that is helpful in that archaeology, I think, is this annotation procedure that I've described.

Tim Bourguignon 39:07
I mean, the alternative would be rewriting the software once making all the same mistakes that the original people did, and then rewriting it again, this time, right correctly. You have to go. You have to go through archaeology, and really find context as you were displaying, explaining the other way around. It's just not practical practice. Absolutely.

Chelsea Troy 39:29
And I think one of the things that we often do to hamstring ourselves as engineers, I mean, I think the first thing we do to hamstring ourselves is we don't learn the investigative skills associated with programming outside of productivity mode. I think there's two modes, there's productivity mode, you're, you're blasting forward on features. And then there's investigative mode. And I think investigative mode is extremely valuable when you're working in code bases that already exist, the more the older they are, the less well documented they are, the more important this investigative set of skills is. And we don't Don't teach it and we don't learn it, we don't explain to anybody how it's different from everything that they're learning in their master's program or online or from YouTube or whatever. And then, in addition to the fact that we have this code base with a bunch of loss context, which is already frustrating, programmers tend to have a very underdeveloped investigative skill set relative to their productivity skill set. And that's part of the reason the debugging takes so long, it's part of the reason that getting legacy code up and running, again takes so long is that our skill set is not up to the job, the way that our skill set that we have trained for, for building features is up to the job. So we ended up in this kind of weird loop. That's a lot of what I ended up doing. So I do a lot of teaching. Now I teach at the University of Chicago, I teach a couple of classes for their master's program there. And I also teach workshops through O'Reilly I teach workshops, at some conferences, going to be teaching one, hopefully, at DDD Europe in June, which I understand will have been over by the time this comes out. But more word on that at the time. And other conferences as well. I teach workshop, I taught workshops last year at Strange Loop, which will be coming up in September, folks. So consider consider a trip to St. Louis. But I'm a big thing that I teach about is this investigative skill set because I think that our educational resources on how to investigate code are lacking relative to our resources on how to produce cook.

Tim Bourguignon 41:32
I think, who was it, I won't be able to find the names, I think it's complete. It's called the baits, coined the term software meander, in order to, to counter act the the the software creation and saying, Well, we're not just creating, we're mending where we start. We'll, we seldom, seldom start with a greenfield project. Sometimes we do but but most most of the time, we don't. And we have to work with that. And as you say, to create context and understand what's happening, and and build on top of that, and not just scratch it and rewrite. And so he wanted to bring a new term in, in our lingo, to really say, or put it in a positive way and say, Well, we're just not working with legacy projects, which kind of has a bad rap nowadays, but saying, Hey, we're mending where we're fixing things so that they can be used and reused and and continue their lifecycle in a sustainable way, which is very, nowadays, problematic. And I kind of liked this idea. It really stuck with me, except his name. stuck with me this idea of mending and I get, but agreed getting context is hide. And it's not what we've been studying, release studied how to build stuff, not how to understand gather, do this investigation at some point start building on top of it. That's very interesting. Thank you for that. Where would you would you send people who would want to know more about this, this getting context, except for workshops.

Chelsea Troy 43:10
Besides my workshops, there are a number of resources that I like to reference. In the workshops, there's a book called working effectively with legacy code called Michael Feathers. For some reason, I have five copies of this book, I don't understand where I got them all. But there's also a wonderful book that I have been referencing lately. It's called Living documentation. It's by surreal martra where I got this recommendation from Rebecca dwarfs frock, it was an excellent recommendation. I really like it. Um, I do not mind head first design patterns, refactoring to patterns, those sorts of books. I do think it is very important to think hard about the context in which we're introducing patterns because I do think it's easy to get patterns fever, and it is the introduction of a pattern, I think, should begin with a consideration of the benefits and drawbacks of that pattern and whether they match the profile of constraints for this project. I really liked the book, kill it with fire, which is a book which is a humorously named book, but it is about the maintenance and mending of software projects. I also really liked the book, your computer is on fire. I got that one. I follow more Hicks, one of the authors on Twitter and found out about it from there. I think that's a really good book, highly recommend. And there is a book that I got recommended by Hello Wayne, who does if you've ever seen a TLA plus workshop was probably by Halloween. He also does them on alloy. These are structural verification tools for software, but he recommended me the book, Understanding software dynamics, and he recommended me another book also called data in the real world. I'm a data engineer. So if you're a data engineer, and you're interested in this topic, I also recommend data in the real world as well as storytelling with data, which is by a cold and this bomber Nasik. I think that's how you pronounce that. So yes, a wide library there, I would say. And then so one that I that I failed to mention at the beginning is object design. That's by Rebecca, we're sproc. And hold on. There's a co author on that. Rebecca Westbrook and Alan McKean. So

Tim Bourguignon 45:38
that's more than five books already coming out. Yeah,

Chelsea Troy 45:40
I do my best I try really hard. Well, it's a bit. So the thing is, I think that there are a number of books in software engineering that has kind of a cult following that I don't actually consider to be the highest quality thing for the thing that people are reading them for. And I get a lot of blowback, when I say that kind of thing. So I need to be very well prepared with alternatives when people are like, Oh, well, if you're not, if you don't, if you don't think that clean code is the best resource on the topic, then what do you think, and I need to be able to list like, eight, and the different circumstances where they're useful, because you have to be that resourced up to question a book like that.

Tim Bourguignon 46:20
And you were well prepared in the

Chelsea Troy 46:22
I try. This is this is how I did it at Pivotal Labs, I just needed to be able to code circles have to be I have to be comically over prepared for situations.

Tim Bourguignon 46:37
I'm sure you do well, on that end. That's the place where I usually ask for advice and, or a piece of advice. And I want to come back to you to your thing you say a couple of times, to this, this intellectual firepower. If you had a student coming to you right now, from probably a student from your classroom in Chicago and say, well, a teacher told me this told me I don't have the intellectual firepower to, to continue on this this this route. What would you say?

Chelsea Troy 47:09
Oh, my goodness. Okay. Um, I think I have a piece of advice for that student. And I also have a piece of advice

Tim Bourguignon 47:18
for teachers.

Chelsea Troy 47:22
Yeah, and that in that piece of advice for teachers, I'll come back to that Peter, Michael thing I kept promising y'all, um, the piece of advice that I would give that student this particular it would be, it would be such an opposite situation, because I could say, look, listen, I am teaching you in a subject in which I was told I lacked the intellectual firepower. And the truth is, this is a hot take. I think the truth is that a lot of teachers spend an insufficient amount of time building accessible pedagogy. And instead, build lackluster pedagogy. favor, the students who do well unusually students who do well in that circumstance probably didn't need the teacher to begin with, and then leave a lot of the students behind who, who actually need the accessible pedagogy that I believe it's the teacher's job to provide. And so what I would say to that student is that there are better teachers out there than whoever told you that, and that you deserve the opportunity to learn from one of them now, how to go about not being that teacher, I think it is easy. And I understand, believe me all of the pressures of academia, all the pressures of capitalism and everything that make it hard for teachers to do their jobs and to want to do their jobs. But I think the answer is very much not relying on state pedagogy and figuring and just allowing that to be what it is, I think, the answer is in reinvesting and figuring out what it takes to build a classroom that is accessible for learners, because it is precisely those students who struggle to learn from standard pedagogy that need you. They are the reason that, that teachers are needed at all the students who do well in the class without a lot of help, didn't need the teacher. They're not the reason the teacher keeps their job. In an ideal world, where education is valued the way that it should be. And I think that what I, one of the things that I learned from the way that Peter Michael taught was that, and I didn't understand that I had learned this from him until much later. But what I learned from him was that when you build a class, specifically designed to be accessible for the people who have the hardest time with this information, you're not favoring those students at the expense of students who have an easier time learning. Peter, Michael took an exercise that dads do with their four year olds, and put it in a classroom in one of the most reputable institutions for engineering in the country in the world. And that class loved it. more accessible resources aren't just better for the people who absolutely need them. When we design for the folks who have the hardest time accesses some accessing something, we tend to make it more accessible for everyone, including the people who would have had access to it the standard way, when we're specifically designing something for, for somebody who has the most trouble accessing it, it tends to get better for almost everyone. I think I really believe that I think about that every time I teach. And I believe that if everybody who taught thought about that more, we would have better educational resources for everything. That's my soapbox.

Tim Bourguignon 50:56
microbe. Yes. But not to Josie, it's been fantastic. I feel we just barely scratched the surface. But that's the show. Thank you very much for that.

Chelsea Troy 51:10
Of course. Thanks for having me. It's been a pleasure to

Tim Bourguignon 51:13
where can people find you online and started discussion with you about BMI or anybody else or any other subject?

Chelsea Troy 51:22
Yes. So my first name is Chelsea like the neighborhood in in New York. Ch ELS EA. My last name is Troy like Helen of Troy, T R O Y. And you can find my blog that I mentioned at Chelsea troy.com You can find me on Mastodon at Hey, he y like hello. Hey, Chelsea Troy. I'm on claw hammer. dotnet, I believe is my server. I am also on Twitter currently, as Hey, Chelsea Troy. You can find me on Instagram also as Hey, Chelsea Troy. And you can email me at Chelsea at Chelsea troit.com. I am regularly at conferences, you can reach out to me, if you'd like me to come to a conference near you. Particularly if you're a conference organizer, I'd be thrilled to receive that email. So I can ask you lots of questions about the conference. Because I'm very excited to come to conferences. And I teach I have a class, you can of course find me if you enroll in the University of Chicago, or in O'Reilly if you're an O'Reilly subscriber, I give a lot of workshops through there. Or if you just want to be able to get my stuff indeed, I have a website Chelsea troy.thinkific.com. Thinkific is the provider through whom I do online courses, I have one finished online course that you can purchase there just like you would purchase a textbook or anything else it is called. It is called technical debt and analytical approach that one is completed. You can also pre order a variety of other courses I'm planning on coming out with which will all be available in the catalog there and you'll be able to tell they're not finished because they are pre order rather than just purchase. Let me think I think that might be every place online that I am regularly. But I can't wait to hear from you all online, and about all of your adventures in coding and teaching.

Tim Bourguignon 53:30
Thank you for that. I'll try to do my best to add all those links in the show notes. I'll require your help with that. So you don't have to search and go back and listen to it. Everything should be there. We'll do my best but Chelsea, thank you so much. It's been a blast the words. And this has been another episode of developer's journey, and we see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share rate and review. It helps more listeners discover stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p porker email info at Dev journey dot info