The Value of Communication in a Developer's Career

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. Well, hello and welcome back. We are continuing our interview series with Timothy Stratton, and we got a little bit of an introduction last time around. This episode we get into essentially the early days, starting off his career, getting into a little bit his degrees, pursuing a masters, and then how that translated into the career that he's at today. This one's a little shorter than some of the others simply because of how the questions and the responses fall. But as all of these together make a great series of discussions, I hope that you have from the first one and continue on through the next couple of parts as well so that doesn't feel like we leave you hanging or anything like that. And so here we are. We'll go ahead and get back to our conversation with Tim. So I want to go back. Another thing that's from your introduction there is you went, I guess, were you a mechanical engineer? Was that your undergraduate degree or was that computer science? Yeah, mechanical engineering was my undergraduate degree. OK, and so and then computer systems engineering was my master. And so that's a path that not actually is somewhat rare. I have run across masters and PhDs in the computer science world, but it seems a lot of people can they get their degree and they're they're off and running. Of course, you took a little bit different route. But I do want to know now that you've had some time, even though you may not have directly used the the research that you you did, I mean, you got but you did get the experience of doing the research of being published and going and I'm assuming defending your your papers to some extent. What has that now, which maybe isn't a strong people may not think has anything to do with coding. But how has that been helped you in your career? What are some things maybe that you can look back and say, wow, it's that helped me. Either as a developer, as a problem solver or as a manager. Yeah, I am seeing more and more of those skills that I used in my research come to come to the forefront as a manager than I did as a developer. As a developer, I saw just a few things, for instance, I had a research, my research professor. He was a he was a he's a great guy, really, really great. But he was a star about research and he had high standards. I think that that's the good way to put it. And it was difficult for me at times, one, keeping up with the pace, but then to really having to change my mindset to document work and discuss work, the work that we were doing in a way that others would understand as a developer. That was a skill that I instantly saw that I was able to take the work and convey it in a way that people understood. And that came directly from research. It wasn't a skill that we got as students. But as I got through my research, I could actually lean into now the master's degree in computer systems engineering, wherein there's a lot of communication involved in a system engineer's role. You're gathering requirements, if not gathering, you're discussing those requirements and documenting, you know, change logs or decision logs or whatever. You're engineering the systems that need to be built, be that design or or even implementing in some sense. All that to say as a manager, those skills and literally got the textbook here on my desk because I'm reading into it every other day or so to refresh myself on those skills. What skills explicitly, I should say, one skill is laying out requirements in a way that makes sense to a developer. We have our understanding of the requirements, maybe as someone who might be in the role of a business analyst or understanding requirements as a DevOps engineer, as a product owner, as as someone as a business stakeholder. These are all different viewpoints or perspectives of the requirements of what they want. Systems engineering really did help me to convey, compile, document those needs in a way that made sense. Again, this is just being able to communicate the requirements in a way that's effective to all the parties at hand, be they extremely technical to, you know, doesn't know how to control C on a computer, copy paste and being able to communicate those requirements and communicate the progress, the roadblocks in an effective way to all the parties involved. That's something I really did see come out as a manager from my time as a system engineering master's. That's I think that is a underestimated value for a developer is the ability to communicate both the technical and non-technical people, at least amongst the developer community. Although maybe it's changing a little. I know that from the business side or the upper management level of companies, there is that recognition of you need to have some sort of ability to communicate. Just writing code is great. But even if you can design an architect, incredible systems, if you can't communicate to your users and to your team what your thought process is, then it definitely limits you. I think that's maybe part of how you sort of progress more maybe well, solidly or quickly even into those management and lead kinds of roles is that you had that experience. So that you can sort of skip ahead a little bit over the going from a coder to really more of a developer and a designer because it's not just in your head. You can share that to other people. You can bring them along and you can have the conversations that allow them to give you feedback quicker. I think it's different if you have to create an application and throw it over a wall and get bug tickets back or something like that versus being able to talk to them about this is what we are planning. This is what we're designing. These are some of the ways that it'll work and doing so in a way that they can maybe not completely visualize, but to some extent have a vision of it so that they can make some corrections even early on and say, oh, you know, this thing you're talking about doesn't really make sense or this other thing that you seem to be downplaying is actually a huge portion of what we do. And it allows that early in the journey to make those adjustments so you don't at least maybe you don't. It goes to zero, but at least you reduce the number of maybe false starts or veering away from the core path that you hit upon. That's so good, Rob. That that exactly is something I think how I don't want to be insensitive to developers because I think we can certainly communicate when it is someone who might not need as much scaffolding to understand. I believe that most of us can do that, at least. But when I was in school, I'll give this short story. I had to redesign my research advisors, his lab, the systems lab that had a bunch of machinery in it, and I had to write up 12 different labs for the students to go through and complete week to week. And I can't tell you how many iterations he and I had going back and forth around, well, why use this language from one step to the next or think about how this particular phrase will come off to the students and how they'll respond to it. Let me rephrase that. Think about how this instruction might be might not be clear to the students. And in that in that exercise, it dawned on me that communication is vital and accurate, concise as I ramble on, concise communication between two people is something that is not just if I get philosophical, not just lacking in development, but in our world today, being able to speak your mind and clearly speak your mind is so important. So I would certainly reiterate that I wouldn't describe it as a skyrocket of my career, but it's something that I know has helped me in my career. It's just being able to communicate accurately and clearly what needs to be done, how it needs to be done and get that feedback earlier on in the process. So good. Yeah, that's I always refer to it as as being precise and concise, even though when I talk, I need to we have conversations and those do tend to drift. But when you put something down on paper, it's amazing how rare it really it is rare across, you know, even outside of the technical world, how rare it is for people to be able to just put the right level of detail down to not distract by adding a lot of flowery words or a lot of content and to do so in a very methodical way. And I don't remember when I first ran across it. I think it was probably back in grade school, an exercise of having you write up instructions for tying a shoe. When you sit down and try to do that, it's it really opens up your eyes, I think, to how much we do that is very difficult to to explain. It's just we do it. And so it also I think that also opens up ideas of things like it's sometimes easier to show somebody than it is to tell them because there's just too many there's just too much nuance or context that you don't get maybe from a from a couple of bullet points. And it goes especially in the modern world where you have a lot of things remote and you don't always have people in the same room that are able to use maybe a whiteboard. But maybe they do need to use some sort of a shared session or something like that to be able to convey an idea because just words and even a conversation sometimes isn't enough. It's it's where you really just have to see it. And then it all comes together. And that's actually sort of funny as I'm thinking about that, one of the things I run into regularly in learning dance, like ballroom dance and salsa and all that kind of stuff is it's amazing how often somebody will describe something and walk through it. And it's not until somebody you show it, you see it, that's something like, oh, that that's how it's supposed to look or that's what's what's supposed to be done. And it's very simple things sometimes are very complex. We just don't we just don't realize it. And I think applications are often that because we get stuck in maybe not stuck, but we are we definitely swim on a daily basis in a certain set of language and concepts and ideas that may seem very foreign to other people. And it's not just it's really any profession. If you go talk to like a medical professional, they will wheel and deal with stuff and go watch old episodes of E.R. or Grey's Anatomy or some of those kinds of things that are procedural dramas for law where there's all kinds of terms that they'll use that you don't hear on a day to day basis. But you realize that it seems funny that you see that in show after show after show. But that's the language that that profession uses. That's just that's just how it is. I think every specialty also has some some specialized language that if you don't understand it, then it makes it very difficult to to keep up. That's good. Absolutely. And that will wrap this one up. I hope you're as entertained as I was and having this conversation, at least you listening as we have this conversation and hopefully give you a little bit of insight on where maybe your career doesn't take the exact path you planned out such as he did where he went through that schooling and that academic period of time. Yet it was not wasted. There were things that came out of that that he's found to be very valuable as he moved forward. And hopefully you will see some of the same things because we all make missteps or take at least a different path sometimes than than we expected. And sometimes that works out OK. It turns out that the experience we have may not be what we would have planned for ourselves. And yet it's still very valuable. That being said, I will let you get back to your very valuable day and we will pick this up next time around. So 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 Noor 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 developernoor.com. Just a step forward today is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noor site. You can also find it on Amazon. Search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our Masterminds slash Mentor group. We meet roughly every other week. And this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time we talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernoor.com if you would like more information. Now go out there and have yourself a great one.