Introduction Link to heading
I have spent my entire career working in the aerospace world. Granted it has only been 8 years, but in that time I have been fortunate to be apart of some excited projects in this space (pun intended). I got to see OSIRIS-REx land on an asteroid millions of miles away, and have worked to maintain dozens of spacecraft until their eventual destruction. In this time there have been a few standout thoughts that have changed the way I not only perform my job, but also how I work on my personal projects. Below are 3 ideas I have carried over from my work in aerospace to my personal workflows.
1. Visibility == Clarity Link to heading
Data is king in aerospace. The more information you can have about your spacecrafts current configuration easier it is to catch problems early. However, data streaming from a spacecraft isn’t always in a format that makes it easy to interpret. Additionally, these packets (typically in CCSDS format, think TCP but for space) have mountains of information about the various components that exists on the spacecraft. This could be solar panel direction, and radio configurations to battery voltages and currents in the payload systems. Finding a way to trend, graph, and alert on this firehouse of information is extremely important for the health of the spacecraft (also your own sanity if you are on call).
Tools like Grafana, Prometheus, and InfluxDB are shining stars in this area and they absolutely deserve a shout out here. It is important to note however that although this tooling helps in this cause, it is on the developer to make sure that the metrics and payload coming into these services is useful. In many other domains it may be seen as overkill to report EVERY single little metric about what is going on (except maybe robotics). However, I think being able to harness that firehouse and use it for visibility helps provide you and your team with clarity of how the product is behaving.
Any personal projects (including writing my own astrodynamics library in zig) I try to put visibility into the design. You should be able to understand where something is misbehaving without having to chase down stacktraces or confusing log messages. Being pedantic in your logs goes a long way in many cases, especially if you are dealing with a complex system or a large team. Being able to better understand that being loud about the moving pieces is crucial to developer experiences and I try to make it a design choice in any of my personal projects.
2. Complicated!=Bad && Simple!=Good Link to heading
Space is hard. Space is unforgiving. Often when you are working to maintain the life of a hunk of metal 650 km above earth there are problems. Those problems can come from within in the form of a hardware failure, or they can be external, like the sun having a few angry months and shooting angry death rays at your spacecraft. In order to work around these complex issues you often need to have a complex solution. I’m not saying that there are no cases where the a simple solution can’t be reached, but it often is not that binary in real life problems. There is nuance and the simple solution isn’t always the good solution.
It’s okay to have complex problems be solved in a complex way. That isn’t to say you shouldn’t be following best coding practices (idiomatic code, functional design choices, etc.). You should strive for easy to read code and simple broken up functionality, but it is OK if the overall solution is quite involved.
In my astrodynamics library, there are some challenging problems that need to be solved including implementing solvers for orbit propagation and impulse control. The accuracy of these functions relies on several complex arithmetic functions that needed to be rolled by hand. The simple solution to this would have been using Kepler’s equation which removes most of the matrix transformation that goes into orbit propagation. However we would be approximating results, and I wanted to make sure that someone using the library would have access to the most accurate results I can provide. It is a design choice for sure, but you shouldn’t be afraid to have a complex solution to your problem space, as long as the code is still easily understood and idiomatic.
3. There Is No Replacement For Passion Link to heading
Backing up, I don’t have a degree in aerospace engineering. I actually don’t even have my degree in computer science. I received my degree in information systems, and while I had a solid gasp of coding, it wasn’t my primary focus. The opportunity to work at NASA was a dream of mine, and going into to my first job at NASA I knew nothing about the problem space I was headed into. The laundry list of buzz words used by managers, and the ever growing list of acronyms that space industry insists on using was completely foreign to me. I felt hesitant in my abilities to perform the core of my work, basic software development, AND felt lost at the context of what was going on.
But I knew something fundamental. I LOVED space. I loved it when I was a kid and I still love it today. I love the mission that often accompanies space, to explore and learn about things much bigger than ourselves will ever be. With the knowledge that I knew I would love working in this field (NASA was an interesting job for me. I may write about my experiences there at some point), I took charge of my own lack of knowledge by being proactive and constantly learning about subjects where I had knowledge gaps. My passion was able to propel me forward, and it pushed me to become better in all aspects of my job. When I eventually left NASA I was extremely confident in not only my coding abilities, but my abilities to have deep and knowledgeable conversations about the space industry.
At my next job working for a private space company, there were new challenges and things to learn. I still had the same love for the industry as I did when I started, and ended up becoming the companies expert on ground stations and ground systems. This was all extra work I had put in purely because I loved the industry and wanted to learn as much as I could. I even stepped outside of the scope a bit and taught myself the basic of RF communications to better help me.
Personal projects should be passion projects. You should want to build the things you are working on. Often times that’s the only way you actually get them across the finish line. It also leads to a deep understanding of the subject and eventually it may lead to your dream job, if you don’t already have it.
Passion breads excellence and it is much harder to grow your skills as an engineer if you don’t have the passion to learn.
Thanks Link to heading
This is my first time attempting having a blog and I’m hopeful I will be back with at least handful of more ideas. I want to do some more technical writing in the near future, specifically some basic workflows I have started implementing in zig. If you want to keep in touch I have my socials listed on the home page, and you can subscribe to my RSS feed