career development, technology skills, management

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Hello and welcome back. We are continuing our season of interviews, and we wrapped up one and moving right into another. This next couple of probably about three or four episodes again, we're going to talk with Timothy Stratton. You may have heard him before. I'll introduce him again here in a minute. He has been a part of the, we'll call it the Develop-a-Noor team for a while, and has popped up before in some of the things that we have done. We will get started here this episode. I think I'm just going to avoid spoilers. I'm going to essentially shift gears here real quick, and we'll get it started, and then we'll wrap it up after getting through this first part. Without any further ado, here is Tim Stratton. First, I want to welcome you, Timothy, to our huge, maybe not so much, audience of Building Better Developers people out here in the podcast world. You may have been, some people may be somewhat familiar with you, as you've worked with us now for a couple of years. You've put together a presentation here and there, and definitely have been an active member of the mentor group. But because you come from a different background, have gone a different approach to your career, and also are solidly, I would say, in the early to mid stage of it, where I think you're pretty comfortable with what you want a little bit out of your career, plus definitely have some experience of initial steps, and you've been able to see what was good and maybe what you would adjust. I think we've got some great topics to cover here. I guess just to start it off is if you want to give a little background of professionally, where you at, what are you doing, if you want to throw some personal stuff in, that is awesome as well. But give us a little introduction in your own words of who is Timothy Stratton. Thank you, Rob. Yeah, Timothy Stratton. I'm a millennial developer turned in a development manager. I've been in a management position at my current company, Exilis, for it'll be a year in September, so three months away from that. And it's all new, lots of learning to be done where you think you're sufficient in technology. You've got a whole new arena of skill sets to learn and experience to be had in management, in administration of development and technological tasks. So backing up some from the management, I've been a developer, mostly Java development, but done a little bit of almost any language. C-sharp, Perl, Python, trying to think of PHP, lots of different languages, a few foreign technologies, mostly some Angular in my career. But yeah, just a lot of cool things I've done. A lot of things I've done with Rob. He's given me the chance to stretch my legs in the contracting arena where I've gotten a few contracts through him, worked for him on some contracts. All those were really fun things. And I will say some of the best learning that I got to do as a developer, being able to switch from project to project, learn a new stack, learn a new kind of workflow, and just really learn the technology in a lot of senses. My background was not development in school. I was going to do engineering, mechanical engineering, in fact. And so I did a research program wherein I was doing, I hope this doesn't sound too crazy, I was doing the system identification of robotics. So mechanical engineers would come in and write out the mathematics for robots so that control systems engineers could then create control systems. That is to say the mathematics that controls the motion of those robots. So that was my research task. And from that, from the system ID portion, I got to start doing computer engineering and really just trying to understand software. So that is how I got into software. I went on to get my degree in computer information systems engineering with that background in control systems and robotics. And ultimately, I did about four years of research. I did never get an internship or anything like that, just straight research. I got to publish a few page papers in the arena of control systems engineering and then graduated. Soon after graduation, I found that not having an internship at a company kind of actually hit me. So I had to kind of scrounge around and find a job where people would accept someone who did not have more of the traditional experience of a college graduate. So I went in and got a job paying $14 an hour at a friend's company as a contractual where I was going to be doing development. It was a C sharp shop. And that was fun. I got to stretch my legs, come up with some crazy applications there where we were trying to integrate data from different systems into a marketing analytics system. And then that from there, I met Rob and that's where our friendship relationship mentorship took off. He was the first real job, I would say, out of school under him. And we've been able to really do some cool things, I feel, since since that point. So I've been knowing him about what seven, eight years. So, yeah, yeah, it's getting to that point. Well, thank you. That's a awesome introduction. And thank you for all the kind words there. That actually leads me that's actually something I didn't have necessarily on my list. But as you mentioned it, one of the things we do talk about a lot is having a broad, technical, you know, a quiver with a lot of technical arrows, you know, being able to, to work in modern stuff like, like an Angular or React and then other, I guess, more established modern like a C sharp or Java. You mentioned you've you've been able to work in a lot of those. How much of that comes from, you know, maybe in an intentional kind of approach or some sort of a plan you had versus maybe just where your career took you? Yeah, I would say the second option where the career took me. And I think I've got no qualms in saying that I believe that, you know, our lives do have some sovereign guidance over it. You know, I believe sometimes I feel like a flag in the wind, wherever wind blows is where I'm going. And thankfully, I've been privileged to get experience in a lot of different arenas, you know, through our friendship and through the contracts we've had, I can probably attribute half if not three quarters of the technologies I've worked in. And it's not by chance. I don't believe that by any means. But then from there, it's also, you know, I think, as you said, being able to have all those technologies in the quiver just opens the mindset. We attend that conference, the Global Leadership Summit, and there's oftentimes a discussion around how diversity fuels creativity. When you have that diverse background, I'm probably getting ahead of you in the interview here, but being able to say I worked in so many different technologies, and I wouldn't even say it's so many. There's so much out there. But the few things that I've worked in, I really do feel have fueled a creative desire in me to, regardless of the tool, figure out the problem and apply the correct tool. So with that is so now that you've had multiple experiences where you've had to come in to some extent, new again, or very, you know, minimal to zero to at least little experience into some of these roles, what are maybe some things you've learned or some some words of wisdom you can give to others that are are faced with those situations and maybe a little bit of how you what your attitude sort of is, and maybe even a little bit of what your attitude is. And how that even has evolved as you've seen those from maybe the first couple of times to, you know, more recent times when you've had to, you've had something presented that is either unfamiliar or brand new. Yeah. Understand what it is that needs to be done, understand the problem. There are parts of me people in technology, who are coming in guns blazing and really aren't understanding the problems that they're trying to solve they're just maybe trying to reinvent the system that they did in the past. This is what I would say to the younger me around my attitude for approaching a new project, because I certainly can't say that I was not that guns blazing guy in the past. I've done that. But that said, you know, one of the things that I would say, even now I'm approaching a bit of a pivot and some new projects is search out documentation, don't be afraid to have those conversations with people who have been there and understand. I cannot tell you how much context, it gives me as a developer. When I go and I speak to the people who are on the front lines, be they technical or non technical, because they've got to use the software and how they use it should shape how I build it, not the other way around. I shouldn't be trying to dictate well this is what you got to do. Facebook doesn't become Facebook, because they lock everybody into one use case. You give diversity and you give that ability to do not necessarily anything you want to do but a multitude of things that people may want to do and how they use it is then what makes software so cool. Some people use Facebook as keeping up a family. Other people may use it as a social gatherings virtually. There's so many different ways to use, as I'm using an example, Facebook, but it doesn't come by coming in and saying well this is how I expect everything to be. It comes by understanding, getting context, understanding what people want, how they want it and then going from there. Of course that agile mentality coming in and getting iterative feedback. Yeah, that's I think part of that guns blazing kind of thing is maybe it's just because I've done the same thing, but it seems like it's definitely not uncommon, at least amongst the two of us. That's 100% of where that has happened. And, you know, I think it's, it's one of those things where you get something, you have something new, and you want to use it. And, you know, when you're starting out, everything's new, everything you found is this is like your first time to come out of, maybe out of a couple years of school and you learned all of this stuff. And you're so itching to use it really for yourself, because professor you use it, but it's driven by what the professor wants. And maybe that's, that's, it would be better to stick with that little, that sort of mentality so that instead of what the professor wants, it's what the customer wants. But I think we want to, you know, sort of flex our own muscles and, and stretch out and show off to some extent is to I think is part of that as you're as you're younger. And I think that's a, that's just a natural part of the learning process is to realize it. There's to know that you there's a lot you don't know. And that there are people that have have gone through these paths before and can help you sometimes immensely through documentation and other, you know, pieces of work and content that have come before, but also to, to understand that it's not about the technology, it is about solving a problem. It's about being useful to whoever the customer is. And I think, yeah, you nailed it with the, you know, having that time to walk in their shoes to watch how they work to to have those discussions with them to see how they use it or want to use it is a huge thing. And it is amazing how many times I've run against or run up against applications that were built, either that I've used or that I've built myself and had other users, you know, give feedback. And it's used in ways no really not even considered sometimes when it was originally built. I, you know, if you use a, I don't know if it's like a address application, there's just limited uses. But you look at, you know, Facebook being example is I think initially it was just to keep up with a few people and it's turned into really the, you know, probably one of the greatest examples of a pure advertising marketing platform that exists. And, you know, it's inside and out. That's a lot of what it is. And even when people complain and know that they're being advertised to, they still draw that on a regular basis. So, you know, it's sometimes they have their life of their own. Yeah, yeah. And I think that that's the world we live in now. You know, I want to reiterate what you said is around being able to come into a project and ask for documentation. I guarantee you, you're not the only one, not you, but whoever's listening, not the only one who's scratching the head and asking for documentation. I've made it a practice that whenever I'm getting pulled into a new project, new feature, whatever, I want to look at tickets. I want to look at documentation. I want to understand what they're trying to accomplish. And I guarantee you, if there's no documentation, I'm writing it up so that someone that's coming in behind me isn't asking those same questions. I can't say that this is the creme de la creme, the icing on the cake for what makes me whoever I am. But I can tell you that it's going to bring value to those behind you. So just if you don't have that documentation, do your best to make it yourself and make the road a little easier for someone else to trek. I agree. That is that probably one of the best habits to get into is as you have questions and they get answered to log that somewhere, whether you keep a journal, whether you do a blog site, whether you have a wiki page or something like that. Because you never know the next person that needs that documentation, maybe you. It's like, sometimes you come back six months later, where was that? Or I think you'll know, and this is actually probably discussed a bit later, is that sometimes your roadmap for the week or the month gets hijacked and something that your heads down on and researching the next thing you know, it's on hold for whatever reason. And you have to just set everything aside and come back to it maybe months or even a year or more later. Yeah, yeah, absolutely. And that will wrap up part one. Before we move on or wrap this up, I do want to swing back around and point to one point that in particular Tim brought up. And that was the idea of getting into a new project and asking questions. The reality basically that if you have a question, probably other people do or would in the same situation. So don't hesitate to speak up, particularly when you're getting into a new situation where there's something that that you just you're not getting or you don't know or there's some ignorance of that. Because the people that are on the other side, they may not recognize that. When you ask a question, they may say, wow, that's obvious. We should have specified that or documented it. But they may not do it until you bring it up because they're they're in it every day. They're used to it. It's something that they they just know. They forget how maybe specialized that knowledge is. And so speaking up will allow them to it helps them help you. It will allow them to understand where there are, we'll say, specific pieces of knowledge that they that are either part of the organization or the the problem definition or the customers or, you know, there's just all those little bits of specialized language that we've talked about before. Those can also be stumbling blocks, basically, when you're trying to bring somebody else in. Because these are things that you know, you know, you just know very well because you've been in it for so long. People that are new to that situation or that environment or that culture may not. So ask questions. Don't be afraid to speak up because that's just one of the things if you ask questions early and start building that knowledge, it's going to save you from it's going to save you time and frustration where you have to go look it up or you're going to go look it up. Or figure it out yourself. And it's sometimes so much easier. Just ask that question. So that'll do it for this episode. Thanks for listening. And we will continue this conversation with Timothy the next time around. I will throw a challenge of the day challenge of the week out this time around. And that is, it goes back to the question thing. Are there some things that are blocking you or slowing you down that maybe you could ask a couple of questions and get those things out of your way? That you could get some clarification and it would help you get you through your day better or move forward on your project a little bit faster. And if so, ask them. That being said, we'll wrap it up. As always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noir podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues. Or visit our site at developernoir.com. Just a step forward today is still progress. So let's keep moving forward together. One more thing before you go. Developer Noir podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoir.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.