General Dynamics/Plexsys

General Dynamics (and Plexsys Interface Products) are government contractors - in this case, contracting with the US Air Force. I joined a team that created software to support distributed simulations performed by the Air Force, and I rapidly became familiar with a variety of new networking protocols through a variety of projects.

While at GDIT I...

  • Wrote implementations of protocols based on published standards
    • Translated technical specifications into practical code
    • Used these specifications to build support tooling
  • Stood up a virtualization and CI/CD infrastructure on an airgapped LAN
    • Established a staging area where we could deploy and test easily
    • Standardized and automated builds, which had been a series of undocumented manual scripts
  • Introduced containers to improve developer efficiency
    • Due to airgapped nature, containers allowed much more efficient onboarding
    • Demonstrated potential benefits of production deployments
  • Created support tooling
    • We didn't have many ways to effectively test some software out of production
    • Created tools that allowed us to simulate situations and recreate bugs
  • Debugged a lot of multithreaded C++
    • Dug through core dumps on airgapped systems to identify heisenbugs
    • Identified and rectified incorrect use of mutexes (deadlocks, etc)
    • Used my tools to reliably reproduce errors
  • Mentored teammates and adjacent peers
    • Assisted junior developers with assigned tasks
    • Gave teaching sessions on Git, programming styles, specific domains
  • Wrote + performed standardized test protocols
    • Learned from our team's Testing Engineer how to write effective formal test documentation
    • Performed formal integration test procedures
  • Fostered cross-team collaboration
    • An independent team was tasked with performing Acceptance Testing of our releases, but communication gaps led to historic misalignment of testing expectations
    • I worked with my team lead to revise the processes in place to align both teams interests and promote open dialogs
    • This lead to a huge reduction in inter-team conflict and failed testing results

My Role

I served in a full stack capacity here, developing at a systems level up through to web frontend development. I also spearheaded operational improvements, such as introducing virtualization environments for improved testing as well as automated packaging pipelines. Over time I became a mentor to new hires, and developed more documentation and processes to support their onboarding.

The development team was relatively small, and going through a phase of growth. There was a healthy amount of institutional knowledge in the veteran members, but the team was in a period of evolution as we adopted new technologies and techniques. I began by absorbing as much of the institutional knowledge as I could, and over time I began establishing new processes to help disseminate that knowledge as new hires came on.

A significant part of the work consisted of systems programming, in particular networking tools that parsed, filtered, routed, or otherwise handled the simulation protocols. I ultimately took part in designing, implementing, testing, and supporting these tools - learning from the experts on my team along the way.

As we continued to grow our team, I had the opportunity to mentor junior developers and provide supporting infrastructure for them. This included one on one code reviews, writing documentation, establishing protocols and processes, and teaching sessions. I tried to take my onboarding experience and smooth out as many of the rough edges as possible for them, while also enabling them to take ownership of their learning. Having the opportunity to share my knowledge with them and hear their perspectives was a very rewarding experience.

My Key Takeaways

I am very grateful to have been a part of a team that was so willing to impart their knowledge onto me, and to then be able to return that favor to the new members as the team continued to grow. Working for the government was a distinct experience, one marked by process and constraint. However, I found that within those constraints we were still able to find ways to make our process more efficient, improve our relationships with other teams, and expand our capacity to take on new projects. These are some key points I carried with me from the experience.

Respect for Process

There are many times when I would prefer to move unencumbered by formal procedure, perhaps even most of the time. And at small enough scale a very light layer of process may be appropriate - but I saw that as things scale up, process was the only glue that kept the system together. Even if kludgy, having defined roles and steps in place ensured that everyone at least knew what to expect. Having the opportunity to see what happens when process can be eliminated, and likewise seeing the consequences of removing it inappropriately, has recalibrated my mental gauge. Moving forward, I now have more tools at my disposal to leverage process when appropriate, and a better sense of when that might be.

Operations and Tooling

I was incredibly fortunate to have a team lead who was supportive of me exploring opportunities to improve developer ergonomics. I learned a ton from standing up a CI/CD and virtualization environment in an airgapped network, and seeing how much it helped our team save time and energy was incredibly rewarding. Likewise, developing internal tools that assisted with reproducing bugs and provided avenues for automated integration testing was a great learning experience. Despite the constraints of the environment, I learned that there were still many ways that we could work with those constraints to improve our experience and produce better software.