Your environment is incredibly important to your work. And if you don't believe this, try turning your AC off during the summer or your heat off during the winter or sitting outside with cars passing very nearby or even just sitting in a room next to people who are talking very loudly and try to work in those environments. It's not going to work out very well. But beyond that, try to work in an environment where you're kind of bored. Maybe an environment that's incredibly sterile. These are places that I certainly have worked. You've probably worked in these same kinds of places before. And you've noticed or maybe you haven't noticed that they affect your work. But it's not just about focus. Of course, that's a huge part of it. But it's also about how your environment can shape your behaviors. And that's one of the things we're talking about in today's episode with Jason Vasquez. Jason is the CTO at developer town. Developer town is probably most well known for the little houses that they create. It's a little neighborhood of houses. These are the houses where you work, actually. You go into work and you have your own little kind of tiny house environment that you get to control quite a bit about. But talk about that and a ton of other stuff with Jason in today's episode, including how your environment can shape your openness and how people perceive you at work. My name is Jonathan Cutrell. You're listening to Developer Tea and my goal on this show is to help driven developers connect to their ultimate career purpose so they can do better work and therefore positively impact the people they influence. And if this description matches you, if this is something you aspire to, to do good work so that you can impact the people around you, it's not just about becoming a great coder because you like code. It's also about what that code is doing, what you're actually making, what you're building, the things you're engaging in, and how you're engaging the people around you. That's what this show is about. That's who this show is for. So I hope that if you are a part of that group that you've already subscribed and if you haven't, take a moment while you're listening to today's episode and subscribe so you don't miss out on future episodes, including the second part of this interview with Jason. Thank you so much for listening to today's episode. Let's get into the interview with Jason. Jason, welcome to the show. Hi. I'm glad you're here to talk. Most people who know about developer town, they're going to, and probably who have heard Jason's name, unless they live in Indianapolis. Most people are going to know or remember you by the houses. Can you talk just for a brief minute about developer town and the atmosphere? Yeah, certainly. So when we started developer town in 2010, we started in a small light industrial office space on the northwest corner of Indianapolis. Not ideal, but we had a really fun time. We had a friends and family weekend. Everybody came in and we got our first nine houses built. A house for us is either 8x10 or 8x12 full house. We're talking walls, windows, roof, doors, the whole thing. They're all on wheels. Each house is effectively an office for an employee at developer town. So developers, designers, project managers, testers, everybody across the company has one of these houses. It's been really nice because we can group them either on your specialty area, your practice area, or by project team. It makes for a nice kind of cohesive unit. So in the old days, you might have had a cubicle with your little personal item or whatever. When you moved, you can put yourself up and put yourself in a box and move somewhere else. But now, at this point in the game, we do it about four times a year. We actually push our houses because they're all on wheels. We push them into new formations that work for us. That sounds cool. Yeah, very cool. And so if I'm a developer at developer town, I get a chance to, how much of this is just, I'm just very interested in this. So this is not particularly important to the developers who are listening. How much of that build process, the physical building process, does developer get to participate in? Yeah, so we had a theory when we started that we wanted Developer To actually build their own house. We thought that would be a good experience thing and kind of be a cultural iconic thing for developer town. Well, especially in the early days, we were scrappy making ends meet and that kind of thing. Turns out the actual construction of the houses was, you know, it was fun, but it was distracting. You know, we had other things we needed to get to. So we now outsource the construction of the houses themselves, but the developers are responding. And well, everybody in the company are responsible for decorating. So, you know, first off, you're very first question. We are getting, not very first question, but you know, as you're onboarding is choosing house colors. So we get your house painted up. But then from that point, employees are responsible to choose their own desks and furnishings and, you know, all of those kinds of things and really make it their home away from home. Yeah, yeah, that's very cool. And I would imagine that you have a couple of people who take the smart home concept directly into those houses. There's a lot of unique niches. You'll see some, we've got some that look like old barns, you know, with old timbers and that sort of thing to some that are kind of like art deco style, a lot of, you know, metal and glass and all that kind of thing to some very basic ones. But you'll really run the spectrum. You know, this is actually a very interesting topic to me. A lot of people who are listening to this right now say, ah, who cares? It's just the work environment. You know, there's cool offices and et cetera, et cetera. Right? It's just another, another stick, another cultural thing. And I want to challenge Developer To think differently about this, specifically about thinking about your environment. Whether you go and work a developer town or not is not really the point of this discussion really. It's more about having the mindset of, you know, understanding that your physical environment, the place that you're in, and how you feel in that place actually has a pretty big effect on how well you're doing. Just how well you're doing as a person. And of course, that cascades into how productive can you be in your job, no matter what your job is. Yeah, absolutely. One of the things I was a little concerned about when we started developer town was kind of that stereotypical introverted developer mindset that you see, and that we were going to build all these houses with doors. And we were going to have people show up. They'd walk in their house, close their door, and we wouldn't see them all day. So if there was a risk that was it, I'm really happy to see that that really hasn't been the case. 98% of the time I'm making up math here, but most of the time you're going to see people, you know, either doors open or out at common areas that we have that sort of thing. But I think what's really powerful and effective about this is that another kind of cultural thing that we've built is that every house has a carriage light on the outside of it. And if you close the door and flip that light on, that's kind of our go away light. That's the, I'm either on a phone call, I'm doing a podcast, I'm, or it's my focus time, right? You know, there's all those statistics about interruptions and what they do. So it kind of gives you that opportunity and you'll see them turned on, but it's not that effective. Somebody walks in, flips their light on, and you never hear from them again. You really see them. Right. It's judiciously, and it's been really cool to see that unfold. You know, it is very interesting that once you have it, it's amazing how little you actually, at least for me. Okay, so, so we have everybody has a similar, hopefully everybody has a similar signal of, you know, I'm busy. Please wait or send me an email or some kind of asynchronous way of connecting with me. Don't try to interrupt me right now. And at whiteboard where I work, I put my headphones on and that pretty much isolates me. Now there's, there's, you know, a hundred different ways to do this. But it's amazing how little of the time that I really actually need to have that truly isolated focus. There's, if you have maybe an hour or even two hours of that, especially, so I've recently started waking up significantly earlier in my day. I'm kind of challenging myself to do this and put some of my, you know, initial thinking and journaling and all that at the very early part of the day before anybody in my house is up. And if I have that time during the morning, then all of that need of, you know, I need to be hyper productive all the way up until 5 p.m. That feeling, that sense of like maybe undue sense of urgency kind of evaporates for me. And I actually, what I found is I've been able to connect with the other developers and people who really truly need my input. Right? I think, you know, you mentioned the research and I think this is a really important point. There's a lot of developers who rejoiced and were so happy that that research came out because it finally validated that they could just kind of shut out the world, which is what they wanted all along. Because dealing with people is hard. Right. And dealing with interruptions is difficult. And the truth of the matter is, while that research is totally valid and I'm not downplaying, you know, the importance of focus and the importance of having that time. If you go too far the other direction, this has actually happened to me in the workplace. People are going to see you as difficult. They're going to see you quite simply as closed off and they're going to be reticent to bring you into something that you actually would provide an immense amount of value to. Right? Like a meeting or something like that. They're going to be reticent to even bring you in, even when you don't really need that focus time. You could be watching a video about some random programming, you know, idea or whatever. And you've decided that that's your focus time. And instead of actually, you know, going and collaborating and practicing some of the things you've been learning. This is turning into a rant at this point. So forgive me. This is something I've experienced very, very recently because I went that I had that same swing. And we've talked about focus 100 times on the show before, but I had the same swing of, you know, man, I finally, I finally invalidated that this this this seclusion is what I really need. And I realized that everyone else working in the company, they started to resent trying to get a hold of me. They're resented working with me and having to collaborate with me because I was so closed off. Yeah. Well, I agree. And I think one of the things that has emerged I think is pretty useful or at least that I enjoy to do is that I'll go off and do this focus work. So maybe I'm working through a difficult, you know, business flow or algorithm or something like that. I really do need that time just to get down a dirty and focus on it. Yeah, absolutely. It helps me to organize my thoughts a little bit because the next step walking out of that is I go grab somebody go grab somebody in a whiteboard and say, OK, so I spent I invested that time right to think through this problem. Here's what I concluded. Can you give me feedback on this? Does this makes sense? You know, because and get out of that kind of siloed kind of mindset where you've fallen in love with your ideas and and don't get that outside input. So I think I think that balance really is effective. Yeah, it's the balance is the key. And I think that's that's something a lot of developers miss is you try to enforce that hyper focus for all eight hours of your day or all, you know, longer than that even. Right. And that's that that kind of defeats the purpose. You have to bring that stuff out and into the open and work with other people before it really becomes truly valuable. Yeah, absolutely. Now anybody at developer town knows I am actually the primary hypocrite of the house culture at developer town. We have a lot of large open areas and I've taken to over the last few months. I actually sit primarily outside now in the open areas. I enjoyed there. I think in my role, especially I prefer to be more visible and approachable. You know, that that sort of thing, even though I have my own project work as well. And I'll go grab my house. You know, when I need to do something, you know, private phone call or or meeting or something like that. But I think providing the right venues has been has been great and so we have those options. Yeah. And I mean, it would be silly to think that every person is going to work perfectly the same way, you know, in the same environment every single time. That's a perfect example of that, right? You know, if you create a uniform environment, then you're optimizing for one particular style of working or you're optimizing for one particular opinion about, you know, how should these desks be arranged or you know, all those decisions have impact on the people around you. They have impact on the working, the working developers. And this is kind of a managerial discussion more than it is, you know, a specific developer discussion. But anybody who's a leader, you know, recognizing those differences rather than trying to suppress them is just as important as creating a productive environment because, you know, for you, Jason, you're sitting outside because, you know, you have to optimize for approach ability. Right. This is something that you care about. It's a part of the role. I'm also CTO. I have to optimize for approach ability too, which means sometimes when I feel like putting my headphones on, really they need to stay off. Right. They need to stay on the desk. Right. Right. So, and, you know, it may mean that at the end of the day, I don't feel, I don't have the emotional or the adrenaline rush of having been extremely productive. But I helped someone else a whole lot. Right. I really was able to provide value to them. But I do love the idea that, hey, you know what? Sometimes you can get out of the house. You can go and sit outside in that, in that common area or whatever. Yeah. And it's great. We've got a nice big skylights and everything. So, actually, it feels like you're sitting outside. So, it's really enjoyable. That's really cool. And just for people who are nearby enough, and hopefully I'll get a chance to be nearby to Indianapolis. I've never been up that way. But, do you guys have like open tours or do you allow guests to schedule a meeting to come and see the place? Absolutely. This should certainly get in touch with me or anyone else, honestly, and we can set that up. It would just like to greet people and we can happy to take them through and show them around. That's awesome. So, I want to kind of rewind, Jason, because, you know, you've ended up in this really cool place. You started a company that has done this. It's a visible thing. A lot of developers like myself, you probably remember when developer town did the house building thing. It was pretty visible, I think, to the development community. But, if you rewind before that, I'd love to know, kind of, your road, your story that led you to becoming a CTO, you actually got the CTO of the Year Award in Indianapolis. And just kind of, you know, thinking back and getting a brain back into early, early years. What first got you interested in software development to begin with? Yeah. Okay. So, probably of, well, what I consider always to be a non-traditional path that I think is becoming a more commonplace path for me. I grew up in, I think, I'll probably go way back, because I grew up in a fairly entrepreneurial family. My family had a small custom home construction business that we ran, but we had a few things along the way as well. Like a electronics company that we purchased and worked on a little bit in the old, and a fishing tackle company, and all sorts of little things like that. So, I exposure really early to that sort of thing of small businesses and what it takes to make them operate from a holistic perspective, right? Of all the little things it takes to make those things work. When I went to school, I went to college. I've been kind of encouraged, and I felt people were right to go towards more of an engineering type degree. I actually enrolled in a mechanical engineering degree program. I sat through the intro to engineering course, the freshman one-on-one course, and they had this professional engineer come in and speak to us that day. And I remember sitting through that entire class session, and walking out there and said, that sounds like the worst thing ever. I think I would absolutely hate that. Really, the main thing I stuck with is that guy sits in front of a computer all day, and that sounds terrible. So, I promptly walked out of there and dropped the degree program, and ended up with a double major in the Bachelor of Arts program in video production and multimedia technology. You know, they're not really necessarily things I use exactly today, although I like to think some of the production quality and some of those kinds of things that I learned during that time still apply. But certainly not down a technical path directly. My last semester at school, I had to fill up some credits, sign it up, taking a programming course. And it was a C++ course, and the instructor was absolutely terrible. It was the worst ever, but for some reason, I think that kind of thing gets me kind of stubborn and maybe a little mad. I don't know. Anyway, I ended up grabbing the book and diving deep and grabbed a couple of other guys, and we went deep, and I kind of kicked myself at that point and go, wow, this was amazing. This is, I think, what I've always wanted to do actually was able to create things and be a maker. This is what I enjoy to do in a way that I didn't think was was really possible for me. So as I left there, I took a job at an ad agency and started doing websites. And this was in the 97, 98 era. So it was really early like database websites, you know, I enabled websites that kind of thing. I went from there to a larger pharmaceutical company and just kind of did a whole range of things there, but started moving up through some of the enterprise architecture groups and that sort of thing is I just start, you know, really just kind of a self studied person all along the way. I really, really loved to learn and everything from, you know, high level architectural patterns and details to software programming down to my new current joys have a electronics hacking hobby currently. So, so you know, things in the small circuits and all that kind of stuff. I felt very accomplished tonight when I replaced a broken just an AC plug for our refrigerator. Yeah, it's great, isn't it? But, you know, yeah, it's great. I feel equally incompetent when I look at some of the projects that I'm seeing, but that certainly is a significant amount of imposter syndrome, but I have absolutely no experience with this physical stuff and I really would love to get into it. Yeah, I'm learning a lot and I think that that for me was kind of the itch right I've been doing software for all of these years and it's kind of fun to see that come alive as well. That engineering degree would have would help you out. Yeah, so I'm going back and then kind of studying push the old math stuff and that kind of thing is I've gotten into it. So that's been fun. Yeah, it's amazing though. It's something that could have probably made that engineering degree significantly more attractive to you back then. It now exists and is accessible and relatively cheap. Yeah, yeah, it's amazing how much you can just learn on your own too, right? And I think it's really the main point for me is that I don't think I'm incredibly smart or intelligent anyway, but I'm very stubborn, incredibly stubborn. I think that's a common trait amongst quite a few developers actually is this, you know, I don't know that it's grit as much as it is. I think it can be as long as you can remember to keep stepping back and making sure what you're working on and doing is actually that important. Yeah, but because it is easy to get get kind of spiraled down or stuck down in something that's not but no, I think you're right. Today's episode is sponsored by the continuously awesome Linode. Linode is the best ram per dollar deal on the market for Linux service provision. In other words, you can spin up a box on Linode for fewer dollars per month and more accurately fewer dollars per hour than any other service for the ram that you receive. Especially when you start talking about their high ram plans, they have massive, massive plans that can service any number of users that you can imagine pretty much any application you can imagine building. Linode can support that, but they also support the small services they support the personal websites. You can start with the Linux box on Linode for five dollars a month and that's going to give you a gigabyte of RAM, right? This is well more than enough for most people's personal sites. And while websites are probably the most obvious use case for the five dollar month plan, you can really do anything with Linode. Anything you can do with Linux, you can do with Linode. So you may want to set up, for example, your own private Git server, you can do that with Linode. You have pretty much total access, total root control access over your Linux box. Go and check it out, spec.fm slash Linode. Linode is going to give you $20 worth of credit just for being a developer to listener. Now, there's a bunch of other stats. And as a Linode user, you have tons of other services that you can tap into beyond just having Linux box. They have APIs, for example, to coordinate all of your servers. You can spin up multiple servers and balance them together. You can have them kind of handle multiple requests. You can balance them together using their node balancer service. Again, check it out, spec.fm slash Linode. They're going to give you $20 worth of credit, which can be used on any of their hourly plans or services. Thanks again to Linode for sponsoring Developer Tea. So you have a very interesting story that I think is relevant to a lot of developers. I think it's easy to think about two extremes in terms of where people come from, their education levels. One is the person who never even went to college. They came out of high school and went straight to Silicon Valley and had to start up and lived in a garage. The typical kind of story of somebody who gets into coding. It suddenly turns on a light in their life and everything is illuminated from then forward. Then the flip side is the person who gets a CS degree and then goes on and gets a PhD in some bioinformatics or something like that. Then goes and creates a more court like a big company based on their acumen. The truth is a large, I would say, most people fall into a category more like you, Jason, where I don't know what I want to study. I'm going to try something. I didn't like it. I'm going to end up getting a different degree. Then I'm going to get out of school and not working anything related to my degree at all. I'm going to try playing around with this code. I'm going to try and become a freelancer. Now I'm good enough to actually go and work at a company. This is my story. This is actually a slightly modified version. It's basically my story. I have a bachelor of arts. I ended up getting a master's of science. That was still not directly related to my job. It's a very interesting thing. This industry doesn't really have that kind of accreditation. It's not like being a lawyer for example. There's no bar exam for developers. It's not really. It's an interesting thing because now you deal with this situation where you don't have formal training and you have these various moments in your career where you're like, wow, this is like a totally beginner thing that I'm learning five years in. How could I possibly have a career in this if I didn't know this? Well, and that's the great thing about this field I think is that it is approachable though because you can identify what you don't know. I think one of the best skills that developers can learn is being able to look at a really big problem space and start to lay down a plan and say, how do I get there and be able to draw boxes around the things that I don't know how I'm going to solve that piece. I'm going to do it right. I'll get there and do that. But there's so much to lean on and ability to go find those things that I can really make that work. I think for me, I've done a lot of hiring over the years and I had to be careful at one point in my history. I started to develop this anti bias towards people coming out of CS degree programs because I hired many who came in and I looked at the way they worked. They approached things. I felt like they were kind of doing it because they felt like they had to. They had gone through this program where somebody told me, you're good at math, you should go to CS degree, you know, probably make some money at it. That kind of thing and they come out and seem like they're doing it because they have to. I was almost for a while by seeing my thoughts the other way as I was evaluating candidates to people that were coming up through self study because it's like they've got some passion. They love what they're doing. They're going to continue to learn and grow and get better. I think that was too heavy of a blanket thought process as I was going forward. I think I do a better job at that these days. But honestly, that's the biggest thing in my opinion is how much she really love doing what you're doing because this is a great place to get to do that. It's a great career to do that. I think the biggest thing that not having a CS degree produces is a lot of this is such a worn out phrase but this imposter syndrome of, hey, I really don't know if my hours spent at night sitting in front of a TV, coding up websites. I don't see how that translates into maybe being qualified for a job. It's a very interesting thing that so many people have that same struggle, that same lack of confidence or maybe it's actually real. Maybe it's that you do have enough gaps in your knowledge that you're going to have to learn a lot on the job and that can be a tough problem to solve. I'd love to know Jason. If you can look back and try to, like we said previously, relive some of those moments. What was one of the hardest moments of your career? One of the most personal struggle or maybe you were trying to interview a bunch and nothing seems to be going your way. Can you share a difficult or dark moment in your career? I think there's two sides to it. I think you imagine the hiring side. That's always been something that's been challenging for me because I know myself and I know how I like to approach things and how I like to approach problems. I really desire that I think maybe a properly a lot of times too. But I desire that in other people as well. I want people to care as much as I care about problems and care about our company and care about the way we approach things. I've certainly gone through periods where it feels like we have a drought. I know of finding those kinds of individuals. I think in the early days it was much easier when we were small. That sort of thing, as we've grown bigger, it's just a percentage thing. There's just more volume. At times can become a little disappointing. But personally on the other side of that, I think, I'll try to think specifically of a few cases. I've been either working on a project or working through a problem where I get blindsided by something. Here's a good example. I tell people I struggle with because I think about it many years ago. There was a member of a team that was at a prior company. It was a member on our team that in my opinion at the time had a fairly negative influence on the team. It was kind of down on things and very vocally down on things. I had a lot of positive ideas. I recognize you see a problem. How are we going to fix it? That's what I wanted. Back off from that. I was chatting with another coworker about this. I set a few things and sent a link to an article I'd read because I was struggling with it in my mind. It turns out I made a terrible mistake. I actually sent this to the individual. Not the happy person I thought I was. It has a couple of great lessons learned from me coming out of that. That was an extremely hard thing for me. I'm deeply embarrassed of. I immediately had to take them out to lunch and say, I'm very difficult conversation at this point. I also led to some good outcomes where I had some very frank conversations that probably should have happened anyway. From the just pure tactical standpoint, always look at what you're doing and if you don't write it down, if you don't, it gets you to be written down. That was really hard. It's still something I look back at. I just face my hands and feel like, how could I have done that? It was just the not very professional for me. I suppose you have to go through some of those things to learn. I hear a lot of developers. I try to put my brain into the listener spot. I hear a developer right now who's saying, that doesn't happen. Perhaps as a manager, that I won't ever have a developer that's like that. If I ever have a frustration, that actually it's only my own fault. I just need to make sure that I'm understanding them and connecting with them as an individual. It's easy to have that perspective because it's easy to believe in people. It's easy to hire, for example. This is something that we've faced at Whiteport in the past. It's easy to hire somebody based on how well you can connect with them on a personal level, which shouldn't be ignored and that should be important. On the flip side, you end up with somebody who's underqualified for the job. Then you're in a really bad spot because not only are you actively creating a sinkhole in your business, but you're also in a relationally disadvantaged position. You can work on these things. Ultimately, what I'm getting around to here is you're going to have situations where, you know what, I do need to have a private conversation about an individual on the team. I need to bounce my perception off of another leader or I need to bounce my perception off of even a teammate of that individual to ask them, hey, what are you seeing with this person? There's a lot of tactics, a lot of specifics that the people who are listening to this episode, you're going to have to use your own judgment because there's not really a good framework. There's not like a perfect way to handle this stuff. Sometimes that direct conversation is the best way to handle it, but sometimes that is actually way premature. Sometimes it's going to blow up in your face. Yeah, I think that's such a good lesson to learn. I actually have a very similar story, except instead of an individual that I was managing, I actually sent a complaint about one of my leaders directly to the leader. At that moment, actually, the leader handled it very, very well with a lot of grace and a plum. That was a leadership lesson for me because I wasn't really a leader yet. I wasn't really over, you know, in charge managing anybody. When I saw that, that told me about how I can be in the future. That's kind of an opportunity. I think I needed a bounce idea off of another leader or whatever that may be. We see these things all through our company, these ripples of things that we do on project levels that actually have huge effect everywhere. It's the same thing. I'll go turn on my light and think about a problem. I need to talk to another leader about, you know, I guess, some feedback. I'm thinking about handling this situation like this. What do you think? Just like I might do the same thing around an algorithm or something like that. So I think that that cycle is really critical, especially for me. I am very open with everybody on my team and around me is that I am not going to be the world's best manager. It's just really not the thing that I was really made for. I'm in this role and I care about people. I want to do my best to serve that well. But at the end of the day, we're going to have to be frank and open with each other. We work through these things to make this work. So we do a great point. I think I really stand out moments. I actually had a standout moment in my career when I was very early on when I was at whiteboard. I was working with a client and I was managing a lot of the relationship. I was going and meeting in person and talking about implementation of the product and ultimately things just kind of going the wrong way. A lot of that was on me. A lot of it was on just it wasn't a good fit. And finally, in one of those client meetings, it's just me and two or three of that clients, individuals, and they fired us. They let the agency go. And I remember walking out of that meeting, first of all, feeling like that was the right that needed to happen. That was the right thing. We needed to sever the relationship because it wasn't going well. We weren't seeing eye to eye. We weren't able to help you, you know, that client in the right way. But then the next thing that was so interesting and this is this standout moment, the first person that I thought to call a lot of people would say, oh, you're going to call your wife or your girlfriend or a close friend or a coworker. Actually, I called my boss. I called the owner of our company and I said, hey, look, this is what happened. And that moment was such an important moment for me because I realized, you know what? I actually trust my boss. I don't I don't fear that a mistake is going to destroy my standing, you know, they believe in me and I believe in them. And that's such a good, you know, I'm not bragging on it. But I think that this, this is a picture of a very good relationship. And something that I want to do for people as well. And I think I think it's a good quality to have. Yeah, absolutely. So we talked a little bit about some of the dark points and the difficult, you know, going through that. I want this is this is kind of on a flip side, a heuristic for the developers who are listening, just kind of a practical question. How many languages and frameworks and and stacks have you worked with, let's say in the last five years? Oh gosh, a lot, right? Yeah. So the last five years, it's been a little more narrow. I say in the early part of my career, it was really all over the place. And, you know, like, during my first five years, I'd say that they was like 13 to 16, you know, that kind of thing. I think it was just like huge sponge phase at that point. More recently, I think for me, I'm getting old, I guess. I'm getting at the point where looking around the landscape in 2017, there's a lot of great tools out there. There's a lot of great languages. I actually don't feel very dogmatic about many of these things. And it's so much more about execution and how you go about using these tools and becoming expert in them that make you really great. So I can tell you at developer town, you know, we have focused primarily around, you know, web applications and mobile applications. So on the website, we've primarily been around just Ruby on Rails for a lot of years. And we're now through a period of transition into really two directions around kind of just the node environment as a whole and the dot net environment as a whole. And I think that kind of these two separate branching points are the mobile side, you know, less Java and objective C and a little bit of Swift. I think I've not personally spent as much time there. So I'd say everything that I've done in the last five years has been really kind of focused around those areas. So I guess we'll put that count. It's like the five or six just in kind of rough numbers. We have a task that, especially for a person, a CTO leader of other developers. There's a lot of people who are listening to the show right now and they're trying to pick just one thing and probably with good intentions, right? They want to pick something that's going to be reliable and they want to pick something that's that they can trust and use and that's going to quite honestly make them employable. And that's what it says, you know, while when you're especially a very early in your career, you do, I think you need to have a primary focus, a primary focus language or something like that. When you actually get into solving problems and working in a dynamic environment, those languages and frameworks that, you know, you really thought you needed to pick one. You're going to find out that things are going to move so quickly that whatever you picked is going to be one of many. And I like to, I like having that answer from you so that we can kind of lay the groundwork for, hey, you know what? This is less about the language. It's less about the framework. Those things are important, but the bigger or more important thing here is to understand the problems you're solving. Right? I have salespeople that will go out, that sort of thing. And they'll ask about the technology side. And at least my input is when we're starting to talk to new clients and that sort of thing, I really like to not because I'm embarrassed about it, but I feel like it is a little bit distracting to downplay just the pure technology side because if we don't understand our problems, basically don't understand the real business problem or how this drives towards a particular goal, be it revenue or reach or or, you know, charitable or whatever. That outcome maybe you really have to focus around that because we've seen a lot of projects that just kind of fall apart, not because of any particular language issue or framework issue or technology issue, but because the business didn't have a solid understanding of the business as a whole or how that was going to be accomplished. So it's really kind of a root problem set to know that you've got your arms around it or at least if you don't have your arms fully around it, know what you need to discover. And go from there. Sure. Yeah. It is so important to kind of strip things back. And I think I think a lot of developers have the preconceived notion, you know, coming out of a CS degree, for example, a lot of computer science degrees are going to teach you Java. And that's kind of the thing you're going to rely on. You can build a long and successful career using just Java. There are a lot of tools out there. There's a lot available to learn and new capabilities are going to increase your, you know, the number of things you can work on in the ways that you can work on them. But getting to to hung up on it is certainly one of the killers of progress for developers and especially when it causes indecision and when you, you know, you're not moving forward because you're so concerned about picking the right thing to learn or to implement for that matter. I've kind of always enjoyed just kind of embracing that issue as a whole. So, yeah, I think it really the light turned off. I was a classically a Java guy myself, you know, way back when. And before it was cool, so I guess that makes me a hifter. I was looking at a so early stuff, you know, like pretty, you know, way pretty looks are in all that stuff. And, you know, I got, I went through there, I built a few things just kind of personally on the side with it is like, you know, that was really cool. And I think we're actually building anything with this, but it really informed the way I thought a lot about the next project and and and bill, you know, just from an architectural standpoint and, you know, so the immutability and the safety standpoints, all those kinds of things, it was really kind of changed the way I thought. So I really encourage people to go out and an experiment go try lots of different things, especially try things that are outside of your comfort zone. Just don't go pick like another sea bass language or whatever is like sure, yeah, different API or whatever, but you know, go try something fundamentally different, you know, toy around with it, you're going to learn something that will probably apply in some way back to what you do today today. You know, it's very interesting that you mentioned the the early thing. I had a very similar experience with Haskell and then very short kind of dive into this and small talk some interesting languages. But what I've learned is, you know, that experience that you had with early, the experience I had with Haskell and other functional stuff, that's not just limited to other tech. It's not just limited to programming languages or paradigms. You can gain that kind of interesting perspective from so many sources. I'll give you an example. I mentioned on the show before that I'm interested in aviation and that I from time to time I fly small planes set like Cessna, High Wing, you know, private airplanes. Sure. You know, some of the designs, the system designs in a vehicle like that or take, you know, a house, the architecture of a house and how things are built and the way things are mapped and the flow and, you know, considering people and how they interact with their environment. There's so many things that you can take and extract, you know, I almost want to call it wisdom, but really it's just extract this architectural perspective that you didn't have before, right. There's a lot of this in mechanical engineering and there's actually a lot of this in like philosophy, right. There's so much that you can gain from getting this more multi disciplinary kind of perspective. So I highly encourage people all the time to find things that give them good metaphors. There's something I really believe in a lot. And if you have good metaphors, then you can understand a subject. Your brain can grasp a thing better if you can compare it to something else. It's kind of an amazing phenomenon, right. Yeah, as I was working through some of this electronic stuff, I mean, I am, I am raw newbie status, so I don't have any. I, I view myself here, but I was working through it just a, you know, building up a problem and this one section of it was fairly complex and I had to go build another section that was, you know, a whole different thing, but also had his own complex issues as well. And all of a sudden this whole concept of, you know, partitioning and single responsibility and all these things, all of a sudden, stabbed into focus. I was like, holy cow, this is the same stuff we think about in software architectures, the same things we're doing here, like let's isolate this complexity. Let's make these interfaces clean and simple and understandable and that makes the approach much easier. It's amazing how much of this stuff can overlap and what you can learn if you're, you know, eyes open is kind of the way I think it's. You know, let everything that you experience bleed into everything else and I'm not saying, you know, have a lack of balance in life. But instead, like don't sequester your free time, your leisure time, often to its own area where you never allow that to enter your brain. And quite honestly, it's, it's impossible for you to do that anyway, but pull from that. Take some, take some cues from the things you enjoy naturally, right? Take some cues from other systems that you interact with. Take some cues from, you know, I know a lot of developers who are able to draw from their, from like physical exercise as, you know, ways of thinking about load, for example, right? Yeah. Yeah. Very interesting and, and vast array of knowledge that we can use because the cool thing is, you know, good software is able to model a lot of this other stuff. Good software can take a concept and realize it in a virtual environment. And that's kind of the backing, that's the structure and the underpinnings that make it possible to use all of these other things that we're experiencing externally and bring them into the work that we do virtually. Yep. I think that's perfect. Thanks again to Jason for joining me on today's episode and go and check out developer town. If you have not yet already seen the awesome pictures of their little neighborhood there. And of course, you can email them if you want to drop by and check out what they have going on there as well. Thank you so much for listening to today's episode and thank you to Linode for sponsoring today's episode. Go and check out Linode's services by heading to spec.fm slash Linode and remember the code Developer Tea2017 at checkout for $20 worth of credit. If you are a driven developer, if you consider yourself in that group of people that we talked about at the beginning of today's episode. As this show progresses into the future, we're going to continue honing it in on this concept of finding your career purpose and really kind of diving in deeper on what it means to decide what you won't do. Cutting out some of the stuff that takes away from your focus. Cutting away this idea that the best way to make it through life is to find all the hacks that you can find. That's not what this show is about. And sometimes the hard road is the best road. So if you consider yourself a part of that group, part of the group of people who is willing to take the high road even if it's more difficult to travel on. Then I recommend that you subscribe and whatever podcasting app you use and just listen to a few more episodes. That's what I'm really asking you to do. You can decide this for yourself, but listen to a few more episodes and judge for yourself if this stuff is clicking with you. And I want to hear from you if it's not. If you consider yourself a part of that group and this isn't clicking for you, then I want to hear from you. Because I want this podcast and everything that I do really to serve that group of people. So you can reach out and ask me questions as well at developert.gmail.com. We cover listener questions on the show as well. Thank you so much for listening. Make sure you subscribe. Especially if you don't want to miss out on the next episode, the second part of this interview. And until next time, enjoy your tea.