In the last episode, we talked with Richard Feldman about Elm and a bunch of other things. In this episode, we're going to talk about some of Richard's personal experiences. My name is Jonathan Cottrell. You're listening to Developer Tea, and my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Of course, a huge thank you to Richard for joining me for this episode, and let's get straight into the interview with Richard Feldman. So I'm curious about some of your personal experiences on this path. I like to ask engineers to share their more experiential explanations of how their career has gone, because it's easy. The reason I do this is it's easy for a young engineer, for example, young meaning early in their career. To think that everyone else had it smooth, right? That everything just kind of happened, you know, like a storybook and, you know, they closed that chapter and just smoothly transitioned to the next one. And I'd love to know if you can take us back to a moment in your career where you felt like maybe you felt like, I don't even know if I want to be a programmer anymore. Or maybe there was a moment where you felt like, man, I just don't feel competent at what I'm doing. Uh, I feel like. I'm not qualified for this or anything that, that was a struggle and inflection point of a struggle in your career. I'd love to know a story like that from you. Yeah, totally. So, uh, one of the Java jobs I had, um, I, I remember very distinctly, uh, feeling that I wasn't, I don't know, I don't know what the right word is, but, um, it felt like, uh, somewhat the word that comes to mind is soulless. Or maybe soul sucking or something like that in the sense that, um, I just, I just didn't want to go into work anymore. Uh, I, I remember just thinking like, uh, man, I, if I didn't come into work today and I didn't, you know, write the code that I wrote, somebody else would write that code. You know, I'm not, I'm not really an important contributor here. It's not like anything that I'm doing here is really unique or like, uh, creative. I'm just like, I'm going to come. And then I have, you know, as, as I've had throughout my career, you know, an issue tracker and I'm going to pull the next thing off the issue tracker and I'm going to make it work. And then I'm going to, you know, repeat until I go home. And if I don't do it, someone else is going to do it. Yeah. The assembly line coder, right? Yeah, exactly. Uh, and you know, I, I, at the time I, you know, I, I needed the money, you know, it's, uh, it's, it's not like, uh, I think. These days people with, you know, 10 plus years of programming experience, I, we, we have the luxury of being able to say, well, if I don't like my current job, I can always leave and go get another job. Um, but I didn't feel that I had that luxury at that point in my career. And I mean, you know, we should all be so lucky as to, you know, have that be true of any of anyone's career, because I know like most career paths, you know, you don't really get to that point maybe ever, but I, I just remember thinking, um, this is just like draining the life out of me. Just, just coming in every day and, uh, feeling like I'm, I'm doing nominally creative work, but, uh, but it doesn't feel creative anymore. Um, I just sort of lost all. And I actually, I remember, um, so for a lot of my life, I, you know, I, I started out programming as a hobby and then it became a career in that period of my life. I wasn't even programming at home for fun. Uh, I was just, you know, I, I, I would just get, get off work and I would think, okay, well that's enough Java for one day. Um, let's go. Let's go do anything else. Uh, and yeah, I mean, eventually like another opportunity came along, um, and I, I sort of jumped at it because I was, uh, I mean, there were a lot of red flags about it, but I was like anything other than more of this, but I mean, uh, there's, there's a very real possibility that maybe nothing else would have come along because, I mean, at that point in my career, I didn't, you know, again, feel like I had a lot of options. And I think if I had, uh, if I had stayed, you know, doing that, I could, could have, you know, assuming the, you know, my employer didn't go out of business or something. Um, I could have, you know, potentially just, just stayed stuck in that loop, you know, definitely. Um, I might, I might still be doing that same kind of work today. I still get LinkedIn, uh, spam from, you know, people saying, Hey, you want to take this Java job? I'm like, nope. Uh, but, um, I mean, I, I can, I can tell other stories about, you know, times I really messed up, uh, at work. Um, but that's the one that comes to mind as sort of like, that was, I think. For me as a programmer, you know, something that started off as a very exciting, you know, um, hobby. And then, uh, now has come back around to being something that I spend. I mean, my wife jokes that, well, not, not, not joke. She's serious. She's like, you know, your hobby is also your job. Like you, you write code at work. And then when you're done with work, you write other code for other projects, which is totally true. Um, uh, and has been true for, you know, many years now. Um, but, uh, but yeah, I mean that, that, that was that one sort of. Stretch of my career where, uh, I don't know, everything just felt kind of bleak and, uh, and I'm, I'm glad that I, when something else did come along, um, I jumped at it and honestly, maybe I should have, uh, taken more initiative and, and tried to find something else sooner than I did. Yeah. I was going to ask you, you know, do you have any suggestions or, or advice for somebody who finds themselves in that kind of situation where they feel like they're just kind of putting in the hours? Maybe it's not as creative as they want, or maybe the stack or the tooling or, or whatever is, is causing that problem. They feel like they are, you know, just totally burnt out, maybe even considering leaving programming altogether. Cause it's not what they had hoped for. I mean, I, I have a few thoughts on that. So one is, um, I had a friend who wasn't exactly that position. He was a PHP developer and, uh, he really was feeling very burnt out and like, he just didn't want to do software anymore, but he had a family to provide for. And he's like, I don't know what else I can do to make money, but he had this very deep passion for. Well, I don't want to get into it cause I don't, I don't, I don't want to like try to give too many details. People will figure out who it is because long story short, he's now quite famous for what he does, um, which is not programming. Uh, and basically he, he decided at some point, um, I actually don't remember what my advice was at the time, but I think I actually did not advise him to get out of programming and maybe that wasn't good advice cause it certainly worked out well for him. Um, but I mean, he, he really had this other thing that he was very passionate about and, uh, really had kind of a novel take on, uh, and it turned out that, yeah, I mean, he, he did decide to leave programming. Um, money was very hard for him and his family for a while, but, uh, ultimately, um, it worked out. I mean, he, he, he translated that passion. He had that drive to, to, to make it happen and now he's much happier. So I don't, you know, I love programming, but I, I don't want to pretend that everyone's like me, you know, I mean, it's, it's fine to love other things and to pursue them within programming. Though. Um, I think if, if I could go back and give my past self some advice there, I think it would be, you can be a lot happier working a job that pays less and is harder and, uh, has longer hours, but where you actually enjoy the process of, you know, like what you're doing at work. So for me, that was a kind of startups. Like, um, at this point I I'm working for the fourth startup I've ever worked for. Uh, and like having worked at startups versus sort of more established companies, not even necessarily big companies, but just, you know, companies of different sizes that were, you know, sort of stable as it were. Um, like they, they didn't have the sort of impending doom that every startup sort of innately starts out with because, you know, they don't have much of the way of money. They're, you know, sort of dependent on investors and so forth. But one thing that I've always really liked about, um, whenever I took a job at a startup is that, you know, yeah, the hours were a lot longer. The pay was a lot worse. Everything was a lot harder because we didn't have any, you know, support structure. Um, always had lots of tight deadlines, but it always felt very exciting. Uh, I always, you know, whenever I'd go into work, I'm like, if I don't go into work today, that is a problem for this company. Like it's, it's, you know, everything that I do. I am essential, right? Yeah. Like, yeah. And it's not just, it's not just, you know, feeling, um, like a feeling of self-worth for, for, for its own sake. But I mean, it's a very real, you know, like this. Very connected. Yeah. Like needs me. And, and, and that means that what I'm doing matters. And, um, and that for me, um, is a very motivating thing as a creative person. Like, I, I don't know if anyone likes to feel like, you know, I made this thing, but it was totally irrelevant and like, nobody cared whether I made it one way or another or, or, you know, uh, and, and another thing that I would note is that, um, I think once you've gotten some familiarity with programming, you can probably surprise yourself at, uh, how much you can do. If you're put under those circumstances where it's sort of a sink or swim, like the first startup I did, I actually was a company that I started and it was a web startup. We, we were planning on making this, well, I say planning on, we did successfully make this, um, sort of, sort of like a social recommendation engines, like kind of like a good reads or a, um, Yelp, but, uh, it was sort of like more zoomed out version of that where it was like, we had books and movies and music and like all these different categories in one place. And the, the, the reason I bring that up is because none of us had ever done a job doing web development before we'd all done, you know, I had done some like Java UIs and, um, and like C plus plus a little bit back in the day and visual basic. Right. And, uh, and none of the people who were working on that, in fact, one of them wasn't even a programmer. Um, and we just sort of had this ragtag band of people that we put together with, you know, because we worked well together and, and we built this whole working website, um, like from a technical perspective. That project was very successful. Uh, the only reason, well, I mean, I don't want to do a post-mortem on a startup, but, um, but basically like, uh, it was technically successful, even though if you were to put our resumes together, you'd be like, there's no way they can actually build this thing. It's like, Oh, we actually did. And I think that's actually true of most programmers. I think, I think most people are capable of more than they might expect based on what they do at their jobs. Um, most jobs are just not. As most programming jobs are not as challenging as the sort of like crucible of a very, very early stage, like, you know, ground level startup. Um, and so for me, that, that would have been good career advice at the time was like, Hey, you should seek this out. You know, you should go try, try to find something where, you know, you can take a pay cut that hopefully you can, you know, you can still pay the bills with. Um, and even though it's going to be more hours and it's going to be harder work, uh, you'll be so excited when you get done with work. I mean, you'll be tired. But, uh, but at least you'll be excited. None of the startups I've ever worked for are anything I could remotely describe as soul sucking. Um, and I guess that I maybe have been fortunate to, uh, I've definitely heard some startup horror stories too. And, you know, uh, like bad cultures and bad people and, you know, unethical people. Um, I, I've been fortunate never to find myself in one of those situations. Um, I guess that's not totally true. There was, there was one point of one startup where there was one person that, uh, I wouldn't have nice things to say about it retrospect, but they didn't last very long at that company. So, well, they lasted kind of long, but either way, uh, despite that, uh, overall, it was still a positive experience. Um, but, uh, yeah, I think that would have been good advice in retrospect. Yeah. So it's interesting because I found myself, um, kind of accidentally in a way thrust into three different startups at the start of my career. Um, not all at the same time. No, no, no, that would, I think, I don't think that's humanly possible. Um, the first one, I call it a startup. It was more like just a very young company. It was technically a startup, but it's not in the same sense that you would think of like a fast growth startup. It was just an agency, um, like a web agency. And the second, uh, company I went to, uh, was called Clearbit. And then the third one was called Tesorio. And all of these had their. Uh, I don't know. They had their, their own issues. All of them had their own strengths. And obviously I enjoyed working, uh, at all of them. I wouldn't have taken the jobs had I, had I not enjoyed it. I was very fortunate to be able to, like you said, kind of pick my job, uh, because of the skillset that I built early on in my career. But I, what's interesting about what you said is this idea that, um, to kind of increase your sense of utility, uh, or, or self sense of utility at a company. Go and work. You could go and work for a startup that needs your kind of more of that from you. And what I found for me now, I work at PBS, just spoiler alert, um, much larger company obviously doesn't have that startup vibe to it, although there are some people in the company, you know, there, there is still some culture of kind of gra you know, grassroots building, uh, things in rapid iteration and that kind of thing. But what I found that was difficult for me in startups. Was the idea that I couldn't slow down to think through the problems I was trying to solve because, and it wasn't a fault by the way, just to be clear if any of these companies, but it was just kind of a, an artifact of being in a startup, uh, at least at the time that's, that's what it felt like we, we couldn't slow down to solve problems because, you know, getting through the theory or thinking about something more thoroughly, if you did that Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. um, about, you know, some part of your analysis, you have to move forward with the very big rough picture. And for me, that was difficult because I like to think about things, think about this podcast very theoretically, right? I take a step back and try to find the patterns and, and, you know, really ask the, do the five whys and all that. And it didn't seem like that was something that was easily tolerated in a startup because just frankly, they don't have time for that. And so I think there's a lot of kind of self-exploration as you go through, through your career. Now that I'm at a company that does have, does kind of tolerate that slower problem solving, more methodical abstract method kind of thing. You know, I think that I've realized that for my personality, this kind of, you know, I've realized that for my personality, this kind of company probably works out really well. It's not soul sucking for me at all to, to be one of a large group, but I can imagine that. So, so I guess all that to say, I don't think that you have to place your happiness necessarily on a scale of big company to small company, but I do think that that's a factor to your point, right? I think that it absolutely plays into, oh, this company is going to be a big company. This company really needs my contribution. And I think that we, we all really want to feel necessary, not just necessary, but like we're actually contributing to something with our work in that we can't, we aren't just, you know, you can't just rip me out and replace me very easily. Even in a big company, I think you can still find roles that fit that description. Yeah, I think that's true. And, you know, I, I certainly don't want to claim that my, anything about my experience or, or even my preferences are universal. Mainly, I just think, you know, that's a, a path that I wish was, I'd known was available to me. And I totally agree with you by the way, about like early stage startups and not having a lot of time to sort of, yeah, like try to do things like in a, in the, like the nicest way possible, or, you know, like a sort of, it's really tough to balance making, like long-term investments in your code. And when you're like, well, we only have like 18 months to live. So how much do we want, how much time do we want to spend investing in a future that might not exist versus making sure that that future will exist, even if we've got a lot of duct tape and bailing wire, you know, along the way. And that's, that's absolutely not for everyone. And I, I, I wouldn't want to pretend that it is. Right. Oh, no. I mean, I think some of it is, is this question of like, you know, like, you know, like, you know, like, you know, like, you know, like, you know, like, do you have the headroom to even ask the questions of what kind of tools should we use for this? Yeah. I think a lot of startups, it's a foregone conclusion that we're going to use one of three, you know, like there's no, there's no negotiation happening. Nobody's going to be presenting slides on which tool to pick because that's a huge waste of everybody's time. Right. When actually maybe in the long run, it wouldn't necessarily be, but it's too risky. Right. It's not that it's the wrong decision. It's the wrong decision. It's the wrong decision. It's the wrong decision. It's just that it's such a risky decision, even if it has a very high return rate or potential return rate, the risk is just not bearable for, for a startup. Yeah. And another thing I've noticed though, is that at larger organizations, so, so now, you know, I've been with the same company for seven years now, which is NoRedInk where we write a lot of Elm code. And, and I've, over the years I've gotten more and more involved in sort of like technology decisions that sort of affect the whole company. So my, my title right now is head of technology. And so I am, I'm dealing with exactly those types of issues now. We're trying to figure out what long-term investments we should make. And in particular, like facilitating the sort of the process of change that involves like, you know, transitioning from what we're doing now to something that we think is going to pay off. Because now that we've been around long enough, you know, we, we're not worried about dying in 18 months. We're, you know, a lot more stable and self-sustaining, but I mean, there, there definitely are their own set of challenges that come with that. But one thing that I have kind of learned is that it's not really feasible for every single person in the organization to have sort of an equal amount of say for that, as much as we might like to do that. There's always going to be people who have, you know, more like longer tenure at the organization. And it's, you know, I have never seen an organization that can sort of, counter that even if they wanted to. Yeah. Yeah. That, that really matters if you're sort of early on in your career, because I don't think that I could have gotten like, let's assume that I were qualified for it, which I don't think I was, but I don't think I could be doing the role that I'm doing now. At that earlier stage of my career, like if someone had dropped me into a company and been like, Hey, you're going to help us facilitate, like figuring out what our long-term technology, you know, investments should be like, which things, which technologies we're going to go with. And also help figure out how we're going to make a plan for transitioning, you know, while still building stuff from whatever we're on now to whatever we think is going to be, you know, a better bet in the long run and pay off for us. That type of work, I think, not just requires expertise, but also, I mean, trust. Like, you know, if I say, you know, based on having talked to all these different stakeholders within the company, this is the way that we ought to go for this new project or whatever, that requires a certain level of trust and buy-in from people. And if you're sort of new to the company or new to the industry, it's a lot harder for people to have that trust in you and a lot easier for people to second guess and say, you know, maybe you get partway through the transition and it's, you know, the going gets tough sometimes and people say, you know what, why don't we just go back to the thing we were on before? Because at least we know that, you know? Yeah. I don't know if that would have been a good choice for me back then, but I'm also quite happy doing that now. It's a different set of challenges than what I had before. But they're still fun challenges. Yeah. It's humans are much harder to work with than code is sometimes, right? It's interesting. I think we could talk for, I don't know, a whole nother interview about the concept of trust and what it really means. You know, what does it mean to trust another person? You know, the kind of mechanistic view of trust is the idea that we can forecast the most positive possible futures from this person, right? You trust them means that you expect what they say is they're likely to stay in line with. And there's all these things that we could define as trust. But then at the end of the day, a lot of our judgment of trust is not that mechanistic. It's much more of a feeling or kind of a sentiment. And we don't really have these, you know, long notebooks worth of data to determine if we trust a person, right? Mm-hmm. We're drawing off of a limited set of experiences and, you know, potentially a limited set of data or even a skewed set of data. It's such an interesting concept because it really changes so much about our jobs. And very often we discount the complexity of those types of problems. And I do think that as we grow in our careers, we start dealing more and more with the people problem. And I think that's a really interesting concept. The people problem side. Yeah. Gabriel Weinberg actually says that every problem is a people problem. And I think that's true, you know, if you think about even the design of a language like Elm, it's not that the underlying languages have somehow fundamentally, we didn't change the structure of computation altogether. We changed the way that we interact with them. And that's a people problem. It's expressed in a technical solution, but it still is ultimately a people problem. So I think that's such an interesting role that you find yourself in now. And I can't wait to hear more and read more from you about your kind of navigating through that head of technology versus the other side of the coin of technical problems. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. that that was something that was out there that i could i could choose to do so yeah i think number one thing is i would have gone back and told my younger self like hey you can use languages that are outside the mainstream just you know go and look them up here's a handful of names you know elm closure haskell fourth prologue um what have you go google these things yeah right just and just you know read read their like intro to the language see what it's about and uh and maybe download it and play around with it for an afternoon and see what you think of it um you know read the official guide and then you know if if you like it you know then i don't need to tell you to keep doing it you just will want to keep doing it right it's kind of interesting uh and then the way i've i've looked at languages uh is is you know you don't have to use a language to know it or i guess a better way to put that is sometimes languages are just as good as a tool for thinking as they are for for building things and i think that's um that's a good way to say okay hey is there another way to think about this problem how would i approach it in this totally other you know different language that we're not going to adopt anytime soon but maybe it's going to enlighten a different path of thinking for me that i wouldn't have otherwise discovered and that was that kind of gave me the uh i guess license to go and learn these languages that i knew i was never going to actually take to production you know at least at the company i was working at and i think that's a good way to say okay hey is there another way to think about this problem how would i approach it in this totally other you know different was that right we have a huge ruby stack and it's like well what would happen if we implemented this with i don't know like you said small talk okay uh this particular problem would look like this xyz whatever and that would help me think through the problem in ruby differently i guess small talk and ruby are kind of probably not a good uh comparison but uh well i mean they're very like mats was extremely yeah yeah yeah so maybe i should have picked something like a functional language or something but um but yeah so so thinking about it thinking about these languages more as dialects of of thinking um rather than you know oh if you learn this then you better be you know ready to go and use it you know for real right like um and and i think the the wrong language that we often use is we're learning it for fun right and and that's fine i think it's okay to learn something for fun too but when you learn things they're all kind of playing off of each other and sometimes it's just as good to learn something for fun for your career as it is to learn it you know for serious i don't know what the opposite of learning for fun is but um for misery i don't know um but uh i think i think that's a uh it's one of the most consistent things that i hear from programmers like you uh from successful career-long programmers is that they engage themselves with languages not necessarily because they have a specific problem they're trying to solve but because they're trying to expand their way of thinking about working with computers well yeah i mean i'd say whatever your motivation is for trying it i think the main thing is to try it um and uh and not just to you know think about it or or like read a blog post about it but to actually like write some code in that language and and and and and and and and and and and and and and see what it feels like and i think that's uh that's where you get the most benefits is from the the actual doing uh of of trying it out for real last question and then we'll wrap up um thank you again for your time today richard i appreciate it yeah what do you wish more people would ask you about what do i wish more people would ask me about hmm it's a great question uh i wish i'd uh i wish i had a chance to ask you about what do you wish more people would ask you about um and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and exposed to more languages over the years. But I maybe I wish people would ask me that just so I could talk to them about it, because I like talking about it. But it's not necessarily something that everybody wants to hear. And it's also not necessarily a quick answer, you know? Yeah, it's not like something you can go and sit at a bar, or I guess right now, we're not going and sitting in bars anyway. But it's not something you could talk about just, you know, off the cuff. I mean, I certainly can't, it would just, you know, we'd need another hour. Yeah, that makes sense. So if somebody was to run into you, let's say in a virtual conference these days, they could ask you, you know, what is the latest resource that you found, or an interesting, maybe a book or something on that subject of language design, and have a good conversation with you about that. Yeah, I guess one topic that I think is very interesting and very under discussed. So maybe maybe this is the actual answer to that question is the intersection between programming language design and API design. So that's like the standard library of the language. And like, what does that encourage? And how does that connect with the language itself? And furthermore, things like, how connected are they? Some languages are, like, didn't originally necessarily have a standard library, maybe they just had some like built in functions. And then later, they got a standard library, or maybe early on, they had something you could call a standard library, but it was very, very small. And there was like, de facto standard library that emerged later, I would say, actually, that's true of JavaScript, where, like, for a long time, jQuery was the standard library for JavaScript, I would argue, because the one that sort of shipped with the language was so small and not, you know, useful enough for the purposes that people wanted to use the language for. And then jQuery actually influenced the standard library. And people on the jQuery team ended up actually becoming, you know, part of the JavaScript core team and that kind of thing. Oh, sure. Yeah. And I think, like, an interesting example of how these things can evolve over time, and how they can influence each other is, is a smoosh gate. I don't know if you remember this, or heard about it. Oh, yes. Yeah, like, the, the, the, They wanted to use the term flatten for a standard library function in JavaScript. But because JavaScript had gone so long without having certain features that people wanted in it, and because JavaScript as a language allows you to override the prototypes of global objects, there were websites out there which already had overridden the array prototype to have a method called flatten, which did something slightly different from what they were planning on doing in the standard library. And because of those two factors put together, they couldn't actually implement the standard library API design that they wanted, which was to call it flatten. They had to pick a different name. They ended up going with flat. But people were joking at the time, like, well, if you can't call it flatten, why don't we try smoosh? Or, you know, that's not taken. And this is the type of thing that can, it's only possible for that to happen because of the two factors that, one, the standard library's API early on didn't include a lot of features that people ended up wanting. And two, that at a language level, JavaScript does allow these things to be overridden. Those two factors put together allowed this problem to happen. Whereas in a lot of other languages, they wouldn't, you know, you would not have a smoosh gate because either you would. You already have something like that in the standard library and it wouldn't be a problem. Or you wouldn't allow that type of, you know, prototypal inheritance or overloading to let people sort of compete or clash with the standard library's namespace for things. So I think a lot of things like that are sort of under discussed. And they're sort of things that we take for granted because, you know, we're using languages where, oh, well, of course that's possible. Of course, that's a problem that can happen. Whereas in a lot of other languages, like for multiple reasons. Problems like that just absolutely can't happen. Yeah, it's funny because coming from Ruby world, if you're familiar with Ruby, you know that you can open a class anytime and change it. You can do this multiple times. So you can override, you know, even very base level methods that you would otherwise expect to be to work a different way. And you can have like lookalike classes that essentially are kind of aliasing up to the. Underlying class, but you're adding some new methods. And we had a lot of this going on when I was at clear a bit. And it's funny because there's all of these kind of institutional knowledge that is carried with these different object types. This happens a lot, a whole lot. And actually, it's funny you bring up jQuery because it's very similar to the way that Rails changed the way people think about Ruby. Yeah. So it's a lot of methods that Rails, some of the action, it's been a while since I've worked with Rails. So, but they added a bunch of methods to, let's say, like the base string. Right, right. And now people are expecting that to work in their Sinatra project or something. Right. Or Rails says, oh, you know what? That's probably a bad idea to include by default. Let's pull it out and make it opt in. You got to add the gem. And so suddenly there's a bunch of stack overflow posts about why is this string method not working? Well, Because it's not there. It's not a part of the, in the same way that a lot of people are asking, why isn't, you know, why is dollar sign doing something totally unexpected? Well, because you don't even have jQuery on the page. You're using the new dollar sign thing that Chrome implemented or whatever. And so it's all these weird clashes between kind of what we expect or maybe it's the wrong encoding that we have in our head that this tool has become so ubiquitous. At the very least, you may haveension of bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing these things together and bringing things in the standard library, everybody has the same experience. And that's an example of one of the contributing factors to how you get to if it compiles, it just works. But we wouldn't necessarily think of that. It's like, oh, well, how does Elm achieve that? It's actually by subtracting features that break that. And it turns out if you don't include the language features that lead things to break, number one, you can find that things break way less often than you're used to. And number two, you might be surprised that actually the language still feels very ergonomic. It's maybe different than what you're used to. But the ergonomics are great. I mean, I'm happier writing Elm code than any other language. And yet, it's also a lot more reliable and easy for me to make changes to. So I think that's an example of that intersection between API design and language design. If those are designed to complement each other really well, you can get pretty surprisingly different and surprisingly great results from it. Yeah. One other thing I was thinking, and then I promise we'll wrap up. This is just such an interesting conversation to me. Is the way that we think about, and I know when you say API, you mean kind of the language API, but we also have this other kind of looming thing out there, this big REST APIs that we all use and we all consume. What's interesting to me is that what we call REST, very often it's not proper REST, but regardless, these resources that are out there on JSON endpoints, how much that has probably influenced the way we think about data consumption, about object modeling in general. We think very much so about objects as, you know, these buckets of data that we can go and get, those resources at some endpoint. And I wonder, you know, of course, now we have, there's some newer kind of thinking around how APIs can work, for example, with GraphQL, that might be breaking a little bit of the way that we think about JSON endpoints. How is that going to change the way we think about the language design? And I'm curious about your thoughts on that. But I know that's interesting. That's a huge question. Yeah, I mean, so the first thing that comes to mind is that I think part of the original vision for Smalltalk, going all the way back, like, so the term object-oriented was coined by Alan Kay in the 1970s. He was the original designer of the Smalltalk language, which was the first language that sort of self-described as object-oriented. Simula had objects, but didn't use the term object-oriented. So the idea behind object orientation was originally to say, let's not use objects for simulations, which is what Simula did. Let's use them for everything. And so part of Alan Kay's interest in this idea of object orientation was that he really wanted things to be dynamically reconfigurable on the fly. So you could have an operating system where every aspect of the operating system could sort of talk to everything other using message passing, passing immutable messages, which they weren't in JSON literally, but you can imagine just... Picture a different JSON, a format that it has the same characteristics as JSON, but it's a different syntax. And that would be how you did everything with this message passing. And that would mean that if you wanted to, you could have one part of your system could sort of change its code and then start accepting new messages and sending new messages. And you could potentially rebuild entire large chunks of your running set of programs on the fly. At the same time, you may have toension yourensionijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij could look at it is that um object orientation really did not end up panning out that way in practice uh like i mean other than small talk like still the original system um that was designed this way uh even like ruby which is very small talk inspired you know you don't see really ruby being used in that way um today with like all this like dynamic runtime reconfiguration and stuff like that really the the place where you see that is in um you know web servers talking to one another via protocol like json or something like that and so what's interesting to me is that um we think of it today as you know talking talking over rest with json is kind of the way it's always been done and can you imagine a language where that was a first class concept in the language and you know we had like the automatic serialization and we could talk to these players and they were like oh you know you can't do that you can't do that you can't do that these other things, you know, that's small talk. Like that, it's not a new language. It's actually an old language. It's not something new coming up on the horizon. It's actually like where a lot of these things started back in the early days of networking that, you know, that predated the worldwide web itself. Like they were doing that, you know, earlier than that. And so maybe another question is, well, I think two valid questions to ask there are one, is that actually something that we want to pursue is like language level support for those things? Is that actually a good idea? Or is small talk maybe a cautionary tale in that regard? Sure, there are lots of small talk fans who would say, of course not, you know, small talk was great. It just didn't succeed because of small talk images or something like that. But I think another way to look at it is if we do think that that is the next step is to try and make like data fetching from, you know, between clients and servers, or maybe servers and other servers more integrated at a language level what lessons can we learn from small talk? Like, can we go back and look at, you know, when this was the goal and we actually did experiments around these things, how did those experiments turn out? What worked well and what didn't? And is this maybe in an Elm-like way, something where we can actually learn a lot from past languages and do a much better job because of it, as opposed to, you know, being perhaps unaware of some of the experiments that have already been done and sort of planning to do a lot of research on them. So I think that's a good way to look at it. Yeah. Well, that's, so in other words, there's nothing new, apparently under the sun, right? We've got all these interesting tools. I think there's plenty of new stuff, but I think it's, maybe the way I would say it is that there's a surprising number of things in programming that have been tried decades ago that have faded from memory or faded from like popular memory. Yeah. Yeah. And it is definitely, you know, there's so much we can learn from the people who are thinking about these things or were thinking about these things 20 or 30 years ago, often because it was a much more kind of pure problem environment. They didn't have so many different things going on. They could think very clearly about, you know, one or two problems and then express those problems very succinctly. I think that was one of the interesting things about the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, the earlier, is that we didn't have these large kind of tangled environments to work with. It seemed to be the norm now. Yeah, I mean, they had a... I would say they had a different set of problems to contend with. Like now we can be like, oh, you know, what's your server running on? It's like probably Linux. And if it's not Linux, it's definitely Windows or macOS. Or like maybe FreeBSD if you're really exotic. Whereas back then they were like, well, we've got our 20-bit systems and our 10-bit systems and our PDPs. There's just like a lot more platform-specific stuff. Yeah, DevOps back then was definitely a nightmare. Right, they're like our operating system is about 12 lines of code, but that's just for the one of the 12 different pieces of very specific hardware we might be targeting, which is not a problem we have anymore today. That's true, yeah. Well, Richard, I appreciate your time so much. And... Certainly would like to direct people to the book that you wrote with Manning, Elm, and Action. Yes. And what else can people learn about you? Or where else can they find you online? You know, what do you want people to know about your work? Sure. I'm on Twitter at RT Feldman. I have also done a front-end master's course on Elm. So there's a beginning Elm and also an advanced Elm course. The beginning Elm course has... Significant overlap with the book in terms of like both of them are basically like, if you don't know anything about Elm, you don't know anything about functional programming, maybe you know some web development. This will get you all the way through building a complete single-page app in Elm. That's true of the book as well as the front-end master's course. Although the front-end master's course doesn't go into quite as much depth as the book. But the advanced front-end master's course, you know, is maybe something if you get farther along in your Elm journey and want to kind of pick up some advanced techniques. That's maybe something to circle back to. Other than that, I've also given a bunch of talks online. So if you just put in like YouTube Richard Feldman programming, you'll find a bunch of talks. One of which, actually two of which are get into some of this like history of programming language stuff. So one of those is called, why isn't functional programming the norm? That one really blew up. It's like 600,000 views last time I checked. And although maybe by the time you're listening to this, it'll be more, who knows? And the other one is the next paradigm shift in programming. So those both, might be of interest. I've also given a lot of talks about Elm. So if you just search for like Richard Feldman, Elm and YouTube, find quite a few talks about me talking about Elm, either at Elm conferences. I actually spoke at the first nine Elm conferences. At the 10th one, I emceed it, but I didn't give a talk. So you still spoke, but just, yeah, that's true. That's true. I guess in that sense. So I have a lot of like, but those are all for an audience of people who already know Elm. So probably you'd want to go for some of the non like Elm Conf, Elm Europe, Oslo Elm Day. What else? Elm in the spring. Those conferences are all like for people who already know Elm, but at other conferences, like done like reactive conf several times. And yeah. Excellent. Thank you so much, Richard. And I appreciate your time here on Developer Tea. We'll talk to you soon. Thanks. Another huge thank you to Richard for joining me on today's episode and the last episode of Developer Tea. Once again, if you didn't get to hear the first part, go back and listen to that to make this session. The second part make more sense. Thanks again for listening to this podcast. And of course a huge thank you to today's sponsor Linode. Head over to linode.com slash developer tea to learn more about your hundred dollar free credit, just for being a listener of the show. As always a huge thank you to the producer of today's episode, Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea. Bye.