Molly Struve shares her approach to ensuring that projects are performant, reliable, and well-documented.
To executives, new features mean more money, but even if you had terrific features, they wouldn't be worth a thing if they only worked half the time. Reliability isn't something you want to put off until later after the project has grown, it will save you a lot of time and money if you factor it in from day one. Everyone has adapted to a speedy internet these days. Users leave if the site is taking more than even a few seconds to load.
It's easy to get overly focused on features while losing the context of the overall application. The first and foremost solid you can do future you is to keep things as simple as possible. Never get overly complicated, that's where you run into scaling troubles. Complexity also causes significant headaches when bringing other people on.
In addition to keeping complexity low, make sure documentation gets written and that it's kept up to date. A solution that Molly's company has put in place to keep the docs fresh is to give every document an expiration date three months out from when it gets written. When someone references the docs, they check if it's past the expiration date, if it is they go through and make sure that the information is still current, and afterward extending the expiration date another three months.
"Build Performant And Reliable Applications With Molly Struve" Transcript
"To me, a site reliability engineer is a software engineer, but with their focus on performance and reliability."
"So, it's a dev, but they've got a little bit of something extra in there that just helps them kind of step back and look at the whole system and ensure that it's performing and reliable."
"There's only so much you can just attribute to the black box. Sometimes you actually got to go in there and figure out what's going on."
"You can have all the great features in the world, but if they're only working 50% of the time, none of your clients are going to be happy."
"A lot of times, if you're just focused on just the feature you're building, you'll lose the context of the overall application."
Joel Hooks: Hi Molly.
Molly Struve: How's it going, Joel?
Joel Hooks: It's going great. How are you doing today?
Molly Struve: I'm doing good.
Joel Hooks: So, I'm really excited to talk to you because lately it seems like, over the last year or so, I keep hearing this term, site reliability engineer, or SRE, and a you are a lead SRE, and I wanted to find out more about that, but I kind of wanted to break the ice and ask you about your relationship with horses and what you do outside of that, because I don't know a lot of people that interact with those fine beasts, and I was wondering how you got into that and what that's all about.
Molly Struve: Yeah, that's actually quite a common reaction I get when I say, "`Oh, by the way, in my free time I ride horses." [inaudible 00:00:44], "Oh, wow. How'd you get into that?" Honestly, I've been riding since I was five years old. My aunt got me a riding lesson and the rest was history. I kind of fell in love and I've been doing it ever since. So, it's something that gives me a nice break away from the computers, and it's outside, and the fact that you get to work with a live animal is also super rewarding. So, it's something I've enjoyed my whole life, and lucky for me, it's kind of a lifetime sport. You can do it well into your 60s, 70s, I've seen 80-year-olds ride. So, it's something that I can do for the rest of my life, which is nice.
Joel Hooks: And you have your own horse, or horses.
Molly Struve: Yes, horses. So, I'm very lucky, my in-laws are also into horses, and so, I ride a lot of theirs and yeah, it works out great.
Joel Hooks: I understand, like if you spend a lot of time with them, I mean, there's a relationship, right? They're intelligent animals, and they know you, and respond to you, and that sort of thing. Is that true?
Molly Struve: Exactly. When you're out there, it's not like a bike, where you buy a bike off the shelf and it's going to respond to what you say. When you go out and look for a horse, it's kind of similar to looking for a house. You got to look for one that meets your needs, that is going to get along with you. It's a team sport out there, it's you and the horse, and if you can't communicate, you could have the best horse and the best rider, and if they can't get on the same page, it's going to be a disaster. So, it's definitely kind of fun to experience horses and their different quirks, and figuring it all out.
Joel Hooks: Yeah, I mean, it's like any sort of of animal companion is kind of that way, right? If you don't match, then you kind of have to just live with each other, and it's no good [crosstalk 00:02:25].
Molly Struve: Exactly.
Joel Hooks: They don't like it either, if they don't like their human, I imagine.
Molly Struve: Yeah.
Joel Hooks: So, what is a site reliability engineer? What's an SRE?
Molly Struve: To me, a site reliability engineer is a software engineer, but with their focus on performance and reliability. It's also usually a software engineer that has some other little area of expertise, so you could think of maybe a software engineer who's really good with MySQL, and really good with databases. Maybe they're really good with Linux. So, kind of the way I like to describe it and also how our operations describe it is a developer plus. So, it's a dev, but they've got a little bit of something extra in there that just helps them kind of step back and look at the whole system and ensure that it's performing and reliable.
Joel Hooks: Does it have anything to do with, like, we have DevOps, right? Is being an SRE, is it somehow related to to DevOps, or would that be like the plus that maybe you have as an SRE?
Molly Struve: So, I would view that, my opinion personally is that that would be the plus. I view site reliability engineers as basically, like I said, software engineers, but their focus is different than delivering features. DevOps to me always was less coding and more on the operations focus, so that's kind of how I see the difference between SRE and DevOps. Now, there are some people that just, they lump them all together and they assume that it's the same thing. My view is that the SREs are much more software-focused to solve problems, where DevOps is kind of more operations-focused.
Joel Hooks: So, I know you went to school and you studied aerospace engineering, so I know you didn't necessarily look at web development as your path, and I assume you obviously didn't look at being an SRE as your path, but how did you go from getting into web development to becoming a site reliability engineer?
Molly Struve: So, like you said, I started in web development and started as a software engineer, and basically what happened is I joined Kenna four years ago, and when I joined them, one of our lead engineers, who was in charge of Elasticsearch, left. So, I saw that as an opportunity to kind of grab a little piece of real estate there and take ownership over something. So, I grabbed onto Elasticsearch, I learned everything I could about it, and over the two years, I became the residential Elasticsearch expert. Because Elasticsearch is such a cornerstone of our platform, I naturally found myself doing a lot of those tasks to improve performance, to improve reliability, to ensure that we could scale.
Molly Struve: So, as our team grew and we started realizing that we were going to have to break up our one single dev team into multiple, our VP came to me and said, "Hey, you kind of are already doing this. What do you think about forming a site reliability team and working on that?" And of course, since it's something I enjoy, I enjoy those performance improvements and finding those ways to make things scale, I naturally said yes, and since that, for the past almost two years now, I've been a site reliability engineer.
Joel Hooks: So, there wasn't a team already, and it was kind of built around the... I mean, I feel like people recognize the need for these sorts of things as you grow to a certain scale, like a five man shop probably isn't going to have an SRE team. So, it grows out of time and necessity, I would assume.
Molly Struve: Definitely. So, it's definitely something that grows, for us it grew out of need, and that's kind of one other thing I like to touch on is sometimes people view SRE as something that only giant orgs have. So, because Google was kind of the one that coined the term, some people think, "Oh my god, you got to be a big Google company before you have an SRE team." But I don't think that's the case. Kenna, when we broke off, our SRE team probably had 60 people, and 20 or so of them were engineers. So, we weren't that large. Ever since we've kind of broken off, my view has been you're never too small to have an SRE. It doesn't need to be a full team. It doesn't even need to be one person's sole job, but there should always be someone on a team that is focusing on those SRE things, those things like performance, those things like reliability. It's never too early to start thinking like an SRE when you're building an application or building a company.
Joel Hooks: I kind of see the SRE, when I use my mind's eye, as almost like a firefighter, but it also feels like that's probably, while part of the job, not necessarily the full job. What else, besides the firefighting, the having the pager go off, which I want to get into a little bit too, what does the SRE do outside of that to maybe prevent fires, I suppose?
Molly Struve: One of the big things is you're the one that has the performance and reliability kind of on your mind all the time. So, one of the things our site reliability team does is, a lot of times when PRs from the main dev teams who are working on the features go out, we'll review them, and we are not necessarily looking for, okay, how correct is the feature or does it work properly, but we're in there and we're looking at the database requests. Are these going to be performant? Are we looping through all these records in MySQL when we don't have to? So, one of the things we do is we're looking at code and making sure all the code going out is going to be performant and going to be able to scale.
Molly Struve: In addition to that, other things that we work on are things like monitoring any tools, creating tools, or doing things that are going to help us scale in the future. So, we're really thinking ahead and trying to get ahead of those firefighting things when they occur. So, ideally, we would design everything and be a step ahead and we'd never have to firefight. That's not really the case all the time, but if we can prevent that as much as possible, then we're doing our job.
Joel Hooks: So, last week Egghead actually, we had our sign-in form just attacked, like there were like some sort of botnet or something just attacking our form. Is that the kind of thing that a site reliability engineer would focus on, too? Is the idea of external forces coming in and taking you out of the norm, like taking you out of your normal day to day?
Molly Struve: Yeah, so that is something our SRE team does, but also the devs need to be aware of that as well. But we actually, it's funny you say that sign-up form, because we actually had a tester come in and see what would happen if they signed up a thousand clients, and it backed up our email. And so, that was something where we had to jump in and be like, okay, how do we flush this email queue and get everything back to normal, and then how do we handle the situation where, okay, if someone comes in and maliciously tries to sign up a thousand users or whatever, how do we handle that? So, that's definitely something that is on our radar, but also is not exclusively SRE. The devs also are kind of thinking about that as well.
Joel Hooks: When trying to make lemonade out of the lemons, I said, "Well, we got testing for free, and pen testing is expensive." They were signing up 6,000 emails an hour.
Molly Struve: Ooh.
Joel Hooks: Yeah, it was interesting. It was fun for me. I guess we're a very small team, so I kind of end up being our site reliability engineer sometimes. It's like a puzzle, but then it pops up and you're also like, "Well, is this going to just ruin the entire business?" I'm a big fan of this entire concept of being a reliability engineer, I think it's great. What's the path, is it just, you said pick a specialty, and I'm kind of wondering, if somebody's in a position and they don't have an SRE team, how do you pitch that or what's kind of the dev boots on the ground sales pitch to form an SRE team in an organization?
Molly Struve: Yeah, it's definitely, it's one of the hardest things to pitch because usually the upper execs, they see features and they see features translate into dollars. But what SRE translates to is it translates to reliability in the platform. It translates to, as a lot of people say, the nines. You can have all the great features in the world, but if they're only working 50% of the time, none of your clients are going to be happy.
Molly Struve: So, luckily for us, kind of early on we had scaling issues, so when the idea came up to have an SRE team to get ahead of further scaling issues, it was easier to sell, mainly because we had had the scaling issues in the past. Ideally, you want to get ahead of the scaling issues and kind of get the SRE mindset going even before, but it's the fact that you have to basically push that performance and reliability, especially in this day and age.
Molly Struve: The expectations for websites are so high these days that if you're not performant and reliable, people write you off. It's like when you go into Instagram or something, if it kind of starts freezing on you, if you have to wait two or three seconds to click around, I mean, you're going to probably shut the app and assume that it's buggy, or come back at a later time. So, these days you definitely have to make sure the performance is there if you want to keep those users.
Joel Hooks: Yeah, I often think of Google.com, the primary search product of Google, and how just lightning fast it is all the time, every day, and it's giving you results that are contextual, it gives you all sorts of different components, and everyday it's just lightning fast, and if it wasn't, their core product would be fundamentally broken.
Molly Struve: Yeah. And you can even think about it, if you get on a slow connection and you Google something, because the connection is slow, it takes a few seconds, and it's amazing how adapted we are to the speed of the internet these days, because when things slow down, you're like, "Oh my god, oh my god, I can't deal with this. I have to wait so long." It's so noticeable just because we're so used to it being so fast.
Joel Hooks: So, one of my favorite quotes recently, I was reading the wonderful book from Will Larson-called An Elegant Puzzle, and he says systems generally won't scale past one order of magnitude of growth. I've heard from you on another podcast, that was kind of the case with the system that you work on, that you were growing, and your growth has been such that the system has basically had to churn out. I'm wondering, is that your experience, and how do you deal with that from a reliability standpoint?
Molly Struve: I would say definitely in the beginning, our system was one of those systems that there was no way we could scale by orders of magnitude. We have come a long way, even in the past two, three years, that because we focus so much on the reliability of the system and the performance, I have salespeople come up to me and they've got these big clients, and they go, "Molly, what do you think, how big can we go? How much data can you handle?" Right now, honestly, my answer is, "I don't know, keep shoving it in there." We've multiplied and we've increased our data by four times since we did a bunch of our ES performance improvements, and it hasn't slowed down yet, it keeps chugging.
Molly Struve: So, we're going to hit the next bottleneck at some point, and we do hit little bottlenecks along the way, and as we do, we figure them out. But I think if you have, like I said, that SRE mindset from the beginning, and you take care to build your code in a way that will scale, you can achieve and make an application that is going to be scalable or easier to scale in the future.
Joel Hooks: So, I've played with Elasticsearch a little bit, and we even used it in a production for a while and ended up just kind of punting. Now we use Algolia because we didn't have anybody that was dedicated to to running Elasticsearch. I was wondering, what is Elasticsearch and what is it used for beyond the obvious, being in its name, search. What is that tool, what's its primary function?
Molly Struve: Elasticsearch, as you said, its primary goal is for searching, but not just searching in the sense that you think, "Okay, I'm going to enter a word and it's going to tech search." It is able to do so much more, to build the sidebars that you see where you can select like, I want all tags with this, I want everything that's after this date, et cetera. So, those are formed using what Elasticsearch calls aggregations. And so, Elasticsearch has the ability to really just take your data, and you can slice and dice and run all sorts of different metrics on it, just through Elasticsearch, and it is incredibly fast.
Molly Struve: That's kind of one thing that has set Kenna apart from a lot of our competitors, is we give our clients the ability to really just break down their data in so many unique ways, and quickly. I guess other competitors, from what I've heard from our CTO who started the company, when someone runs a search on their platforms, it can take hours or days for that search to run, and what Elasticsearch does is it gives you the ability to run that search in a second or less, and at scale.
Molly Struve: So, it's definitely something that it is unique, it is extremely powerful, but as we found out kind of the hard way, it's one of those where it's easy to get started. You can throw a bunch of data in there, it stands up and it's fast, but to get it at scale, that is harder, and that's why I've written a blog post and I've done talks on scaling Elasticsearch, because that's literally what we did. We threw everything in Elasticsearch and it was fast when we had 500,000 documents. No problem. But when we have 4 billion, we had to be much more careful and much more cognizant of how we were using it. So, it's one of those, it's easy to learn, but it's hard to master.
Joel Hooks: Yeah, I mean, I got in there and over the weekend I was like, "Oh, look at this. I know Elasticsearch," and then over time it was like trying to maintain it, and something would break, or getting good results, or the whole thing. It's just impressive to me how it's used, because it's a wonderful tool and they made it really approachable for the first mile, but becoming a true expert in making it reliable and useful for specific use cases or specific business needs and outcomes, that's a totally different story.
Molly Struve: 100%, 100%. There's only so much you can just attribute to the black box. Sometimes you actually got to go in there and figure out what's going on.
Joel Hooks: I think maybe if you pay attention, that's true for a lot of these tools that we use, across the board, and actually is kind of the story of this field.
Joel Hooks: So, part of being an SRE, I think, that I would associate it with, anyway, is the the idea of being on-call of PagerDuty or even a physical phone attached to your job. I think that's associated in a lot of ways in a negative context and can be really grueling. Is that true? Is that part of being an SRE, is the on-call aspect?
Molly Struve: In my perspective, on-call is an aspect of every software engineer. And so, the way we do it as Kenna is it's not just SREs on-call, all the devs are on-call, as well as operations. So, it can be grueling, but the way we've set it up at Kenna is the SREs kind of own their alerts and their things that are going to alarm, and then the dev teams, on the flip-side, own other alerts that are kind of based around the code base and things that they've built. What ends up happening is that you end up with four or five people actually on-call at once. So, we have an on-call person for basically every team. What that does, is one, it gives you a lot of on-call reps.
Molly Struve: So, I think one of the things that can be grueling about on-call sometimes is if you don't go on-call a lot, you don't get a lot of practice. And so, you're not really comfortable when those alarms go off. So, one thing that breaking it up into smaller teams and smaller rotations does is it allows people to be on-call more often, which gives them more reps, and so they're more comfortable with it. And the second thing is because we have multiple people on-call all the time, no one ever feels like they're alone. There's no time where the alarms are going off and you have nobody that you can reach out to. I think that's gone a long way into making it a lot less grueling and a lot less tedious, because when those alarms go off and everything's kind of going wrong, the last thing you want to do is feel like you're in there alone.
Joel Hooks: Yeah, it's like stage fright and anxiety all kind of bundled up.
Molly Struve: Exactly. It's hard to get on stage by yourself, but if you spring three of your best friends up there with you, suddenly it's a lot more relaxing. And so, those are two things that we have done to really kind of make on-call suck less. And I've actually, I wrote a blog post on it because I think it's one of those things that a lot of devs find very stressful, and before we overhauled our on-call system, our devs hated it, and now they've completely bought into it, and they feel a sense of ownership over what they're supporting, and that goes a long way into making, like I said, on-call suck less, because it shouldn't be something that is a horrible experience. Sure, it might be hard at times, but you shouldn't dread it all the time.
Joel Hooks: Like any system, right? We can design our on-call system to be efficient and something that is useful and that nobody really dreads and it's just part of your job...
Molly Struve: Exactly.
Joel Hooks: ... or you can have something where it's essentially torturing and burning out a limited subset of your coworkers or employees.
Molly Struve: Yeah.
Joel Hooks: Yeah. So, if I want to build reliable and resilient systems, where do I start? If I'm sitting down to to build an app, what are the primary things that I need to take into consideration when I'm thinking about that?
Molly Struve: One of the first things, I think, when you're building an application, is first and foremost, as you're building it, you one, you want to kind of keep things as simple as possible. Never get overly complicated, because complicated code is where you'll usually run into issues in terms of scaling, and then in terms of when you bring other people on.
Molly Struve: In addition to that, as you're building an application, it can be very easy to kind of get into the weeds. You think, "Oh, okay, I got my application, I want to build feature A." So, you build feature A. Then feature B comes in. You're like, "Okay, I'm going to build feature B." So, you build feature B. Feature C comes in, you build that. A lot of times, if you're just focused on just the feature you're building, you'll lose the context of the overall application.
Molly Struve: And so, one of the easiest things you can do when you start building an application, is constantly taking a step back and looking at how all the pieces fit together, and thinking of that application as a whole. What that's going to allow you to do, it's going to allow you to think about things like scale, think about things like performance. It can be very easy to kind of get into the rabbit hole of thinking, "Okay, I got feature A that I want to turn out, and as long as feature A is good and it works, then boom, we're good to go." But at the same time, you need to be stepping back and be like, "Okay, we've got feature A, B, and C here. How do these all fit together? If they're all going at once, how does my database react to that? Can they all run together happily, or is there going to be some fighting over resources?" So, keeping that big picture in mind is kind of one of the best things you can do as you are building an application.
Joel Hooks: So, how does documentation come into this? I assume that part of the idea would be also to knowledge share, right? Like knowledge transfer. Is documentation internally an important part of this?
Molly Struve: Oh my god. Documentation is huge, and it's one of those things where when you're small, especially at small companies, you just don't think about it. You've got five of you standing around and your computers, everyone kind of knows what's going on, and so, you don't think of docs. We didn't start thinking about it at Kenna until we probably had 10 plus engineers, and we started bringing on engineers quickly, and at that point we realized that there was a lot of knowledge that was up in our heads that we then had to get to all these new hires, and having to tell new hires over and over again the same information is not ideal when you're trying to grow a team quickly. So, that point is, that's when we realized, "Okay, we got to start writing this down."
Molly Struve: So, what documentation does is one, it allows you to bring on people faster, and two, it avoids that issue of tribal knowledge, of having one person just have all of the knowledge in their head and it not written down. That's never good. You never know when someone's going to leave, you never know what's going to happen. And so, having that information written down is huge. And kind of one of the ways... I saw a talk at Ruby Conf last year, and this kind of helped kickstart us in terms of really getting our documentation up to date. One of the things the girl suggested was to put expiration dates on your documents.
Molly Struve: So, in all of our documentation, every document has an expiration on it and it's usually about three months out from when the document was written. Then it's the job of the developer, the next person that goes, if they look at that document and the expiration date has expired, it's their job to make sure everything on it is up to date and still relevant, and if it is, then they push the expiration date out again three months. And so, that really allows everybody to kind of participate in keeping docs up to date, and that, for us, has been huge in helping us one, keep the docs up to date, because we're growing and changing so quickly, and everyone's bought in to making sure we have sufficient docs.
Joel Hooks: I think for most people, the idea of documentation isn't a sexy or fun work that comes with being a developer, right? We all love puzzles, for the most part, developers I talk to like the puzzle aspect, and docs aren't really a puzzle, but they're so critical. I know we're a tiny team, and we have this handful of documentation, and when you go and somebody's no longer with the company or something, and then you go back and it's actually documented, it's like the most warming feeling, and the exact opposite is true when you go to something, you don't understand it, and there's no documentation, you just don't know what's going on. Everything is intentional in a system, every line of code was added intentionally by a human, and why?
Molly Struve: Exactly.
Joel Hooks: I know you have built some and work on internal tools, and there was something that really struck my interest that I've heard you speak about, and it's Mr. Radar. Can you tell me what Mr. Radar is and what that does for your company?
Molly Struve: So, Mr. Radar was built out of the need to monitor our data. We have your standard test suite, we have standard continuous integration set up, so every time code changes are made, we run the specs, we make sure everything passes, and then deploy the code. Well, as we were getting more and more data and more and more clients, we started realizing that our code working was only half the picture. The other half was the data, and making sure the data was correct. And so, early on we actually had some issues with the data being correct, and that is how Mr. Radar was born.
Molly Struve: What Mr. Radar does is it's basically a set of what we call antennas, and they run via a cron job in the background, and it basically goes into our databases and it checks on a bunch of different things to ensure that the data is correct, and anytime it finds data inconsistencies, it alerts us to those so that we can go and investigate them and figure out what caused them.
Joel Hooks: The impetus for building a custom tool, is it because there's nothing exists, or just the specific needs of your application and your users, or what motivates the building of a custom tool beyond just, like you said, you need to test for the data and whether it's accurate?
Molly Struve: What motivated it for us is that it was a pretty simple problem to solve. It really just involved, "Okay, let's make a couple MySQL queries here. If we get numbers back we don't expect, well, trigger an alert." So, it wasn't something involved that we really needed a lot of something fancy for, it was simple enough that we wanted to create it ourselves, and then we would have full control over it, and we could kind of tweak it and do with it what we pleased. And so, I think that's what drove us to create it ourselves rather than going outside and looking for another solution. At the same time, we were also really small at that point, so you kind of want to do things as cheaply as possible, and like I said, because it was a simple tool, it was like, we'll just build it ourselves.
Joel Hooks: I try to be cognizant of the idea of not invented here. There are good ideas externally and we don't have to invent everything ourselves, but sometimes it just makes so much sense to build your own tools, and then, specifically, for the control, I'm a little bit of a control freak.
Molly Struve: Yeah.
Joel Hooks: Sometimes I just want to have full control of my platform or the tooling therein.
Molly Struve: Yeah.
Joel Hooks: When is the right time to break things out of a system? As it grows, like your system's growing, you are building a large application, and you start breaking pieces off, whether it's a tool like Mr. Robot, or extracting something into an external service. How do you go about that thought process and deciding when to do that sort of activity?
Molly Struve: So, that, I think, happens... It's different for everyone. At Kenna, we have done it four times. The first time we did we had code written that needed to get rewritten, and it had a very specific functionality that was very isolated in our application. And so, that's when we decided, "Okay, we need to rewrite this code and it's already super isolated. Why not break it out?" So, I think that's one kind of indication that you might have a service on your hands, is if you already have something that's naturally isolated in your code base, it's not reaching out and touching a bunch of things, that's kind of a good indication, like, "Okay, maybe we could separate this."
Molly Struve: And then beyond that, a lot of it has been driven by performance and usability by the devs. So, usually when we hit a performance bottleneck somewhere, we'll kind of look at it... For example, say our main application, the deploys are taking too long because we have to deploy to 20 sidekick servers that are running. Okay. Well, what do those sidekick servers do? They're processing background data. Huh. Is that something we could separate so that our main application can deploy faster, and then we can do all of our data processing separately? When you get to bottlenecks like that, I think those can have a lot of impact on driving when you break things out.
Molly Struve: I'm definitely a big proponent of not over-complicating things and not just looking at a system and being like, "Okay, how many pieces can we break that into?" Because I think that leads to unnecessary complexity. I like when it happens more organically, and it feels more natural in that sense.
Joel Hooks: It adds complications to monitoring and being able to observe your overall system, like if you get into too tiny of pieces. It's like the right level of abstraction for the needs of the system, I would think.
Joel Hooks: So, to kind of switch topics here and close this out, what are your current favorite communities related to software development, on the internet?
Molly Struve: Oh, great question. So, my favorite is dev.to, and I recently started blogging on that back in December, and it's been fabulous. I've really enjoyed... Basically, the community in general is very approachable and just wonderful to work with. I've written some posts on there that were kind of hard to write and were very personal to me, and the response has been amazing. In addition to that, I also enjoy Twitter, which I think is kind of a surprise to a lot of people, because a lot of people think, "Oh my god, there's so much crap on Twitter."
Joel Hooks: It's true.
Molly Struve: But I think if you are really cognizant of who you're following and who you're not, it can actually be a really great experience. Don't follow people who are negative, don't follow people if they're like raging politicians or something. I think if you just really focus, and you follow those that embrace your kind of ideals, and tweet about things you're interested in, which in my case it's software. My Twitter is purely software-driven. You look on my Instagram, you're going to see all ponies and dogs. You look at my Twitter, it's going to be all software. So, I think it's kind of what you make it, and if you're really cognizant about who you're following, you can actually kind of have a great experience on Twitter, in my opinion.
Joel Hooks: I love Twitter, too, and I also love dev.to, but Twitter to me, and this is how I explain it to people who maybe have a better time on Twitter, it's like a bonsai tree, and it's your space. People talk about, well you don't want to live necessarily in a bubble, and I think that's true to an extent, but also, your own personal happiness is important, too. So, the extent that the bubble helps you and you get what you need and want out of it, that's it. You don't have to follow celebrities or politicians, or you can use it to follow your community, which is how I've always used it and enjoy it as well.
Molly Struve: Yeah, definitely.
Joel Hooks: Well Molly, I really appreciate it. Thank you for taking the time to talk with me today. It was truly a pleasure, and look forward to seeing what you're up to next.
Molly Struve: Yes, thanks for having me.
Joel Hooks: Cheers.