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!
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!
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 Reilly. This is another interview from the Squares Conference. My name is Jonathan Cottrell. 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 them answer them. And I hope you 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. I'm 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 have a great day. I hope you have a great day. I hope you have a great day. 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 is best practices of an API. And we had a good discussion afterwards. And I 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. I don't know how much of this you can talk about publicly. But I know you're working on some of this stuff. So I'd love to talk to you. Let's start with that. And what do you do? What is your kind of 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 True, who's going to be talking at Circles next year. Or yeah, this year, rather. And then we've got Nick Ciccanelli, who's here with me. And he's working on some of our other product that we can't talk about. And then Adam Trabold, who's working on... Local and also the app. So they design 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... I don't know. I don't know. I don't remember her last name. Ann Gunn... Gunnhoser, I believe. I may be 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 frame stuff. Is that correct? Grundhofter? Yes. Yeah, that's correct. Cool. Yeah. So it helps frame stuff. It helps frame stuff. Because we're in the exploratory phase. And we just 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. Yeah. But man, it was... Kind of detail some of that stuff. It was great. It's really good. This is, you know, this is 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. Right? So there's design systems. There's brand guidelines. There's design guidelines. There's... Libr. Libraries. Yeah. 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. Yeah. 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 the sort of stack. Yeah. It's one of those... It's one of those common things that we say. It's one of those common things that we say all the time as developers is naming things. It's one of the hardest things that we do as developers, right? Yeah. We're basically creating, you know, for lack of a better term, that words are variables that our mind attaches meaning to. Yep. And so we have these variables of pattern library. Well, what does that actually mean? Yeah. And how can we make those variables like strong type? Because... That's good. It would be pretty nice. Right. The way that I learned to code was strong type. I like that. Yeah. Sort of... What language is it? I learned Java. Okay. And then I learned .NET and Microsoft technologies. Mm-hmm. It just totally helped. Yeah. I knew what was going to fall into what, like 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 a... I like this. Like a Ruby type system, which is duck typing, right? Yeah. 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... I'm just going to assume that it's correct, right? Yeah. 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, or 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 benefit is. And 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. Like 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... 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... It's challenging enough that it's... It's challenging enough that it's... 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, you know, 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. Right. That also does mean that there's the eating part. That means that it can grow. Like, we're always hungry. So the designers understand when to start exploring with something maybe more complex or something else. Like, so how can we reduce the time to get to the spot that we can... Start that exploring? Yeah. Yeah. And there's... It's just... There's a lot of work to do. Yeah. Yeah. The thing that you showed me yesterday, I'm not sure exactly, you know, what tools you were using to build it. I know you said you're using Polymer. But ultimately, the thing that I loved about it was this left... The 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. Yeah. To come up with... You know, how do we determine what variability we need to document for a given component or whatever you want to call it. Yes. So we have, you know, the button. Let's take the button example. We talked about what things can change in a button, right? And you have those things in there. And then you had something like rules and a few other really interesting things. Yeah. Do you want to talk a little bit about some of the things you have in that? Yeah, absolutely. So we have three general, like... This is my attempt at it. I don't know if it's right. I don't know what I'm doing. I'm actually... It's funny. I'm presenting this next week so that we can try to figure out, like, start to poke holes in this thing. And I think it's going to help a lot of people actually to hear this. I would absolutely love to have any feedback. So if anyone agrees or disagrees, like, at me, I would love that on Twitter. So the way that we have it are... Let me try to... So properties have... Properties, let's define that word, are all of our sites or apps... Or et cetera. Products. Could be print even. Properties are like app.getflywheel.com, getflywheel.com, which is our marketing site. app.getflywheel.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. Sure. And so how do we capture the rules for those personas? Right. Or 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. And 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. And 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 kind of collection of stuff? Brad Frost's what, molecules? Yeah. And then how do... How do we vary those that need to be... When they need to be for different markets? Like marketing wants to be more friendly and open. And so it needs more space between the H1 and the H3, for example, like low level. And then how do we take that? Those rules get the reasons from the designers. Because we want to understand what the validation is. Yeah. 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 solve problems. So if you have a problem or join something, maybe like sign up for our affiliates program, there'll 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, I feel like that's... Yeah, yeah. It's secondary actions. I think that is pretty... I think it's... Comprehensive way of... Yeah. Then we have tertiary actions, which are outlines. They have like their white... They've got... Well, I mean... 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... For example, in the context of what I'm doing with Polymer, you can create your own HTML tags, a lot like a React kind of HTML tag situation that's happening where you capitalize the first letter. But this is an actual HTML tag. It's a tag that's created from an HTML tag, primitive of the browser. So you can register an 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 and 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. And those numbers are, does it fit this rule? Great. Check. Yeah. 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. Then the designers can start to explore. I think that makes sense. Yeah. 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 Anne's talk. 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. Mm-hmm. These are good questions. I don't know. Yeah. Working it through in 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. Right. 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. Something 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 values, about, okay, we want the brand to be friendlier. Right. And you could even continue that train of thought further up. Why do we want the brand to be, you know, friendlier? Mm-hmm. And so you ask that question, why until you get to, you know, maybe a piece of research, or maybe it's, this is just a, this is a brand value that we, you know, this is part of the brand, right? Yeah. 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 whimsy. Yeah. We just know it. Exactly. We just like that. Yeah. We, we want to do it. And, 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, cause this will happen, every developer knows that this happens. You're going to encounter a situation where you're at the edge of, 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, is invalidated, right? The reason is broken. And so the, the driving purpose for the rule, you know, it's kind of like parenting. I have, I have rules. I will have rules for my children and you know, creating these rules for your children. It's like, okay, well. It's not the rule that matters. It's the, 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. And so knowing that full chain of reasoning, I think is, is extremely valuable. And I think more development shops, more agencies and more companies like Flywheel 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. It's because they can make these decisions that are not prescribed. They're they're dynamic decisions that, that rely on the full context. Yeah. Yeah. Really interesting. It is, it is. It's a hard problem to solve. Um, and I remember working at an agency and I would want to be able to, uh, there were, there were, because there were only three designers, I could pick up on their patterns. Yeah. Yeah. Because I was not intending to do, and I could reuse the things that they, uh, they would reuse in their designs because it would help them. It was effective and they wanted to make sure that people, uh, kept that, um, sort of taught uh, experience when they're like clicking buttons, for example, outline buttons or call to action, stuff like that. Very simple things. Um, the idea of reusability in a, and, and, and in capture. Yeah. Yeah. encapsulated components especially that react has been pushing i just love i want to figure it out yeah um 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 uh every firm has the opportunity of defining this language for themselves so it's it's a it's a worthwhile exploration um i'm gonna shift gears here uh first of all flywheel bought everybody pizza here flywheel is is not technically a sponsor of developer t but today they are because i'm gonna eat pizza that they bought so it's super cool um happy to help candidly i also we use local uh some of us have adopted it at at whiteboard i i'm testing it out to see if i want to kind of make it a standardized tool that we use yeah at whiteboard that's great that's great because it's built on um this is just an aside but it's built on on really strong technology things that we trust already right we we know that containerization is a good thing for example 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 um which you know in our previous setup we had native everybody set up a native install of apache and we didn't use map because that caused a bunch of problems so we were we all have native stuff set up on our 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 um and and this this helps mitigate this right um and and now this the the the setup process is uh particularly this is for wordpress um the setup process is clicks right um and i'm not like i'm not i'm not trying to expand this beyond the real value like it's it is it is a very simple tool that does a very good job so i'm really i appreciate the fact that flywheel is giving this away yeah so that's super cool it it is really cool i'm a developer and i still do uh side gigs i still have sure stuff that i work on yeah um i can't talk about the project that i'm launching i think soon but it's wordpress and i use local um and the uh experience of setting stuff up is significantly quicker yeah it's great because at flywheel we we talk about this so much um it's like in our dna which is great we really want uh agencies and designers to have the simplest experience when working on their website we care about their workflow yeah um 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 uh with uh designers and and your client and what that can how you can move as far as the design process goes and i think that's a really good point and i think that's a really good point and i think that's a really good point and i think that's a really good point fast as possible doing the things that you absolutely love yeah um and local complements 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 right the system dependencies uh when i had to use uh vagrant vagrant would just uh just shut off yeah which would be kind of frustrating it was it felt like overkill always felt like yeah yeah so yeah yeah absolutely so we wrapped it up um well previously it was prismatic bought it and uh now we're going through some cool stuff i'm really excited about it yeah i'm so excited about it oh 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 a 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 codec apps and i think that's a really good point and i think that's a really good point and i think that's a really good point and i think that's a really good point 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 is fuse fuse is a program that you install it's a development environment program that you install on either mac os 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 go and check it out spec.fm slash fuse now this all compiles down to native ios and android applications so there's no performance concerns go and check it out once again spec.fm slash fuse thank you again to fuse for sponsoring today's episode of developer t i'm excited to learn more about how uh 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 right like i would i would love to be able to manage containers through local and and you know be able to have that interface for those kinds of things as well um so maybe i'll have to send a couple of feedback tickets to oh for real we listen to them i read them all the time i believe it i believe it so um uh like i said i wanted to shift gears i got off on the tangent about local but you you did this this uh workshop yesterday yeah and you know going into that kind of thing i kind of want to discuss the experience of 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 you know planning to go and give a workshop at a conference necessarily you probably will experience something like this in your workplace right where you need to uh whether you're maybe a developer and you need to teach younger developers uh something some part of your process or yeah something new or or maybe you were um you know doing something in your local community and uh you want to teach developers in your local community whatever the purpose is building this kind of content is going to be you know teaching is a fundamental part of learning right so uh i'd love for you to kind of discuss what you're you know leading into that what you what your ideas were because i think it's a really important part of learning and i think it's a really important 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. Yes. And then, you know, kind of your takeaways. Absolutely. So I got contacted by Ish probably November or so. Feels about right. Said, hey, do you want to do a workshop on APIs? I said, absolutely. That sounds like a lot of fun. Sure. In high school, I worked on my very first API and I started like consuming other APIs. So I knew it 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. Let's talk about what the product was. Let me back up a little bit. That works. So the API workshop was to do a social platform called RSpace. Very simple. Just capital R-S-P-A-C-E. RSpace. Yeah. It's a social platform where you can post a story and you'll see a feed of all the stories. Dead simple. Sure. And then the collaborative aspect of the workshop would be to create the likes feature. Yep. Mm-hmm. 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. Yeah. And it does sound like a great idea. And I think it still can be executed. Just we'll talk. Yeah. So we'll hit on that in a minute. Yeah. So I have a repo of the express node express server that serve the API. Mm-hmm. And I want to add a little bit of a demo. Because I want to show you something that I've been working on for a long time. Because I want to show you something that I've been working on for a long time. Because I want to show you something that I've been working on for a long time. So we spent probably the first hour setting some of those things up. But then after that, everybody had the node server working. Mm-hmm. You could go to localhost colon 3000 slash API slash stories slash one or drop the one and you get all the stories. Yep. Mm-hmm. 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 tangential how can we make those discoverable 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 2 and it can cap out and it can say hey there's no more pages, which is great, that can suggest that you don't have to keep querying for some reason or another sure 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 alright, because we also had the cognitive load of learning JavaScript sure I think if I was going to read it, I would have to do it if I was going to do this, I would get rid of the JavaScript dependency and just focus on the what makes a good API and how can we show that best I think there's some value in that and then I'm trying to think what else, what were the latter two questions so I think this kind of 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 know, you had students who, I'm going to call them students, because it's kind of in this scenario, it makes sense 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 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, so people who had never set up a node server never seen an express app never seen ES6 template or whatever literal string or whatever they're called what are those backticks in my JavaScript? what's going on? yeah, I don't 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? everyone sees a title and they see an abstract of a workshop like this and they have a preconceived notion of what they should walk away knowing and part of your job as the 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 and it was very interesting 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 clarify when they saw someone else struggling 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 you were dealt a really difficult hand, I think I told you this yesterday but 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 when you have that large of a gap to make up you're basically teaching you take advantage of the time you're teaching ten 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? what does that look like? and then for the person who is caught up it's the options header that's something new the actual content and I think it was very interesting so to be! completely clear there was no way that you could have known what those people were going into that and that's okay this was one of the best learning experiences I've ever had it was a bummer which is okay 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? on stage like okay, let's see right, right so it's great because I think something like this could be a great format for Treehouse for example where I could say 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 compliments 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 that was extremely interesting and again 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 and what they're going to get at the end of it what 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 and how to how to create content that is going to be helpful to them without leaving a large portion in the dust and it was very interesting actually I had a discussion with another person I can't remember who it was but they were also in in the API workshop with us and they mentioned this idea that like there are there are certain like philosophies not to get too deep on the subject but certain 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 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 it's difficult it's difficult yeah but go ahead I just I didn't mean that no we like there was there were a couple uh individuals in the class who were uh struggling and that's sure that's more than understandable right um my gut 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 uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh so do you want to take it back up sure yeah uh uh 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 center around these same kinds of topics is 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 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 it 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 might want to know these things yeah uh and if you don't then you may feel behind yeah yeah yeah um but again all these everything is 20-20 in hindsight yeah it really is it's really difficult but I enjoyed it very much because again because uh the the learning experience was great I thought the content was fantastic um and that you know given another hour we would have gotten something really good yeah I think so yeah I look forward to future iterations of it and seeing where you go with it definitely me too yeah I I also appreciated it because everybody was real they were honest and it was great that they were so human and okay with watching me fail sure uh that was cool uh it didn't feel like a failure from the audience perspective though yeah I I hope so I hope so sure yeah but I think that the way that it was done I tried to handle it in yeah yeah the most considerate way possible I think it was I tried to present myself as I was there for them to help them and even if this uh workshop ends at five we can still chat sure that's way okay yeah it's totally cool and that's what teaching is about it's it's really about finding finding a way to help someone and and! enable them uh so and every you know 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 or or even the desire to be able to teach the opportunity to teach um 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 the sharing of knowledge um how can that stuff propagate faster as accurately as possible right like 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 it's it's! it's not just a good hearted thing to teach someone it is actually a business value yeah exactly exactly so this is funny I learned to code from a person who left a big corporate job um who's 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 and math 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 uh was interesting because he was considerate when people were struggling and trying yeah and that kind of perspective like I think I hope I try like to to embody that yeah yeah it really helps yeah it really helps so other takeaways on this takeaways yeah 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 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'll be 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 this homework assignment is to give people 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 could you teach I think that's an extremely useful opportunity for a lot of people yeah I agree so I have two questions I like to ask all the guests that come on the show and I'm going to ask you these two questions now the first question is what do you wish more people would ask you about what topic it doesn't have to be development it can be anything oh wow gosh that's a great that's a great question and I don't know really what I want more people to ask me about is probably what what let me think what this is always a hard question by the way yeah how do other people answer this some people talk about their hobbies some people talk about the one value that they find really important yeah you know 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 was your day yeah I like those questions because that is the entry point to talk about attention yeah and then resolve it huh yeah it's a really simple question too and it also literally shows that you care about that person's day uh huh actually I kind of wish yeah more often more people would ask how was your day yeah that'd be nice and be willing to hear something other than it's fine yeah yeah oh yes yes it's not just a not just a I think a lot of people end up in that in that scenario where they they you ask this question more as a courtesy or but ask it with intent yeah it's not small talk yeah it's 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 see if you see Will at a at a conference or if you I don't know visit Flywheel or something totally we're in Omaha super friendly ask him about his day yeah how was your day I love it how's it going the second question I like to ask all the guests that come on the show is if you had 30 seconds of advice to give to all developers which is a very broad group wowza yeah you know beginners and experienced alike what would you tell them um uh take some time to value design uh it's hard and you never are good at it uh I can say that for dang sure I've worked at 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 it's good cool well well thank you so much for coming on the show and uh and uh 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 it's is it spec or is it a longer name uh spec is spec is right yeah spec uh I love every podcast that you guys do like I'm a sucker for does not compute nice I'm a sucker for design details very cool uh my buddy uh Nick Chickenelli he's here uh 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 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 miss out on future episodes and future awesome interviews with people like Will go ahead and subscribe in whatever podcasting app you use thanks so much for listening and until next time enjoy your tea