What it means to be a Polyglot Developer with Sarah Withee

Sarah Withee is a polyglot software engineer, international public speaker, mentor, and hardware and robot tinkerer located in Pittsburgh. She is passionate about the intersection of technology and people. And as a Polyglot developer, she’s worked at a wide range of tech stacks and has built desktop, mobile, web, and backend applications. She is the treasurer of the board of directors for Prototype PGH, a non-profit with a mission to build gender and racial equality in tech and entrepreneurship. She is also one of the organizers of Code & Supply, Pittsburgh’s largest technology community. She is currently mentoring an all-girls high school robotics team and has been mentoring and judging FIRST competition teams since 2001. I first met Sarah Withee through her Twitch stream at twitch.tv/geekygirlsarah.

https://geekygirlsarah.com/links
https://codethesaur.us/

This podcast was released 02/03/2021 as part of the Polyglot Podcast - a series from The New Relic Relicans - both the series and team that created it have been dismantled. It was so much fun while it lasted, and I’ve recovered as much as possible from the Internet Archive.

Huge Thanks to Mandy Moore who produced, edited, and put untold hours into this podcast. Without her work, the transcripts below (and episodes themselves) wouldn’t have existed.

Teaser

Chael: I actually want to ask you about one of your projects that’s been really exciting me, and I think is incredibly important to the idea of being a polyglot and that’s Code Thesaurus. Can you tell us a little bit about what Code Thesaurus is?

Sarah: It’s about a dinosaur that programs. No, I’m kidding.

Chael: [Laughs]

Sarah: So Code Thesaurus is a project that I’m calling a polyglot developer reference tool. And the idea is if there’s a language you know and a language you don’t know, you can look at them side by side and see the structures of the language. So let’s say you know how to write functions in Python but you don’t know how to write them in Java, you could pull up Python and Java side by side and look at the different ways you can write code in both of those and see them and compare them. And the idea came to me after – It was four or five years ago that somebody had DM’D me on Slack for programmers. And they had said, “Hey, I saw you’ve been here for about – can I ask you a question about code?” And I’m like, “Sure.” And she’s like, “So I have this Ruby code and it’s doing this thing, and I don’t know how it works. I don’t know what it’s doing wrong. Can you help me?’ And I’m like, “Okay, well I’ve never done Ruby (at the time) but I can probably help you.” And in fact, I figured out what her problem was, but I didn’t know how to fix it. Well, I knew how to fix it in Python and C# and all these other languages, but I didn’t know how to do it in Ruby. And the problem with trying to find that out is you’re frantically searching for weird things like how do I do a whatever in this language? on Stack Overflow. And there are good examples, and there are bad examples, and they’re really hard to find. You can go into the documentation, but now you’re reading a book to try and find out the correct way to do a thing or to find out the correct syntax. And it gets difficult and time-consuming for this tiny little piece of syntactical sugar that I really need.

Chael: I 100% understand. Every single language has a different syntax for CASE statements and sometimes they call them switch statements, which of course makes it harder to Google.

Sarah: Yeah. And some of it is a string in Java is capitalized, but a string in C++ is lower case. But there are also C strings in C++ but C strings and strings are two separate classes where the same thing exists in Java. So we have little nuances there that the basic fundamental concepts are the same but you do them differently. The longer I’ve been programming, the more I realize learning a new language after you’ve known several is not the hard part of programming; it’s not the hard part of picking up the new language. The hard part really is understanding the nuances of new programming paradigms or programming methodologies, whatever you want to call this.

Full Transcript

Rachael Wright-Munn: Hi, I’m Rachael Wright-Munn, but I go by Chael. And this is the Polyglot podcast. Today I’m joined by Sarah Withee. Sarah Withee is a polyglot software engineer, international public speaker, mentor, and hardware and robot tinkerer located in Pittsburgh. She is passionate about the intersection of technology and people. And as a Polyglot developer, she’s worked at a wide range of tech stacks and has built desktop, mobile, web, and backend applications. She is the treasurer of the board of directors for Prototype PGH, a non-profit with a mission to build gender and racial equality in tech and entrepreneurship. She is also one of the organizers of Code & Supply, Pittsburgh’s largest technology community. She is currently mentoring an all-girls high school robotics team and has been mentoring and judging FIRST competition teams since 2001. I first met Sarah Withee through her Twitch stream at twitch.tv/geekygirlsarah. And I’m so excited to have you as the preeminent polyglot developer on the podcast.

Sarah Withee: Thank you. I’m glad to be here.

Chael: First off, I feel like the question that needs to be asked at the very beginning of anything to do with polyglots is what are the languages that you know?

Sarah: Oh gosh, I always feel like I forget some. I suppose if we go by what I have done in a professional setting in code, I’ve committed to company codebases, I would say C++, C#, Java, Ruby, JavaScript, Node and regular JavaScript, SQL, HTML, all the classics. If we go by outside of that, I’ve done also Python, I’ve done Haskell. The first language I ever learned was BASIC and Visual Basic. And oh geez, there’s probably more in there. [Chuckles] It’s definitely been plenty over the years.

Chael: I think just listening to that list, I’m hearing the progression of technology throughout time. Are you planning on adding Rust anytime soon?

Sarah: You mention that, I have taken a workshop at a conference on Rust.

Chael: [Laughs]

Sarah: And it was interesting because it was a three-hour or four-hour workshop; I don’t quite remember. He spent three-fourths of it explaining like, “Look, you can’t do this normal stuff with Rust. Everything’s immutable. You have to do all these little tricks to play with your variables, and it’s done on purpose to be really safe with all your data and everything. But here are all the hoops you have to jump through to do things.” And then the last little tiny bit of the workshop was like, okay, past that, it’s a lot like C++, Java, or whatever. So you’ll probably be fine.

[Laughter]

Sarah: So I’m familiar with Rust. Actually, the last company I worked at had Rust codebases, and I think had they not decided to lay off our whole team, I probably eventually would have ended up writing some Rust code and contributed to those codebases too.

Chael: I should have guessed. I actually want to ask you about one of your projects that’s been really exciting me, and I think is incredibly important to the idea of being a polyglot and that’s Code Thesaurus. Can you tell us a little bit about what Code Thesaurus is?

Sarah: It’s about a dinosaur that programs. No, I’m kidding.

Chael: [Laughs]

Sarah: So Code Thesaurus is a project that I’m calling a polyglot developer reference tool. And the idea is if there’s a language you know and a language you don’t know, you can look at them side by side and see the structures of the language. So let’s say you know how to write functions in Python but you don’t know how to write them in Java, you could pull up Python and Java side by side and look at the different ways you can write code in both of those and see them and compare them. And the idea came to me after – It was four or five years ago that somebody had DM’D me on Slack for programmers. And they had said, “Hey, I saw you’ve been here for about – can I ask you a question about code?” And I’m like, “Sure.” And she’s like, “So I have this Ruby code and it’s doing this thing, and I don’t know how it works. I don’t know what it’s doing wrong. Can you help me?’ And I’m like, “Okay, well I’ve never done Ruby (at the time) but I can probably help you.” And in fact, I figured out what her problem was, but I didn’t know how to fix it. Well, I knew how to fix it in Python and C# and all these other languages, but I didn’t know how to do it in Ruby. And the problem with trying to find that out is you’re frantically searching for weird things like how do I do a whatever in this language? on Stack Overflow. And there are good examples, and there are bad examples, and they’re really hard to find. You can go into the documentation, but now you’re reading a book to try and find out the correct way to do a thing or to find out the correct syntax. And it gets difficult and time-consuming for this tiny little piece of syntactical sugar that I really need.

Chael: I 100% understand. Every single language has a different syntax for CASE statements and sometimes they call them switch statements, which of course makes it harder to Google.

Sarah: Yeah. And some of it is a string in Java is capitalized, but a string in C++ is lower case. But there are also C strings in C++ but C strings and strings are two separate classes where the same thing exists in Java. So we have little nuances there that the basic fundamental concepts are the same but you do them differently. The longer I’ve been programming, the more I realize learning a new language after you’ve known several is not the hard part of programming; it’s not the hard part of picking up the new language. The hard part really is understanding the nuances of new programming paradigms or programming methodologies, whatever you want to call this.

I am doing Node in my current job, and I’ve done JavaScript before. So the idea of programming JavaScript is not really new to me. The part that was new is Node has this event system in the background that’s kind of looping over different things, and it tries to paralyze as much as it can. So where if you call five functions in a row, it’s going to actually literally call five functions at the same time because it’s going to try and optimize for that. And if you’re not used to that kind of knowledge, your program’s not going to work the same way you expect. And so the hardest part of that was not learning how does Node do functions? It’s learning how does this stuff work in the background to change things? And so I had to shift how I programmed to adapt for that, and that was the hard part. So I really feel like learning a new language is like oh, these are your data types, and these is how you do functions, and classes, and namespaces and read data from files and all this; that’s not hard. Those are things anybody, I think, can pick up once they’ve done a language or two. So I feel like a tool to kind of optimize for that – Like, if I want to learn a new language, I don’t need to read a programming book on welcome to the wonderful world of programming. We’re going to teach you everything you need to know about – I’ve been there.

Chael: [Laughs] Here is how to write “Hello, World!”

Sarah: Yeah. And tell me your “Hello, World!” show me a bare-bones web framework. How do I do a git call, git pull, respond with different types of objects, et cetera? And I’m probably good to go for the most part, and I can just look up the syntactical nuances a little later.

Chael: That makes a lot of sense, and that’s a really interesting way of looking at it. You mentioned Haskell, and you mentioned different programming paradigms; is the way that you’re thinking about problems in solving them based on the programming paradigm as object-oriented versus functional, or does it still not impact your ability to solve problems in that language?

Sarah: I think that’s some of it. So when I learned Haskell, I learned it in college the first time, and we had to do a math number parser or something like this where you give it an equation, and it’ll figure out if it’s a valid equation or not. And it was a lot of fun; I learned a lot from it. But when I learned that Haskell is typically a functional language, I’m like, what does that mean? Of course, it has functions, but then so does C++ and so do all these other languages. And it took me a while to actually learn what ‘functional’, quote-unquote, meant in terms of a programming style and how that differed from object-oriented programming. And then eventually learned hey, you can actually merge the two styles together, but you don’t have to. And that’s also kind of a little bit of a different way of thinking. So I think some of it is what the language allows you to do because there’s a lot of languages now that have started incorporating functional principles in there. So if you’ve done filter MapReduce, you’ve done a little bit of that functional programming. If you’ve done unit tests, if you do it right, you’re doing proper functional programming. [Chuckles] If you do it wrong, you’re still writing unit tests, I guess, but you’re not really doing it right.

Chael: [Chuckles]

Sarah: And some languages are more adapt to do things differently whereas some you can kind of do whatever style you want. So I think having that experience of not just seeing different languages and how they would solve problems but also jumping around to different types of codebases in those different languages has taught me different ways to solve problems so that if I know I’ve given a problem, I have several approaches that I could probably think well, this one’s probably the most efficient, this one’s probably the most time – whatever makes it run the fastest. And based on the language, based on what the codebase already has based on these other things, I can make decisions on the direction to go with that.

So I’ve actually told people the expectation as you move up from junior to mid, to senior, to lead to whatever your levels of developers are in your company, the expectation that as you grow you become more and more experienced in a language and you don’t have to look up as many things, and you don’t have to do as much research, I think is kind of wrong. Because I feel like I’ve become better even though I’ve never stayed in a language more than two years at a time because I’ve seen so many different types of problems and so many different approaches in different career fields, in different languages, in methodologies in all this. I feel like I’m more able to solve problems more creatively than your average person.

Chael: This may be an open-ended question, but I’m really curious to hear your thoughts on this. Do you think that the ways we approach problems and the fact that there are different approaches to problems in different language communities has more to do with the construct of the language and what it supports or more to do with the practices that are promoted inside that community? It makes me wonder because sometimes I’ll go to a talk and I’ll hear someone sit there, and they’ll talk about services, or they’ll talk about using this library or that library. And I know for sure once I’ve gone to one of those, I’m more inclined to use that approach. But at the same time, do you think there are solutions that are promoted by the language itself, like the function and form of the language?

Sarah: I had a job several years ago, and it was on a very large team, but I was working on a subset of that team. And they were rewriting 20-year-old software, so this was a mini, mini year-long project. And I was part of three developers that got pulled off the side, and we were rewriting a part of this, a small part of this thing. And they were trained to design a system that would instead of generating a set of legal documents internally, they would farm them out to a third-party API, and it would take a while to generate these things. So there was this process of you send them out, you wait a bit, and then you get them back. And I don’t remember exactly how but once the documents were made, they were written to a network server somewhere. And then there was an entry written in a database that says, “Okay, this part of the step is done. You can continue whatever you’re doing.” And the two of them that were in there were people that had 15 years’ experience in the industry. I had a lot less at the time, and they were like, “The best way to do this is we’re going to have this thing that runs in the background, and every 10 seconds it’s going to run a query on a database to see if this file showed up.” And I thought to myself that’s a really weird way to do it. Why would you call a database every 10 seconds to see if a file showed up? Because that’s putting stress on the database in the network because the database wasn’t on the same server looking for a file in a particular place. And I’m like, “Well, why don’t we set up a sort of system call because you can call an operating system API? So, when something in this folder changes, let me know. And so when you see a file showed up or file’s changed or whatever, you can look for a file that’s new, and that’s pretty easy to do.” And they could not wrap their head around this for a little bit until I finally spent five more minutes drawing out diagrams on this whiteboard. And they’re just like, “You know what? That’s not a bad idea. And I’m surprised it takes almost no system resources to do this kind of thing because you’re sitting and waiting instead of actively looking.” And so that’s the direction they went. And I think some of it was at a certain point, if you’ve done something enough times, it becomes a lot easier to use things you already know as your solutions to problems. And some languages I feel have very limited ways to do things and some languages have very broad ways to do some things, and it depends on what the things you want to do in those languages are. My friend, Jeremy Bytes, @jeremybytes on Twitter, had posted something about how sometimes things are hard for beginners to pick up. And he used an example of a really simple case to think of some sort of looping over an array or something really fairly simple. And he was like in Python, there are six different ways to do it, and he listed those.

Chael: [Laughs]

Sarah: And in fact, as the thread went on, some other people chimed in with several more ways to loop through an array.

Chael: [Laughs] Yeah.

Sarah: He was like, “Is there a ‘right way’, quote-unquote, to do this? Or is there the way that we’ve been taught and therefore that’s the way we typically do it? And are we going to shame people that do it these other ways? Because that may not have been the way they were taught or may not have been the way they were doing it before.” And, you could probably get in the nuances of like, well, Big O optimization, blah, blah, blah. But I don’t know that on a granular level of most use cases, it really does matter. I don’t think there’s a big difference. So some of it I think is what will the language support? What’s the, quote-unquote, ‘best practice’ for whatever the language is? Because you can pretty much take any language and do terrible stuff in it, but there’s probably a lot more to be said about what have we done in the past? ‘We’ meaning the developer or ‘we’ meaning the team of developers.

Chael: Yes, that’s what I see the most.

Sarah: And then from there, does that go into what’s, quote-unquote, ‘right or not wrong’

Chael: Oh, that’s really interesting because now we’re starting to get into the idioms of a language too. And I wonder, as a polyglot, how do you feel about that? How do you feel about the fact that somebody who is naturally attuned to that language is going to write things in the way that the community expects them to be written in? You’re kind of stepping in from outside the box.

Sarah: Yeah. My friend Abby has talked about how she learned and used Java for a really long time, both in school and in her career, and then went to a job where she partly does Java and partly does Python. And she said she’s written a lot of Java-like Python.

Chael: [Laughs] When I was first learning Ruby, that’s exactly what my tech lead said to me. He was like, “You write Ruby like it’s Java.”

Sarah: It’s not necessarily wrong. It’s probably not what you expect. It may not be the most optimized, but it kind of depends on what’s sort of allowed or what’s sort of use case you may need for how optimized it is. But that is kind of one of the downsides, if I’m starting a brand new project, which I literally just did at my current company a few months ago, there is sort of this worry, like, am I doing this code correctly? But am I doing it the way that other people would expect it to be? And I did find, as I was writing some of this project, it just got progressively worse the further I got into writing it. But thankfully, I had been researching a bunch of stuff along the way, and so I did take two days and rewrote the large framework of this whole thing, and it made it dramatically better. And I think actually more, quote-unquote, ‘Node-like’ in that process. So some of it is kind of a learning curve once you’ve adapted to old ways of doing things or old languages of doing things and you try to pick up a new one. But I also feel like if your team is open to either people trying new things, that’s not going to be too much of an issue. They may be like, “Hi, what are you trying to do here? There might be a better way of doing this.”

Chael: You mentioned there’s a better way. And this reminded me of a conversation we recently had about Corey Haines’ book The Four Rules of Simple Design. He dropped by the book club, and we were talking about it. And there’s a passage in there where he talks about instead of talking about things in terms of good design and bad design, talk about it in terms of better design. So when you’re talking about your approach to code, when you said, “Oh, it’s not the right way,” or like, “It’s not the way that people expect it to be,” you’re not talking about code that is buggy or broken, or non-functional, you’re talking about code that works, that is good, that is solid, that is built from a different perspective than most of the developers working on that codebase. And I think talking about it in terms of idiomatic, or better, or easier for existing developers in the community to digest, takes away a little bit of that feeling of like, is this code the right code? Because when we talk about things in terms of the right code, it starts to bring up questions of oh, well, if I didn’t make the right code, did I make the wrong code? And gosh, that has me thinking if code is functional, doesn’t that mean that it’s functional and performant?

Sarah: Yeah. There could be something to be said for language optimizations and the compiler or interpreter or whatever your language does, but we are kind of at this timeframe where CPU usage is very plentiful, memory usage is very plentiful, storage space is very plentiful. And there are some things you don’t really have to worry about as much, like, there’s probably always more efficient ways to do most things, but maybe sometimes it doesn’t matter as much. Maybe you can write something that’s not the 100% most optimized way to do it, and it’ll be just fine. Like, when you get into big data, there might be trade-offs for that.

Chael: [Laughs] No, I think you’re right. I think you’re right. It makes me kind of wonder, as a polyglot, do you prioritize functional code and working code over-expressive or idiomatic code? What are your priorities?

Sarah: I would say most important is that it does work and it is as bug-free as you can make it on the first round of code anyway; it’s never really totally bug-free. Because you don’t ever want to infer optimization first and then fix problems later because you’re losing your optimization as you’re probably going to try and fix things. So you want to make it correct and working as much as possible first. And then go back and say well, so like me, I have this habit of I’m going to try something and if it doesn’t work, I may comment out parts and then try again. So that way, I kind of have a temporary record of various things I’m playing with. And then before I commit the code or PR it or whatever, I could go back through and be like oh, hey yeah, all this junk I can just delete out before I could save it.

Chael: [Laughs]

Sarah: And I do this a lot more than I really want to admit.

[Laughter]

Chael: That’s the magic of patch adding. You’re just like, I’m going to add this line, that line, and skip all my comments, git stash and I’m done.

Sarah: Yes, yes. And it feels very hacky. But if I didn’t do that strategy, I don’t know that I’d necessarily be optimizing working things because I do know a lot of optimization strategies. But in the beginning, I don’t think that’s a main focus, so I definitely want to write good working code. And then the second step would be optimizing it, and then maybe the third step would be cleaning it up so it’s more readable because it’s very easy in IDEs now to right-click in a variable and be like hey, rename this variable, and it will change it in every place you use it.

Chael: [Laughs] Yes, this is so true.

Sarah: Like, ‘hacky variable one’, and it doesn’t really work after you’ve written a big elaborate function around it. But in the beginning, that might be just perfectly fine. But before I save it, I’m like eh, I should call this variable what it is.

Chael: And I think you’re right, having those underlying tools to make that clean up so much faster and easier means that it’s much more, as a developer, efficient on your time to go through and build something and then clean it up. I feel like we’ve gone very, very deep, almost to the bottom of the ocean. I want to bring us back up to the surface with a thought that you sparked in me earlier. You talked about show me the Hello World app and show me your web framework, basically like a web application in it, and this kind of brings me to a discussion that we had when you were starting Code Thesaurus, which was about which platform you wanted to use, as a polyglot you’re often choosing. When you’re choosing that framework and that platform, what sort of trade-offs are you thinking about, and are there major trade-offs?

Sarah: There’s definitely a lot of that, and I’ve been a strong believer of you choose the right tool for the job, as they say in the cliché when all you have is a hammer, everything looks like a nail. But if you have the ability to start something and you have this, you know, you can use whatever technology or framework you have, which is not always the thing you can do. But if you do have that, then there are a lot of things to consider. Some of it would be – when I was thinking through Code Thesaurus, I’m, like, the biggest part of this is going to be how do I store all these language concepts in some system that I can pull this stuff out and compare it? The web framework side of it, the more I thought about it’s almost like all of them are about equal. I’ve done PHP and Symfony before, and I’m like, well, that’s about on par with Python and Django, which I had not done before, but I’d read up about it, which is about the same as C# and MVC, which I’d done before, which was about the same as Ruby on Rails, which I had done before. And I’m just like, almost all of these are similar in what they do, similar in how I would do them, similar in the end result. And so I did. I kind of fretted about this for a long time. I think some of my decisions were – for an open source project at least, I was thinking a lot about how would other people be able to come in and look at this? Will there be enough community support to help people? I don’t want to pick some abstract language and some abstract framework, like, it’s really efficient, but nobody knows how to do anything. That doesn’t solve the problem. And so, like I said, Symfony, Rails, MVC, and Django are all very popular frameworks, and there’s a good community support around all of these. I ended up choosing Django. Well, it’s not the first one I chose; I ended up rewriting the whole thing. But I settled on Django because I thought it would be simple code that was very easy to read so that anybody that wanted to come in and contribute bugs or new features or whatever could look at this and probably figure out what I was trying to do and what they would need to do to simply to add onto it. And I know for the business world that’s a little different so some of it might be, do you have vendor buy-ins? So if you’re using AWS, I know sometimes some of those services don’t support every language whereas Azure – the more Microsoft you can use, the better. It’s not all they support, but the more you get into that ecosystem, the better everything ties in. You’ll just be easier off overall versus Google and that’s the one I know the least about, so I don’t know what they support or what they don’t support, and I would have to go look that up. And some of it would be what does your team already know? So the less you have to teach them new things, the bigger you’ve reduced the hump that they have to get over, but there might be the trade-off of if something does some task you need really well, that might very well be worth the change.

Chael: It’s almost like now that these web frameworks have achieved feature parity, the deciding factor, because we always talk about what is the right tool to use, it’s almost like the deciding factor isn’t those features it’s things external; you mentioned vendor pressures and vendor buy-in, and you mentioned your team’s knowledge and expertise. It’s almost like the language doesn’t matter. And I wonder if some of that comes from the standards and patterns that have developed around web applications. We already understand Rust very well; we understand an MVC framework. We can pull these out, build them, and if you’re going to build the same thing, you end up with the same structure. If you know what your end result is going to be, you kind of know how your end result is going to affect how you get there.

Sarah: Yeah. In the last project I had at the last company I worked at, we had written all of our codebases in Scala and Rust, which were very good languages for the tasks we were trying to do. And so that’s why when my manager built up this team, it was a brand new project, he chose those languages. He ended up getting removed from the team and the company was trying to figure out like, “Well, what do we do with this now?” They brought in a new manager that didn’t know Scala and Rust and he was just like, “I don’t even know what you all are even doing.”

Chael: [Laughs]

Sarah: And that was a bit of a struggle because we knew what we were doing. And I guess he couldn’t wrap his head around that I can still support my team even if I don’t specifically know the technology. And there were a lot of company politics, and I won’t get into those. But ultimately, their decision was we’re going to essentially kill off this project. We’re going to rewrite it in Java, and I forgot what the other language they mostly did was.

Chael: Oh, no.

Sarah: And the whole direction we went with everything on it just sort of backfired back.

Chael: As soon as you said, “They chose to rewrite it in Java,” I immediately understood the organizational pressures that you were under when that happened. And then actually that kind of ties into languages having communities because there’s nothing wrong with Java. But when you said Java, I knew that he had come from a Java shop. That was the only thing he’d written for the last 10 years, and that’s why y’all made the transition. And it was a very enterprisey Java shop, right?

Sarah: I wasn’t super enterprisey. But yeah, there was a lot of that’s what we’ve done before, that’s what we should keep doing. And we had microservices and everything was CI/CD built and his stuff wasn’t; he had never done those before. And so when he was like, “Well, how do you know what version you’re running?” “Well, we’re always running the latest version.” “But no, like what version is that?”

Chael: [Chuckles]

Sarah: “It’s whatever is in master. Master branch is always what we’re running.” And he couldn’t wrap his head around that because he was used to you build a Java application, you compile it, and then you release that as version number whatever and the fact is that we had a system that never did that, it always pushed it, it always threw it on AWS, and it kicked the old one off and started the new one, and that was seamless and you never knew. He couldn’t wrap his head around that. And so, yeah, there are some organizational pressures even if for our particular version of this project we had very efficient things. But as they took over, everything had to change because they just didn’t know, and that was too much of a hurdle for them to get over.

Chael: That really ties back into what we were talking about earlier because you could build a microservices architecture in Java. It’s entirely possible. You could have 20 different Java applications and your versioning has nothing to do with your codebase. I can do versioning on a book. I can use Git to write a book.

Sarah: I’ve known people to do it.

Chael: [Laughs] Yeah. So that really ties back into what we were saying about communities having a shared knowledge of what they’re doing and that not getting shared. And as a polyglot, I guess that falls into your role of taking that information and transitioning it between communities, which makes me really wonder, like, you’re very deeply invested in a lot of communities, but they’re not necessarily language communities. How does that come into play?

Sarah: And you also reminded me one of the things I’ve started using as a reference is sometimes I feel like I’m the glue of a team because you do have some very expert level; I’ve only built this thing in this language, and this is my knowledge base. And I’m like, cool, those are important people, but sometimes you do have this like, oh crap, we’re having this weird problem and nobody really has time to work on it or doesn’t really know how to solve it. “Sarah, you’re the one that does all this random crap. Can you go figure it out?” And I love doing that. I love taking weird problems and solving them. And that’s definitely one of the weird things, as I’ve gotten in the conference speaking and stuff there are very siloed communities. I don’t mean that in a bad way, but I mean like your .NET communities, they don’t play with anything else; they only do .NET. And I’ve dabbled in some of these, and I’ve dabbled in JavaScript, and I’ve dabbled in PHP, and I’ve dabbled in all sorts of different communities in various cities, online and offline, and all that. I found sometimes it’s hard to relate just because I don’t have that whole, this is the best thing ever kind of personnel.

Chael: [Laughs]

Sarah: And some people are like that, and I’m totally cool that you loved whatever tech thing immensely, and that’s not necessarily a bad thing. It becomes a little bad when you’re so closed off to everything that everything’s like the worst language ever. I love Python, but everything else sucks. Well, no, not everything else sucks, and Python has its own suckiness too. I can go into a long rant about different things I love and hate about tons of languages, but I won’t. But I have found it’s a little easier in, I’m going to call them polyglot communities, they usually aren’t called that, the ones that are very language agnostic, tech agnostic. We love having a variety of different people come and talk about a variety of different things and that’s communities or conferences or meetups or whatever. And I do fit into those well, but I also can jump around and be like, hey, I have done Python things. I can talk about things I’ve done. I’ve done PHP things, so I can do those too, whatever.

Chael: I think it’s a shame that you won’t rant about all of your feelings about different languages. I might have to invite you on the podcast again to rant about all of those specifically. [Laughs] We’ll have a whole episode on Sarah’s opinions on different languages. I want to go back to this concept of this language is the best, all other languages are trash because I see a lot of that, and I feel like it’s a preconception that we’re always fighting. I wonder what the root of that is because I always think about it as rooted in insecurity or FOMO maybe. Obviously, you don’t have this problem.

Sarah: [Chuckless] I sort of have that problem because I want to learn all the things and I never get to. But I think some of it is there’s sometimes a lack of empathy. We see this a lot in trash-talking tabs versus spaces, Windows versus Mac, Vim versus Emacs. And for me again, that goes back to there’s pluses and minuses for all of these things. I see the value and the pros and the cons of all these. I think some of it is it’s easier to say “I’ve tried these three different things; they’ll suck. I’ve tried this fourth thing I love it. I’m going to stick here and everything else sucks.” I think it’s also easy to say, “I used PHP 10 years ago, and it sucked, and therefore, PHP always sucks.” Well, no, if you look at what they’re doing now, PHP 7 and 8 have gone drastic strides to fix all of the stuff people hated in PHP 4 and 5. And we see these issues with Python where 2 and 3 have this fight amongst themselves. [Laughs] And finally, version 2 is no longer supported; they dragged it out for years. And everybody that did Python 2 now is kind of suffering because they have to switch to 3 and all these codebases that are still written in 2 a year later.

Chael: [Laughs]

Sarah: It’s still struggling. And some of the later versions of Java changed a lot of things. And so some people have been like, “I’m used to writing it this old way, but now there are all these new ways to do it.” And kind of what we were talking about earlier, if you’ve seen enough problems, that becomes the way you solve everything, or if you’ve seen enough solutions to solve problems, those become the way you do everything. And in an ideal world, we would be constantly learning, we’d be constantly evolving, we’d be trying out new things. But that’s not always feasible either because of companies, because of teams, because of codebases, whatever. And so it’s definitely hard sometimes, but saying this thing sucks my thing is better, is never the right answer.

Chael: I agree. And I think also a lot of times we prematurely announce things dead. [Laughs] For example, I saw an article from last year from the creator of C++ talking about how they’re still releasing new features, right?

Sarah: Yes.

Chael: C++ still has an active community. And for the most part, people have announced it dead, and we saw with the unemployment crisis in the United States that there’s still a lot of stuff written out there in COBOL.

Sarah: Yes. My favorite, it’s funny because it’s absolutely real, is COBOL on Cogs, which is a web framework in COBOL.

Chael: [Gasps]

Sarah: It seems to explode everybody’s brain but I mean, it’s true. I don’t know that too many people actually use COBOL on Cogs, but the fact that it exists, I think shows it’s still evolving. And people are like “Oh, nobody uses PHP anymore.” PHP is still one of the prominent web languages and a lot of that’s because a lot of stuff is still written in WordPress.

Chael: I think PHP has evolved a lot from when it was [inaudible] language. [Laughs]

Sarah: Some people are like, you know, these other things are dead. There are still little bits and pieces of all these things that are still out there. And I think there are shifts towards the more modern languages for things, but there are still so many companies out there with so many legacy projects that are still written in old languages. And that’s not to say they’re dead, but some might be dying.

Chael: I’m going to be honest, COBOL on Cogs absolutely delights me.

Sarah: [Chuckles]

Chael: My mom told me her first language was COBOL. She told me this after I was a developer for seven years that she used to code. But I’m kind of delighted by this, and I’m tempted to now make a series in COBOL on Cogs and just be like, “Hey mom, do you remember that language that you learned before I was born? Guess what? It’s still around.”

Sarah: I haven’t dived too much into it, but the website’s kind of amazing. You should go check it out.

Chael: I want to thank you so much for joining us for one of our first episodes of the Polyglot podcast. As soon as I saw that we were creating this podcast, I immediately thought of you and knew that we had to get you on the show. Where can people find you online?

Sarah: On all the social things, I’m pretty much Geeky Girl Sarah, so G-E-E-K-Y girl Sarah, Sarah with an H. For email, there’s always hello@geekygirlsarah.com. I love having conversations with people. I don’t really like using Twitter as kind of like I’m only re-tweeting things, and I never talk to people. I love chatting about things. So if any of you have heard anything on this episode and you’re just like, “I want to talk more about that,” please reach out. I would love to chat more on Twitter or wherever and just keep the conversation going because I think a lot of what we shared here today is not just good for developers, but I think good for building better teams and stuff too. Take the focus away from the deep dives into only tech all the time. I’m like, well, there are other things than just the tech.

Chael: Absolutely. Instead of chicken soup for the soul, this feels very much like coding for the soul.

Sarah: Yeah.

Chael: Thank you so much for joining us.

Sarah: Thank you. I’m really glad I could drop in.