The Relicans

Cover image for Learn Systems, Not Languages with Jessica Kerr
Mandy Moore
Mandy Moore

Posted on

Learn Systems, Not Languages with Jessica Kerr

In this episode, developer and symmathecist, Jessica Kerr talks about how the beauty of being on a team means that you don't need to know everything as an individual, that you too can become an expert by declaring your intention to be an expert on a thing and then going and doing said thing, the importance of designing programming languages to make them easier for humans to use, the concept of symmathesy, and how getting better at learning is appreciating feeling stupid and appreciating being wrong in order to become ultimately wiser.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

play pause Polyglot

Transcript:

Jonan Scheffler: I am joined today by Jessica Kerr. How are you, Jessica?

Jessica Kerr: I'm great. How are you, Jonan?

Jonan: I’m hanging in there. I'm actually having a really good day. I've been excited about this. I've been wanting to start this podcast, Polyglot, up for a while because I want to talk to people about higher-level software concepts or systems concepts that sometimes we talk about on these podcasts. We get down, and we talk about individual technologies or languages, and I see a lot of patterns above that that we talk about sometimes, but it's easy to get stuck in the weeds. I guess stuck in the weeds describes it as more unpalatable than it is.

But I wonder if before we jump into all of that, you might tell me and our listeners a little bit about yourself.

Jessica: Oh yeah. I'm Jessica Kerr, better known as Jessitron on Twitter and jessitron.com. I've been in software for 20 years. I consider myself super lucky. I got my first job in software in 1999, a beautiful year to find a job in programming, and I went into it because it was easy.

[laughter]

At the time. You get to go home at 5:30, and there's no homework. I thought that was great after college, but then I caught the bug, and now I love being in software because it's hard and it keeps getting harder.

Jonan: We keep finding new ways to make it harder on ourselves, maybe.

Jessica: Well, we keep doing more. Our standards keep increasing. We used to build systems that ran on a machine in a process, and now, everyone builds distributed systems—if it's a website, it's a distributed system—and we build them to run across machines, and we build them to be pretty, and we build them to interface with all kinds of things and just standards keep going up because we keep getting better at it and therefore, it gets harder.

Jonan: That’s an excellent point, and a much more optimistic view of the software world than a lot of people take, but I like that. That's a good take.

Jessica: It is really, really hard, especially for people coming into software more recently. I was lucky to get to start with C in Unix, one database, and just the standard library. GitHub wasn't there.

Jonan: Right.

Jessica: You didn't just download a library to do a thing. You wrote the function that you needed if it wasn't already there, and it's more work, it's more typing, it takes longer, but it's also way the heck easier than trying to be aware of everything that's available to you and integrating it and working it all out smoothly.

Jonan: Yeah, and you introduce so much more surface area that you need to be aware of. In a modern system, as you were saying, we're not running a single process on a single server. We've got many processes on many nodes running in many clusters, potentially.

Jessica: Yeah, and there’s languages built on top of languages, too. Today, I was struggling with an error in my YAML that's inside a markdown file that's processed by Jekyll, which I think runs in Ruby, but I was finding it in Docker containers so that I can push it up to GitHub for it to do GitHub pages on whatever the heck it does.

Jonan: Wow.

Jessica: And that's the easy stuff!

Jonan: Yeah.

Jessica: Oh, I love GitHub pages. It's so easy. I’ll just whip out a website. Yeah, until you get an incomprehensible YAML error that it was telling me was it line two character one, but really, I'm pretty sure it was the combination of parentheses, quotes, and a link outside the quotes in the field on line eight.

Jonan: YAML is my worst enemy in a lot of ways. I think I get it. Parsing a DSL is hard and identifying where the problem exists is hard, but I've had many days that I determined not only was there a bug in Docker but maybe in my operating system and every language I was using in the stack because a YAML character was out of place. [chuckles]

Jessica: Wow, wow. It's just, there's so many things that when you've learned them one at a time aren't too much, but when you need to integrate them all at once, that's overwhelming. It's a lot of power. But if you feel stupid when you hit one of these problems, it's not you. It's not you. It really is that hard.

Jonan: Yeah. I think a lot of people talk about things that are early on in a career like, you start out, and you put an HTML on a CSS site online.

Jessica: I didn't even have CSS. I just had HTML and tables! [laughs]

Jonan: I remember when I was in university introducing CSS to my CS group. I did a whole tutorial on it. Then my professor went to use this. CSS was very new, yeah. That was not a thing.

Jessica: Did they hate it? Programmers usually hate CSS.

Jonan: Back then, it was a lot simpler. Nowadays, it's not even CSS. Right now, we have SCSS and various flavors in between where we're compiling.

Jessica: Right, to compile to CSS.

Jonan: Yeah. Cross-compiling, transpiling.

So when you look at what a developer needs to know today to become competent, there's this long list of things. If I was to write out all of the technologies that are necessary to ship a static page on a GitHub page using Jekyll and Docker and all of the languages that you could know in that stack, it's a long list. It's a much longer list than it was in 1999.

However, we also see more people joining software more quickly. I think then we ever have. There were many, many developers in this industry who came out of code schools with three to six months experience and started being productive.

Jessica: Yeah! Within a team.

Jonan: Within a team. Do you think that we're leveling up the teams and the process around forming teams fast enough that that's becoming less of an issue? How is that even possible? How are we doing that?

Jessica: The trick is no one person knows all of this. Even the people who've been around a while certainly don't keep up with everything new. We can't. No one person can know it, and that's why we have a team, and you don't need to know everything.

The trick is okay, you have a vague idea of YAML, but to do a Jekyll site, you don't even need to know how to-do lists in YAML. It doesn't matter. You learn enough YAML, and then you learn enough Markdown, and then you learn enough Jekyll and enough Bundler and enough Docker and so on.

So you get enough breadth, and then you try to dig in depth-wise, as you have to, and the trick is to have a team of people so that not everybody has to understand everything.

Jonan: And then they just collaborate on the pieces that they don't understand, and that new way of handling a team doesn't allow for that lone wolf coder; the one who's a little grumpy and sits in the corner and knows most of the things.

Jessica: Yeah, because that person may be able to do work themselves. But our software is past the point where a single programmer can do something that's really powerful for the business. Yes, I'm sure there's an exception here and there that proves the rule.

Jonan: Right, yes.

Jessica: [chuckles] But in general, because software is harder because there's so many layers involved and you need enough understanding, you need lots of people. You need more brains to hold all that knowledge, and we need to think collectively.

Jonan: So we should wire our brains together à la Elon Musk. Are you going to get the implant?

Jessica: I have an implant in my hand.

Jonan: Oh, you do? [chuckles] That's a cell phone for those of us without the visual.

Jessica: [laughs] Right?

Jonan: Yes.

Jessica: [laughs] I mean, who needs a chip when these things are inseparable from us.

Jonan: That's a really good point.

Jessica: They are an extension of our brain, and they are connected to the internet.

Jonan: Let's talk about extending our brains and maybe how we design systems, or in software, how we design languages to make it easier for humans to use because that wasn't necessarily the case always. Software languages were designed to make it reasonable for us to accomplish things in a computer world. But I feel like early on, they certainly catered more to the computer side of the house than the human side of the house.

Jessica: Right.

Jonan: How do you think things have evolved there since 1999?

Jessica: We do have a lot of progress in the culture of programming languages. We recognize that programming languages are for humans and that the part about getting them to talk to the computer is the easy bit. I love languages like Elm and Elixir are pushing standards forward. Evan, the author of Elm, says that if you get a compiler error and you don't know what to do about it, that's a bug in the language.

Jonan: Oh! I haven't played with Elm, and I suddenly regret it because that is a beautiful insight that compilers errors are in the language if the human doesn't understand what's happening.

Jessica: Right, and in general, I forgot who said it, but the quote is, “They're not error messages, they're help and guidance messages.”

Jonan: And they are supposed to point you back towards a path where you can go explore that depth, as we talked about, where you get to dig into that specific feature of your language or whatever API you're using and discover on your own.

Jessica: Oh yeah, as necessary. Oh, there's some beautiful React error messages. I was using React for something or other, and it gave me an error message with a URL in it. This was a runtime error, but the message had a URL in it that took me to a page that explained what it was about with links to further concepts if you need those and really explained why I should, for instance, be adding a unique key to every list item.

Jonan: Oh.

Jessica: They need to teach you. The messages that we get from our technology, which is our languages and frameworks, which are there for us, need to teach us as we go along because no, we're not going to RTFM.

Jonan: Right.

Jessica: There is no one manual anymore, and if there were, we wouldn't read it. I mean, maybe eventually, someone on your team goes off and makes friends with React and spends a couple of days here and there then, of course. The more likely way that you get to be an expert in React and Jekyll—take your pick—is you declare yourself the expert on your team, even though you're not yet, and everyone brings their questions to you, and then you go research them and bring me answers back.

Over time, you become the expert, and then maybe you speak about it at conferences or blog about it, more likely these days or tweet about it, and then people start bringing you their stories. Just by declaring your intention to be an expert and then doing it, like following up to find the answers and digging deep where you can, you become one.

Jonan: So you would recommend this as an approach for teams with the technologies they use? Do we sit down on day one and–?

Jessica: Yeah, designate somebody.

Jonan: Yeah.

Jessica: Yeah, I know you don't know CSS now, but go spend half a day learning a little bit about it, enough to get the vocabulary to be able to Google the things that we ask about, and then the designated person on the team will become an expert in that. I did that with Git. I'm the person on the team that somebody comes to when they don't know how they screwed up their repository, and I'm like, “Ooh, let me look at your repo.”

Jonan: And then you have to do an interactive rebase for them and save them.

Jessica: Yeah, yeah. You get there by encountering problems, and the trick is to get other people to bring you a problem.

Jonan: Oh yeah, getting other people outside of your team to bring you problems, or inside the team, or both, I guess.

Jessica: Start with inside, and then word will spread and outside your team and outside your company, if you're blogging and tweeting and stuff.

Jonan: Which is maybe equally important, the work that you do and then the communication you do about the work.

Jessica: Yeah, because so much of the outcome of our work isn't in the code. It’s in our heads.

Jonan: Right.

Jessica: It's how we grow. Symmathesy, that concept of a team as a learning system made of learning parts. The code is learning as we teach it, and the running software is part of the team, so it learns from us as we change it and we learn from it both, as we change it and as we listen to what's happening, see those errors—especially the TG errors—see the data that it changes, see how our customers react to our changes and what events that generates. That learning integrates us and the software into a system together, and that's where you get power.

That's where the business people can come to you with a problem of, “I don't know why conversions are down. I see this point in the funnel as a problem now,” and you can say, “Oh, let's see, that goes on this page, and we have these events. Let me add one to find out what's happening,” and then you get that leverage into knowing a lot about what's already in the system and being able to add the visibility that you need. In order to increase your own learning, and then you wind up feeding that back into the system through changes.

Jonan: So what we've constructed here, you described this Symmathesy concept, a learning system made up of learning parts, which are software components and human components.

Jessica: Symmathesy is a more general term and describes ecosystems and economies. All the really important living systems that we have are learning systems made of learning parts. You can never model them perfectly because nothing in there is holding still. Everything is finding its own nation, adapting reaction to everything else.

But I think software teams are particularly interesting examples of symmathesy because those learning parts are both social and technical. There's us, the developers, there's the running software, and there's all of our tooling. Jekyll is part of that system as we can at least configure it upgraded and potentially, even contributed to its development. It's all part of the learning system both, at the scale of our team, and then when you get outside the team with both learning and contributing, we're also part of learning systems at higher levels at our company and our community.

Jonan: And this actually kind of stands in opposition, I think, to the way that people thought about software for a long time. In part because we shipped the physical disc with the software. Anyone who ever got an AOL disc in the mail.

Jessica: Yeah, yeah!

Jonan: Those we used to deliver.

Jessica: We used to deliver on floppies.

Jonan: Physical media. We had a gold, what did they call this? A gold? I don't remember.

Jessica: A golden master?

Jonan: Golden master, a GM. Some people still call a GM like an MVP, a first version of a software, a GM. This is the golden master version where we're done making changes. But the way to hear you describe it, you –

Jessica: Done making changes!

Jonan: Right. Software is not done. Software is never done.

Jessica: Yeah, yeah. There are software that we hardcode into chips and ship with physical devices in ways that can't be upgraded. Now, the modern ones can be upgraded. They do over-the-air updates. This is why a la Tesla, it just changed the car business. I don't think it's about the electricness of it, I think it's the software updates that happen over-the-air. Other car companies are getting there.

But that embedded the exception of software that really does ship and never changes. It's almost a different industry. You need different rules, different practices for that. Don't try to put that in because the software that we're talking about is usually business software, it's usually web, and we can change it any time. Or mobile, you can change it every couple of weeks. Please don't make me download an update every day.

Jonan: You don't want to update every application on your phone every single day, sometimes multiple times?

Jessica: Right. But on the other hand, my kids are like, “Oh yeah, this is a good app. It updates pretty often.”

Jonan: Wow! Really?

Jessica: Yeah! They recognize frequent updates as a sign of quality.

Jonan: Interesting. I guess I do, too.

Jessica: I would never update; I don't trust it.

Jonan: They haven’t changed that in a while. I think of really well-built teams as being able to continuously deliver their software. They are able to set off a deployment pipeline that is testing. In companies that I've been really impressed with would frequently just have that master-wise production, maybe even twice a day.

Jessica: Right, right. With a web app, you can do that.

Jonan: Right! With a web application, you just have this constant upgrade process. If a bit of code is merged into master, I expect that that ships at noon or 5:00 PM or even right in the moment, depending on where you're working.

Jessica: That is the ideal, yeah, and you have to decouple that from feature releases with feature flags and stuff. But if your code reflects reality of production, then you get much faster feedback if the code and the running software are the same.

Jonan: Because it's a living system like us. So when you talk about this Symmathesy, you described yourself as a Symmathesist. The term, Symmathesy, is a new one to me, and I have an idea of what it is now, but it applies in other industries more often than software. You hear people talk about Symmathesy more often in science or biology?

Jessica: Symmathesy is a new word. It was coined by Nora Bateson. She's an anthropologist, and she coined it only, I don't know, the last decade or so. So it is a new word, but other sciences talk about complex systems and systems thinking as Symmathesy, as a neologism, emphasizes the learning.

Our software is part of a Symmathesy only one it's undergoing change. That chip with embedded code in it that cannot be updated might be part of a complicated system. A mechanical system that hypothetically, if you spent enough time, you could understand everything about how that system works. But as Symmathesy, that can never be true because as you spend time learning about it, it's also learning, and it doesn't hold still.

Jonan: I remember as a child being very disappointed to learn that I couldn't finish reading all the books in the world if I lived long enough.

Jessica: Aww! [chuckles]

Jonan: That as long as I lived, more people would be writing books than I could read, and there was no way to just know all of it.

Jessica: Oh, now it would seem so sad if I could.

Jonan: Yeah.

Jessica: And that's when I went into programming. It was because you really could predict the outcome of the program, and that was so satisfying. My degree, just a Bachelor's, is in physics and it kind of lost its charm when we got into quantum, and I'm like, “You can't solve the equation to predict everything? Well, I'm going to go into software!”

Jonan: And here we are with quantum computers now!

[laughter]

Jessica: That's true. We have quantum computers. But also, in distributed systems, you're never going to predict everything.

Jonan: That's an excellent point. I think that we can do our best to prepare for the unpredictable. We talk about observability. That’s essentially, I think, what we're trying to do is that you can't actually predict the pieces of the system that are going to break. What you can do is get as much data as possible, as much as you can reasonably house into the system, and then try and make intelligent decisions on it, which I guess, is where artificial intelligence comes into the conversation.

I wanted to talk to you a little bit about that, because as you're describing this, these Symmathesy, the neural networks that we're now using that are continuously relearning based on their new input. It was at one point a thing in AI, where you would train up your model and then you would let the model go and make decisions, and you would show it in many pictures of a thumbs up and say, “These are a thumbs up,” and then show it many pictures of –

Jessica: That’s machine learning.

Jonan: Yeah, machine learning and then as opposed to a neural network that is able to learn and train itself as it takes new input.

Jessica: Or they train each other.

Jonan: Yeah!

Jessica: They pair them up these days and find they can learn a lot better from each other; that you'll have the one that generates images and the other one that labels them.

Jonan: Oh, that's interesting.

Jessica: Yeah. I don't remember that the acronyms of the thing, but there's a good one lately where it can generate pictures of an avocado in sunglasses sweeping the floor. You pair up the AI systems—are they AI or ML, whatever—so that you've got one that's generative and one that's interpretive, and they start learning from each other.

Isn't that how they finally made a chess program that beats all the humans?

Jonan: Oh, yeah.

Jessica: Because they let it learn from other programs. Instead of trying to only pair it against humans as if humans are the only thing it could learn from.

Jonan: And they're now able to beat any human because they let the chess AI teach itself with other chess AIs. They played it against itself.

Jessica: Yeah, that's what I heard on Twitter.

Jonan: I believe things that I read on Twitter. [laughs]

Jessica: [laughs] Of course, I believe it. It agrees with what I already think.

Jonan: Yeah.

[laughter]

Self-reinforcing.

So you think that when we design teams, we should be one, conscious of designated experts that you step up and you own JavaScript, or even smaller areas encompassing that, you're in charge of the React, and you need to know really well how Docker works.

Jessica: No, no, not you need to know. You need to want to know or be okay with knowing. Absolutely not you need to already know; you are just in charge of figuring this out.

Jonan: Right.

Jessica: And here are some people in the company that also work on Docker and want to figure things out, and some of them no more than you. So give those people resources and ideally, an internal community, but definitely an external community. If it's a small company where they're not going to have all this internally, your job is to find the Docker podcasts and start listening to them. Maybe get into some Slacks where people are into this kind of thing to develop the resources because we're never going to learn all this on our own. We don't get to go back to first principles very often, but we can together.

Jonan: Yeah, and this is the value of having a whole team of people. That ability to specialize, because we can hold more in our collective brains than any one of us could, no matter how good that one person got and understanding a piece of software.

Jessica: And we still have to work together because in the end, Docker is easy and Jekyll is easy, and the interaction between the two is not.

Jonan: Relatively, yeah. For a definition of easy, that is, in fact, hard because both of those things that you said, they're complicated.

[laughter]

Jessica: Right, exactly! Exactly and when you get your individual tech mashup of oh, my latest side project is in JavaScript with Vue except not JavaScript. I want to use TypeScript, and I also want to use RxJS for reactive streams, and that's enough right there. Oh, and I'm developing NPS code. So you've got the plugin for Vue and the plugin for TypeScript, and maybe there's a plugin for RxJS. I don't think there is, but then you’ve got the types for TypeScript, and where do you put those, and that's enough. That's enough of a combination that there are weird error cases, this is not all supported natively, and I've got to figure out how to blend those together, and that's everything all the time, man.

Jonan: You have to blend all of it together all the time. So if you were setting out to build a team today, if we're going to have a startup—well, we probably have funding at this point, but let's say, we're going to try and hire a team of 20 people. We're building an engineering team from scratch. What advice would you have for organizing that engineering team to allow for those kinds of interactions?

Because we try to do this, when we're building teams, to create these areas of specialization and we used to do it in say, “Well, this is the frontend team, and this is the backend team, and this is the infrastructure team.” But I think more and more, you're seeing developers own components all the way across that stack, for example.

Jessica: That’s the ideal.

Jonan: That's the ideal, right?

Jessica: But then you have to be careful of how deeply let that stack go. You can do that if you use services for as much as possible. You pick a platform as a service and just stick with what works there. You're using CICD as a service, and you're on github.com, and you have a CDN preferably integrated with your platform as a service, or maybe you just use Netlify for everything.

You have to make those layers not go too deep. You have to make them as shallow as you can so that you can focus on okay, what do we have to know on the backend? What do we have to know on the frontend? You want to reduce the possibilities in terms of using standardized parts for everything that is not your secret sauce and keep all that mental energy of understanding, customizing, and being able to change in your specific business domain. When you start, I think that's super important.

Don't be special! [chuckles] Keep as little special as possible, and it should only be special because this is how your business is special, and this is how your mission is different from everyone else's.

Jonan: And this is the unique competency that you have. You are the best in the world at building features for your customers around the product that you have designed. Don't rebuild a platform as a service or a CICD infrastructure or your own GitHub, for heaven’s sake.

Jessica: Yeah, use what's out there. Now it gets way more interesting when you're not building a team. So most of the time, you're not building a team. Building systems is weird. Evolving systems is much more common. Even if you're assembling a team from people who already work at a company, that's an evolution, and then you have more to accommodate.

So when you're looking at a big company that already has all this legacy software, you can't say, “Just use Netlify, don't use anything Netlify doesn't support,” for instance. You have to accommodate what's already there, and then you start winding up, and when you're bigger, you can do those winding up with internal platform teams that offer a platform as a service that is more specific to this company and more specific to the things developers in this company already know.

Jonan: That's an interesting point; the things that developers in this company already know. I'm curious, not because we have spoken about this before, and this is definitely not a setup, what your favorite software language is?

Jessica: Well, my personal favorite at the moment, I use TypeScript for things. It's a nice compromise. But the language, I think, you should use—for generic you—is whichever one your team already knows the best.

Jonan: Yeah.

Jessica: Because you matter, you are part of the system and people are like, “Use the best language for the problem.” Okay, to a point, that's true. When we say general-purpose programming language, we actually mean internal business that’s mostly CRUD or a website. Elm builds single-page apps. That's it. Doesn't try to be anything else.

If you're doing math and science and number-crunching, please use Python and its libraries that call into Fortran code [chuckles] that are fast. If you're doing data science stuff, MATLAB is great. So there is a point.

If you need to do – oh, what do they call it? If you need to do live streaming of massive data inputs, you probably want scholar Python because that's where the libraries are. To a degree, your language and your language community needs to be suited to the problem, but that's a big category of problems.

If you're writing business software, Ruby, or Java or C-sharp, or TypeScript, or Alexa, or whatever, any of these general-purpose languages are going to work, and the biggest determining factor in how well they're going to work for you is whether you already know them!

Jonan: Right.

Jessica: I'm using you, plural meaning the whole team.

Jonan: I agree with you. I think that very often we talk about wanting to use the best tool for the job, but the fact of the matter is we are real good with one tool. If we are walking around with a real big hammer, lots of things start to look like nails. Yes, that’s a problem.

Jessica: Yeah, if it's close enough to a nail, awesome.

Jonan: Yeah.

Jessica: Use the hammer that's in your hand because one thing I've noticed, as I have become more and more a polyglot, I'm trying to default to TypeScript for things these days, just to default to something. Because when I'm switching between Scala, Clojure, TypeScript, and of course, there's always YAML, Markdown, and everything else that's in between, that's always there and HTML and CSS. When I'm switching between those, I'm not great at any of them, and I'm slow in everything.

As a polyglot programmer, I am slow, and when I worked with only Java or after two years in Scala and still doing Scala, then I was able to express the ideas without stopping to think about what to type next. How do I write that? I know what I want to write, and it's out there, and that's where you want to be most of the time. For that, you have to go deep.

Jonan: You think that polyglot developers are able to achieve that in multiple languages and hold all that context in their heads at the same time? Do you think I could do the same with Scala and Ruby and TypeScript, and reach that same level where I am speaking fluently in all three languages, and I don't have to think about how I'm going to achieve a thing, I just need to think about what I want to achieve?

Jessica: That's a good question. Everyone is different, but I think you're never going to be as fluent as three is if you focused on one. There's always new stuff to learn. Typescript, for instance, is releasing a new version every year and adding stuff constantly and just keeping up with the latest in that language takes a lot of time, plus the latest libraries and stuff.

But if you're in a language like Java or C-Sharp or something that doesn't move too fast, yeah, you can be good at that and JavaScript. Frankly, everyone needs to know JavaScript because most of us are on the web or doing something for the web, but it gets really hard.

Oh, and then there's some languages that are just farther apart than others. Like Scala and TypeScript, switching between those two is not the end of the world. The hardest part is that there's some syntaxes that are close, and so, you get them mixed up. Scala and Clojure, oh my God. Rod Johnson says that Clojure is like Australia. It's a really lovely place to be, but oh my gosh, it's such a long distance from everything else.

Jonan: And the spiders are giant.

Jessica: Not the giant spiders but right, the giant spiders and not the dangerous spiders. [laughs]

But yeah, there's a brain space of switching, and there's a tool space of switching because we don't program in languages. We program in language ecosystems and the editors for Clojure, they're great. ParEdit, I really miss it in every other language. I really want ParEdit for TypeScript. Please, someone, make that because I don't have time to do it well.

[chuckles]

There’s how do you run tests? What is the latest testing library? In Clojure, you can do gradual typing. In TypeScript, you also get to do that, but it's completely different mechanisms and paradigms. If you're switching between Java and Clojure, you have to move between functional and mostly OO so, there's very different brain spaces.

I used to scoff and roll my eyes at people who wanted to do JavaScript on the backend because just pull your pants up and learn another programming language! But no, no, I want to be focusing on the business feature I'm implementing and what it needs to do and what it needs to report back to me and everything higher level than that. Switching languages costs me mental space. It costs me working memory. And it costs me just work. Yes, especially when I was younger, I had plenty of that to spare, and I could do it and pursue the thing.

When it feels hard, when we hit something hard, like we hit a tricky bit in the code or something like switching back and forth with languages, it feels productive. We feel smart. It feels good, and it's useless. It’s wasted. We can use that intelligence and that brain space for something more specific to what we're doing.

Jonan: We have found ourselves in a situation where the dopamine in our brain is building habits that reinforce these issues for us. It feels productive. It makes you feel very smart to solve a difficult problem, and that then trains you like you are receiving a treat for a behavior to continue that.

Jessica: Yeah.

Jonan: Is this why I sometimes work for an entire day and end up with no result and throw it all away?

Jessica: Ask yourself how your brain is different. What do you know now that you didn't know, or know more deeply that you didn't know at the beginning of the day? That's my compensation for that.

Jonan: That's a pretty good prize.

When you were talking about languages, I was thinking about this in the context of real human language and trying to draw a parallel. Do you speak any foreign languages?

Jessica: I don’t. A little bit of Spanish.

Jonan: A little bit of Spanish. So I speak Japanese reasonably well. I rarely would call myself fluent to another Japanese speaker. To most English speakers, I’m fluent, and the difference in my mind, I think, is that I can have a conversation if I guide the conversation towards topics that I understand well and I've spoken about in the past. I can't write poetry very well in a foreign language. I definitely struggled in my high school physics class in Japanese—very specialized terminology.

So I think that maybe the parallels exist there that no matter how many languages you learn, you're going to have one that is easier for you to write poetry than the rest, that flows like water out of your fingertips into your editor in the programming world.

Jessica: Nice. Yeah, and I feel like I've lost the ability to write poetry in any programming language by switching back and forth, and of course, I don’t code all day in my day job anymore.

Jonan: Yeah. This has been really interesting. I really appreciate you coming on the show to talk to us about these things. I think it's a good kickstart for Polyglot. People who I think are often thinking about these things are pretty late in their careers. Maybe early on, I was just trying to get up that mountain as fast as I could, but I wonder if you have any advice for people. If you are a new developer, it's very easy to stand around paralyzed, trying to decide which language to learn or which language to learn next, and I often tell people – well, I tell them what I tell them, but I want to hear what you would tell them.

Jessica: Oh, well, learn one deeply. Whatever one is most useful to you at work, go deep on that and then, by all means, play with other languages because they make you think differently. But Elm is a great one for this because it has its own little ecosystem, and especially if you're not a web dev, you don't have to learn all of the JavaScript ecosystem, which is terrifyingly deep. Elixir also because it emphasizes tools and developer friendliness.

Don't feel like you need to learn other languages the way you know your primary language. Let them twist your brain. Try to write single page web apps the Elm way and then in Elixir, see if you can get into processes and the things that make the early runtime unique and try to do things a different way in a different language for the sake of your brain because that's really valuable.

Also, oh, so I don't know Polish, but I went to Poland three times for conferences, and I learned enough to be able to pronounce people's names and say good morning and stuff. I just worked on getting the pronunciation pretty good. Cześć is hello in Polish, and it has two different ‘cz’ and two different ‘sc’ sounds in it. The differences in English are fascinating, but people loved it that I could pick up their name tag and make a reasonable pronunciation of their name.

Being able to read a language is really valuable. I know enough Haskell to be able to watch presentations on it and understand the types that they're talking about because that's Haskell’s strength; communicating with types. So I highly recommend reading other languages and writing them enough to kind of make your brain hurt, but then you can communicate with people.

Jonan: The goal is not to become fluent in multiple languages. The goal is to learn one really well and then stretch your brain by trying others.

Jessica: Yeah, and eventually, you'll decide to learn another language really well, that's fine for a job you want to get or just because you found one that you really love.

Jonan: All right. I will make sure to follow your advice myself. Even now, ten years on in my career, I could stand to hear these things. I'm going to check out Elm. Elm and Elixir sound awesome.

Jessica: Oh, Elm is fun. Yeah, so much of a language is the community, and they have great communities.

Jonan: That's one of the things that I look for in languages, and that's part of why I've stuck around in Ruby so long. I love Rubyists. They’re fantastic humans.

Jessica: That's why I learned Ruby.

Jonan: Thank you so much for coming on the show, Jessica.

Do you have any parting words to share with everyone, or should we just tell people to find you on jessicakerr.com? Is that correct?

Jessica: Jessitron.com

Jonan: Jessitron, okay.

Jessica: J-E-S-S-I-T-R-O-N.

Jonan: Any parting thoughts?

Jessica: We talked about how it feels good to feel smart, and you get that dopamine hit.

Jonan: Yeah.

Jessica: A big part of getting better at learning is appreciating feeling stupid, appreciate being wrong because that's the step to getting wiser and if you can get comfortable with not knowing, with being lost, and especially with asking for help. If you compare humans to the animal kingdom, we have language, we have high articulation vocal things, and we have opposable thumbs, these are nice, but our superpower is using that language to ask for help.

Jonan: I saw a billboard going around on Twitter, the source of all truth the other day, that said, “Be brave enough to suck at something new.”

Jessica: Oh, yeah.

Jonan: I really like that quote. Thank you again. I really sincerely appreciate you joining me for this, the very first episode of Polyglot, and I look forward to having you back.

Jessica: Thank you so much!

Jonan: It was a pleasure. Take care.

Discussion (0)