Personal life basics
My name is Chris Juszak, but some folks call me CJ. I was born in California, lived in Virginia for a while, and I am now living in Colorado. I have a wife and son that is in middle school. We plan to remain in Colorado while my son finishes finishes middle and high school.
This website
This website (geohub.com) is a convenient place for me to post notes for reference and to occasionally share information with others (and whoever happens to trip across this website). Every so often I clear everything off this website and start over (saving some of the old stuff that might be useful to me some day).
Work life basics
I’ve worked in the defense industry since 2002 in various engineering roles. I started in this industry as a government computer scientist for NAVAIR, then worked for defense contractors since 2005 in various roles centered on software engineering, systems engineering, user support, and team leadership. I have real-world knowledge and experience in military test and evaluation (T&E), infrastructure support, and user support, combined with systems and software engineering skills. My long-term goal is to transition to a “purely software engineering role”, working primarily from home as a remote employee.
I currently work for KBR, with 100% of my tasking on a US Government Test Resource Management Center (TRMC) “user support” contract. TRMC provides infrastructure and technology support for US military T&E organizations (infrastructure, networks, and software used by military ranges and facilities). My role is to support these organizations as a software engineer with subject matter expertise in integrating live, virtual, and constructive (LVC) systems, and communication interface modeling design and development. I have been in this role since 2007 (working for three different contractors – starting with BAE, then Wyle, and now KBR).
TRMC is growing and I am looking for opportunities within this growth to begin narrowing my focus to fewer projects where I can spend quality time as a direct software development contributor. I will also look for opportunities outside of KBR and TRMC where I can best achieve my long-term goals. I believe the future is very bright and exciting for software developers and I look forward to contributing to the success of many software products in the years ahead. On top of my experience and skills, I take pride in my grit and individual contributions, and I will carry my intensity forward in every future endeavor that I am part of. While I have over 20 years of experience in engineering, I know that I am just getting started!
Some more details on my background…
My background includes engineering support for nationally distributed Department of Defense (DoD) test and training activities. I have a Master of Engineering degree in Systems Engineering (2014) and a Bachelor of Science degree in Computer Science (2000). I worked for the Naval Air Systems Command (NAVAIR) from 2002 to 2005 as a Computer Scientist (federal employee). NAVAIR gave me unique opportunities to learn about military range operations and contribute to nationally distributed military training operations. Leaving NAVAIR in 2005 was a decision to pursue new engineering opportunities. Since leaving NAVAIR, I have worked for four different defense contractors providing engineering support to the DoD, including Cubic, BAE Systems, Wyle Laboratories, and KBR.
During my time with Cubic (2005 to 2007), I learned more about contracting, business development, government organization, and engineering team building. Leaving Cubic in 2007 was a decision to remain active on direct engineering tasks rather than the increasing supervisor and business development duties I was being tasked with at the time. I started working for BAE Systems in 2007 supporting Office of the Secretary of Defense (OSD) Test Resource Management Center (TRMC) contracts related to distributed software development and network infrastructure support. The Test & Evaluation (T&E) projects that I supported for BAE Systems involved a lot of the same technologies and people that I had worked for while supporting joint training events for NAVAIR. I started working for Wyle Laboratories in 2013, continuing to support TRMC projects when BAE Systems no longer had a contract vehicle related to these projects. In 2016 KBR purchased Wyle Laboratories and I became a KBR employee. While working for BAE Systems, Wyle Laboratories, and KBR, the primary contract vehicles I have supported have been through OSD’s TRMC, with tasking assigned to various projects throughout the DoD by TRMC.
I realize the words “defense-industry contractor” can bring up visions of secret projects, government conspiracies, and various other things that media and entertainment have bashed into our brains over the years. Do not get too excited. I am just an engineer that has an interest in cool technologies and the DoD has a lot of neat toys and has been kind enough to give me a lot of opportunities. I could just as well be programming elevators or printer drivers (two of my most promising job prospects before I started working for NAVAIR). That said, I am still trying to figure out what I want to do when I grow up 🙂
The type of work I do has evolved a lot over the years, but involves a mix of systems and software engineering, working with distributed engineering teams, providing distributed software development related training, and various kinds of software support and troubleshooting. The contractor I work for now provides engineering support to organizations throughout the Department of Defense (DoD) and occasionally some non-DoD projects. So, what does that really mean? Well, I am a programmer that mostly uses C++, but I use a lot of other programming languages as well (e.g. C#, Java, Python, etc.). Really, I can confidently say that I can jump into any programming language and learn how to be proficient and productive using that language. To me, it is the underlying concepts that are important, and the language is just a tool that facilitate telling a computer what you want it to do. C++ has been my go-to language mainly because that is what the folks I work for mostly use. Any language I have never touched is just some time and reading away. These programming languages, operating systems, and technologies are all just tools in our toolbox. They will all fade away some day, but the basic concepts will remain – and evolve as things like artificial intelligence change the landscape of computer science.
Right now, I provide support for a specialized model driven distributed engineering architecture (which can be used with C++, C#, or Java). This capability does some cool things. For one, it allows engineers to model communication interfaces in a specialized data definition language. “Communication interfaces” (and the associate data models) refers to the data structure and values that needs to be exchanged between systems in a distributed network environment. This could be within a single lab, or on a network that spans continents. Most of the projects I have supported are for systems within the continental US. So, part of my job is to sit down with engineers across the DoD, discuss the kinds of information that needs to be exchanged between systems, and figure out how to translate that information into a specialized format. This includes the structural composition of persistent and momentary data types as well as some behavioral aspects of how this data is exchanged.
Once we have modeled the kinds of information that needs to be exchanged (and some behavioral aspects), we end up with a data definition file, or multiple files in some cases (which look a lot like C++ with namespaces, classes, attributes, method signatures, etc.). These files are used by a centralized repository to autogenerate programming libraries with Application Programming Interfaces (API), example code, and other capabilities (e.g. a logging and replay system). This leads to the next part of my job. So far, modeling the communication behavior between systems has been a theoretical or academic exercise. The next step is training software engineers how to use the autogenerated APIs to integrate individual systems into a network distributed system. Other activities include working through issues, testing, troubleshooting, giving demos for specialized apps, etc.
So, what kinds of systems are these? So far, what I have described is generic and could really be used for any network-based communication system in any industry. The DoD community (AKA defense industry) has taken this capability and agreed on certain “standard” ways of communicating between systems that support Test & Evaluation (T&E) and training (i.e. the kinds of information that systems share). I like to divide this information into two oversimplified categories: simulation and instrumentation – although the DoD’s term is “Live, Virtual, & Constructive” (LVC) data (which causes more headaches to explain than it is worth).
“Constructively” simulated data is the “made-up” stuff. This could be a simulated aircraft firing a simulated missile at another simulated aircraft. Since it is all “made up”, these entities can fly in their own little world, have their own concept of the terrain, and even operate in time that is slower or faster than real time. Instrumented data is the “real” stuff that is measured somehow. This could come from telemetry systems, radar systems, optical tracking systems, etc. The “LVC” thing basically has to do with how we can do meaningful things with made up data and measured data in the same “event” (e.g. for testing or training). There are places where this is possible, where it makes sense, and where it can add value to an event. There are other places where LVC integration is either impossible, nonsensical, exceedingly difficult, or poses a safety risk. In any case, I also spend time explaining what these “standard” data types are to engineers, how to use them, and even how to leverage them in the composition of new custom data types (which can save a tremendous amount of development time, reduce overall program risk, etc.).
So, I have either lost you at this point in a bunch of techno-jargon that you really do not care about, or you are following at least some of this and it sounds kind of cool (but it is likely hard to “envision”). From giving many trainings and demonstrations over the years I realize how easy it is to lose people’s attention. Luckily, we have cool 3D visualizations and graphical user interfaces (GUI) to keep these engineers’ attention that we train and support. I would have bored myself to death by now if I did not have cool visualization software to play with, or real projects of my own to work on.
One cool project I worked on is a system that tracks live aircraft using something called ADS-B. ADS-B is used by aircraft to send all sorts of information, including identification, position, etc.. For some reason, data is more interesting if you know it is coming from live entities. So, I use this live aircraft data and sometimes various things I have instrumented with GPS sensors, etc. in trainings and demos. Then I will use software that simulates other data types to demonstrate various concepts. Lately, I have been using a small radar interface simulator along with a 3D geographic visualization tool to show what it looks like when objects are being tracked by a radar. The radar simulator itself can be controlled by other software, which helps demonstrate system monitoring and control concepts. I have also built other small applications that do things like fire simulated missiles at the planes and do all sorts of other things to help visualize geographic data modeling and behavioral concepts.
A side effect of supporting multiple organizations within the DoD is that I spent a lot of time learning about how various systems work. Having a good systems view is usually essential if you are going to provide meaningful contributions to parts of the system. Although, sometimes I would learn out of curiosity, obsession to whatever problem we were trying to solve, and even pure selfishness when I really just wanted to know more about a system that few people would ever have the opportunity to work with. This would sometimes get me hooked into other tasking. For example, I have worked with tactical communication protocols, network infrastructure and performance testing for distributed events, static code analysis, etc. Actual programming was sometimes a very small part of the projects I was supporting. But this is something that I am striving to come back to – to come full circle and leverage all that I have learned in a more purely software engineering role (i.e., writing code and developing products).
The best part about my tasking over the years is that I have had the opportunity to work with hundreds of incredibly talented, dedicated, and interesting people. My work environment included my home, sometimes a real company office, and wherever I was sent; including cubicle jungles, remote test sites, government laboratories, contractor facilities, and dozens of military bases across the US. Hotel rooms, coffee shops, and restaurants were also work environments when I was on the road. While many of these trips were challenging for numerous reasons, I was fortunate to have the opportunity to witness and be a small part of how the DoD has evolved since 2002. With every project I’ve worked on, and every individual I’ve worked with, I’ve learned new things. I’ve spent thousands of hours talking with engineers and system operators, picking their brains about their unique experiences and how they think about problem solving in complex environments. I guess I’ve looked at this as a natural chore in surviving as an engineer (obtaining an essential tribal knowledge and way of thinking), but it has also been personally rewarding as well. I am fascinated by the evolution of technology in the defense industry. There’s a story here that I haven’t seen anyone assemble and share in a way that does the story any justice, but I feel like I’ve had the best seat in the house, hearing parts of this story from the best people to tell it, and witnessing parts of it myself.
So that’s a little about me! My resume on this website has some additional details about my work experience. I try to keep my resume up to date on LinkedIn as well. As mentioned, my long term plans are to transition to a “more pure” software engineering role (software design and development). I’ve done a lot of software development over the years, but it was mixed with other kinds of tasking, and I jumped between a lot of projects as part of the nature of user support. I have enjoyed my role in TRMC and contributed to numerous successful projects. But I believe that I will be most productive (and happy) in a pure software engineering role.
Ideally, I will remain with KBR and on contract with TRMC where I can build on the relationships and knowledge that I have developed over the years. However, KBR’s role in TRMC is user support focused, which basically means that we support a variety of projects based on TRMC’s infrastructure and technology support across the DoD. This leads to a lot of necessary bouncing around between projects, making it difficult or impossible to spend quality time on any one project. This was a great environment for me to work in for many years, but I’d like to take some of that broad knowledge and experience and apply it to a narrower project focus that allows me to further develop my software engineering skills and experience.
I have no immediate plans for change, and I plan to diligently support TRMC and the DoD, as I have done for many years now. But I am exploring opportunities to transition to a new role that is focused on software product development. I have talked with many people within the TRMC team, so this information will not be surprising to the people on our team that I have personally communicated with (including our team leadership). I have worked in a few different roles within TRMC in the last year as a result of some of these discussions, but my role in support of the TRMC contract is user support focused, not product development focused. I’ve been fortunate to bend these rules over the years with tasks related to TENA support, but our core function is still DoD user support – related to military T&E infrastructure and technology.
I am very excited for the future – both for my own personal growth and for TRMC’s potential. I may continue to be part of TRMC’s growth in the years to come, or I might take a different fork in the road sometime between now and the next few years.
— cj —