Today's episode is all about the environments we work in and the skills that contribute beyond the code. Jason Vasquez, CTO at Developertown, joins me as a guest. Today's episode is brought to you by Linode. Linode Provides superfast SSD based Linux servers in the cloud starting at $5 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners .
Today's episode is all about the environments we work in and the skills that contribute beyond the code. Jason Vasquez, CTO at Developertown, joins me as a guest.
Today's episode is brought to you by Linode.
Linode provides superfast SSD based Linux servers in the cloud starting at $5 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners!
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 Vesquez. 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. We 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 Cottrell. 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 one, which is the second episode of the show. And I'll see you in the next episode. 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? Yeah, sure. So when we started Developer Town in 2010, we started in a small, kind of light industrial office space, kind of 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. And a house for us is either an 8x10 or 8x12 full house. We're talking walls, windows, roof, doors, the whole thing. And we had a really fun time. And we had a really fun time. And we had a really fun time. And we had a really fun time. And we had a really fun time. And we had a really fun time. And we had a really fun time. They're all on wheels. And 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. And it's been really nice because we can group them either on your specialty area, your practice area, or by project team. And it makes for a nice kind of cohesive unit. So in the olden days, you might have had a cubicle, right? With your... Little personal item or whatever. Sure. And when you moved, you know, you kind of put yourself up, put yourself in a box and moved 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's cool. Yeah. Very cool. And so if I'm a developer at Developer Town, you know, I get a chance to... How much of the... 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 a developer get to participate in? Yeah. So we had this theory when we started that we wanted developers to actually build their own house. We thought that would be a good experience thing and, you know, kind of be a cultural, iconic thing for Developer Town. We... Well, especially in the early days, we were scrappy, you know, making ends meet and that kind of thing. Turns out the actual construction of the house, 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... And, well, everybody in the company are responsible for decorating. So, you know, first off, your very first question we were getting, not very first question, but, you know, as you're onboarding is choosing house colors. So we'll 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 uniqueness. 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 with 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, 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 shtick, another cultural thing. And I want to challenge developers to think differently about this, specifically about thinking about your environment. Whether you go and work at 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, that 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, 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 effect of somebody walks in, flips their light on, and you never hear from them again. Really, you see them used judiciously. 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 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, 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 hyperproductive 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've 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, 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 program, programming, you know, idea or whatever. And you've decided that that's your focus time. And instead of actually, you know, going in 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 a hundred times on the show before, but I had the same swing of, you know, man, I finally, I finally invalidated that 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 ahold of me. They 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, to get down and 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, okay. 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 make sense? You know, cause, and get out of that kind of siloed kind of mindset where you fall in love with your ideas. And, and, and don't get that outside input. So I think, I think that balance really is, is effective. Yeah, it's the, the balance is the key. And I think that's, that's something that 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 enjoy it there. I think in my role, especially, I prefer to be, you know, more visible and approachable, you know, that, that sort of thing. Even though I have, you know, 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, but I think providing the, the right venues has been, has been great. And, 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, you're optimizing for one particular style of working or you're optimizing for one particular opinion, you may have evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution Optimize for approachability, right? This is something that you care about. It's a part of the role. I'm also a CTO. I have to optimize for approachability 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? And 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 common area or whatever. Yeah. Yeah. And it's great. We've got a nice big skylights and everything. So it actually 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? Yeah, absolutely. They should certainly get in touch with me or anyone else, honestly, and we can set that up. We just like to greet people and we're 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, you know, 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 your brain back into early, early years. What first got you interested in software development? Yeah, okay. So probably, 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. You know, like an electronics company that we, you know, purchased in, worked on a little bit and sold and a fishing tackle company and, you know, all sorts of little things like that. So got exposure really early to that sort of thing of, you know, small businesses and what it takes to make them operate from a, from a, just 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'd been kind of encouraged and I, and I felt people were right to go towards more of an engineering type of thing. And I think that's what I've been doing for a long time. And I think that's what I've been doing for a long time. And I think that's what I've been doing for a long time. And I think I actually enrolled in a mechanical engineering degree program. I sat through the intro to engineering course, you know, the freshmen, you know, one-on-one course, and they, they had this professional engineer come in and speak to us that day. And I remember sitting through that entire, that class session and walking out of there and said, that sounds like the worst thing ever. I don't, I think I would absolutely hate that. That guy, and you know, really the main thing I stuck with is that guy sits in front of a computer all day and that sounds terrible. So I, I promptly walked out of there and dropped the degree program and ended up with a double major in a, in a bachelor of arts program in video production and multimedia technology. So, 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, my last semester, at school, I had to fill up some credits. I ended up taking a programming course. And it was a C++ course. And the, the instructor was absolutely terrible. It was the worst ever, but, but for some reason, I think that was, it actually, that kind of thing gets me kind of stubborn and, 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 in deep and I, I kind of kicked myself at that point and go, wow, this was amazing. This is, I think, the best thing I've ever done. What I've always wanted to do, actually, you know, was able to create things and, and, and be a maker. It's just what I enjoy to do in a way that I, I didn't think was, was really possible for me. So as I left there, I, I took a job at an ad agency and started doing websites. And this was in the 97, 98 era. So it was some really early like database websites, you know, enabled websites, that kind of thing. I went from there to a, a larger pharmacy. And just kind of did a whole range of things there, but I started moving up through some of the enterprise architecture groups and that sort of thing as I just started, you know, really just been kind of a self-studied person all along the way. Really, really loved to learn and everything from, you know, high level architectural patterns and details to software programming down to my, my new current joys. I have a electronics hacking hobby currently. So, so doing things in the small circuits and all that kind of stuff. So, I felt very accomplished tonight when I replaced a broken, just an AC plug for our refrigerator. Yeah. Yeah. That's great, isn't it? But, you know, yeah, it's, it's great. I feel equally incompetent when I look at some of the projects that I'm seeing, but that's certainly is a significant amount of imposter syndrome, but I have absolutely no experience with this physical. And I really would love to get into it. Yeah. I'm learning a lot. And, and I think that, that for me, it 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 going back, I've been kind of studying much of the old math stuff and that kind of thing as 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. More attractive to you back then. It now exists and, and is, is accessible and relatively cheap. Yeah. Yeah. It's amazing how much you can just learn on your own too, right? Be it through, you know, online universities or, or just self-study. And I think, you know, really the, the main point for me is that I don't think I'm incredibly, you know, smart or intelligent anyway, but I, I am very stubborn, like incredibly stubborn and I will second that. Yeah. I don't 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 maybe a healthy obsession. Is that the right way to think about it? Yeah. I think, I think it can be as long as you can remember to keep stepping back and making sure that you're doing the right thing. Yeah. Yeah. Yeah. Yeah. Making sure what you're working on and doing is, is actually that important. Yeah. But, cause it is easy to get, get kind of spiraled down or stuck down in something that's not, but, but no, I agree. 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. At the same time, you may find your building, Linode can support that. But they also support the small services. They support the personal websites. You can get started with a Linux box on Linode for $5 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 $5 a 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's going to give you $20 worth of credit just for being a listener. Now there's a bunch of other stats, and as a Linode user, you have tons of other services. You can do a lot of things with Linode. You can do a lot of things with Linux. You can tap into beyond just having a 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. You know, I think it's easy to think about the two extremes in terms of where people come from, their education levels. One is the person who never even went to college, and they came out of high school and went straight to Silicon Valley and had a startup and lived in a garage. And, you know, the typical kind of story of somebody who gets into a business and they're like, I don't know, I don't know, I don't know, I don't know, I don't know. And then the flip side is, you know, the person who gets a CS degree and then goes on and gets their PhD in some kind of bioinformatics or something like that, and then goes and creates a more, like a, I don't know, a big company based on their acumen. And the truth is a large, I would say most people fall into the trap of a CS degree. And so, you know, I think it's into a category more like you, Jason, where, hey, 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, you know, getting a different degree. And then I'm going to get out of school and not work in anything related to my degree at all. And hey, wait a second. I really like making stuff. And I'm going to try, you know, playing around with this code. I'm going to try and I'm going to become a freelancer. And now, oh, I'm good enough to actually go and work at a company. And this is my story, right? This is actually, I have a slightly modified version, but it's basically my story. I have a Bachelor of Arts and I ended up getting a Master's of Science, but that was still not directly related to my job. And so, you know, it's a very interesting thing. This industry doesn't really have that kind of accreditation. It's not like, you know, being a lawyer, for example. There's no bar exam for developers, right? Not really. And so 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. And, you know, how could I possibly have a career in this if I didn't know this? Right. 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, right? And I think that's one of the best skills that developers can learn is, you know, being able to look at a really big problem space and, you know, start to lay down a plan as to how they'll 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'll get to it, right? I'll get there and do it. But there's so much to lean on and ability to go find those things that 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, I was like, I'm going to do this. I'm going to do this. I'm going to do this. And I started to develop this anti-bias towards people coming out of CS degree programs because I had hired many who came in and I looked at the way they worked, the way they approached things. I felt like they're kind of doing it because they felt like they had to. Yeah. They'd gone through this program where somebody told them, hey, you're good at math. You should go CS degree, you know, probably make some money at it, you know, that kind of thing. They come out and seem like they're doing it because they have to. And I was almost for a while biasing 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. So I think I do a better job at that these days. But honestly, that's the biggest thing in my opinion is how much you really love doing what you're doing. Because this is a great place to get to do that. Right. Yeah. And it's a great career to do that. I think the biggest thing that, you know, not having a CS degree produces is a lot of this. And this is such a worn out phrase, but this imposter syndrome of, you know, hey, I really don't know if my hours spent at night, you know, sitting in front of a TV coding up websites, I don't see how that translates into me being qualified for a job. Right. And it's a very interesting thing that so many people have that same struggle, that same kind of lack of, it's a, you know, maybe it's a 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, that can be a tough problem to solve. I'd love to know, Jason, if you can look back and try to, you know, like we said previously, relive some of those moments. What was one of the hardest moments of your career? One of the most kind of the personal struggle, or maybe it was you were trying to interview a bunch and nothing seems to be going your way. Can you share kind of a difficult or dark moment in your career? Yeah, I think there's, there's two sides to it. I think, yeah, you mentioned the hiring side. That's, that's always been something that's been challenging for me because I, I know myself and I know how I like to approach things and how I like to approach problems. And I really desire that. I think maybe improperly a lot of times too. But I desire that in other people as well. Like I want people to care as much as I care about problems, you know, and care about our company and care about the way we approach things. So, um, I've certainly gone through, where it feels like we just, we have a drought, you know, finding those kinds of individuals. And, um, I think in the early days it was much easier when we were small and, you know, that sort of thing. Um, as we've grown bigger, it's just, it's just a percentage thing, you know, there's just more volume. So that at times can become a little disappointing. Um, but personally on the other side of that, I think, um, I'm trying to think specifically of a few cases, uh, you know, as I've been, you know, either working on a, on a project or working through a problem where I kind of get blindsided by, um, by something. I, uh, let me, I, here's a, here's a good example. And it's still something I tell people I struggle with because I think about it. It's many years ago, there was a member of a team that was at a prior company that there was a member on our team that, you know, in my opinion at the time had a fairly negative influence on the team. Um, he was kind of, I was kind of down on things and very vocally down on things. And, you know, without, you know, in my opinion, didn't at the time have a lot of like, positive ideas. Okay, great. I recognize you see a problem. How are we going to fix it? Right. That's, that's what I want to hear. Just, you know, you know, back off from that. And I, um, I was, uh, chatting via IM with, um, another coworker about this. And I, um, you know, said a few things and sent a link to an article I'd read cause I was just really kind of struggling with it in my mind. And it turns out I had made a terrible mistake and I had, um, actually sent this to the individual. Not the person I thought I was, uh, which has a couple of great lessons learned for me coming out of that. But that was a extremely hard thing for me. And it's still something I am, you know, deeply embarrassed of, you know, I immediately had to take him out to lunch and say, you know, like very difficult conversation at this point. Um, but, but it also led to some good outcomes where we had some very frank conversations that probably should have happened anyway. Um, but, you know, from the just pure, uh, tactical standpoint, always look at what you're doing. And if you don't want another, don't write it down. If you don't think it should be written down, right. Uh, that kind of thing. Um, but that, that was really hard and it's still something I look back at and I just, you know, put my face in my hands and go like, how could I have ever have done that? It was just, uh, not very, uh, professional on, you know, for me, but I suppose you have to go through some of those things to learn, right. And I feel them. Here's, here's, I hear a lot of developers. I try to, uh, uh, kind of put my brain into the listener, uh, the listener spot. And I hear a developer right now who's saying, uh, you know, uh, that, that, you know, that doesn't happen or, or, uh, you know, perhaps as a manager that I won't ever have a developer that's like that, that if I ever have a frustration that actually it's only my own, my own fault, or, you know, that, that I just need to, you know, make sure that I'm understanding them. And connecting with them as an individual. And it's easy to have that perspective because it's easy to believe in people. Uh, it's easy to hire, for example, and this is something that we faced at whiteboard, uh, in the past, it's easy to hire somebody based on how well you can connect with them on a personal level, which is shouldn't be ignored. And that should be important. But on the flip side, you end up with somebody who's underqualified. For the job. And then you're in a really bad spot because not only, uh, did, uh, are you kind of actively creating a sinkhole in your business? Um, but you're also in a relationally, uh, disadvantaged position. And, uh, so, so, you know, you can work on these things, but ultimately what I'm, what I'm kind of 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, um, that, that it's the individual. I'm not ready to pull them in yet. I need to bounce my perception off of another leader, or I need to bounce my perception off of, you know, even a teammate of that individual to ask them, Hey, what are you seeing with this person? Or, you know, and there's, there's a lot of tactics, a lot of, uh, uh, 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. Um, there's not like a perfect way to handle this stuff. Right. Uh, sometimes that direct, uh, uh, conversation is the best way to handle it, but sometimes that is actually way premature, right. And sometimes it's, it's, it's going to blow up in your face. And, um, yeah, I think, I think that's such a good lesson to learn. And I actually have a very similar story, except instead of an individual that I was managing, I actually sent a complaint, uh, about one of my leaders directly to the leader. Yeah. Yeah. Very awkward. Yeah. But at that moment, actually the leader handled it very, very well with a lot of grace and aplomb. And that's the kind of, uh, uh, you know, that was a leadership lesson for me. Um, because I wasn't really a leader yet. I wasn't really over, you know, in charge, managing anybody. And when I saw that, um, that told me about how I can be in the future. Right. It's kind of an opportunity. Well, and you mentioned, um, you know, needing to bounce an 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 like on project levels that actually have huge effect everywhere. And, um, it's the same thing. I've go turn on my light and think about a problem I may be having, but I need to go talk to another leader about, you know, get some feedback. And so I'm thinking about handling this situation like this. What do you think? Um, just like I might be able to do it, but I'm not going to be able to do it. Um, and so I'm thinking about handling this situation like this. What do you think? Um, just like I might do the same thing around like an algorithm or something like that. So I think that that cycle is really critical, uh, especially for me. Cause I, I, I, um, very open with everybody on, 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. Um, I'm, I'm in this role and I, I care about people. Right. And I want to do my best to, uh, to serve that well. But at the end of the day, we're going to have to be, you know, get open with each other as we work through these things to make this work. So, um, so yeah, it's a great point. I think a really, you know, standout moments. I actually had a standout moment in my career when I very early on when I was at whiteboard, uh, I was working with a client and, you know, I was managing a lot of the relationship. I was going and meeting in person and talking about, uh, implementation of the product and ultimately things just kind of going the wrong way. Uh, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and so, and a lot of that was on me. A lot of it was on just, it wasn't a good fit. And finally, you know, in one of those client meetings, it was just me and two or three of their, uh, of that client's individuals. And they fired us. Um, they, they let the agency go. And I remember walking out of that meeting, first of all, feeling like that was the right, that, that needed to happen. That was the right thing. Uh, we, 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, that client in the right way. Uh, but then the next thing that was so interesting, and this is the standout moment, the first person that I thought to call, a lot of people would say, Oh, you're going to call, you know, 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. We've 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 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, my first five years, I'd say it was like 13 to 16, you know, that kind of thing. I think I was just like huge sponge phase at that point. More recently, I think for me, I'm, I'm getting old, I guess. I'm getting to 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 an expert and then that make you really great. So I can tell you at DeveloperTown, you know, we, I've focused primarily around, you know, web applications and mobile applications. And 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 .NET environment as a whole. Kind of these two separate branching points. On the mobile side, you know, lots of 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 at like the, you know, five or six, just in kind of rough numbers. The reason I like to ask that, especially for a person, a CTO, leader of other developers, there's a lot of people who are listening to this 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 the truth is, you know, while when you're, especially 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, ultimately 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, more important thing here is to understand the problems you're solving. Right. I have, you know, salespeople, that'll go out, that sort of thing, and they'll, 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 problem space, if we don't understand the real business problem or how this drives towards a particular goal, be it revenue or reach or charitable or whatever the outcome may be, we really have to focus on 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 as you go and go from there. Sure. Yeah. It is so important to kind of strip things back. And I think a lot of developers have the preconceived notion, 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 the number of things you can do. So I think it's really important to kind of strip things back. work on and the ways that you can work on them. But getting too hung up on it is certainly one of the killers of progress for developers, especially when it causes indecision and when 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 I think it really, the light turned off. I was classically a Java guy. My second year of college, I was a Java guy. I was a Java guy. I was a Java guy. I was a Java guy. I was a Java guy. I was a Java guy. I was a Java guy. I was a Java guy. I was a Java guy. Way back when. And before it was cool. So I guess that makes me a hipster. I was looking at Erlang stuff, you know, like, like, you know, way pre-Elixir and 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. It's like, you know, that was really cool. I don't think I'll ever actually build anything with this, but it really informed the way I thought a lot about the next project I went out and, and built. just from an architectural standpoint and then some of the immutability and the safety standpoints, all those kinds of things. It's really kind of changed the way I thought. So I really encourage people to go out and experiment. Go try lots of different things, especially try things that are outside of your comfort zone. Just don't go pick like another C-based language or whatever is like, sure, a different API or whatever. But go try something fundamentally different. Toy around with it. You're going to learn something that will probably apply in some way back to what you do day to day. You know, it's very interesting that you mentioned the Erlang thing. I had a very similar experience with Haskell and then a very short kind of dive into Lisp and Smalltalk, some interesting languages. But what I've learned is, you know, that experience that you had with Erlang, 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 from time to time, I fly small planes like Cessna, high wing, you know, private airplanes. And, 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, and 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 multidisciplinary kind of perspective. So I highly encourage people all the time to find things that give them good metaphors. And 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, and you can understand 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 raw newbie status, so I don't have any high view of myself here, but I was working through just 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 its 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 snapped into focus. I was like, holy cow, this is the same stuff we think about in software architecture. It's the same thing as 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, you know, eyes open is kind of the way I think. You know, let everything that you experience bleed into everything else. And I'm not saying, you know, have a lack of balance in your life, but instead, like, don't sequester your free time, your leisure time, off into its own area where you never allow that to enter your brain. And quite honestly, it's impossible for you to do that anyway, but pull from that. 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? Sure. A very interesting 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. Go and check out Developer Town if you have not yet. I've already seen the awesome pictures of their little neighborhood, 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 services by heading to spec.fm slash Linode and remember the code developer T 2017 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, we're going to be talking about the future of the world. 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, you know, 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, you know, I'm not going to be talking about that. And sometimes the hard road is the best road. So if you consider yourself a part of that group, a 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 in 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 at 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.