Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. Today I am interviewing Mackenzie Child. This is the second part of my interview with Mackenzie. Mackenzie created Unicasts.com. You might know him from his 12 apps in 12 weeks. If you haven't listened to the first part, check out developertea.com. You can find it there. Of course, you can find it in most podcasting apps as well. Be sure to follow Mackenzie on Twitter at at Mackenzie Child. That's M-A-C-K-E-N-Z-I-E Child. Of course, that link will be in the show notes, so you don't have to remember how to spell it. In fact, all of the links from this episode will be in the show notes at developertea.com. Thanks so much for listening, and I hope you enjoy the interview with Mackenzie Child. Mackenzie, welcome back to the show for the second part of the interview. Hello, everyone. We talked about a lot on the last episode, a lot about giving yourself challenges, and about overworking yourself and maintaining relationships. A lot of really interesting content there. Not so much specifically related to development, but still a really interesting conversation. What else did we talk about, Mackenzie? Being overcommitted and trying to find a balance between work and life. Absolutely. We also discussed Mackenzie's site. What do you call it? I guess it's not called a site. It is a website. What? What? What would you call it, Mackenzie? A learning platform? A learning platform. That sums it up, right? Yeah. Yeah, that sums it up. So we also talked about Mackenzie's learning platform, Unicast, which you can go and sign up for at unicast.com. Of course, Mackenzie learned how to write 12 separate apps. He taught himself how to create 12 different apps in 12 weeks. And you can see the videos of him actually going through that process on Unicast. So if you're interested in learning more about how to create a new app, you can go to unicast.com as well. That's a great way to try out Unicast before you subscribe. Ton of great content there. And in this episode, I want to talk a little bit with you, Mackenzie, about your background as a designer and how that kind of interplays with your new skills as a developer. So how long have you been a designer? For about 10 years now. Okay. I don't know if you said that on the last episode, but that's a pretty long time to be doing, you know, doing design. I guess designing is the better way of saying that. It's a long time to have been doing anything really. And so I would say that you're probably, and you can tell me, but you probably are really proficient as a designer. I'm definitely more comfortable as a designer than a developer. And fluid with your tools and, you know, pretty much able to create anything that comes to, you know, comes to your mind most likely. Mm-hmm. Yeah. And this is something that comes with time. It comes with experience. It comes with being challenged multiple times over and over. And so I'm interested in knowing how strange it was to jump back into the beginner seat for you. I would imagine that it would feel very jarring to be at the position of being a beginner again. Yeah. I've been at the beginner position quite a few times, actually, because I started in design, like you said. And then I taught myself to code the front end. And then I tried to teach myself the back end and failed and tried again and ultimately led me to the 12 and 12 challenge. Yeah. And so what was the reason that you decided to start learning how to code both on the front end and the back end? Was it just that you were really interested in it or you wanted to just be more proficient? What was the reasoning behind all that? A few reasons, actually. I was working as a designer, graphic designer and web designer, but I didn't know any code at this point. And when I would pass off my beautiful pixel perfect designs to the web developer, it would just come back completely butchered. Margin, spacing, padding, everything would be completely wrong. So that led me to want to learn how to code everything myself. If you want something done right, you do it yourself, right? Yeah. Yes. Another big reason was because I was fresh out of college and completely broke. So I didn't have money to hire someone. I had all these ideas on cool stuff I wanted to build and wanted to see made a reality. But I didn't have like the thousands of dollars it would cost to hire a developer to do that for me. Sure. And and anybody who's listening to this, if you're wanting to learn to code for money, you might hear on other podcasts, or, you know, from other people who are developers that you shouldn't learn to code for the money, you should learn to code because you love it. I don't agree with that. I think it's totally okay to learn to code because you want a job because you want to make more money. It's totally fine to learn those things because we do this all the time with different skill sets. And coding is no different. If coding or learning to code is going to make you more attractive to an employer, or if it's going to, I don't know, raise your salary or, whatever, that's a totally fine reason to learn to code. Now, it may not take you, you know, the long run. It may not, it may not fulfill you. You may not be happy being a developer if you don't enjoy it naturally. But I think, and what do you think about that, Mackenzie? I would say that people who learn to code for money, that's a totally fine pursuit. Mackenzie Peltz Yeah, I definitely agree with that. 100% actually, because a there's nothing wrong with making money, get you, it can get you out of, of different positions in life. And like you said, uh, you can become more attractive to employers, assuming you don't want to build stuff for yourself. You just want to be a part of something awesome. Build learning to code, uh, especially if you're a designer already is, uh, very attractive to, to employers. I think there's a little bit of a cultish perspective on this, that to learn to code effectively, you actually have to enjoy coding, uh, or that you have to, like, it has to come out of a passion rather, than out of a need or a desire for money. And I just don't think that that's, I don't think that's true. And for many reasons, we do this all the time with other skill sets. And I think that, that just because somebody doesn't necessarily, you know, love coding doesn't mean that they shouldn't learn it. And, and that, that brings up a good point that a lot of people, uh, a lot of people are learning to code only because they love it. That is also fine. Like, I feel like, uh, there's, there's a big, uh, overarching misunderstanding in why you should learn to code. Like, for example, should designers learn to code? Well, it depends. Do you want to, is your job going to, uh, to suffer or is it going to get better? If you learn to code, just take all of these things and make a decision. There's not really one right answer or one wrong answer. Yeah. Yeah. I completely agree with that because, uh, me personally, I don't absolutely love to code. Uh, for me, I love building stuff. Uh, so coding is a means to be able to, uh, build out my ideas. But, uh, if I had to choose between design and development, I would choose design and heartbeat. And I, I think there's probably a lot of people on this show that they don't know what they would choose yet. Yeah. Right. Because it's kind of a difficult thing. There's a lot of overlap, which is actually what I want to talk to you, uh, after we get back from, from a sponsor break. But there's a lot of overlap here in skill sets and how, uh, you know, learning to develop can support or even make you a better designer. Uh, for me, I actually started as a designer and went to development. And I would say development actually has made my design skills worse. So if I really enjoy design, then development might not be something that I should be pursuing. But we'll talk about that when we get back, uh, from a quick sponsor break. What if you could learn to build anything? And one month, well, with one month.com, you can just ask any one of the 20,000 students who have learned to code on one month.com by building real websites and applications complete with payment systems, security solutions, and full stack deployment. You can start without any prior experience in just 15 minutes a day for 30 days, all online. That's because one month hyper focuses on applied techniques that you use immediately in the apps you are building as part of the courses. One month's courses are the easiest way to learn new tech, skills, including Ruby on rails, Python, content marketing, growth, hacking, and more. And the best part is if you get stuck, there's always someone there to help you out while you learn. Yes, that's a real person, not an automated computer. So enroll now at one month.com front slash developer T and get 25% off your first month. Now, normally access to all courses costs $99 and access to one course usually costs $49. But with the special URL, you get full access for just $74. Or, one course for $37. That's less than $3 a day. Or if you do a single course, it's just over $1 a day. Enroll now for 25% off your first month at one month.com front slash developer T. In the second part of this interview with McKinsey child, we've been talking a bit about having a background in design and also why McKinsey decided to, to learn development and why you guys might be deciding to learn development or in the process of learning. And we discussed how it's, it's totally okay to, uh, to learn for monetary financial reasons. And it's also totally okay to learn it as a hobby. There aren't any rules to, to whether or not you should learn to be a developer. Uh, with that said though, I think it's really interesting to explore specifically how development and design, uh, affect each other. How, uh, McKinsey, for example, you learned development significantly after you started, uh, your career as a designer. How did parts of maybe your design skillset change, uh, whether they got better or worse? How did they change when you started learning development? Um, when I started designing, I came from a print. I did mainly print work for the first few years. Uh, like logos and then flyers and all that sort of stuff. Um, and then I started designing UIs and it wasn't until I actually started coding that, that, um, I realized what was, uh, simple to, or what I thought was simple to implement in the design was a tremendous amount of work. When you actually got into the code, it makes you aware of the different aspects that can be easily done in code and what is possible, what isn't possible, et cetera. Yeah. I, I actually heard a, I heard Chris Coyier talk about this a year or two, a go. He was talking about, you know, is it important for a designer to learn how to code, especially to learn, you know, front end. And there was, there's a good debate there because he was saying, you know, if you, if you don't learn, then you never know the restrictions. Right. And there's some, there's some positive aspects to not having the restrictions, uh, in the back of your mind while you're designing. Uh, but then there's also the positive aspects of knowing what is possible, right? And, and then utilizing that, maybe thinking about that as you are designing and what tools do you use, uh, to design with, by the way? Um, I use Photoshop just because I've been using it for almost a decade now. I tried to get into sketch, like every, all the cool kids now, nowadays, but, uh, I just couldn't do it. And I keep falling back to Photoshop. That's another perfect example of somebody who knows their tool really well. And you don't have to change to be, able to design well, right? Yeah. I think we're addicted to tools and I've talked about this on the show before, but why change when you can effectively design with what you already know? And it's worth exploring, but you know, if, if you're, if you're coming up against a deadline or something, then using the tool you already know that does effectively the same thing that another tool does is going to be more, uh, probably a better idea. Yeah, absolutely. I started, I started with a illustrator actually for web and UI stuff, but, uh, recently found that I'm just much more efficient and faster in, um, Photoshop. A friend of mine actually still uses fireworks. Oh really? And he swears by it. He loves fireworks. He thinks it's the best thing that ever happened to the web. And I respectfully disagree with him, but at the same time, he designs pretty beautiful stuff, like effective, you know, functional, but also really good looking, stuff in fireworks. So who's the, who says that he's wrong for that? You know, yeah, it's really just pick the tool that you feel comfortable and we'll get the job done. Sure. Like I know I've been doing a lot of illustration type stuff lately, and I know I could do that in Photoshop, but I'm just more efficient in illustrator than I am in a Photoshop. So I jump around between the two programs quite a, quite often. And this actually leads me to another question that I have, back on kind of the development discussion. When you, when you started learning 12 apps in 12 weeks, what tools were you using back then? Because you created Unicast after you did this 12 apps in 12 weeks. So obviously you couldn't use your own material back then. What did you use? I know you mentioned already in the last episode, I believe Michael Hartle's tutorial, the rails tutorial.org. But what else did, what else did you find useful? Um, yeah, I did a lot of stuff actually. Uh, as I mentioned previously, I tried to learn on and off. So I had a subscription to like code school and I did tree house for a while. And I did code Academy pretty much any online, uh, coding platform. Uh, I used at some point to learn, but when I started to do the 12 and 12 challenge, it was a lot of Google and a lot of, uh, stack overflow. Sure. Yeah. Yeah. I think a lot of people probably have a similar, a similar experience. Um, and how does, how does Unicast kind of approach that differently? So at Unicast, we cover the entire process. Uh, when I started, uh, teaching myself to code, uh, I kind of had to piece together different resources, uh, which made it very difficult to learn. So, uh, Unicast kind of gives you the whole picture. Uh, it takes you from, from start to finish of building a real world web application, instead of, uh, just giving you different pieces here and there. And, uh, cause seeing the whole picture, in my opinion is, uh, a much, much better way and more efficient way to learn than, uh, spending the time piecing different things together. Yeah, definitely. Would you say that Unicast is best for designers who are looking to become developer designers or the unicorn, I guess, is, is the, uh, is the term for that. Um, or would you say the other way around maybe, uh, developers who are looking to learn a bit about how to be a designer or a mix of both? It's definitely a mix of both. Um, I found just from demand, it's, uh, a lot more of the people who have signed up already know at least some rails, uh, but they don't know the front end or the design stuff at all. So the majority of the people who find a Unicast, they're not sure if it's useful or have been going for the, the design and the front end stuff. But that is not to say you can't learn from the rail side as well. So McKenzie, I've been asking you a lot of questions in this interview. Uh, but really what I want to know is what is one question that you wish more people would ask you? Um, this is definitely a tough one, but I would say if I was to ask myself a question, it would probably be, how has my life changed? How has my life or how has, how do I say that in third person? How has McKenzie's life changed, uh, by being able to build his own ideas? Okay. So, so I'd like, I'd like for you to actually answer that question. How, how would you say your life has changed by you being able to build your own ideas? Um, well, being able to do both the design and code, I've gotten a fantastic job out of it. Um, I've been able to work on some really fun side projects, start my own little side business, uh, Unicast and, uh, meet some really awesome people in the process. I think a lot of people who, who, uh, learn to do something like coding or like design on the side, aside from whatever they were doing previously, vocationally, they have a similar experience. Um, and, and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have 30 seconds to speak with a beginner developer or even with a seasoned, experienced developer, what would you tell them? For a beginner developer, I would say probably never lose your curiosity because that is what will help you grow and help you learn and help you stay on top of the ever-changing development scene. Great advice. And I think curiosity is definitely one of those core tenets of, maybe not if you're a hobbyist developer, but if you want to actually pick this up and run with it full-time, to be a full-time developer, curiosity is a core necessity. Absolutely. Oh, another thing I would say, it's just coming to my head, experimentation. So you can learn or you can go through tutorials all day long, but you won't actually learn until you start applying those skills yourself. Would you say? Your 12 and 12 was a lot of experimentation? Yeah, that was one big experiment, not only for the coding side, but producing content and making videos, all that sort of stuff. That actually brings up another question that I have about 12 and 12. I know that I asked you kind of the final questions, but this is something I just wanted to ask you real quick. Did you decide what those 12 different applications, what they were going to be before you built them? Somewhat. I came up with, I think, about 15 to 20 different ideas. And it kind of depended on my workload for the week, actually, because some apps were a little bit easier to build than others. And as if you look at the time for the various videos, some are like 45 minutes long and some are almost two hours long. So, wow. Yeah. Yeah. It really just depended on how, uh, how much work I had. And I think that's kind of what I was trying to do. So I was trying to do the work I wanted to dive into that week and how comfortable I felt with the, uh, the concepts, concepts I was learning. That brings up a really good nuance to this conversation that we had in the last episode with relation to challenges. You shouldn't just kind of blindly choose a challenge because it sounds good. Uh, there's a bit of planning and concepting that has to go into this to be able to make it a reasonable challenge, right? Like you couldn't say, you know, I'm going to run across the United States. I'm going to run across the United States. I'm going to run across the United States. In 10 days, that simply is impossible and a silly challenge, right? There's nothing useful in that challenge, but you sitting down, for example, McKinsey and saying, okay, here's 20 ideas. That is a step into crafting a challenge that actually has a meaningful, you know, roadmap in front of you. Yeah. If you look at the 12 and 12 applications we built, none of them are extremely complicated. Like some are more complex, than others, but, uh, none of them, it wasn't like I was like, uh, I'm going to recreate a stack overflow in, in this week and, uh, create the next Google the next week or something like that. Right. Yeah. Uh, that's another reason I focused, um, a hundred percent on the rail stuff and just glossed over the front end and design stuff because, uh, well, one, I just wanted to learn the, the rail side, but two, it was, uh, just a matter of, how much can I afford, how much time can I afford to spend this week doing this challenge. And I think it's probably most valuable to those people who were coming from design. They might have a little bit of experience with front end, but probably have significantly less experience with rails. So I think that focusing on the rails aspects, uh, of those challenges was, was, uh, was a fit for the audience for those challenges as well. Yeah. Definitely. Well, I've enjoyed this interview, Mackenzie. I really appreciate your time. And, uh, I'm sure that there are a lot of people who are listening to this episode who also appreciate all of the things that you've offered, uh, and all of the insights and interesting information that you have. If you would like to listen to more of what Mackenzie has to say, or if you'd like to learn directly from him, you can go to unicasts.com, uh, where there are, there is some free content there, right? Mackenzie? Yeah. Uh, I think there's about 20 something, uh, free videos at the moment. The first 12 of those, uh, go through building entire web apps and then the others are just kind of one-off, um, how to do specific features and, um, actually do a few design videos as well. Awesome. And then people can dive a little bit deeper, uh, with you through your premium subscription. Mm-hmm. Yeah. Uh, the premium subscription, you get the, entire process. We go from, uh, planning to wireframing to design to front end to back end. So you see step-by-step how to, uh, design and code the web apps. Great. And that would be a really good idea, uh, for, for developers who are looking to learn design, especially you would be able to take design and see how it integrates into, into your process and great for designers as well, who are looking to learn how to make your ideas come to life. Thank you again, Mackenzie. This has been fantastic. Is there anything else you'd like to say, uh, to the listeners of Developer Tea? Um, I don't think so. Just, uh, thanks for having me on. I really appreciate it. It's good talking to you. Thanks so much for listening to today's episode of Developer Tea. Make sure you follow Mackenzie Child on Twitter and check out unicasts.com, especially if you are a designer that is learning how to code. Mackenzie has a lot of interesting insight to provide to you because he has a lot of great ideas for you. So if you want to learn more about how to code, you can go to unicasts.com. Thank you. Thank you for listening to this show. If you enjoy Developer Tea, please consider leaving a review on iTunes. Developer Tea is also in the running for a net award for the podcast of the year. If you want to vote for Developer Tea, you can go to bit.ly, that's B-I-T dot L-Y slash vote T-V-O-T-E-T-E-A. Of course, that link will be in the show notes with all of the other links from this episode. And you can find me on Twitter at unicasts.com. And if you want to vote for Developer Tea, you can find those at developertea.com. You can always reach out to me on Twitter at at developer tea, or you can email me at developertea at gmail.com with suggestions or questions about the show or about your career or about anything really. I would love to talk to you. Thank you so much for listening to the show. And until next time, enjoy your tea.