Test Driven Accessibility with Erin Doyle

At first, React looked like it might have been a fad, and JSX seemed weird. But, it didn't take long for people to see the power and beauty of it. React makes reuse easy, which makes accessibility a lot easier.

Every time you needed an input, you had to remember all of the accessibility attributes and write it all by hand. With React, you can make a reusable input with all of the accessibility built-in.

You must make your components accessible. There's a broader range of people who need accessible features than you might think. Most of us think of people with visual impairments, but they're also for people with cognitive, auditory, and motor skills issues.

We also don't think about the temporary issues that nearly everyone faces at some point in their lives, such as broken limbs, and medication side-effects. Accessibility features are even helpful under certain environmental conditions like exceptionally bright or noisy places. Even internationalization can be seen as an accessibility issue if your site isn't supporting all languages and localizing all dates. Accessibility is very multifaceted.

Try taking a test-driven approach when it comes to accessibility. Start with the low hanging fruit, static code analysis, and running a scan with a browser plugin. Then try to use your app with accessibility tools yourself, figure out how you can make it a better experience for your users. Finally, have real people with various disabilities test out your app and give you feedback.

Transcript

"Test Driven Accessibility with Erin Doyle" Transcript

Resources

• Aria in HTML
• Firefox: Axe Developer Tools
• Chrome: Axe Developer Tools
• Chrome: Lighthouse

Erin Doyle

• Twitter
• Github

Joel Hooks

• Twitter
• Website

Transcript

Joel Hooks: Hi Erin.

Erin Doyle: Hey Joel.

Joel Hooks: So I'm really looking forward to talking to you. I think accessibility is one of the key essential questions in software development right now, especially in the the web development space and you are a software developer and an accessibility cha champion. But first I wanted to get to know you a little and I wanted to understand maybe how you got started in web development to begin with.

Erin Doyle: Yeah, absolutely. So I don't know, just from when I was really young. I was one of the few kids I knew that like had a computer at a really young age, and I just loved doing stuff on the computer and figuring it all out. So when I went to school it was like, do I do computer science? I also was really into music, so I ended up going the music route. But I continued to take classes and tinker in my free time. And by the time I graduated, unfortunately I just finished a degree in something I decided I didn't want to do anymore and that I actually really loved programming.

Erin Doyle: So I found a job that thankfully allowed me to work on projects. They wouldn't hire me to become a fully fledged programmer without a degree. At that point of time you had to have the credentials and I didn't. But I was able to tinker and work on special projects, and prove that I could do it. And in the meantime went and got a Master's in computer science. And finally by the time I had that I was pretty much doing the job and was loving it. So it's something that I've just been jazzed about from the beginning.

Joel Hooks: So when you're a youngster, get into computers and exploring that, what drew you in? What was exciting to you at that time?

Erin Doyle: I'm not quite sure what it was, but they were just so fun, and I'd say even thrilling, like using a computer and maybe having to figure something out, or having to fix something was thrilling, once I did. And I guess maybe that's part of what I love about programming. It's this emotional roller coaster of like, "I've got a problem to solve. Either I need to do something new or something's not working, and I need to figure out how to get it to work." And maybe I bang my head against the wall for a little while and I get frustrated, and it's always just a matter of time. I almost feel like there's nothing we can't do, we just have to give it enough time and eventually you figure out the solution. And I feel like I'm a rock star. Like "Yeah, I figured it out, I'm awesome." And then you iterate, you start again.

Joel Hooks: I don't think there's nothing I've ever experienced in my life that took me from the highs of feeling like some sort of genius for a minute, to the lows of feeling like I'm absolutely incompetent quite like programming computers.

Erin Doyle: It's really pretty amazing like that. We really do have that constant bipolar nature to it. Yeah, you do go home at the end of the day sometimes and you're like, "Oh, I'm an idiot, I suck. I can't do it, so embarrassed." And then you figure it out, and like you said, you're like, "I am awesome. I am a genius."

Joel Hooks: Often after that night's sleep where you wake up in the morning with do your eyes popped open and going, "I know how to do it."

Erin Doyle: Yes, and it's amazing.

Joel Hooks: Yes, It's wonderful.

Erin Doyle: It is.

Joel Hooks: And I think it's that kind of feedback loop. It's almost like a puzzle, we're constantly solving this infinite puzzle. And there's so many rungs of mastery to climb too, which is awesome.

Erin Doyle: Absolutely, that's definitely a cool part. It's like no matter how long you've been doing it, there's still the times where you know nothing. Or you continue to make stupid mistakes, and there's always more to learn. So it's like we're constantly beginners, so it's really cool in that way.

Joel Hooks: I think it's interesting that you studied music. And I don't know if you've noticed this before, but I've talked to quite a few people that have gone that route. Where they studied music and got through their undergraduate degree, and discovered that that music probably wasn't going to be their career and switched to programming. And I was wondering, have you ever noticed any correlation or any similarities between those two disciplines that would cause that phenomena?

Erin Doyle: I have. I've definitely no known a number of people who had music backgrounds or music degrees and ended up in programming. And I don't think I've ever really put my finger on why those tend to be drawn to each other. Maybe it's discipline, you have to have an immense amount of discipline to be a musician, and that was maybe one of the things that turned me off. They were telling me I needed to practice five hours a day, and that was just more than I wanted to commit. But there's just something about the learning process, and the practicing and the dedication that...

Joel Hooks: The mindset that goes along with [inaudible 00:05:14]?

Erin Doyle: Yeah, I think that somehow those two relate really well to each other. And maybe like you're saying, the mindset, the thought process, somehow they do correlate well. And I don't totally understand it, but like I said, I've known a lot of people come from music backgrounds who end up in programming. It's pretty cool.

Joel Hooks: Mm-hmm (affirmative), it's neat. So what are you doing now? What's your job and what tools do you use?

Erin Doyle: So I work on a team that focuses primarily on e-commerce business to consumer retail application. We're in the gift cards space, and we re-wrote this application from scratch about three years ago with a new React-based stack. And that's when I started working at this company. So I'm a full stack, I've always done full stack which I really enjoy. I like being the jack of all trades, and I have to be okay with being master of none. But we cover... Of course accessibility has been a top priority of this application that we're primarily focused on. But it's got a lot of fun challenges. There's localization, internationalization, security, performance, all of those things. I think because it's e-commerce, we have to constantly be thinking about all of those things.

Joel Hooks: So you use React, and I was wondering how that's been for you as a tool, using react to build this? And a big rewrite too, so that's a significant improvement.

Erin Doyle: Yeah. So when I joined this company and they were starting this app from the ground up with React, I was coming from more of an Angular background. I was a huge Angular fan. And up until that point I was thinking, "Oh, React is just this fad." My first look at it was like, "Oh, JSX is weird, I'm not sure I like it." And it wasn't until I finally stopped, opened my mind, did some research on it, it didn't take long before I really saw the power and beauty of it.

Erin Doyle: And definitely as we started developing the app, especially from the beginning where you're still figuring out how you want to architect things. And you end up needing to move components around, or compose things differently. It was just so much easier to do that with React. I feel like the way you can architecture components makes reuse so easy, and it really makes accessibility easier, I found. You can create lower level, we call them primitives, so primitive UI-related or concerned components that have the accessibility built into them. And then you can reuse them throughout your application.

Erin Doyle: Every single time you need an input, you don't have to write all the accessibility around that input and remember what attributes do I need, and what do I need for this and that? You can build that into your component, and then it's just always there. And we've gone on to share... We've got a primitives library that we created, which the components are accessible. And they've also got styling built into them. And we've been able to share those across all of our React applications, so we've got consistent design across applications and we've got accessibility covered across applications. So it's been really helpful in that way.

Joel Hooks: So you teach accessibility workshops for web developers. And I was wondering, I'm sure this comes in part of the intro to a workshop, but what is accessibility? What does accessibility mean in terms of of web apps?

Erin Doyle: Yeah. So when it comes to web applications, we're talking about making sure that the web is usable by everybody. And a lot of focus ends up being put on people with disabilities. People who are blind, deaf, have cognitive issues, motor skill issues. But it really encompasses way more people than that. There are people who have temporary impairments, maybe you broke your arm. Or you're on some medication that makes your head foggy, so you have cognitive difficulty. Or maybe it's environmental, maybe you're outside and you're using your mobile device and there's screen glare, so the contrast is impacted. Maybe you're in a noisy space, so you can't hear something you're trying to listen to without subtitles.

Erin Doyle: Those things can happen to anybody at any time. And then as we age, we pick up various impairments with our vision, our motor skills, our cognitive abilities. So really at any point in time, anybody is going to be impacted by the web being inaccessible.

Joel Hooks: It's all of us.

Erin Doyle: Yeah, it's all of us at any time, and it's however we need to use the web. So whatever tools we need to use. If it's a screen reader, if it's voice control. If it's a Braille display, if it's switched selectors. There's an immense amount of assistive technologies and tools. Or even just strategies, zooming into the page to make it bigger, or using a high contrast tool. There's a lot of stuff out there that people need to use, so the web has to work in all of those ways.

Joel Hooks: Would you describe it as a full stack problem?

Erin Doyle: Well, I'm sure you could find a way to see it that way. If your performance is bad, if your response time from the server is not good, you're impacting people who are in an area that doesn't have good reception. Or maybe more impoverished area, where people can't afford computers and mobile devices with higher processing capabilities, so you're impacted people way. Even internationalization can be seen as an accessibility issue. If your site's not supporting all languages, and localizing all dates. And it's really pretty multifaceted.

Joel Hooks: Yeah, I was wondering when you could say, "Well, it's not my problem. I do this in this space, so I don't have anything to do with accessibility." But I have a hard time... Because like you said, it's like performance and it's such an integral part to how we [crosstalk 00:12:23].

Erin Doyle: Yeah, and I hear that a lot. I hear people say, "Oh, well I do this, so it's not something I have to worry about." I've even heard, "Well, our app is internal and we don't have anybody that works here with a disability, so we don't have to worry about that yet."

Joel Hooks: I wonder what... That's like a chicken and the egg problem, that sounds like.

Erin Doyle: Yeah. I heard a great story from someone who told being about a coworker that they had, that was using their internal app. And they didn't know that this person was colorblind, and apparently their internal app does not support high contrast tools, and it's not colorblind friendly. So they were talking to this person and they said, "Yeah, I actually can't see what's on that page, so I have to go do this extra thing in order to do this part of my job." And that person was amazed, they were like, "Wow, I didn't know that this was impacting someone here, because I didn't know they had an impairment or disability all this time." So you don't always know that someone's being impacted by a lack of accessibility. So even if being an internal app, you can't just say, "Oh, we don't have anybody that this is impacting." Because maybe you do, and you just don't know.

Joel Hooks: I think a lot of times folks that are, for lack of a better word suffering, don't want to be complainer's and they don't speak up all the time, right? They're just used to it, and used to our world being inaccessible to them, so they have all these work arounds that that are a huge cognitive load for them and extra work that they [crosstalk 00:14:02].

Erin Doyle: Yeah. When you actually experience using the tools or the strategies that people have to use and you experience various websites and applications from their perspective, you learn how painful it really is. And I think that they do, they get used to a certain level of things just being terrible all the time.

Joel Hooks: So what initially drew you into this world of trying to make web applications more accessible [crosstalk 00:14:35]?

Erin Doyle: Yeah. I wish I could say that it's just because I'm a really altruistic person that cares about my fellow human, and of course I care about my fellow human. But what got me started was just that thankfully my company that I work for now made accessibility a priority. And up until then, I didn't know anything about it really. I'd never worked for a place where it was a priority, and I just had no concept of how many people in the world are impacted and in what ways they were impacted. I just didn't think it was that many people. I just thought, "Oh well, I guess if you're buying you can't use the Web," which is really naive.

Erin Doyle: So again, thankfully this application that I work on now when we started it, accessibility was top priority. From the beginning, from the ground up, we wanted the app to be accessible. And because my company does e-commerce, they recognize the importance of we want everybody to be able to check out, we want to make money. And we also want to avoid lawsuits, and they're very real. So that was a priority for our customers, and that was a priority internally. So I just had to be tossed into the deep end and learn from the ground up, how do you make a website accessible?

Erin Doyle: It was a lot to learn, and what was really helpful... Finding tools that helped. And then we worked with a company that did auditing of our application for accessibility issues, and they actually have people with various disabilities impairments testing on the actual assistive technologies that people are using, and reporting findings back to us. So through that experience, they would give us a finding. When I use just the keyboard, I can't get to this part of the page. Or if I'm using high contrast mode this thing is invisible, I can't even see it. And that really opened my eyes to a whole range of groups of people that we were impacting that I didn't realize were impacted that way.

Joel Hooks: Yeah, actually testing with users essentially, that [crosstalk 00:17:02].

Erin Doyle: Yeah. So they taught us, "Well, if I'm a person who can't use a mouse, I'm going to need to use keyboard." And this is the expected keyboard navigation. There are patterns for how a widget should behave, certain keys on the keyboard should have certain expected behavior. And I had no idea. So it was definitely a lot to learn but a great experience.

Joel Hooks: And you mentioned tools, and I know you've been involved in helping to create tools to make and identify accessibility problems. And I was wondering what your experience is and what your favorite tools are?

Erin Doyle: So pretty much anything that the group DQ Systems or DQ Labs puts out is awesome. I see them as one of the top authorities in the accessibility space. They do consulting and training and knowledge sharing, and they have a whole suite of tools. And they've got a ton of credibility in the space. So they've got a Chrome plugin called Axe, which you can run on your pages and it shows you findings. And any finding that they report links to more resources where you can learn more. They tell you what standard and level of compliance is impacted, what user groups are impacted and in what way. So I found that to be a really great way to learn. Start by testing.

Erin Doyle: One of the things I teach in my workshops is taking a test driven approach. So you've got these tools, you test, you find bugs, and then you learn about them. You learn like this thing that's wrong, why is it wrong? Who's it impacting? And then, what are the ways to fix it? And you just iterate on that. So they're plugin Ax is great for that. It used to be called Lighthouse, built into Chrome. Now I think they just call it Audit. That's actually built on the Axe engine, so I think the results it should be reporting are probably the same. It just just depends on what user interface you like better.

Erin Doyle: They've also got a library that you can use for, I believe Selenium tests. So if you want to automate your front end tests, they've got that. And then I think fairly recently they put out a tool that basically replaces, in my opinion, React Alley, which was a library I used to work on. And it audits your app at runtime in development, you wouldn't want it running in production. But as you use your app, it will analyze what's in the Dom and then output it to the console any findings as you use it. And that's really great to use in conjunction with... There's an [inaudible 00:20:04] plugin that will do the static code analysis for findings. So it's like a...

Joel Hooks: Yeah, I've seen a JSX analyzer that for react apps particularly that [inaudible 00:20:16].

Erin Doyle: Yeah. So that's a nice layering. Start by just analyzing your static code, that's the lowest hanging fruit and then start checking it at runtime as you're working through it and then start doing scans with the browser plugin. And they even have an enterprise level tool, which my company's checking out where you can automate scans and it will spider its way through your whole app and then send you any findings. So you could just schedule it and have it constantly running, and anytime there's something new that pops up, you're alerted to it. So it's nice.

Joel Hooks: And then all the way through like having actual real humans with impairments, trying to use your application I think would be the final layer of checking.

Erin Doyle: Yeah, absolutely. That's something that I definitely learned, and that's a misconception I run into a lot is that people think, "Oh, well I'll just use these tools to scan my app. Especially those that give me a rating, like am I 100%? Or if there's no findings, I must be 100%," and they think that that's it. But really, you have to have people manually testing. Unfortunately it takes time. It's time consuming, but you need people using the actual devices that people are going to be using. So the screen readers, all of them, using a keyboard only, using various high contrast modes.

Joel Hooks: I'd probably go as far as to say that the automated tools analysis are the table stakes. That there's no excuse for not using them and that we should all be running static analysis. And then that's more like the beginning. This is the fundamental baseline. [crosstalk 00:00:22:12].

Erin Doyle: Yes, absolutely, it's really easy. It's so low barrier to just adding those tools to your suite, and as you said there's really no reason not to do that part. Just like we lent our code, add that on. There was actually a study done not too long ago by the web accessibility in my group that looked at the top 1 million sites. And if people are curious, how do they know what are the top 1 million? You can look at the report and they tell you how they figured that out. But anyway, the top 1 million sites, and scan them for accessibility issues. So again, just a scan, not manual testing, just one of these easier scans that's only going to catch a small percentage of problems. And I don't know, it was like 97% or something like that. So almost all of them had findings. And this was just the easy stuff, the low hanging fruit that we could all be eliminating by running these tools. So if we all just did that, the web would be massively more accessible.

Joel Hooks: Yeah, it feels like we have to start collectively changing maybe our definition of done in terms of features and adding things to our applications. And I think like what you said, where it was baked in to the current application you're working on from the start is a really important observation. Because this stuff is really hard to attack on later, and it gets more expensive and more time consuming [crosstalk 00:23:46].

Erin Doyle: Yeah, absolutely. If you've got findings, and it's going to take maybe a refactor to make something more accessible, that's a lot harder than designing it from scratch to be that way for sure. Yeah.

Joel Hooks: So I have a technical question. What is an RIA attribute?

Erin Doyle: So it stands for accessible rich internet applications, and it's basically an attribute that you add to an HTML element that can layer in more information for assistive technologies to understand what purpose does that element serve? What's its role, what's it functioning as and what's its status. So this could be things like defining what kind of widget is it, if it's a more complex widget like a menu or a dialogue. So identifying that piece. Or is it maybe a landmark area, or is it a structure of the webpage? Is it a header, a footer.

Erin Doyle: Or providing status? So if it's something that can be checked, selected, opened, hidden, those kinds of things. Just defining more information about that element or that widget. So that provides much more context to the assistive technology tools, especially as we're building these more complex things that you don't just get out of it. A tag by itself. We give more information to the assistive technology, so they can explain that, or however that's being convened to whatever the device is that's being used for the user.

Joel Hooks: So I've seen a lot of people talk about Aria versus Semantic HTML, and the idea that semantic HTML is really what we want to be doing. And I was wondering, what's the difference there and what do they mean when they say use semantic HTML, and you solve a lot of your accessibility problems?

Erin Doyle: Yeah, that was really confusing to me at first. Because when you're reading articles and some of them are a lot older, the advice shifted over time. It seemed like for a while, a lot of their advice was saying use HTML5 tags and Aria attributes always. Even if they're redundant, use both. And then I started reading articles that said don't use both, don't ever use both. So it's confusing. But I think what happened is, initially browser support for both HTML5 and Aria tags was really sporadic and inconsistent. So one browser might support one but not the other, and then another vice versa. So that's why the advice originally was just use both, throw both on there everywhere, and hopefully it'll all get covered somehow.

Erin Doyle: But as time's gone on and browser support has gotten really good for both HTML5 and Aria attributes, now we get to choose what makes more sense. They're supported similarly, so I think now we want to be writing more descriptive semantic code. So I think that's why the advice now is, if you've got both and the options are redundant, favor the HTML5 tags because they're just more descriptive. That gives us cleaner code, instead of having a ton of divs that have various roles on them.

Joel Hooks: Mm-hmm (affirmative). I feel like the idea of going in there and just really structuring your markup in a way that makes sense is more maintainable and less prone to kind of human error. If you can get away with that, right? If you don't need to think about an ad, various new attributes to [crosstalk 00:27:52].

Erin Doyle: Yeah, it takes research. Again, I had to do some looking at, "Okay, well what tags and attributes are redundant?" And in some cases, maybe you do need to use both. And then in other situations you don't, so it takes research until you get the hang of that and learn it. So it's not bad or wrong to use both, or to you use an Aria attribute where you could have used an HTML tag. So I hope people don't get the misconception. I think maybe they do, that like, "Oh, it's bad, I'm doing something that's wrong." I think it's preferred to use the HTML5 tag, where you know that they're both available and lean towards that one.

Joel Hooks: Yeah, and I feel like that's a place where our static analysis and these tools that we discuss can really come in and help you to understand, "Oh, you're missing this or this should be this way. Or if your HTML is structured in this fashion, then you'd be able to get rid of this." That that seems like [crosstalk 00:28:53].

Erin Doyle: Absolutely. And the [crosstalk 00:28:56] plugin, I think more and more they're adding rules that will tell you that stuff. Where you could have used one versus the other, they can check for it and they can tell you. And certainly, I really encourage people to contribute to libraries like that. If you have come up with a case where you're like, "Wow, this is something we could totally be checking for and then I don't have to remember everything in my head," please add an issue or contribute.

Joel Hooks: Yeah. So beyond accessibility, which I think is a hugely important issue and I think it's going to continue to be for years. What are you excited about in web development, and the full stack spectrum of web development? What's exciting for you now?

Erin Doyle: Yeah, that's a hard question to answer, because it's just all exciting right now. The rate at which new tools are coming out and new features of the language are coming out, or new new languages and frameworks, new libraries? it's really exciting when I think back to when I started doing development. And I don't know, '98, '99 and we were using notepad. And yeah, but I remember reading all about DHTML.

Joel Hooks: DHTML I think was popular at the time.

Erin Doyle: It was the new hotness, and we had to deal with Netscape and FrontPage and oh, it was so crappy. And the landscape now is just... The developing experience is just lovely. And...

Joel Hooks: Yeah, I see people that get sad or upset about it, and I agree with you actually, I think. I've been making software for a long time, and right now it's the best I've experienced so far. Yeah, for sure.

Erin Doyle: Yes, yeah. And I love JavaScript, I love where JavaScript's come over the years. When people complain about, "Oh, there are so many libraries and frameworks, and how do we keep up with them all?" I don't know. I think the power of JavaScript, and I think the beauty of what we've created out of it is really cool. But I'm really excited about where React continues to go. We've got hooks now, we've got suspense. We've got a lot of things helping us lazy load, got Bunzl splitting in Webpack. Those are a lot of areas that I'm trying to get more into right now. There's more security tools.

Joel Hooks: I'm personally excited about Ryan Florence's Reach UI too, I think he's doing an-

Erin Doyle: Yes, absolutely.

Joel Hooks: ... Amazing service to the broader community.

Erin Doyle: If we can put out a library-slash-framework that people can just use, and they don't have to become complete accessibility experts? They can just rely on it and it's baked in, that's going to be a huge win for everybody.

Joel Hooks: And just another part of of that particular resource that's interesting to me is if you go look at the source code. Because Ryan's developing it openly, and it's all in progress and you can go like analyze it and get the ideas of what he's doing to address these accessibility problems. So maybe you don't use React, but the solutions and what's going into it are going to carry over and really change everything [crosstalk 00:32:23].

Erin Doyle: Yeah, absolutely. That is a great point. There's definitely been times where I've needed to do a thing, and maybe I found a library that did it but it was more than I wanted to pull in. Or like you said, it's maybe a different framework than what I'm using. Yeah, look at the source code, learn how that was solved and and apply that back to what you need to do. That's a great way to learn.

Joel Hooks: So you may have noticed this, I noticed this on the internet that there's a lot of people that want to learn how to be web developers right now. And I was wondering, do you have advice? What do you tell people if they want to get into this field, and it's a career that they want to do? How do you recommend that they start?

Erin Doyle: Well again, it's such an exciting time to be in. Because like I briefly mentioned earlier, when I got started you had to have a degree if you were going to get a job, or if you were going to be paid close to what people doing the same thing you could do are doing. And I had to go through that. It was a while before I got to make what my peers were making, because I didn't have the degree. And now you don't have to have a degree, it's really cool. You can go out and either take one of various different mediums of courses that are now out there, including Egghead. But there's UME, plural site. There's now these hack reactors, schools. And yeah. [crosstalk 00:33:57] and then there's just an immense amount of articles and blogs and videos out there talking about how to do things. You don't have to get a degree, you don't have to buy a book. I remember when that's all you could do to learn something new is you have to buy the book, and hopefully you got the right version.

Joel Hooks: I feel like nobody reads books anymore. I still always recommend, "Well, you should get this book." I recommend JavaScript for kids as a good place to start. And kids sounds like it's like infantilizing, but actually all it means is it doesn't take itself too seriously, and the examples are fun. But I've seen this downward spiral of people first seeking Internet versus seeking [crosstalk 00:00:34:36].

Erin Doyle: Yeah, I think it goes towards what are our learning styles? Some people, video is really what they need. And some people, that's maybe too slow and they want to jump right to code examples. For me, I need to see the code example, maybe even before I hear something or read something explained. So when we finally made the jump from books to Google, and I could like jump right to exactly the part that was helpful for me versus having to read paragraphs describing it, that worked better for me. But there's a lot of people that maybe they need to hear it. Maybe someone actually has to say it out loud, and then they need to read it and then they need to do it. It's all of our different learning styles. So it's great that there's options no matter what your learning style is now.

Joel Hooks: Yeah. And I generally am like, "You should probably look all of it, right? Watch the videos, listen to podcasts. Read articles, dive into books as necessary." There's so much information in how do you do this? One, just consistently practice and keep at it, because the only way you fail is if you stop. Because there's so much. And this is probably true for most software careers anyway. There's so much information available on the internet, you can keep learning and keep doing and keep growing infinitely. And for free for the most part, you can get in so far. I operate a pay service, and as a personal thing, I don't really like watching videos on the internet to learn stuff. I just prefer reading. But there's so much out there and there's so much to get a taste of it. But then when you pay for resources, whether it's going to a boot camp or something, it's like this acceleration and the accountability.

Erin Doyle: Yeah. So go find what works best for you, and what you enjoy and get excited about. And for me, that's maybe doing some tutorials, or coming up with a project that I can actually do, and then I learn from the doing. And I get that thrill of making a thing work and trying to make it do. So I guess that's definitely my advice is, go find what medium works for you out of all of our lovely options. And then just like you said, keep doing it because I know I forget. If I don't do it, I'm going to forget.

Joel Hooks: Yeah, stick to it. Yeah, There's a lot of helpful people out there if you ask nicely. There's folks out there that help. [crosstalk 00:37:15].

Erin Doyle: I feel like that landscape's changed a lot too. It used to be all trolls. If you asked a question, the answer was always... Exactly.

Joel Hooks: Like [inaudible 00:37:23]?

Erin Doyle: And you don't see that anymore. It's really rare I feel like.

Joel Hooks: Now, and Twitter's is a neat space. I'm a a Twitter native. And I just think it's interesting as I've watched over the years that people will come together and help people, and get people boosts and amplify their voices and do that kind of stuff. Which is really quite nice in terms of of community. There's a lot of folks out there [crosstalk 00:37:44].

Erin Doyle: Yeah, I feel like the community definitely has grown. As open source grows and all these resources grow, it's totally about community. It's very cool.

Joel Hooks: Yeah. And accessibility on a career level in some ways I think. Well, Erin, I really appreciate it. Thank you so much for your work and spending some time with me today to talk about this stuff. Where can people find you on the Internet?

Erin Doyle: So I'm on Twitter, Sunshiny Doyle. And I'm on Github as Erin-Doyle. Those are probably the best places that people can look me up and check me out. I try to post my resources when I do these workshops so that people can actually work through them on their own. If they weren't able attend, they can still learn. And then certainly send me any DMs on Twitter if anybody has any questions. Yeah, thank you very much. This was fun.

Joel Hooks: That's awesome, thank you so much. Cheers.