Why would you learn a programming language that you know you're never going to use on a real project? That's one of the things we're talking about in today's episode. My interview with Noah Labhart. This is another interview from Squares. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on this show is to provide you with the coaching and the insights, the conversations with other developers like in today's episode that help you become a better developer, help you level up in your career as a developer. That's the entire point of the show. And I'm thankful to say that I've received many emails and tweets and even in person thank yous from those of you who are listening to this show and it is helping you. So I'm really thankful that that's actually happening that we're finding a way to do this together and to help all of us become better developers, have the right conversations. And constantly having a dedication to learning. So thank you so much for listening to today's episode of Developer Tea. Noah is a successful app developer. He owns his own company. He was a developer that went out of development and came back. We'll talk about all that stuff in today's episode. I'm going to go ahead and get out of the way. We're going to get to the interview with Noah Labhart. I'm here at Squares with Noah Labhart. Howdy. Howdy. Howdy. Howdy. Howdy. Howdy. We have TouchTap apps. That's right. Tell us what TouchTap does. So TouchTap is a native mobile development agency. So we focus on native development for iOS and Android. That's kind of our bread and butter. We also do backend development services, front end, marketing websites, things like that. Our big advertisement. We really focus on its mobile. Yeah. So you did a workshop on animations. That's right. So this crowd, it's really interesting. This crowd is full of people who really is a lot of designers. There's a lot of developer designers front end devs, people who are not, meaning there's not a ton. It's not a heavy audience of backend developers. Probably not a super heavy audience of native developers either. That's true. Yep. So you're kind of bringing this somewhat foreign topic to the table. How did it go? It's not in that one, I was in a different workshop at the time. How did the workshop go? Sure. It went great. And you're spot on. It's a bit of a more technical concept or topic than most people. Maybe the crowd is positioned for, so to speak, but it went really well. Everybody was very receptive. In fact, I had a room full of just designers and one web developer. So no iOS guys. So I didn't look. Oh, I didn't make any mistakes to the image in their eyes. That was good. But yeah, it went really well. We had a lot of fun. We got to show them some stuff and animate some things. The primary goal was to bring a little bit more technical content to some of the workshops. A little bit more rich technical content. But ended up getting into a lot of good discussions about what should you animate. You know, what is tasteful animation. And works as, you know, like the 90s website with the marquees going on. You know stuff like that. So it was really good. Really enjoyed it. And I'd love to do it again. Very cool. Yeah. So animation on iOS. This is probably something that you that you've done quite a bit of work with. Sure. Yeah. Because animation is so important. Important to do correctly. Right. And important for a good app to have. Right. That's a very broad way of describing it. That was good. That was good. If you have a native application, then really to set yourself into even the average crowd, you probably should have some decent animation going on in the app. So that's absolutely true. Talking about tasteful animation. You know, how do you know what, where do you draw the line on what is appropriate and what's, you know, over the line or feels gratuitous maybe. Do you feel like that's something that a developer can develop the taste for or do you think that's something that should be determined well in advance by a designer or maybe it's a collaboration? Sure. Great questions. Two things. I'll answer both. One kind of how do you determine like what is the level of animation to figure out what to use. And it's really sort of the best animations are subtle and transparent to the experience. They're almost unexplainable. Something just happened when I clicked that button and I didn't almost didn't see it. But it felt really good. And I want to do it again. I was telling people in the workshop yesterday every time I opened an app with a parallax image at the top that hides itself, I want to scroll and I want to play with it. So whatever, like functionally helps for users have a better experience and whatever brings them back to that experience and makes them want to do it again. That's what you want to animate. And then as far as where it starts, I think it always starts with a designer. I think if us as developers who are true to what we're good at, which at least for me, I'm not a designer. I believe in design and I believe that I've been very lucky to work with some really good designers. I think it always starts with them because they see things differently than we see things. Now there's always some good conversations about, okay, we can't do that or we can't do that. That's going to be an extra six weeks of development. So there's always those type of conversations. But I think it's got to start with the design. Sure. So the designers at TouchTap or if you work with external agencies, how are they typically doing their prototyping? Do they have any particular tools they use for animations specifically or do they explain them? That's a great question. So we've kind of run the gamut on a couple of different tools. The ones we've been using recently are Envision and then Flento is another one. Mainly those aren't specifically geared towards animation. They're more towards prototyping. So anything that we sort of get heavy animation on, it's more of a conversation at this point. I think there are some good tools that they allow you to mock up some good animations. I'm drawn a blank right now of what one of them is called, but there are some out there that focus specifically on that. Sure. There's quite a lot. I know when you may have been looking for, I don't know, but Marvel is, is Marvel being. We've used Marvel before too. That escaped me. Yeah, that's so. There's quite a few of these tools. Interestingly, we were actually just having a really good discussion a few minutes ago about tools and about the purpose of learning a new language. We did a panel, Lauren, my wife and I were on the panel a little bit ago. One of the questions that came up and you were in the room, one of the questions that came up was, how do we keep up to date effectively? This is something that we talked about on developer to countless times. Very common question for Developer To ask because as people come into the industry, as the industry grows, tooling will grow as well. The things that we create and the things that we share, that sharing level, it's very similar to if you were to walk into a bookstore and say, all right, it's my job to read every book in this bookstore. Now take that and multiply it by 10 or 20 times or maybe more. I'm not sure how many books are on average, how many books are in a bookstore. Every week the books always change, too. Exactly. You're talking about a massive amount of information and tooling and choosing between those tools sometimes feels like you're drawing a lottery ticket. What a lot of people do is they effectively buy a bunch of lottery tickets. They spend all of their time and all of their energy trying to figure out which direction to go. Again, something we talked about quite a few times in the show, but this discussion I think something that we came on after the fact, a really cool point that we ended up discovering together was this idea and you actually mentioned it. The idea that the creative process is a waste. Can you expound on that a little bit? Sure. After your panel, which I did great, by the way, after that talking, we were talking about the tools and such, but I struck a parallel between the creative process. When you're creating something from an purely art standpoint, when you're trying to build something, whether it be art, whether it be something like woodworking or things like that, go to the elements. There's a lot of waste. When you're cutting pieces off or you're cutting clay off or things like that, there's a lot of waste to get to the end product. It's not about the waste, it's about the end product. Us as Developer Tend to focus a lot on inefficiency and having the answer black and white. That's the right thing to do and arriving at the answer, arriving at the goal or the product that you're trying to output, there's a lot of waste that goes into it. Even in our own self-development as developers, there's a lot of waste that goes into learning or it feels like waste. There's a lot of intrinsic value and learning, shaping value that comes out of that so-called waste. I may build a project on a weekend in this new technology and then throw it away. Yeah, exactly. What we arrived at in talking about this was learning a new programming language. If you walk into that with the only objective being I want to add to my toolset, then you may miss out on extremely valuable exercises, right? And extremely valuable learning opportunities that you otherwise could have expanded what you said sharpening your axe. This idea that I've looked at a couple of functional languages and not enough to add them to my toolset as something that I can regularly use, but instead to change the way that I think. In many ways, this is the same reasoning applies to why people should read books. Why people should be exposing themselves to many different ideas. It's not because those books are necessarily going to give them a tangible skill to walk away with and immediately use. Instead, it's a different type of utility. I think that's a very interesting insight into this learning. If we view languages, and actually I mentioned this on a recent episode of the show, I can't remember which one, but we talked about languages as a collection of opinions. The same type of logic run through two different languages is going to look different, but it's going to have basically the difference in the syntaxes, difference in opinions most of the time. Exposing yourself to multiple design opinions, how things should look, or how things can look can totally change the way you think about the way you're building your thing, right? Absolutely. No matter what you're using. I write in Ruby relatively often, but I looked at Haskell and looked at Elixir and a few other functional languages. It changed the way I think about the way I write Ruby. The same is true for learning Ruby and then going to JavaScript or what I fill in the blank, really. It's not only limited to programming languages. You can learn a lot from philosophy. You can learn a lot from it. Is this concept that your knowledge is a single bank rather than your knowledge of programming being a list of capabilities? Right. You're not a machine. Absolutely. It gives you a broader perspective. That's why I love things like squares and circles and conferences we go to because I feel like just like the toolset, just the people, too, hearing about their experiences and opinions and what they're presenting, broadens my perspective and sharpens my acts in a different way that makes me think differently, just like you're saying. It's very, very good insight actually. Another concept that gets broken at conferences for people in a good way is the perception of the online personas of developers like you or me or anyone else who's here. We have a constructed version of ourselves that people see online. We can develop a lot of self-consciousness when we are not in contact with other developers. We think that other people are learning everything. We think that everyone else is moving faster than we are. The reality is very different and when you talk face to face with another developer and you realize that I learned from them but they also learned from me. Now it's a collaborative effort and now you're realizing that the value that you have provided to the world and it can be very helpful for feeling a sense of a lack of motivation or a sense of depression or like you're missing the mark for example. I would say that's really the big value of coming to a conference. It's weird to think of it like this but we work in the digital world. It's very cold. We're on slack all day or on some sort of chat or on the web or on a computer but getting face to face and talking to people. There's warmth and there's something that comes from. It's a vibe of something that comes out of just interacting with people and you can't get and you start to realize, hey we're all human and we're all doing this and not one of us is better than the others. Maybe we're in our skills in certain areas but. That's it. It is vulnerability I think. If you look at a computer is completely invulnerable. When you have made a mistake it will let you know right away and with no uncertain terms right. We're faced with our mistakes as developers. Another kind of background theory, popular theory that I have at this point that because developers are constantly facing the reality of our mistakes. We constantly are hitting bugs. You go to a live coding session, the API coding session, most of the changes that you make and test and a lot like when people are watching, you're going to be making mistakes and becoming comfortable with that is really hard to do when you're only on your own. It's easy to have the perception that other developers are not making mistakes because they're only showing you their finished product. The thing they're proud of, you're not experiencing that together when you're only engaging via social media. It's really important to remember that vulnerability being such a key part of a healthy career. That's good. It's interesting to see parallel between social media and a GitHub repo for a developer. Sure. It's like our online persona. Here's my perfect code. This is the way I code all the time. That's very interesting. Especially for developers who are very much in the public. If you write a blog or if you own a company or if you host a podcast, people see this whole picture that is presented that maybe I don't even have a full control over what people are going to take away from that. If we were to meet in person, it's almost certain that I'm going to be different from that. It'd be very hard to be perfectly transparent in that digital version of myself. Absolutely. I'm picking the good pictures to show and I'm composing the tweets. You're not hearing the mistakes, right? Or at least hopefully, not too many of them. But that's very composed. That's true for literally every human in this building. Absolutely. The person on the planet is prone to those mistakes. It's very encouraging to see someone that you admire make a mistake. All that to say, having that in mind, I think allows us the sense of freedom to pick up a tool for only for the fun of it or only for the experience of it and not have to worry so much about the perfect efficiency of that learning process. The same with animation, I'm sure. Try a lot of different things. But you get back to the very simple realities. Absolutely. You're right. In the same route that we were talking about earlier with all the tools, the way to animate things in iOS is the same way. There's five, ten different ways to skin that cat. If not a thousand. Totally. People abstract it in new ways. Open source libraries that you can use and get in there and really change the way that you know how to do things and then you feel like you're back to square one. The developer meme that's like, there's bugs and then you're questioning your career and then it always ends back at bugs. Right, right, right, right in your back. Oh, wait, it's working now. That's good. We're talking about mobile applications in today's episode and if you're a developer and you've been building mobile applications for very long at all, then you probably know that the toolset doesn't really change very often. The applications may change and the business landscape is changing all the time, but the toolset itself seems to stay relatively the same in terms of what you have to do. Usually you have one screen with some code on it, you're writing that code, then you're saving it and you're recompiling and you're watching for the changes in another screen. This has been the way that App Development has worked for really decades with some slight improvements and slightly nicer screens, new typefaces, but ultimately the same kind of model. And today's sponsor is helping change that landscape. Today's sponsor is Fuse and with Fuse, if you've ever used a game development tool called Unity, Fuse is kind of like Unity for app development. It allows you to write a little bit less code and get a whole lot more done. Fuse installs on Windows or on Mac OS very easily. There's no external dependencies and the apps compile to iOS, native iOS and native Android applications. Go and check out what Fuse has to offer to you as a developer T-lister and by going to spec.fm slash Fuse, that's spec.fm slash Fuse. Thank you again to Fuse for sponsoring today's episode of Developer Tea. I think this discussion on tooling is so important. With things like native development, you're seeing tons of tools come out. Things like electron for the desktop and React Native for iOS and Android and then plenty of other tools that we don't need to necessarily go into. But it's very interesting to hear and encouraging to hear that someone who is working in a native environment that being open to those tools is still, you're not going against some unwritten code or some unwritten agreement that you're going to be a good developer. Going and testing out React Native doesn't make you a worse developer because you don't know how to code the native side of things. Sure. That's good. The more knowledge we can have and the more we can sharpen that ax, if we were talking about is always so good. If we are remembering what we're developing for, we're building a product for some reason. At the end of the day, the tech is important in how we get there, but it's not the end goal. If we're building the product and meeting the need and our clients or customers or users are happy with that, it's a win. Allow it to be fluid and be willing to change. The most successful developers are, in my opinion, going to be the ones that both are willing and prepare for change. Both of those are important. If you're only preparing for change, but then you're unwilling when it needs to happen, then you've got a bunch of useless knowledge. If you're only willing to change, but you're unprepared when it needs to happen, then you have a huge gap between the time that it needs to happen and the time that you're able to make it happen. No matter how willing you are, that gap is still going to be there. Preparation and getting your mindset ready for adaptation. That also means getting your code base ready for adaptation, making things in a way that allow them to be changed. That goes beyond just good code quality and it moves into more of a holistic perspective on what is the purpose of technology? What is the purpose of an application? Typically that purpose is not terminating when you deliver the project. Typically, it lives on. It lives on past that. This has been fantastic. I like to ask all my guests two questions. The first one is, what do you wish more people would ask you about? That's a great question. This was one that we were asked in the panel. I finally had somebody ask me that question. That is good. That is good. What do I wish people would ask me more about? This can be anything. It doesn't have to be just developer. Okay. Gotcha. Gotcha. I enjoy telling the story of how I've gotten to where I've gotten in my technical career. I don't wish that people would be like, no, how did you do it? Because I'm in no way a superstar. I have gone through some trenches of some different things. I think there would be some good insight I could offer to new developers. I like mentoring younger developers and junior developers. I think asking me about that would be cool. Do you want to actually give a quick rundown of where you did come from? People are, if we have time later at another date or maybe people want to ask you more, they can reach out. Absolutely. That's great. I started out doing.NET development in the corporate world. Graduated from tech saying M and then started doing.NET development straight after. Did that for years? Then went into corporate America for another eight years and did more project management, implementations, things like that while doing software development on the side. It's easy to look at that and see, well, you're not doing software so you're missing your skills or eroding or things like that. What are you really learning that has to do with software delivery or software development? I actually learned a lot. Sure. In the corporate world and in actually supported manufacturing for several years. I learned a lot about project management. I learned a lot about delivery. I learned a lot about budgets. I learned a lot about people, managing people and leading people. Without that, I couldn't jump out on my own and be the entrepreneur that I am today. Did that for eight years and then I jumped out after that time and started touch tap. We've been rolling for a few years now and been doing that and been growing at a really good rate, which is awesome. I have some really good guys that I work with, that work for me and they're fantastic. My latest venture actually is a return to manufacturing, which is my startup called Variable and it is a on-demand marketplace for manufacturing labor. Oh wow. Interesting. It's bringing new tech to an old industry. A new idea that needs it or a new idea to an industry that needs it. For sure. Very exciting. Type stuff. I think. Yeah. Congrats. Congrats on the whole journey. That would, I think for, especially for people who feel like they're stuck in a job they don't want. Knowing that, and this is something I tell listeners all the time, a lot of people try to either rush away from the job that they're at so they get this sense of excitement and hope about becoming a developer and they'll go in and give their two weeks notice and then suddenly they're out of a job and now the clock is taking. Right. And time is not on their side. Whereas before it kind of was on their side and they lose the ability to be flexible. They lose the ability to get into a new job because they don't have enough time to learn or they don't have enough time to actually find the opportunity. Right. And so they cut their own legs out from under them. And instead of taking that energy and excitement and parlaying it into study or parlaying it into some other pursuit like writing your resume at night. Right. Right. They end up acting on it in a way that hurts them in a long run. So I think that's really encouraging to hear that you had this relatively long period of time for your career where people were telling you, hey, you're writing your skills and in actuality for you, the way you experience it was you learn more. You actually could take that experience and use it rather than just hurting you more and more over the longer you waited. Right. Right. Just back to every sort of experience or opportunity whether you feel good about it or not, like if you're in a job you don't like, you're getting something out of it. There's something you can take away from that. And it may not be the day to day that you're dreaming of that you're really going after. But you can learn something from it and take it and you'll use it. Yeah. You'll use it later. And when I jumped out of corporate, the corporate world, it was scary. It was that same sort of feeling like, okay, why are we going to? Now we're going to eat next week and things like that. Right. Very, very blessed to have a wonderful wife that supported me through that. While we still had children and believed in me and encouraged me through that. So a big props to her. Yeah. Because you're hugely helpful to have one of those. Yeah, absolutely. I have one of those as well. It's a blessing for sure. That's such a great story. I'm going to go ahead and ask the second of the two questions. If you had 30 seconds to give every developer regardless of their experience level, a little bit of advice. Why would you tell them? That's a great question. I'm a little bit of a perfectionist and heart. So I'm like trying not to perfect. I'm just going to go from my gut there. Sure. I would encourage all junior Developer To do two things. Put in the time to learn and to gain experience. I think we're in an age where everything is accessible. Information is accessible everywhere. It's kind of easy to feel like you know everything already. But until you jump out there and do it and be a part of projects and do things, you don't know what you don't know. Kind of things. I would encourage Developer To get in, put in the time, work hard and do what they can do there. And then the second thing, which I wish I could go back and tell myself a couple of times, listen to your older developers. Listen to your mentors, listen to your managers. They're in a position to see things differently than the way that you see things. They may not feel like you can't see outside of what you're doing in your coding interface or your IDE. But the reality is when your head's down in code, you can't. So those people, their opinions are really valuable. So I'd say listen to them. That's great. That's a very good advice. I think that, so I'm going to continue that discussion and then we'll wrap up. The idea that another developer is their ideas are not going to be relevant to you. Even people who are adjacent to you, right? In terms of the structure of your company or even people who are junior to you. This is something I experience all the time at Whiteboard. Those who have come onto our team that I'm leading that teach me every single day. And it's a humbling experience. But when you do actually learn to lay down a little bit of the ego or the pride of knowing how to do something, right? When someone else, when you allow someone else to give you their opinion, then it turns, it shifts from a fight, right, which could be a conflict, a negative conflict, into a positive conflict. And that positive conflict means they are going to pick between two good options, right? And that opportunity is invaluable. A lot of people reject that opportunity and end up not picking the better of two options and just going with an option. And most of the time, if you have the option to pick, you're going to end up with better software in the long run. Right. So having somebody come in and collaborate is hugely, hugely valuable. So, and to your point about mentors, I think the fact that some people are disillusioned to this idea that an older developer or somebody who is kind of of the old guard, like they don't know the stuff that I'm using. Or maybe they don't respect the new things that I do respect. I think it's important to know what pieces of that are valid, right? And to know what your differences are. But it's also important to respect the fact that they've been facing problems. And problems are, we all are human, right? We've been facing and solving problems and their experience will be valuable. In one way or another, it's going to be valuable. And you may have a chance to increase learning on both sides of the table. And usually that's the case. Totally. I'm going to take that with me. I really like that perspective of the double win to two good options. Yeah, yeah. Appreciate that. Awesome. No, thank you so much for coming on the show. Yeah, thanks for having me, Jonathan. Thanks so much for listening to today's episode of Developer Tea. Each and every one of these episodes is thought through very thoroughly to help you become a better developer. That's the entire goal of this show. And I am always open for your feedback and your questions. The problems that you're having, please send them my way. I'd love to hear each and every one of those problems and questions. You can email me at developert.gmail.com. You can also find me on Twitter at @jcutrell. J-C-U-T-R-E-L-L or at developert. Thanks so much for listening. Thank you again to today's sponsor, Fuse. If you've been developing applications and you're using the same old ways of developing, then maybe it's time for a change. Go and check it out, spec.fm slash Fuse. Thank you again for listening. If you don't want to miss out on future episodes and awesome interviews with people like Noah, then subscribe in whatever podcasting app you use. Thanks again for listening. And until next time, enjoy your tea.