Personal life basics
My name is Chris Juszak and I live in Colorado with my wife Laurie and my son Lee.
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
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 still be there.
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” refers to all the data 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”). I have realized how easy it is to lose people’s attention over the years, giving many trainings and demonstrations. 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 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.
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, bars, 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. I’m a kid from California. I had what I think are some fairly unique life experiences as a teenager. I managed to get through college and just about accidentally ended up in the defense industry. I’ve worked hard over the years, I’ve learned a lot, and I’ve had a lot of fun as well.
My resume on this website has some additional info about my work experience. I try to keep my resume up to date on LinkedIn as well.
— cj —