Squares Conference (Will Riley)
Published 5/24/2017
In today's episode, I talk with Will Riley from Flywheel about design systems, local development, teaching a workshop, and API design.
Today's episode is sponsored by Fuse! Build native iOS and Android apps with less code and better collaboration. Head over to spec.fm/fuse to learn more today!
Transcript (Generated by OpenAI Whisper)
As a developer, you're probably going to find yourself in the role of teaching somebody something at some point, and perhaps teaching multiple people in kind of a classroom scenario. And you're going to find that that's not an easy thing to do. It's not a natural thing to do for everyone. And that's what we're talking about in today's episode of Developer Tea with Will Riley. This is another interview from the Squares Conference. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on this show is to help you become a better developer. I do that by giving you kind of this virtual coaching experience, but also just learning with you. Finding things that are interesting and that multiple developers are going through that other developers are struggling with. That's why we take questions from listeners and try to answer them in reasonable ways and have these kinds of conversations with experienced developers working in companies like Will Works at Will Works at Flywheel. You probably have heard of Flywheel Local. Flywheel is a WordPress hosting service. And Will works as a front-end engineer at Flywheel. So I'm really excited to talk to Will on this show, and I'm excited for him to share with you some of his experiences. And really thankful that Will took some time to sit down and talk with me at Squares. I'm going to get out of the way. Thanks so much for listening to today's episode of Developer Tea. I hope you enjoy my interview with Will Riley. I'm with Will Riley at Squares Conference. Will works at Flywheel. He also did a panel, not a panel, a workshop. I've done this twice now. Will hosted a workshop here at Squares. And I asked if he wanted to come on Developer Tea. So thank you for joining the show, Will. Absolutely. Thank you so much for having me. Really excited to talk to you about a few things. I was in the workshop that you did, the API workshop, as best practices of an API. And we had a good discussion afterwards and think that we can talk about some of that today, as well as some of the stuff that you do at Flywheel. And in fact, we also talked before your workshop about you were working on some design system, things, and you were discussing that with another person. And I don't know how much of this you can talk about publicly, but I know you're working on some of this stuff. I'd love to talk to you. Let's start with that. Yeah. What do you do? What is your primary job at Flywheel? So for me, I'm a friend and engineer. And so we've got a design team of three people, Andrea Tru, who's going to be talking at circles next year, or yeah, this year, right there. And then we've got Nick Chickenelli, who's here with me. And he's working on some of our other product that we can't talk about. And then Adam Trayvold, who's working on a local and also the app. So they designed stuff. I translate that to code. And so we're working on a little bit of design system stuff, basically exploring it, like poking and prodding, trying to figure out what that means and how to make it work. We just got out of a talk at squares. And I don't remember her last name. And Goon Hozer, I believe. I'm maybe wrong. Anyways, her talk is amazing. She works at Project 202. It's funny because the booth is like right there. So her talk was amazing and it helps like, to confirm stuff. Is that correct? Green top? Yeah, that's correct. Cool. Yeah, so it helps frame stuff, you said. It helps frame stuff. Because we're in the exploratory phase. Don't know what that really looks like. So trying to understand some of those things. Her talk, I really hope that it's available, like the slides and stuff. But man, it details some of that stuff. It's great. It's really good. This is a constant conversation. And I think a lot of the language around this is important, but it also becomes ambiguous depending on who you're talking to. So there's design systems, there's brand guidelines, there's design guidelines, there's libraries, pattern libraries, all of these things end up becoming a little bit fuzzy unless you decide for your organization to use one term for one thing. Yes. I think that's super important. Another interview we did on Developer Tea was with Brad Frost. We talked about some of this stuff. Yes, atomic design is, we use it and it helps. It really creates clarity in what things are responsible for what and at what spot in sort of. One of those common things that we say all the time as developers is naming things. This is one of the hardest things that we do is develop. We're basically creating, you know, for lack of a better term, but words are variables that are mind attaches meaning to. So we have these variables of pattern library. What is that actually meaning? Yeah, and how can we make those variables like strong type because that's good. It would be pretty nice. The way that I learned a code was strong type. I like that sort of. What languages? I learned Java and then I learned.net and Microsoft technologies. It just totally helped. I knew what was going to fall into what I expected to happen. I think so often we do, you know, if we're going to extend this metaphor, our minds kind of use like the Ruby type system, which is duck typing, right? It kind of sounds right and it seems to work as long as we use it and I can talk to you about it. So we're just going to assume that it's correct, right? Rather than creating a very explicit definition for these things. And sometimes it's important to create that explicit definition. Maybe sometimes it's not. I think the important thing though, the most important part of it is understanding the difference, right? Like understanding that if we don't have definition for these things, what the possible negatives or negative outcomes could be as a result of that, right? Yeah. I really want to set out to like at Flywheel we have a design system and we have common ways of using our pieces of UI challenges that it's tough to test those things right now that the way that it's executed. So we're exploring that. How do we make it more encapsulated, reusable so that one of the key things that Anne said was make it so that, for example, one department isn't redoing the same thing, like redoing buttons, yeah. Let's share our code. It makes sense. Right. Yeah. Something that I remember Brad said on that episode, we keep going back to that because something he said that was so valuable, I think, was allowing ourselves to get away from the idea that redoing these things is somehow inherently valuable, right? So the concept being, even though it may feel good to write solid CSS, right, or whatever you're writing, even though it may feel good to do that over and over because you know how to do it and it's very fluent, right? So you find yourself in a state of kind of like a flow state because it's still challenging enough that it engages your mind, but you're fluent with it so you don't have to do a lot of new research for it, right? That gives us this illusion of value that may or may not actually even be there, right? So if we can capture that value once and replicate that value without investing the time necessary to redo the same things, you know, retrace the same steps that we've traced in the past, I think some of it is a fear that we won't find something new and valuable to do or that somehow, you know, that unique value that we provided that first time we can't translate that into a new objective. Yeah, and you kind of sink your time into something where like designers know the brand. They at Flywheel, how do we say it? Live, live eat, live eat and shit the brand. So what that means is like you know it to your core. That also does mean that there's the eating part, that means that it can grow. Like we're always hungry. So they're the designers understand when to start exploring with something maybe more complex or something else. So how can we reduce the time to get to the spot that we can start that exploring? Yeah. And there's a lot of work to do. Yeah. Yeah. The thing that you showed me yesterday, I'm not sure exactly what tools you're using to build it. I know you said you're using Polymer. Yes. But ultimately the thing that I loved about it was this left side which I was paying really close attention to this because this is a very common thing that we have to do in the agency world as well. To come up with how do we determine what variability we need to document for giving component or whatever we want to call it. So we have the button, let's take the button example. We talked about what things can change in a button and you have those things in there. And then you had something like rules and a few other really interesting things. Yeah. And we'll talk a little bit about some of the things you have in them. Yeah, absolutely. So we have three general, this is my attempt at it. I don't know if it's right. I don't know what I'm doing. Actually, it's funny. I'm presenting this next week so that we can try to figure out, start to poke holes in this thing. And I think it's going to help a lot of people actually to hear this. And I would absolutely love to have any feedback. So if anyone agrees or disagrees like at me, I would love that on Twitter. Sure. So the way that we have it are, let me try to. So properties, let's define that word, all of our sites or apps or etc. Prompts. Could be print even. Properties are like app.getflavl.com, getflavl.com which is our marketing site. App.getflavl.com is our dashboard for managing sites. And then we've got, for example, big one, local. It's a desktop app. Those three things are probably the most commonly understood properties. So they're great examples. They kind of designed, they're designed and catered to different audiences, different personas. And so how do we capture the rules for those personas? Right. The way, the term that I'm using right now, Jeff, who's another speaker, he introduced me to the word personas in design systems. I was really interested in that. I was like, hmm, I think that there's something there. So I'm trying to, today I'm playing with personas. So those variants or personas, they take advantage of systems. We've got a lot of systems and we list them. And I will get to the UI stuff. Systems are like accessibility and color and type. How does type respond and relate to other type when it's in a collection of stuff? Brad Frost's what molecules? And then how do we variate those that need to be, when they need to be for different markets? Like marketing wants to be more friendly and open. So it needs more space between the H1 and the H3, for example, low level. And then how do we take that? Those rules get the reasons from the designers because we want to understand that what the validation is. We want to get some of that background knowledge. Like, okay, you're doing this for a good reason. Great. How can we get a list of all those rules and then apply them to the pieces of UI and then lock it down to what the options are that you should be using. So for buttons or yeah, buttons is a great example because on flywheel we have a primary button state. It's got plenty of padding and you know that it's a call to action that is going to help you like solve a problem or join something maybe like sign up for our affiliates program. There will be a green button that says join. For secondary actions like create a new backup we have a blue button inside of the app. And that blue button is just like there are actions that don't maybe create large things or I think the designers can define this a little better. But easily undone actions. Yeah, yeah, I feel like that's yeah, it's secondary actions. I think that that is pretty comprehensive way of yeah. Then we have tertiary actions which are outlines. They have like their white, they've got well, we've got a gray border, circular, gray type, all cap and same padding as the secondary buttons. So it's smaller, less padding and those tertiary buttons they're used on all throughout the app. And so we know that those patterns exist. We don't want to break them. So how can we say you know, for example in the context of what I'm doing with polymer, you can create your own HTML tags. A lot like a reacts kind of HTML tag situation that's happening where you capitalize the first letter. But this is an actual HTML tag that's created from an HTML tag primitive of the browser. So you can register and honest new HTML tag. We find that I find that a lot more valuable because of reasons that I'll get to, but we are able to lock down what should happen. You can get those definitions from the designer, apply the rules, the systems to the pieces of UI, make sure that they fit all the criteria, all the rules and reasons. And then we can come into the UI and say, check, that is correct. We can put numbers behind the implementation of the UI. Those numbers are, does it fit this rule? Great. Check. That's 100%. Right, right. Yeah. And then we put those on our properties. Hopefully we share that code so that we don't have to rewrite it. And then the designers can start to explore. I think that makes sense. It feels like it makes sense, but we're using different terminology. Sure. What we pretty much led with, like properties. I didn't hear that in AnzTalk. So is that valuable? Is it going to be confusing? Not sure. And then systems. Maybe there are some systems that we're not defining right. These are good questions. I don't know. Working it through my brain. Are variants personas? I don't know. Right. Right. So there's something there. I think that could be pretty helpful. Yeah. I think, you know, it kind of depends on the team executing. So for example, in the agency world, we work with so many different brands that we almost have to apply this concept in separate iterations, right? Is there something that we as an agency, and I'm not asking you for an answer on this, but is there something that we as an agency can take advantage of at that meta scale, right? Yeah. And maybe it's something like generating these things that we have to answer the questions. I think that's super interesting in what you're talking about is this discussion of rules, right? So the developers quite often, we receive, you know, the average development shop is going to receive designs or design specifications that they need to follow. But I really love this idea of pairing with that the reason for the rule, right? Yeah. Which really is a, it's another way of talking about about values about, okay, we want the brand to be friendlier, right? And you could even continue that train of thought further ab. Why do we want the brand to be friendlier? So you ask that question, why until you get to, you know, maybe a piece of research, or maybe it's, this is just, this is a brand value that we, you know, this is part of the brand, right? This is, this really identifies with what we want to be like. What we've chosen, yeah, yeah. And whether, whether there's data for that choice or not is sometimes irrelevant, right? It may just be that this is, this is, all right, this is really what we want. Yeah, this makes us more winzy. Yeah, we just know that. We just like that. Yeah. We want to do it. And, you know, ultimately having those reasons allows you to be a more informed and intelligent developer and understand the, like the execution of the design. And when you do encounter situations, because this will happen, every developer knows that this happens. You're going to encounter a situation where you're at the edge of some design system, where for some reason, some combination of these, of these elements or some combination of these things that doesn't have these rules. Yeah, they have these rules wrapped up. But the reason is invalidated, right? The reason is broken. And so the driving purpose for the rule, you know, it's kind of like parenting. I have rules. I will have rules for children. And you know, creating these rules for your children is like, okay, well, it's not the rule that matters. It's the principle that I'm trying to teach the child. And if the rule ever overrides the principle, then the rule becomes useless, right? Yeah. So knowing that full chain of reasoning, I think, is extremely valuable. And I think more development shops, more agencies and more companies like Firewheel adopting that full line of reasoning. You know, this is one of the reasons why the designer developer, combo person has always been viewed as so valuable is because they can make these decisions that are not prescribed to their dynamic decisions that rely on the full context. Yeah. Yeah. Interesting. It's a hard problem to solve. And I remember working at an agency and I would want to be able to, there were, there were, because there were only three designers, I could pick up on their patterns. Yeah. But they were kind of intending to do and I could reuse the things that they, they would reuse in their designs because it would help them. It was effective and they wanted to make sure that people kept that sort of taught experience when they're like clicking buttons, for example, outline buttons or call to action, stuff like that, very simple things. So, idea of reusability in encapsulated components, especially that React has been pushing, I just love, I want to figure it out. Yeah. Yeah. Yeah. There's a lot there. There's a lot there. Yeah. There's a lot to unpack and I think, you know, every, every firm has the opportunity of defining this language for themselves. So it's, it's a, it's a worthwhile expression. I'm just shift gears here. First of all, flywheel, bot, everybody pizza here. Flywheel is not technically a sponsored Developer Tea, but today they are because I'm going to eat pizza that they got. You know, buddy. Super cool. Happy to help. Happy to help. Candidly, also we use local, some of us have adopted it at, at whiteboard. I'm testing it out to see if I want to kind of make it a standardized tool that we use at whiteboard. That's great. But because it's built on, this is just on the side, but it's built on really strong technology. Things that we trust already, right? We know that containerization is a good thing, for example. Yep. It uses Docker. It uses Docker. And so we can shift our version of PHP or we can shift our version of my SQL per install if we want to and match, you know, something that that particular install needs, which, you know, in our previous setup, we had. Native, everybody set up a native install of Apache and we didn't use MAMP because that caused a bunch of problems. So we were, we all have native stuff set up on our machines and that works very well as long as you always have the same version of PHP and you always have the same version of Apache and you always have the same version of my SQL on everybody's computer and you also have all of those versions live, right? So, you know, whatever server you're using needs to conform to your local and your local conforms to the server and your whole team conforms to those constraints. Well, that was causing problems, right? Because when we had a new team member come on, they're going to install the latest version. And so now they're ahead of us. They're ahead of the older team members. We had this weird situation where the older, you know, the longer you've been on the team, the more likely that your problems, that your machine is going to have problems, right? Yes, yes. And this helps mitigate this, right? And now the setup process is, particularly if this is for WordPress, the setup process is clicks, right? And I'm not, like, I'm not trying to expand this beyond the real value. Like, it is a very simple tool that does a very good job. So I appreciate the fact that Flywheel is giving this away. Yeah. So that's super cool. It is really cool. I'm a developer and I still do side gigs. I still have stuff that I work on. I can't talk about the project that I'm launching, I think soon, but it's WordPress. And I use local and the experience of setting stuff up is significantly quicker. It's great because at Flywheel, we talk about this so much. It's like in our DNA, which is great. We really want agencies and designers to have the simplest experience when working on their website. We care about their workflow. We're not just a host. And we are a host and we do very good work doing hosting. But we also really care about the experience of you working with designers and your client and what that can, how you can move as fast as possible, doing the things that you absolutely love. And local compliments that in a ridiculously good way. Like, I want to code. I don't want to have to deal with what you're talking about, which are the system dependencies. When I had to use vagrant, vagrant would just shut off, which would be kind of frustrating. It felt like overkill. Always felt like overkill for me. Absolutely. So we wrapped it up. Well, previously it was prismatic, bought it. And now we're going through some cool stuff. I'm really excited about it. Man. Most of the mobile applications that you build or really anyone builds have a lot of similar functions. They have a lot of similar needs and they have a lot of similar boilerplate code that you end up writing over and over and over again. This is usually a waste of time, but unfortunately it's still necessary in most coding environments, most application development environments. And part of this is because application development environments haven't really changed for decades. Today's sponsor is helping change that landscape. Today's sponsor's Fuse. Fuse is a program that you install. It's a development environment program that you install in either macOS or on Windows. And it generates a lot of that code that you don't have to necessarily care about. You're going to be writing less code, but doing more with your product, focusing more on the application itself. This gives you time and energy to put towards things that matter more. Now check it out, Spectat FM slash Fuse. Now this all compiles down to native iOS and Android applications so there's no performance concerns. Now go and check it out. Once again, Spectat FM slash Fuse. Thank you again to Fuse for sponsoring today's episode of Developer Tea. I'm excited to learn more about how some of the internals of local, there have been projects that I wanted to use it on. I would use it for Rails if I could. I would love to be able to manage containers through local and be able to have that interface for those kinds of things as well. So maybe I'll have to send a couple of feedback tickets to the file team. We will be listening. I read them all the time. I believe it. I believe it. So like I said, I wanted to shift gears. I got off on the tangent about local, but you did this workshop yesterday. And going into that kind of thing, I kind of want to discuss the experience of building content for a workshop because I think a lot of developers are going to experience this, regardless of where you do it. I don't think you have to be planning to go and give a workshop at a conference necessarily. You probably will experience something like this in your workplace where you need to, whether you're a lead developer and you need to teach younger developers something, some part of your process or something new or maybe you're doing something in your local community and you want to teach developers in your local community, whatever the purpose is, building this kind of content is going to be teaching is a fundamental part of learning. So I'd love for you to kind of discuss what you're leading into that, what your ideas were because you talked about building an API and you used Node and Express and just kind of leading into that and then how things were different than you expected them to be, how they were the same, and then kind of your takeaways. Absolutely. So I got contacted by Ish probably November or so, he was about right, said, hey, do you want to do a workshop on API? As I said, absolutely. That sounds like a lot of fun. In high school, I worked on my very first API and I started like consuming other APIs. So I knew what was happening. And so going into this, I was thinking I would be able to make an API, show the process of an API being created by, or at least one endpoint. Let's talk about what the product was. Let me back up a little bit. So the API workshop was to do a social platform called RSpace. Very simple, just capital R, S-P-A-C-E, RSpace. It's a social platform where you can post a story and you'll see a feed of all the stories, dead simple. And then the collaborative aspect of the workshop would be to create the likes feature. So this is what I was thinking I would do for the workshop that I had really high naive hopes. I really hope that this would work in this way. And it does sound like a great idea. And I think it still can be executed. We'll talk. So we'll hit on that in a minute. So I have a repo of the Express, Node Express server that served the API. At the last minute, I added Postgres as a dependency for everybody. That was a mistake. So we spent probably the first hour setting some of those things up. But then after that, everybody had the Node server working. You could go to localhost, colon 3000 slash API, slash stories, slash one, or drop the one and you get all the stories. Which was great. Then what I wanted to do was focus on these are the endpoints. Here's how you work with them. Now how can we make endpoints that like 10 gentle? How can we make those discoverable? Sure. Great example are the next page in a paginated list of stories. How can we get the next page? Well, you can add an options underneath. You can add an options array underneath the data array, which returns the stuff that the API you really kind of care about. And the options is just like a hint. Like, hey, here's how you go to page two. And it can cap out and it can say, hey, there's no more pages, which is great. I can suggest that you don't have to keep querying for some reason or another. It also, what I wanted to do was explain what options the options header was. Because it was really for me learning API, APIs and design. I looked at Flickr and they had really good documentation. And I learned that the options header, while they didn't really use the options header, the options header was intended for what does this API offer? What are the options I can use? I can act on. And so showed that. I don't think it really hit, which is okay. It was all right. We also had the cognitive load of learning JavaScript. I think if I was going to redo this, I would get rid of the JavaScript dependency and just focus on what makes a good API. How can we show that best? I think there's some value in that. And then trying to think what else? What were the latter two questions? So I think this leads into just a discussion about it. I was in this discussion and I sat back and took it in because I thought it was so interesting to watch. Because the variety of people in the room was the full spectrum. You had students who, I'm going to call them students because it's kind of in this scenario that's working on. Students or customers or whatever, that they had a certain level of knowledge that was right at the cusp of just under. And it was enough that they could keep up and learn a lot. So and that's kind of what you want. You want as many people to be in that group as possible. And then you have people who are way to the left or way to the right of that as well. The people who had never set up a node server, never seen an express app, never seen ES6 template, whatever, literal strings or whatever they call. What are those back ticks? I'm like, God, that's going on. Yeah, I understand. And then even people who had never seen JavaScript, much less, you know, and so I think walking into that, they had their preconceptions of what they were going to learn. In fact, everybody did, right? And C is a title and they see an abstract of workshop like this. And they have a preconceived notion of what they what they should walk away knowing. Yes. And part of your job as the teacher teacher is to anticipate some of those. But also some of it is to reveal some of those and get them to be bought into that, right? And it was very, it was like a study for me in sociology because it was so interesting to see the different breakdowns of people when one person would jump in and try to, you know, clarify or, yeah, when they saw someone else struggling, right? There was this sense of tension in the room because you could tell that there was that disparity between the two ends of the spectrum. And it's so it's very, so you had a very, you were dealt a really difficult hand. I think I told you this yesterday, but it was, it's one of the hardest jobs to fit that much of a content piece in three hours, right? Three hours, it feels long, it felt like a long workshop. But ultimately, you know, when you have that large of a gap to make up, you're basically teaching, take advantage of the time. Yeah. Exactly. You're teaching 10 different workshops is the idea, right? So for one person, the workshop is, how do I get node installed for another person, the workshop is how do I use JavaScript? Exactly. Yeah. And then for the, for the person who has caught up, it's the options header, right? That's the new content. Exactly. Exactly. And I think it's, it was very interesting. So, and you, so to be completely clear, there was no way that you could have known who, what those people were going into that, right? There was, and that's okay. This was like one of the best learning experiences I've ever had. It was a bummer, which is okay. Right, right. That kind of stuff happens. That's all good. But it was really good because I can, I was even doing this in real time because I was like, how do I do this? How do I adapt this? It was like, on stage like, okay, let's see. Right, right. Yeah. So, it's great because I think something like this could be a great format for a treehouse, for example. Yeah. We're going to make an API and we're going to use Express. And at the end of that, then we'll say, here are the great things that you can do to make your API secure, discoverable so that it complements whoever's consuming the API and among other things, authentication. How do you handle that? How do you deal with tokens and stuff like that? Right. Yeah. Which we didn't get to get to. Sure. Yeah. But we did end up getting to this, to the liking and the deletion of likes and things like that. And all of that was extremely interesting. And again, as being one of the people in the room who had worked with JavaScript, it, to me, was very transparent, right? The JavaScript part of it was, I think, for other people, that's where it became opaque. Which, again, this is a learning experience in teaching because understanding, having a very clear picture of who you are, who you are teaching and what they already know and what their goals are, what they're going to get at the end of it. They intend to take away. Yeah, exactly. Which is very difficult. It's, you know, with a podcast. It's the same thing. My job is to understand the people listening to this podcast, what their ultimate goals are and how to create content that is going to be helpful to them without leaving a large portion in the dust. It was very interesting, actually, I had a discussion with another person, I can't remember who it was, but they were also in the API workshop with us. And they mentioned this idea that like, there are certain philosophies, not to get too deep on the subject, but certain philosophies about, you know, the social economics of it. So for example, you have one person in the class that takes five times as long to get set up, let's say. This is not, this isn't true, but some one person in the class that's kind of dragging the rest of the class down. Is it more correct to allow that person to fall back and continue forward? I don't think so. I think it's difficult. It's difficult. Yeah. But go ahead, I just, I didn't know that. No, we, like, there were a couple individuals in the class who were struggling. And that's sure. That's more than understandable. Um, my, the way that I'm wired is, yeah, no, I want you to be on the same page. I want you to experience this because I want all of us to have fun together. I want all of us to see this happen. And yeah, so it was a three hour workshop, for example. But, um, so I don't want to interrupt too much because you're on a really great track, talking about teaching. So do you want to take it back up? Sure. Yeah. So essentially saying that the, the, there are some, you know, utility models, for example, of, of teaching that, uh, you have people in the room who could go very far, right? And then you have people and this is, there's a lot of discussion around things like Common Core in the United States and, um, they, they sent around these same kinds of topics. What, how do you help maximize the, the overachievers and help, uh, you know, assist the underachievers, right? Um, and just statistically, how can, where, where do you draw the lines and how can you create the right boundaries for those people? And how do you tell someone, hey, maybe this, maybe this, uh, workshop isn't going to go super well for you, right? Yeah. Yeah. Um, because we discussed this in retrospect, that would have been helpful to be able to say the, I think that the line that we're talking to could be solved with a word, which is, this is an intermediate. Sure. Yeah. It's like a prerequisite, right? Yeah. You, you might want to know these things. Yeah. Uh, and if you don't, then you may feel behind. Yeah. Yeah. Um, but the, again, all these, uh, everything is 2020 and hindsight. Yeah. It really is. Yeah. For sure. But, uh, I, I enjoyed it very much because, let me explain. Again, because, uh, the, the learning experience was great. I thought the content was fantastic. Um, and, and that, you know, given another hour, we would have gotten something really good. Yeah. I think so. Yeah. Yeah. I look forward to future iterations of it and seeing where you go with it. Definitely. Me too. Yeah. Yeah. Yeah. I, I also appreciated it because everybody was real. Yeah. They were honest and it was great that they were so human and okay with watching me fail. Sure. Cool. Uh, it didn't feel like a failure from the audience perspective though. Yeah. I, I hope so. Yeah. I hope so. Yeah. But I think that the way that it was done, I tried to handle it in, yeah. Yeah. The most considerate way possible. Right. I think it was, I tried to present myself as I was there for them to help them. Yeah. And even if this, uh, uh, workshop ends at five, you, we can still chat. Sure. That's way okay. Yeah. It's totally cool. Yeah. And that's what teaching is about. That's, that's really about finding, finding a way to help someone and, and, and enable them. Uh, so, and every, you know, I, I talk about this stuff a lot on the show, even though, uh, this is a developer show. Um, so many people are going to experience the need to be able to teach, right? The, or, or, the, even the desire to be able to teach the opportunity to teach. Um, and, and I'm so convinced that, that teaching is such an essential part of what we do in this job, um, because this is a knowledge industry. Right. So everything that we do is going to rely on the transfer and the multiplication of knowledge, right? Yeah. The sharing of knowledge. Um, how can that stuff propagate faster as accurately as possible? Right. I guess that's, that's, yeah, it's interesting. And for someone who has knowledge, yeah, if they can find a way to teach it to get it out effectively, that's going to, you know, increase the, the overall capacity of the industry. Yeah. So it's, it's kind of a, it's not just a good, hard, it thing to teach someone. It is actually a kind of important, yeah, exactly, exactly. So, uh, this is funny. I learned to code from, uh, person who left a big corporate job, um, who's, uh, one of the best communicators I think I've ever met. Wow. Yeah. He decided to join and go to a public school to teach code. Very cool. Yeah. Yeah. That's awesome. And so, uh, he was there for, I think probably three years or so. Yeah. But him teaching me that, um, uh, was interesting because he was considerate when people were struggling and trying. Yeah. Yeah. And that kind of perspective, like, I think I hope I try. Like to embody that. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. So takeaways on this, uh, takeaways, yeah. Some, some homework takeaways. I think for people listening to the show is modify your perception of yourself just as an exercise. Take a few minutes and add teacher to your list of responsibilities. Think about who can you teach? Like, well, who are the people around you that you can teach? You know, sometimes I have this energy to teach and I have no one around me. But my wife. And so, I mean, like, can I just show you this thing? You know, and it really is kind of a, almost a mental release for me to be able to, to explain something to another person. It helps me learn more completely. But, um, this homework assignment is to, is to give people the, the expansion of their mind to say, you're not only an executor, right, or an executive person. You're not only producing, you also could teach. Now, imagine who, who could you teach? I think that's an extremely useful, um, opportunity for a lot of people. Yeah. I agree. So, I have two questions I'd like to ask all the guests that come on the show and I'm going to ask you these two questions now. Mm-hmm. The first question is, uh, what do you wish more people would ask you about? What topic it, it doesn't have, doesn't have to be development. Make me anything. Oh, wow. Gosh. That's a great, that's a great question. Um, and I don't know, really, what I want more people to ask me about is probably, uh, what, what, uh, let me think, um, this is always a hard question about that. Yeah. How do other people answer this? Uh, some people talk about their hobbies. Some people talk about the one value that they find really important. Yeah. I think some people make it very narrow and they say, I wish more people would ask me about how to create better passwords. I kind of think that I wish more people would ask the kind of simple mundane, like, very very day-to-day questions, like, how's your day? Yeah. I like those questions because that is the entry point to, uh, talk about attention. Yeah. And then resolve it. Huh. Yeah. And it also literally shows that you care about that person's day. Uh-huh. Actually, I kind of wish, yeah, more often, um, more people would ask, how's your day? Yeah. Yeah. And, and be willing to hear something other than, it's fine. Oh, yeah. Yeah. Oh, yes. Yes. It's not just a, not just a, uh, I think a lot of people end up in that, in that scenario where they, they, uh, you ask this question more as a courtesy or, but, uh, ask it with intent. Yeah. It's not small talk. Yeah. It's, uh, you're asking someone about the most important thing their time, right? So take it seriously. Yeah. Exactly. It's good. So, hi. If you, if you see, will, at, at a, uh, conference or if you, I don't know, visit, who will or something, uh, then, uh, then, uh, we're normally, uh, super friendly about his day. Yeah. How was your day? Yeah. I love it. How's it going? Um, uh, the second question I like to ask all the guests that come on the show is, uh, if you had 30 seconds of advice to give to all developers, uh, which is a very broad group. Wow. Yeah. Uh, you know, beginners and, and experienced alike. What would you tell? Um, uh, take some time to value design. Uh, uh, it's hard and you never are good at it. Uh, I can say that for dang sure, uh, that design companies for a while now and, uh, take some time to value design, look at what it means. And then also take some time to, uh, explore psychology. It's fun. Yeah. Uh, and don't be an empath like deeply empathetic, but be very empathetic to the people around you and understand the struggles that they're going through. And also vote, please. It's good. Yeah. Cool. Well, well, thank you so much for coming on the show and, uh, and offering your, you know, tons of information and very good conversation about all the things we talked about. Thank you very much. And thank you for being an amazing host. And also, like, uh, is it spec or is it a longer name? Uh, spec is, spec is right. Yes, spec. I love every podcast that you guys do. Like I'm a sucker for does not compute my sucker for design details. Very cool. Uh, my buddy, uh, Nick, chicken, Ellie, he's here. Oh, huge fan. You guys do great stuff. Oh, thank you so much. I really appreciate that. Awesome. Thank you. Thank you. Thank you so much for listening to today's episode of Developer Tea and thank you to Will Riley for joining me on the show, uh, stopping by and talking to me at squares. I really enjoyed my interview with Will. I'm sure you all did as well. Thank you so much for listening and thank you again to today's sponsor fuse. If you have been developing apps for any longer than a year or two, then you know, uh, that the development environment hasn't changed very much, but that's what fuse is doing. They're changing that so that you can write a little bit less code and instead focus a little bit more on the product. Go and check it out. Spec.fm slash fuse. Thank you so much for listening to today's episode of Developer Tea. If you don't want to sign on future episodes and future awesome interviews with people like Will, go ahead and subscribe and whatever podcasting app you use. Thanks so much for listening and until next time, enjoy your tea.