Mission Possible Podcast
Welcome to the Mission Possible Podcast, where we dive deep into the stories of extraordinary individuals who push the boundaries of what’s achievable. Each episode features leaders, visionaries, and changemakers who share their personal journeys, pivotal moments, and practical wisdom on overcoming challenges, driving innovation, and creating meaningful impact. Join us as we explore resilience, purpose, and the power of embracing uncertainty to transform obstacles into opportunities.
Mission Possible Podcast
Zil Vyas & Jason Hershcopf: Collaboration and Code
Episode Description:
What separates software engineers who merely code from those who drive transformational mission outcomes? Chad sits down with veteran engineers Zil Vyas and Jason Herschcopf to explore the leadership principles that elevate technical teams from functional to exceptional.
This conversation goes beyond typical tech talk to examine the human side of software engineering. Zil and Jason share their unconventional paths into technology—from pharmacy technician to application developer, and childhood programming prodigy to rapid prototyping savant. They dissect career-shaping moments: early mistakes, mentors who reframed failure as learning, and communication strategies that transform defensive code reviews into collaborative growth.
The discussion reveals a fascinating contrast—Zil's structured, edge-case methodology versus Jason's rapid prototyping approach—yet both consistently deliver exceptional results. They tackle cross-functional team dynamics, breaking down organizational silos, and recognizing when to move on from stagnant environments.
As the conversation shifts toward AI and automation, both offer grounded perspectives on how intelligent tooling will amplify rather than replace strategic thinking. Their advice for new graduates cuts through industry noise: prioritize adaptability, communication, and finding work that genuinely energizes you.
Whether you're leading technical teams in mission-critical environments or navigating your own engineering career, this episode delivers battle-tested wisdom on thriving through continuous learning and authentic collaboration.
Thank you for spending time with us today! If you're energized by the conversation and eager to see how bold ideas translate into real‑world mission advantage, explore the Bcore ecosystem. At Bcore, we're uniting exceptional people and cutting‑edge technology to accelerate mission impact and advance national security.
Learn more, connect with our team, and discover opportunities to collaborate at bcore.com. Join us in pushing the boundaries of what's possible.
Hey everyone, welcome. In today's episode, I get to talk to two people. I'm talking to two of my favorite software engineers, Zyl Vias and Jason Hershkoff. Today's conversation, we dive deep into collaboration, the mindset needed to thrive in these fast-moving technology landscapes, and just practical lessons on building strong, resilient teams. So whether you're a technology veteran or just starting out, Zyl and Jason share compelling insights, just really good perspective from behind the scenes. So please join me in welcoming Zyl and Jason. All right, so I'm talking, this is a two-person, this is a two-guest interview today. So I got Zyl and Jason, awesome technologists, software engineers. I'm going to start with Zyl. Just how did you get into tech? Like, how did you become this super nerd that I know and love today? So tell us that short story.
SPEAKER_00:Short story. It's, you know, honestly, I don't, I don't know that I can like pinpoint what it was because growing up like I think I always assumed yeah I'll do like engineering or I'll like take after my dad do architecture or like my sister at the time was studying like she wanted to do pharmacy so I was like maybe I'll do that but yeah I think like I my part-time job was I was a pharmacy technician for the longest time and then I just I just didn't vibe with it and in school I didn't really vibe with like science classes and like those classes but they didn't offer technical classes in my high school um and so for me i was kind of like well this is gonna sound really silly but i love espy like as a kid i was like i want to go there and we get games and we get electronics i get super excited to get a new phone all these things and then um i think it just like fell into my lap when i was like applying for schools of like well i want to do engineering but i don't want to do like mechanical. I don't want to do electrical, but I really like computers. I like technical work. So computer engineering was the natural fit of like, okay, I can figure out, do I like hardware? Do I like software? Where, like, where is my passion going to fall? And it was pretty easy. I was terrible at the hardware stuff. I was really bad. So naturally I was like, okay, I think I'm just meant to be a programmer. And I honestly, I can't say I was great at it in college either, but it was just fun to learn. And like, fail over and over until like I perfected the craft. And then, yeah, it just led me into, to this work.
SPEAKER_01:That's pretty cool. All right, Jason, how about you? How did you get to
SPEAKER_03:tell? Wow. Um, I don't think my, my story is as exciting as Zill's. My, my dad was a programmer. Um, and I saw all growing up and then I started looking like six or seven. We had a TI, actually, yeah, TI 99, uh, 4A with a little tape recorder next to it that you like recorded your code. Um, and I started doing that, like from the back of a
SPEAKER_01:magazine. Zill and I are looking at him like, what,
SPEAKER_03:what? So if we have a Smithsonian, you'll see like in there. Yeah. They, um, so started doing that and starting the programs at the back of the magazines and then trying to expand on what was there. Um, and then my geek moment, like, like program competitively in high school, like for competitions and stuff from the computer club, um, which. Shout out to the computer club. I know. Right. So, um, and I, ranked nationally, like above all my peers. And I'm like, this is cool. And then I kind of had this thing of, I don't know, being not even privileged isn't even the right word, but when I graduated college, I wanted to have a job where I was guaranteed air conditioning in the summer. That's a good bar.
SPEAKER_00:I love like, that's a great way to.
SPEAKER_03:And as I went and did computer science in school and went out and then had a variety of jobs afterwards and great mentors and then just learn stuff and like just keep learning so it's uh and it's always a challenge right it's all ones and zeros um and it's always interesting people like oh the computer is doing this and like maybe now it is but like years ago it wasn't ascension it wasn't like going and and doing things that randomly wanted to do it is it was programmed that way and if it wasn't doing what you wanted to do is because you made a mistake in the code
SPEAKER_04:yeah
SPEAKER_03:so Just doing that, and it's fun, and it's always something different. I feel like we're continuously learning. There's always some new technology where I'll talk to Zil, and she's like, hey, did you use this library to do this? And I'm like, never even heard of it. And I'll look it up, and I'm like, how have I gone this long in life without having known this Python package was here? That's
SPEAKER_00:one of the most rewarding but also scary parts of our field is because things are changing so quickly, and to keep up with everything is kind of very difficult, but at the same time, it's so much fun. Because every day is different.
SPEAKER_01:I think the basics are, I mean, I want to go back to your point of the failing fast and just learning from that really quickly. And you had mentors that helped guide you there. But I just feel like You know, way back when I used to do cool stuff, like, you know, and then if you step away, you forget it. However, I think the fundamentals are there because you're still trying to solve a problem. And later in life, you can go ask somebody. Now you can go ask this machine and it'll spit out something that's half right or whatever. But like... Walk me through some of those moments where, you know, there's an emotional component when you're wrong or you're having to learn, you're a little awkward or insecure, but then also there's that reward of like, oh my gosh, like I've learned that I'll never ever make that mistake again or I'll know how to do that. Like, what was that first moment for either of you?
SPEAKER_00:My first moment was probably like pretty early on. I mean, I'm still like very early on. I think in my career, early on in my career, I've made several mistakes. And it's like silly to say because like now when I look back, I'm like, that's actually not a huge problem. But like I've introduced like memory leaks and I've like racked up AWS bills before just from like poor design and just like I just didn't know. And at the time I was like embarrassing and then I had to like take accountability. But it was also at the same time really rewarding having like senior mentors and senior engineers like walk me through like he this is how you should do it. And this is like where we went wrong. And it was always the approach of like, It wasn't, Hazel, you did this wrong. What resources did we not provide to you so that you don't make this mistake again? And so in the past, I was always embarrassed because I felt like I was behind everybody around me because I was always the youngest person. But I feel like, yeah, I've made plenty of mistakes. I've introduced plenty of bugs in code. And people have definitely called me out. They still call me out to this day, but... You know, I just think it's just part of the job and just taking accountability.
SPEAKER_01:Well, have you had that moment
SPEAKER_03:where you're running out, turn off the server? No, I definitely, my first internship, I was working in a company actually my dad had worked for. And every year the owner, it was a small company, and every year the owner of the company brought in one of the kids of one of the programmers to intern for the summer. And I was there my first week and I needed to upgrade a Novell network. Okay. Sorry, and I need to install a mail package. And I saw on the server there was a slash mail directory. And I was like, oh, well, it's not installing right. Obviously, I need to get rid of the mail directory. So I deleted it. Except that on Novell network, the mail has actually got where all the security credentials are stored. So I locked everybody out of the network. And unfortunately, the poor
SPEAKER_01:network... It's
SPEAKER_03:an intern. It's an intern. And unfortunately, the poor network admin, she got yelled at for it because she should have known better. And I was like, no, this is my mistake. Like... I'll fix it. It's not her fault. She still got in trouble for it, but whatever. I felt bad for her. But yeah, I mean, there's always like stuff. I mean, even we found the bug in our code that we've been running for three years in production that there's a logic error in there that we never accounted for. So I think it happens all the time. It's a learning experience. Like Zill was saying, I think the most important thing is just taking ownership of it. I hate when you go into meetings and people are like, Oh, it's Zill's fault. It's Chad's fault. It's so-and-so's fault. Like, it doesn't make a difference. We're here. This isn't working. We need to move forward. We can figure it out later. And obviously, whoever made the mistake is going to learn from it. But calling them out and humiliating them and making them feel bad is not going to change the situation right now.
SPEAKER_01:Yeah. And we've all worked on really cool teams, really great teams, and also really bad teams. So... Can either of you walk me through some of the dynamics of you guys are highly intelligent beings, very analytical engineers, et cetera. And you start storming and norming with different personalities. Like there's some craziness and some beauty there too. Like walk me through both sides of that.
SPEAKER_00:Where I've seen issues the most is just like bad communication or lack of communication. And that goes across like everybody, right? It's not just the engineers, I think. there's a communication gap between some of the technical and non-technical folks that are involved. And I think that elevates issues and technical debt and all those other things that come with it. And I think as long as everybody is communicating and they're on the same page and you're empathetic and you have the same level of expectation for everybody, I think then you can jive well. And as long as you have a clear and concise strategy and expectations and That's generally what I think works best for people.
SPEAKER_03:And I think something I learned or someone once told me that has always stuck with me is that 10% of people do 90% of the work. And once I came to accept that with most teams, you're kind of like, oh, you're part of the 90% then. You're not going to really contribute a lot unless we ask you. You're not going to push the envelope. You're not going to do more than you have to do. You're not going to be creative. You're not going to do anything innovative. But the 10% people are awesome to work with. And then, I mean, I've been fortunate, like the team I'm on now, like it's all 10 percenters, right? So it's awesome to go in and have someone challenge you. And to me, like when someone's like, hey, your code's wrong or this isn't going to work right, like, okay, why? Show me what I'm missing because I thought this was going to work. So having people that go and push you to be better is, I think, really enjoyable.
SPEAKER_01:Do you guys have any secret tricks? Like how do you attack that type of problem? Yeah. You do the incremental things, or are you trying to look at it holistically?
SPEAKER_03:For me, I have really bad habits, which I know when I've talked to Zilph before, she hates. I am completely random and very unstructured. And I think it just goes back to when I started to learn how to code and how I learned how to code. It was just a free-for-all. So modern things like Agile and Git and stuff, I didn't know that younger people live off of, like it drives me crazy because I need to look at the entire problem. I can't just look at it chunk by chunk. But also I feel like after having some experience in a variety of things, it's also easy to look at a problem and know where the root cause is. I was on a networking team early in my career and the guy who is running the team, who's really awesome mentor, he, whenever someone's like, hey, there's a networking problem, he would make me run it down. from workstation to server to whatever, even if we already knew it wasn't the network, he's like, go through the method all the time. So we'd have a developer come in and he'd be like, oh, it's a networking problem. I can't get to the server. We're like, we know it's not. We know it's your code. But getting that and being a good... I'm a huge proponent of full-stack engineers. I think people who can just do front-end or just do back-end who don't understand how it all fits together... or at a disadvantage when it comes to developing any sort of system.
SPEAKER_00:Yeah, I would agree to Jason's point. It's not that I am so different from Jason, but my practices, like I was taught early on to like always write code or like do your work in a way that somebody else can take it over. Don't be married to your project. Don't be married to your code because somebody else will probably come in and take it anyway. And so I've always like had that mindset of, I don't take constructive criticism like poorly because I'm like, yeah, at the end of the day, this isn't just mine. This is ours as a team. Somebody else should be able to come in and work on this and whoever's coming in next because I might go off into a different project. So I, yeah, I have a certain way of doing things because I'm probably a little bit more structured and a little bit more particular on how I set projects up. But yeah, I also like to use like suggestive language when I'm like working with other people of, whether it's like reviewing code or documentation, I always like to say, hey, I think we should do X, Y, Z and not, hey, this is how it should be. Because I think people aren't as receptive to hearing it that way. And I think if you are giving suggestions, it's a little bit more cohesive. Like it feels like we're doing this together and you're not overtaking somebody's code. Like I think In our craft, people do get really attached. And when you say to somebody, hey, you're doing this wrong, they feel like you're attacking their skills.
SPEAKER_02:Yeah.
SPEAKER_00:So I try to take the approach of, hey, this isn't an attack on you. This is how do we make this better so that the end user, the end customer gets what they want. It's less work for us in the, you know, on maintenance.
SPEAKER_03:It's like going off, I feel like to your point, like if you have people buy into what you're trying to accomplish and everything goes so much smoother. Like people are not defensive about their code. They're not, um, hostile towards the other people. Um, but they, they want to contribute to the team. Right. So I think like that's probably even more important than their coding abilities is the willingness to want to, to help and want to advance and want to keep the, keep things going forward.
SPEAKER_01:Do you know any good techniques of that? Cause like I've been on some teams where, you know, they would do like legitimate code reviews where they had printed and put on the wall and show like, this is excellent. This is, funny. It was always kind of joking and whatever. I don't know if that worked well or not. The other question to point to that too is like, you know, Jason brought up the whole thing of like full stack development and even with folks working in 2025, like that's what I'm trying to do is like just have that end-to-end context about like, it doesn't matter if you're, if you're a data scientist, cool, but like you need to know the end-to-end because you also need to know what questions are being asked, what information you might need to kind of solve that problem. Is that scalable? Like in 2025 with all the tools and everything kind of coming together. And I mean, what is a modern 2020, a 2025 software engineer to be thinking about? Like if you're, especially you're fresh out of college, et cetera.
SPEAKER_00:I mean, I don't know if this answers the question, but I think it's, there's like knowing backend, frontend, data science, all that stuff, but like knowing how to consume those technologies and use them is super advantageous for like 2025 software engineers. I'm, I'm not a data scientist by trade, but if I know how to leverage like data science libraries in my code, I think that's a win-win. Um, So I think it's just like understanding how to consume the tools that are given to you that might not be traditional software engineering frameworks or things like that, but just knowing, hey, I'm not a backend developer, but I just need to understand what this API is doing and how it's structured so I know how to communicate with it,
SPEAKER_01:things
SPEAKER_00:like that.
SPEAKER_01:Where do you get time to learn those extra libraries and use cases? Or is it just more project work?
SPEAKER_00:I think it's on the job and project work, at least for me.
SPEAKER_03:I mean, it's most of it's on the job. Um, but sometimes like I'll, I'll see a new package. I'm like, I have to figure out how this works or I have a problem that's, that's bothering me. Um, and then I'll go at nights or weekends, whatever, and try to figure out how to make it work or how to make it work better. Um, but going back to your question, I think like the most important thing I want to see from anybody, like when we do interviews isn't is basic logic stuff, right? So to me, there's, there's two types of programming languages, right? There there's scripting and there's object oriented. And if you understand the philosophy and the content and how to work with those, the language itself doesn't matter, right? But you also have to want to learn. Like if you're totally set in your ways, like I'm going to use C++ for this because I've done this in college and like this is it and it's not going to work, right? I'm sure you have a job someplace, but in the environments we work in and people I think who are successful here are really, they want to learn something new, right? Yeah,
SPEAKER_00:you have to be flexible and adaptable.
SPEAKER_03:Yep.
SPEAKER_01:Yeah. Well, Zyl, if you had a big sign as to what type of developer you might be, what is that moniker?
SPEAKER_00:Honestly, mine has always been just application developer. And I think it's because I really love... building an end-to-end product for an end user. And I think sometimes when you're doing like solely just backend work or something that's like siloed, you miss the big picture. And what I really like about application development is you're pretty much like front and center working with the stakeholders, the end users, but you're still building the full stack. It's a very rewarding experience because you get to tell the story from start to finish. So I think for me, I would say application developer.
SPEAKER_01:That's pretty cool. What about you, Jason?
SPEAKER_03:I do a little bit of everything. So it was kind of a jack of all trades, master of none, chaos. Usually a lot of just throwing stuff together to make it work. Some of it's not the prettiest code, but a lot of times, and we'll see it like in code reviews where people are like, why'd you do this? I'm like, I don't know. It worked at the time. I was like, I'll come back and refactor it later. Later never happens. And then we just move on to something else and try something else.
SPEAKER_01:But if I were you, I'd be like, I was a national coding champion, by the way.
SPEAKER_03:Now I regret saying that at all. That's a great fun fact.
SPEAKER_01:That is. So how do you balance the, you know, you have his style of just like, and I've had the privilege of working with Jason for a while and like Jason can create magic very quickly. And then sometimes like if you're very, you know, how do you balance this, you know, rapid, you know, urge to create something quickly versus like, resiliency and all this other stuff. How do you balance that? Or do you let someone else figure that out later?
SPEAKER_03:It's a yardstick. I mean, when I worked with Zoe before, she's like, stop doing that. Stop. And we have a mentor to both of us, probably, Corey, who, brilliant. And if you did something wrong, he was not shy about telling you. But it was always in a very, like, Well, it might have been in a harsh way, but it was always coming from a good spot. He wanted you to be better. He was never telling you anything to belittle you. I think every team operates differently, and you have to understand the personalities to what people are going to respond to. Some people would enjoy going to the code review like, hey, who wrote the dumbest line of code this week? And be like, oh, it was me. Or other people are like, oh my gosh, I can't work in that environment where I'm constantly humiliated. Well, then get better at your job, right? Just kidding, kind of.
SPEAKER_00:Corey's been rubbing up on you, I can tell. For me, it's like early and frequent feedback when I'm like prototyping or doing rapid prototyping. And I think that's why like Agile and that stuff works really well, at least in previous settings I've been in, because you build like small feature sets or the core sets that like answer to the problem faster. early and then get the feedback very early. And if you need to pivot and change direction or just throw it away, like as long as you're doing that early, I think that's probably the benefit of doing prototyping.
SPEAKER_01:And that's exactly why I wanted both of you here, because just in my conversation with you, we're not talking about engineering problems all the time or anything like that. It's just life. I mean, I love how both of you tackle similar issues, but completely differently. Zil, I can just see her like you know, processing every edge case imaginable for any kind of decision point. And then Jason's like, I'll go try it. But often you reach the same conclusion. It's just different technique and approach, which is, that's the cool part of us being humans and everyone has it. There's no right or wrong way to do it. Of course there is. Yeah, for Zill's way. Yeah, Zill's way.
SPEAKER_00:I'm sure Jason gets to it much quicker. So maybe that's the right way.
SPEAKER_01:On the team piece, you know, because you guys obviously are working with different companies, but you guys are all on the same team. Like how does accountability and just making sure people are kind of maintaining like quality or this or that, like how does that kind of work itself out in a team dynamic?
SPEAKER_00:As long as there's shared ownership and everybody kind of understands that we're not on, we're not on different teams, even though you're a different company, it doesn't really matter. We're still answering to the same problem. And as long as everybody's on the same page and there's clear, like I said, clear communication and concise communication, expectations and strategy, as long as everyone is sharing the ownership together, then I think you're successful.
SPEAKER_03:I mean, it depends on the team and how motivated people are, how invested people are in the project, right? So we have like, hey, it's a job. I'm here for eight hours a day. I'm going to do my time. I'm going to leave. Don't bother me nights, weekends. If I'm on my way out the door, I'm on my way out the door. There's other people like, okay, They take pride in what they're working on. And they're like, hey, I want this to be better. So if someone's going to critique me, it's not a bad thing. And I'm honestly like, I love when people critique because if I can't justify what I did or how I did it, then maybe it wasn't the right way. It can be painful at times, don't get me wrong. But I think it goes in, if you have people who are interested in doing it, but across companies can be, I found it to be challenging to, especially if they're not working for the company you're working for or someone's a prime on a contract and you're not trying to go that way. I feel like those teams don't generally succeed or people don't stay there that long.
SPEAKER_01:Walk me through one of those interpersonal dynamics that posed a challenge and how did you handle
SPEAKER_00:it? For me, the challenges I've had is just if I'm on teams that are very divided in skill sets, So if there is a back-end team solely and a front-end team and whatever other teams, for me, because I'm a full stack, I kind of need the full picture to understand requirements and the asks of what I'm trying to accomplish. So the challenges I've had is I've been on certain teams where they are very like, hey, these five people do this and nothing else. And these four people do this and nothing else. And it's kind of tough when you're in a position of like, well, I don't understand how to answer to the requirement I'm doing because it's a little bit of this and a little bit of that but they're not communicating with each other and so in those situations I've tried to just like overly communicate and I take the approach of just hey why don't we all just talk like like on the dumb-dumb in the room. And I need to understand the full picture so that everybody can communicate to each other effectively. Back end should be able to communicate to the front end in a way that they can understand, vice versa. Same with data scientists, like everybody. I think that is my challenge is just everybody being siloed. And that goes back to shared ownership. Yeah, we're not rowing in the same direction. So that for me is very challenging. And sometimes that's just personality base. Sometimes that's to your point, like different companies, like it could be different companies hiring just for a backend and stuff like that. So I don't know that there's like a secret sauce to fix those problems. But I think for me, I just try to overly communicate in those situations.
SPEAKER_01:Communication, communication for Zil.
SPEAKER_03:Yeah, that's a good question. So especially between
SPEAKER_01:Jason's the chief snark attack.
SPEAKER_03:I am. I am. I have no patience for, for communication. people not wanting to do their jobs, not wanting to help. And I think one of the things that makes Zill so good at her job is she understands, I think at least, that knowledge is power, but it's not having the knowledge and not sharing it. It's teaching. I worked for a guy who used to have this expression. It was his goal to make himself useless and expendable. So teach his job to the person below him so he didn't have to do it and he can go do something else. Yeah. So I think there's that part of it. But in terms of working between teams, you try to have a cordial environment with people. Like an integrated team with different front-end, back-end database people, that's one thing. When we work across projects, we'll often see competing priorities. Sometimes you have to escalate it to other groups and make, hey, I need you to make a decision. We're ready to do this. This team's not going to do it for two months. What do you want? Like either you have to change their priorities or change our priorities or people aren't responding. So you like escalate it. Um, and I've been very fortunate to work with supervisors who have had a really big stick, um, who are just like, either you're going to do this or you're not, or we're going to do it ourselves. So, um, it can be challenging. I think like trying to go in though, and then be casual and understand what people have to say and be like, Hey, talk to me like I'm three years old. Right. Like that works sometimes. Um, Sometimes they actually talk to you like you're three years old and they treat you like that the rest of your. So you just said dumb, dumb just earlier. Okay. Yeah. So it's, um, it just depends on the team, I think.
SPEAKER_01:But last question on team, like when is it time or when's it time to move on from a team? And do you guys have any kind of rules there where it's like, Hey, you know, I want to go only go a couple of sprints or a couple of features sets with this one team before I try to mix it up and. do something else.
SPEAKER_03:I think like when I get to a point on a project where I don't want to go to work, um, or I'm not interested in technology, I'm like, it's time to go. Um, like my current project, I've been there for, for over four years now. I love going in. I think about it. Obviously when I'm at work, like nights, weekends, whatever, like I'm invested in, I enjoy what we're doing. We're always learning. I'm always learning something new. But when it gets to the point where like, I don't want to talk to people I'm working with because they annoy me or I'm not learning something new. That's usually my metric. Like, I'm done. It's time to go on.
SPEAKER_01:That's a good indicator.
SPEAKER_03:Yeah.
SPEAKER_00:Well, I don't know that I,
SPEAKER_01:cause you've been on a lot of teams.
SPEAKER_00:Yeah. I've been on a lot of teams. Um, for me, it's when I hit a point of just when I'm not learning anymore. And so I'm bored. And so, cause I've been on like one of my previous teams was probably the favorite team I've ever worked on. Like I enjoyed going into work every day. Like we were a really tight group. Um, And we're still very close. Like I loved going in and the work was really exciting for like the two and a half years. And then when it got to a certain point, I kind of felt like now I'm stagnant. And for my own benefit, I do need to move on because I need to progress. And like I need that continuous learning to feel excited about work. So for me, it's generally if I get bored, it's time to go. But luckily that doesn't happen that often.
SPEAKER_01:So like... With AI and all these automation features that are coming out, where will you be spending your time once this thing's really operational?
SPEAKER_00:I think it depends on what we're talking about as being automated, because if we can be part of the team that's automating those things, that's fun and that's part of our job. But other than that, I mean, if something else is running to build some artifact that I don't need to spend 10 minutes doing and I can spend that 10 minutes like solving something really cool. That's great too. But at the end of the day, with all this AI and automation, like we as software engineers need to know how to use these tools to be effective and to stay relevant.
SPEAKER_03:I mean, we're having a raging debate about this in our office now. A
SPEAKER_01:raging debate.
SPEAKER_03:It gets heated at times. Um, not in a bad way because people are passionate, passionate, good word for it. Um, the tools are awesome, right? Like I can go and be like, Hey, I need code to do this, this, and this, especially when I do like UI stuff. I, I don't like UI stuff, but when I go to like chat, GBT or cursor, I'm like, Hey, I need a UI to do this, this, and this using these, these libraries and this methodology. It spits it out. Like, this is awesome. The problem is I don't understand how the code works. And I think we're still early in the life cycle of what AI and these tools can bring to bear in terms of accuracy of code or actual functionality of code and having people who don't understand how the code works. It's not that I need to write it myself, but if I don't know how to write it myself, then it's a lot harder to troubleshoot, at least in my mind. And then the other piece is, going back to the full-stack developers, is I haven't seen it, maybe you can in some system, go and say, hey, I need a system to do X, Y, Z, like write everything about it. Or tell me if this is possible, right? If you come to us and say, hey, can you do a system that can track trucks across all of Virginia? Okay, I have an idea of what I would need to do it, how long it would take, like that sort of thing. But I don't know if any sort of technical solution now can actually give you that output to say, hey, it's going to take you this long and have the estimate. So there's there's a basis of our experience that I think can't be replaced just yet.
SPEAKER_01:Yeah, for sure. But at least on, you know, like on the strategy, that other kind of knowledge piece to get a context quicker, it's like, boom, that's like your superpower. So I don't know how it's going to perform like in the engineering or the, you know, where you only have subset of certain edge cases you can solve for. I, you know, remains to be seen, but that's why you guys are going to figure it out. Yeah. Are you worried about that?
SPEAKER_03:I'm not worried. I'm not worried at all.
SPEAKER_01:All right, to close us out here, right? So you just graduated college in 2025. You're going to join a government services contractor in your performance software development work. What's your advice for the right mindset for them to have? What habits should they start forming early and what should they avoid? I
SPEAKER_00:mean, I think it's the theme of what we've been saying. Be flexible early. Be adaptable. Learn anything and everything that you can, but just be prepared and ready to change directions at any time. And that's like framework, language, technology. It doesn't matter. I just think just be flexible and adaptable. And from the communication standpoint, always be overly communicative. But also, and Jason knows this about me, document everything. I'm a huge... advocate for documentation so like getting into that that habit early because a lot of people that i've worked with they're kind of like oh whatever we'll just document that at the end and it just never happens so as long as you're documenting as you go like it's a really good habit so that like i said earlier the next person can jump in at any at any time and like documentation is also like it's funny because you talked about cory earlier and like he was somebody that used to say you shouldn't have to write like blocks and blocks of comments in your code If you're writing your code in a way that reads like a sentence, that's the way you should be writing your code. If it doesn't read like that, then put in this code box. But I do like, I like to document like, like in read me's or confluence or whatever. It doesn't, I don't even care. Just if somebody else comes into this project, how do I get up and running? How do I run it? How do I deploy it? That kind of documentation.
SPEAKER_01:I need to meet this wise guy. My mental image of this dude is like, He's got robes on with rosary beads and a goatee. That's not too
SPEAKER_03:far from the
SPEAKER_00:truth. I mean, yeah, it's not. You're close.
SPEAKER_01:Just slaying the code dragon all day. All right, Jason, how about that on the mindset, the habits, and the things to avoid?
SPEAKER_03:I'd say, like, get a job that you're passionate about. Like, if you're going to a project, you're like, oh, this sounds like it's kind of cool. Like, I don't really, like, it'll be a paycheck. Find something you really enjoy. Like, and not what people are telling you you should be enjoying. But something that when you're interviewing, you're talking to people about it and talking about the project, that sounds really interesting. I want to do this. I want to be a part of this. And then once you get there, I'd say listen more than you talk. And it's not that people's opinions aren't valuable. But I mean, we have kids coming a year or two out of school who are telling us how to work these systems that we've been working on for years. And you're kind of like, Why don't you figure out the basics first? But in the same account, like some of them have great ideas, right? So just pick and choose what you're saying. You don't have to comment on everything. But yeah, like be flexible, comment your code. Don't do what I do. If I'm doing it, I'd be like, that's the wrong thing to do. I need to be doing better. Yeah, but always like be willing to learn and always like take, if someone offers you a chance to learn something new or do something new, the answer should always be yes. Otherwise you're going to, In five years, you're going to be outdated.
SPEAKER_01:Wow. Thanks for your time. I really appreciate the perspective of just the mindset with being a developer and an engineer in some of these weird environments that we're in. A lot to unpack in future episodes. So welcome you guys back for sure.
SPEAKER_00:Awesome. Love to come back. Yeah. Thank you.
UNKNOWN:Thank you.
SPEAKER_01:Thank you for joining us on this episode of the Mission Possible podcast. For more insights and to discover how we're making missions possible, visit us at bcor.com. Thank you and see you next time.
