Episode #29: Development Series Pre-Production

Kevin Milner: Broadcasting from Fairfax, Virginia. You are now listening to The Highlight Cast.

Roman Zhelenko: Hello and welcome back to The Highlight Cast. My name is Roman Zhelenko , Director of Digital Government here at Highlight, and our team is excited to be back with a deep dive into the federal development process through three stages. Pre production, development, and post development and maintenance alongside various team members, both from management and the technical side. Today, we’re starting with the pre production part of the show, alongside Kevin Long, who is the VP here at Highlight, and Kevin Milner, who is the program director. Welcome, guys. Thank you. How’s it going, Roman? So as we know from experience that setting up a new development program takes time and ensuring you lay out that initial foundation. This initial episode will focus more on that post award scenario. This is after it’s been awarded. This is after our team has been given the win and we’re starting. We’re going to go through a couple different scenarios that we’ve all run into and just kind of discuss them. So the first one we’re going to talk about tech stack change. You know, a lot of the time when we’re starting the program, we’re proactively staffing a lot of different technical resources. We’re working through business analysts. We’re trying to anticipate what we see coming down the pipeline. So let’s talk about what happened or what they specifically list in the RFP. Also true. So if let’s say a scenario where we got, you know, we got a Java program, we’re proactively already sourcing Java people, we’re sourcing Java developers, we’re sourcing people that know this technology. What happens if we get in there and we notice that everything’s C sharp? What happens if we get in there and we see a tech stack that we just don’t anticipate?

Kevin Long: You know, sure That that’s a trickier one, cause I’ll tell you the best C sharp developers I’ve ever found have actually been Java developers, but I 

Roman Zhelenko: agree with you on that one 

Kevin Long: beside that, at least from a transition in point of view. And then I’ll let Kevin talk about how it happens and feels on the ground. First thing you do is you re scrub all of the resumes for the people that you’ve got, and you see who are the switch hitters that fit both. Right? And then you pick up the phone and you call all of them and make sure that since an audible has been called by the customer. that it’s still a job that they’re interested in doing. The customer isn’t changed, the mission isn’t changed, but what IDE you’re using probably has. And so that’s the first thing that I do in concert with notifying recruiting.

Roman Zhelenko: I guess sometimes we do get lucky. We, you know, it doesn’t change that much. It stays, it still stays object oriented development. So you have that developer that’s able to adjust.

Kevin Long: Yeah, I mean, it’s easier with more senior folks. Programming being a mindset and the rest being syntax. If you’ve done it long enough, you probably have the syntax for several languages somewhere locked up there. So how about you, Kevin? I’m sure you’ve come in and had things thrown sideways at you like that.

Kevin Milner: Oh yeah. Very much so. In that sort of situation, there’s more concern than just switching from Java to C Sharp. They’re basically the same language, but the environment that surrounds it is so much different. One is more Windows focused, and the other is more generally in a Linux environment. But, what you want to do is make sure, as you said, when you go in and are hiring for this position, you want to make sure that You have somebody that has a firm understanding of the concepts of programming. Anybody can write any language in any language. I mean, they’re all equivalent under the hood. And if you understand that, it’s not that hard to move from one language to another. There may be some translation delays, but in general, if they’re strong enough on the fundamentals, they should be able to adapt easily. One of the instances I can think of that we had, we came in to a project and the tech stack wasn’t quite defined. We recruited assuming we were going to be doing Java development. Then they came to us and said, Hey. We need Drupal. And 

Kevin Long: that’s pretty deep shift. 

Kevin Milner: Yeah. Fortunately, the guy that we were talking to, to be our tech lead, anyway, we put on a requirement, Hey, do you know Drupal? And it turns out he did. So fortunately we were able to bring him on. And then the hilarious thing was immediately after we said, Hey, we got you a Drupal guy. They said, yeah, we don’t want to do Drupal. And we actually ended up doing everything on service now. So. You know, the plan that you have when you get awarded is often not the plan that you end up hitting the ground with.

Roman Zhelenko: And that’s, that’s actually a very good point. Let’s say, what is the type of candidate that you’re looking for? What is the optimal candidate? Are you looking for somebody that has 10 years experience in one language? Or are you looking for somebody that’s, you know, did two years of this one, two years of this one, and you can tell they’ve adjusted. Because from my experience, you know, coming from development, sometimes Java is not the best language for it. Being able to realize that your favorite language doesn’t fit all problems, it takes time. So, you know, I’ll throw this one to Kevin. Well, Kevin Long first. 

Kevin Long: Sure. That is very program specific. There are contracts out there. Their tech stack isn’t going to shift because it’s technology that’s 12 years old, the cost and the work and the risk to just suddenly up and shift it to a different. More modern stack isn’t going to happen, right? And so at that point you truly are hiring I don’t want to call him a tool jockey per se but you are hiring cold fusion developer, right? For example or or something like that something that isn’t super popular in industry anymore And so at that point you’re looking for deep and specific experience Now where we’re doing our more dev sec ops You Sort of leaning stuff where we are contracted to provide n number of developers that can do modern software development through modern in quotes with You know using agile dev sec ops and things like that Then yeah, I would say I look for I tend to like t shaped experience, which is shallow wide Yeah in a lot of stuff, but then deep in a very specific thing, right? And you want To be able to have the vertical on the t in several different things full stack developers Nobody handles every part of the stack as well as others, you know So you have a full stack that is really good at back end database sequel things like that really good at Ui ux front end development really good at at the middle tier and business logic stuff, right? So It really depends a lot on the program, like is the technology that they have not going to change for business price or political reasons, then you got to go look, then you’re looking for an eye shaped experience where it’s, you have the person that knows what the customer is using and that’s it, right? Not that’s it, but that’s their primary focus. And then you have the more generalized software development where, heck, we might. Jump to mobile development or things like that, where you look for people that have done a little bit of a lot, but has an expertise in a specific thing. 

Roman Zhelenko: So tossing it to Kevin Milner, from a tech perspective, when you bring on people to your program, how do you judge if somebody is willing to learn that wants to learn that wants to change their skill set? You know, I’ve run into people that Just want to do one language for their entire career. I’ve run into people that really want to shift to the DevOps side that want to learn this new skill set. What are some of the things that you look for on your program specifically that kind of goes that shows a developer that’s willing to adjust?

Kevin Milner: Yeah, one of the things I like to do is when I’m asking someone and talking to someone, I like to sort of focus on the soft skills a little bit to get an idea of the direction that they take their hard skills. So if I ask somebody, you know, what do you like to do for fun? What’s your idea of relaxing? If their idea of relaxing is studying pipelines, right? Yeah, building pipelines, then 

Kevin Long: we know these people. 

Kevin Milner: Yeah, yeah. Yeah. So I try to get a feel for the person, there’s a few technical questions I can ask from a computer science background that you can assess how able someone would be, or how non specific to a language they are, you know, and things like that. So I just generally try to get to know the person and see if that’s, Going to be the way that they operate mentally. 

Roman Zhelenko: Naturally curious. 

Kevin Milner: Yeah. 

Roman Zhelenko: Asking a lot of questions, figuring out exactly what they’re working on, and then suggesting like, hey, why aren’t we using, you know, Kubernetes instead of OpenShift? Or asking those questions that we want them bringing up in conversation when they see the environment. Isn’t 

Kevin Long: OpenShift a Kubernetes platform? 

Roman Zhelenko: No, it’s a Red 

Kevin Milner: Hat platform. Oh, my 

Kevin Long: bad. 

Kevin Milner: It’s like a wrapper around. Some of the cloud aspects of Kubernetes. Okay, slight, slight variance. Again, 

Kevin Long: no, I mean, we’ve learned I’m not technical anymore, just technical enough to be dangerous, 

Roman Zhelenko: right?

It happens, it depends on how quickly it does change though, so. 

Kevin Long: Well, speaking of that, that’s the other thing that you look for, right? It’s people that are always looking for the next thing, right? You know, my next thing became, you know, Business focused stuff a while ago and stick with that. But when we’re looking at the technical folk, right, really, it’s the people that are excited to find out, you know, what’s next on the automation and DevOps front 

Roman Zhelenko: on it. And it really comes down to us as being the leadership on the program to determine what resources are. Ready for that next step or figuring out what they want out of that. It’s figuring out, you know, this developer really wants to shift to a leadership role. We’ve had so much luck finding, you know, senior developers that really want to take that lead role in training them from within. So it’s been a big success on some of our programs shifting over a little bit. So let’s say. Backups. How do we prepare? How do we open? Do we overstaff? Do we keep options open before we even start the program? At what point do we stop backup candidates? Yes, backup candidates. So let’s say we have our initial 10 resources for the program. Do we close out the openings, the recs, or do we keep them open and continue having? All right. Let’s say this is a scenario if we need more DevOps resources, or we need to shift this resource off and move them to different programs, what are some options we have there? 

Kevin Long: Sure. I’ll take this. Yeah, you’re essentially always looking to have a pipeline of. Smart talented candidates coming into the company. So for job openings that are not just Specific to one program or even with the one program honestly because they can be harder to find We tend to keep job openings open So that we can keep finding people so that there’s a backlog of folks that might want to come in So that when we win new business We we’ve got people or if someone wins the lottery You And then they’re like, Hey, we love working with you highlight, but I have 325 million in the bank. So I’m going to go buy an Island instead. We’re, we’re not hung up. Right. And so I have to have a very good reason to close a good general. Uh, hiring category

Roman Zhelenko: that works and Kevin Milner. Sorry, I got to figure out another way to address both of you. That’s a big thing. Maybe for the next session, anything that you’d like to add for that one?

Kevin Milner: You know, I mean, I had a lot of traumatic experience with job hunting. So I tend to be more on. The job hunters, you know, try to see things from their, their viewpoint a little bit more. So I try not to like just have people hoping that we’ll call them back, you know, with an offer as much, you know, I mean, I’m not really in a position where that. Ever actually happens. But having said that, I try to focus with my teams on having in technology, you have what’s called the bus metric, which is if you have a team and a member of the team gets hit by a bus, how many days? down are you before you can be back up to speed in terms of knowledge that’s lost from your poor dead developer.

Kevin Long: That’s why I use the lottery example. It’s so much, so much less gruesome. 

Kevin Milner: Yeah, well, we’re different people. But, but the way I try to address That is, I try to make sure that we cross train as much as we can on our team, so that it’s not quite so imperative that if we lose a member of the team, we can, you know, we can’t function until we get our DevOps guy in. You know, I try to make sure that, that everybody at least has, An idea of how to fake the other guy’s job until we can get a replacement. 

Roman Zhelenko: A cross, cross trained team is always a good option. So, that actually leads us very well into our second scenario for the podcast. The second scenario is more focused on balanced teams. I’ve seen a lot of situations where tech, all tech, all developers are prioritized rather than having a handful of developers, business analysts, testers, you know, scrum masters, etc. So, What are some of the benefits of having a balance team over in all developer focus team send this over to KL first? 

Kevin Long: Okay, so benefits of a balance team. Sure balance team allows you to tackle more than one type of problem, right? I mean a lot of the hardest parts of the types of programs that we do Aren’t just the technical pieces of it. It’s Understanding the the full scope of what needs to be built who the stakeholders are Understanding where there’s a difference in what the definition of done is from from customer to customer as well as what needs to be documented at the end of it and and the work that that’s That’s going to be documented to come after and how things are organized and executed. It’s always good to have a people person, not just a machine person on, on a team. I think now, now some customers will say, you know, only tech people on this team. And then the question that I will ask is awesome. No problem. Who from another contract or the government is going to be providing your scrum mastership or your business analysis or the things like that. So that That if we’re, if we are only being the tech part of a team, then I want to know where the rest of the team is that has those soft skills, uh, wrapped around is going to come into it. 

Roman Zhelenko: I get, I mean, coming from development, I know going and asking clients questions throws you off for the rest of the day when it comes to your process, you could be in the middle of your algorithm. And as soon as you’re disturbed from an email. There goes that train of thought. So having that dedicated resource, you know, that business analyst who is sometimes cross trained to do other functionality allows your developers to develop, to focus on their train of thought, to just focus on solving that problem and you just get a better product quicker. Kevin Milner, what are you thinking? 

Kevin Milner: Yeah, so like if you, if you have your testers, your QA people, if they are also the developers, there’s going to be an inherent bias in them. And when they’re doing something, they’re like, Oh, I’m not going to go ahead and click on it this way because I know that the Windows messaging system can get delayed. 

Roman Zhelenko: Are you saying Developers shouldn’t do their own testing? 

Kevin Milner: No, no, I’m not talking about that. Yes, yes. 

Roman Zhelenko: I’m not talking about that. Developers shouldn’t do their own testing. I mean, obviously I want to break the thing I was working on for the past several weeks and I’ll do everything I can to, you know, show that, right?

Kevin Milner: Yeah, I’m not talking about just regular testing. I’m talking about QA, you know, before we ship it out, making sure it doesn’t embarrass us testing. And what you need is somebody that doesn’t know how the sausage was made. To, to go in and, you know, I guess to continue that metaphor, taste it and make sure there’s no horse parts in it, uh, you know, so, um, so what, what you want to do is, uh, you know, you want to, you want to have somebody that is knowledgeable in the domain that you’re working in, test it to make sure that it meets their needs because, you know, You know, as a programmer, I’m an expert on programming. I’m not an expert on government procurement. So, you know, what we want to do is make sure that for the testing purposes, we include non technical people that are going to test it and hopefully break the code. The application, because it’s much better to break it in a test than to have, you know, you can ask Bill Gates when he’s out there demoing a windows thing. It was 98 and it just blue screened of death on him. You know, that’s 1 of those things you don’t want to have happen. 

Roman Zhelenko: So not a bug. That’s a feature that was something we experienced multiple times. Yeah, but I completely agree with you. I think a lot of the time asking the right questions is a is a skill set being able to work with the clients, being able to approach them and show them we really understand this and working with them to figure out what they want. You need a dedicated resource for that. A lot of developers I worked with, they really just want to focus on the development side. They want to make sure they’re building it. They’re not as into asking the questions, figuring out the requirements. They just want to do what they’re. Specializing in yeah, mr. Long any experience in that again. I’m changing the names. I’m giving you guys. So we’re going for macro I’m going from Initials to last names. I’ll figure it out. 

Kevin Long: Yeah, ask me one more time. 

Roman Zhelenko: So we’re talking more on specializing and asking the right questions, so A lot of the times the developer is not going to be the one to work with the stakeholders to get those requirements to figure out what they want. Sometimes you need somebody that specializes in building and asking and documenting, putting it, breaking it out in the stories, et cetera. 

Kevin Long: Oh, sure. 

Roman Zhelenko: I 

Kevin Long: mean, I mean, absolutely. I mean, and that’s why when you don’t have a balanced team that has people that are focused on that, the first question I ask to our customer is who do we have that we get that from? Right. I mean, that’s, it is absolutely a different, a different skill set for that. You know, I would not ask a capture manager to write software. 

Roman Zhelenko: Well, not good software. You’ll write something. So hello world. So if that, I mean, it will be nice. Well, one thing I know we’ve experienced is we’ve cross trained some people, and I think the best combination of cross training actually comes with a business analyst who also can do five way testing, for example. That’s somebody that understands what the client wants, knows enough about the technology to be able to dive in a little bit, and in case there’s downtime, you know, adjust, shift, and support other parts of the business. You need the people person from office space. 

Kevin Milner: There’s a 

Roman Zhelenko: people 

Kevin Milner: person at 

Kevin Long: office? There is. He takes the plans from the tech people to the managers. Yeah, absolutely. 

Kevin Milner: Does he physically take them? Yeah. No, his secretary does it, but he’s part of the process. What is the matter with you?

Kevin Long: Yeah, that’s okay. He can have his joke to conclusions, Matt. 

Roman Zhelenko: Uh, Sorry, next podcast will be a movie discussion about tech focused movies.

Kevin Milner: This 

Roman Zhelenko: happens when Kevin and I 

Kevin Milner: get in a conversation together 

Roman Zhelenko: It’s kind of 

Kevin Long: unavoidable. 

Roman Zhelenko: Yeah, it’s expected. Frank’s going to have a blast with that. So the next question is more focused on experience and certifications for some of these resources. Are there any certifications that really stand out or is it more on. Contract specific, for example, so, you know, a trusted tester for supporting a DHS client or, you know, an AWS certification. You know, there’s tons of them out there. How do we tell people focus on this one or? Sure. I mean, 

Kevin Long: security plus is an easy one to pull out there. I mean, anywhere in DoD, if you want to be an admin on any system, security plus is the, is the fastest certification that meets the DoD calls for that. PMP, absolutely, is all over the place, uh, for that, for, uh, So I actually just reading today an RFP where, uh, PMI’s Agile Certified Project Management CERT was accepted as a replacement or an addendum to a, to the PMP CERT. So there’s definitely that I’ve seen not with his requirements, but nice to have a safe Agilest and CSMs. The certified scrum master. 

Roman Zhelenko: So I always end up looking for the certification and then application of that cert. So if you have a safe agile, making sure that, you know, all right, what’s the benefit of agile? Is there, is this the right fit or is there a better fit? You know, not just, you know, Mr. Milner, any, any certs from your side that just really, you see them and you’re like, this is it.

Kevin Milner: I, I’m not as big a fan of certs, I don’t always hold them as, as, I mean, it shows that somebody can pass the certification test and that’s, you know, that, that is a skill in and of itself. I’m not sure how much it always has a direct relevance to some projects, but that’s just my personal opinion. You know, studying for the PMP. A lot of it was like, this doesn’t have any reflection on the real world. This is just, can you study to pass this test? And so I’m not as in odd of certificates as probably, you know, I, I once was. But I mean, they are kind of a shortcut for being able to say, well, this, this person has at least been exposed in depth to this technology stack or that sort of thing.

Roman Zhelenko: And that’s a, that’s a good point. I can’t say that having a cert versus not having a cert will show that this resource is any better or any worse. I’ve had situations or both situations have happened. 

Kevin Long: Oh yeah. I mean, certificates are great or certifications are great for. The you must be this tall to ride. Yeah. Right. I mean, it’s, it’s, it’s, it’s on paper, but it, but then it’s, it is absolutely. I mean, it’s, it, it does not obviate the necessity to evaluate the person in the work that they’re doing with that. But, yeah, I mean, we’re seeing more, but there are some tests that I’ve seen that are difficult enough that unless you actually use. the work or use the tool, you won’t be able to pass it. The, the AWS certified architect professional level, not an associate level, right? That is, that’s, that’s a no joke exam, right? Where you’re going to have to know AWS to be able to do that. Yeah, to get that certification. And so I put some weight in that similar to, well, I guess a little contrary to what Milner was saying with the PMP. It says that, you know, a broad scope of different project management capabilities. The PMP is for building space shuttle software and skyscrapers. Right. And so any certification that allows you to manage such wide and varying types of projects is going to have very different things that aren’t going to fit for your particular type of expertise. And so you can pick and choose those once you’ve done that. But it does show that you have an exposure to and an understanding of the principles that would drive that type of work. 

Kevin Milner: Yeah. And for transparency, Mr. Long has his PMP and I have not yet taken my test, so that probably does. 

Kevin Long: Hardest multiple choice test I’ve ever taken.

Roman Zhelenko: I’m in the same boat with you, Mr. Milner. Yes. You know, some people just don’t enjoy tests. Mr. Long has that skill set, he’s able to do it, so. Do you think I enjoy tests? Yes. Yeah, I think 

Kevin Long: so, yeah. We’re going on the record. There’s a difference between enjoying and excelling at them. 

Roman Zhelenko: Yeah, alright, fair. Oh, that’s fair. No, I’m still practicing. It’s just occasionally you get sidetracked. Again, I’m with Milner. Some of the questions are not the way you would do it in the environment. Some you have to adjust quickly. Every client’s going to be different. It’s never exactly like it states, so. But I do agree with Mr long with the AWS cert. I have seen that I’ve seen some of the developers in the DevOps resources that have studied for it. It is tough. We recently just had one of our architects on a different program past the architect exam from AWS. It took him weeks of studying. So that is that was no joke. 

Kevin Long: And he uses AWS every day. 

Roman Zhelenko: Yeah. So that one really demonstrates like, Hey, you know, your stuff shifting over a little bit, are there any future technologies? And I guess this one’s going to Mr. Milner, are there any future technologies that you’re, you see coming in? Do you see any shift into say GCP or Azure or, you know, what’s the next thing that, well, your prediction and we’ll note it down now and come back in a few months and see if you got it. No, 

Kevin Milner: no pressure. Sure. My prediction, the DoD, or at least the Army side, seems to be going all in on service now. So, low code solutions, I think, are, are sort of, are sort of where a lot of these are going. You know, I’m a classically trained developer, so the idea that sort of, like, who? You don’t write your own memory management routines? Ha, ha, ha. But, you know, I also, for instance, on my project, we’ve, we in a year have produced an MVP ready for its initial deployment that, that does pretty much everything they wanted for an initial MVP. And we were able to do that with a, a team of four developers. A UX designer and, and me hindering the whole operation. So, you know, that was, that was pretty incredible. So I think, I think platforms like that ServiceNow, Salesforce, those sorts of things are a pretty good. Indication of what’s to come in this particular space. I mean, obviously, you’re not going to use it to write a video game, but, you know, for for managing, for instance, D. O. D. Workflows approval workflows. It’s it’s a great tool. Very flexible. 

Roman Zhelenko: So with with the no code solution, are you saying that there’s going to be less dependence on Um, Low code with the low code solution. Are you saying there’s going to be less of dependence on, you know, full stack engineers, you know, trained DevOps resources, and it’s going to shift to less technical people or for this domain.

Kevin Milner: And I mean, they still they still are doing coding. There’s still some JavaScript that our guys have written, they write tests for the automated testing framework. A lot of the underlying stuff is taken care of for you. So for this domain, Government contracting, I, I think that that is a really good. Taking off point in the, that, you know, you don’t have to worry about things like developing for mobile app and web app. And, you know, how are we going to put it in in nipper net and stuff like that? It’s already handled by this. multi billion dollar corporation, uh, service now. So all we have to do is customize it for what we need. Uh, so, I mean, it’s still going to require technical people. You’re not going to have as many of the needs for like the, the high power technical, you know, the, the AWS architects and stuff. They will, they will probably migrate AWS or, or, you know, some of the middleware companies that, Provide stuff to service now. So what we’ll see is maybe a little bit of the more elite people becoming more elite and the less elite people being able to fill in some of those those spaces. So I think it’ll actually end up being more opportunities for more. Diversified people instead of just rock stars. 

Roman Zhelenko: Don’t get me wrong. That’s actually a good thing. It makes it easier for us to find people too. 

Kevin Milner: Yeah. I mean, I love rock stars, but you know, It’s harder to find them. We can get people jobs. That’s, that’s what I’m happy with. So. 

Roman Zhelenko: And before I send it to Mr. Long, I think the future is going to be more on the modernization side. As people start shifting things to cloud, it’s not just the lift and shift, which is a cringe term. It’s more of determining how you, how you modernize it. What are you going to redevelop? What do you actually need to move from this large application? Oh, yeah. A lot of the times, it’s not the whole app. You only need like a couple sections. And instead of moving the whole thing, you shift over parts. And that’s where a good business analyst that asks the right questions comes in.

Kevin Milner: Oh, yeah. And there’s definitely places for modernization. I think that, like, for instance, the FAA is still using, you know, vacuum tubed computers with punch cards. And what you’re seeing now is That’s not adequate. There’s a nearly every day now. There’s there’s news stories of near misses or in Boston Logan last week. They had planes backing into each other at the gate. So, you know, definitely modernization is extremely important because. Old stuff can’t keep up with the new stuff. It’s just not designed to process the volumes or, you know, whatever the particular issue is. 

Roman Zhelenko: Yeah, I mean, and it takes a unique skill set to be able to read, you know, Fortran or Pascal and modernize that into another language or move it to the cloud. Or ColdFusion, for example. Yeah, all those poor ColdFusion developers. Ah, maybe one day we’ll do a podcast just for them. Ha ha ha! You know, all four of them, uh, and, uh, and Mr. Long, what do you think is the future of, you know, what, what’s the next thing that we’re going to be looking for? Wow. Certification wise or technology wise?

Kevin Long: Honestly, I think it’s going to be ways to, uh, visualize and integrate more disparate types of data as more and more comes through that, whether it be through AI or through what have you with that, that that’s

Roman Zhelenko: there you go. Right. That’s a different approach too. I like it. Mm hmm. So now that we’re coming up The big, big takeaways is being able to constantly be aware of the program. If you’re starting a new program, just looking at everything, figuring out, all right, this, this we’re foreseeing this to change. We are expecting this language to come in and being prepared for any of those shifts. And again, you can be prepared for all of them and having a backup position open or always sourcing is another way to approach it. And now I’ll bring it back to, you know, your earlier developer days. What is one thing that you remember that a stakeholder PM scrum master did that was, you know, impactful, beneficial for you? You know, well, what’s something that in your earlier times when you were just starting out, what’s something that you saw that, you know, stuck with you? And I’m going to start with Mr Milner because I see you’re ready. It’s more what 

Kevin Milner: my first development job that I had that I liked wasn’t my first development job. It was the first one I actually liked. It was a two person team. We wrote medical device drivers for an emergency room software thing, but. You know, I was, I was young and stupid and like we get these issues with the driver and I’d want to go and refactor the whole thing and rewrite it because the person who wrote it before didn’t know what they were doing. Obviously, they weren’t me. And my mentor said, you know what? Do the least amount of change possible to fix the problem. And, and that’s actually, you know, really good advice. And that, that one has always stuck with me. So, so, like, try to have the minimum amount of, uh, of changes, you know, for, for a thing in order to solve the problem. 

Roman Zhelenko: That’s a very good point. I like it. And Mr. Kevin Long? 

Kevin Long: Sure. Uh, what I remember wasn’t, wasn’t actually from a business analyst or anything like that. It was actually from a nurse that I was working with at a startup where we were writing disability claim management software. I was a junior developer, right? And I started to ask questions about the software. And she stopped me and said, hold on. I think our time would better be spent if you understood the work that we do and what outcomes we’re trying to have. So that you understand from my point of view, what is, what it’s trying to do. Cause I’m not going to understand the software, but I think that if you understand our end goals, you can make the software do what we needed to do. And. As someone who was not a comp sci major did not take business analysis classes, having a customer be willing to take the time and sort of work through that, I mean, at the end of it, you know, she was like, you understand our processes and what we do better than, you know, 90 percent of the people that work for me, if you would like to come have this job. Just let me know. The answer was no, I did not. I did not want, want to be a disability claim manager, but to this day, I can articulate a lot of their processes and what they, what they do with that. And that was 2001 when, when I did that and it, it made a real impact on me. 

Roman Zhelenko: That’s good. That’s actually something that our, our USAS team that they did a site visit and they were able to see what their changes are actually doing how they were helping the case processing go. So it was definitely impactful when developer sees that they’re making a direct impact on the mission. So for me, my biggest impact had to be when I first started. I, you know, I do, I actually started in DoD contracting, so back in college, and I had a PM that backed you up. So usually you get that hard deadline and you will burn yourself out to try to hit it and get it wrong. Having somebody that came from a technical background and, you know, push back and say, hey, this is not going to happen. And having that support is the reason I wanted to do management afterwards. You know, being able to support developers from a perspective of being a developer. So. It was always nice to see that, Hey, this will get done, but we want to do it right rather than burning out our resources. Yep. So with that one, thank you for listening to the Highlightcast. To keep up to date with Highlight’s news and activities, follow us on LinkedIn and visit our website, highlighttech. com. Tune in to our next episode and thank you. And we’ll see you on session two for the software development lifecycle. 

The views and opinions expressed in this episode are those of the hosts and do not necessarily reflect Highlight Technologies and or any agency of the U S government.