At the beginning of my tenure at NanoDx my primary responsibility was to run experiments on our electrical test setup. The procedure was complicated, and the results could be convoluted, as is sometimes the case with new and experimental technology. As I grew in this role I took on additional responsibilities for analyzing, interpreting, and presenting the data I was collecting. Executing these tasks required me to develop a deep understanding of the device physics and test methods in order to properly execute and report on experimental outcomes. When my fellow R&D engineers and I invented a new test mode that increased our biomarker signal dramatically, I was asked to develop new test software that would automate our complex test method and ensure accurate, repeatable, and efficient results.
There were a lot of moving parts to creating an effective solution, and the only real experience I had with Python up until this point was my Python3 Codecademy certification. I started by consulting the programming documentation supplied by the manufacturers of our electrical hardware. This helped me to understand more of the details of what the hardware was doing, and how I could leverage its features to test our devices. The docs also supplied example code that I was able to implement into our code. I leaned heavily on my knowledge of the test method to guide me in choosing how to program the hardware to meet our needs.
I had to expand my knowledge of Python programming significantly throughout the course of working on this project. Multi-threading was a new concept to me, however it was important to come up to speed on this toolkit because our test method required multiple hardware units working at once (i.e. changing applied signals at the same time as measuring output signals). In the end I was able to successfully program the hardware to test our devices and collect and save data simultaneously.
As a former test operator, I knew the program needed to be easy to use so that the operators in the lab could focus on juggling sample times and otherwise properly managing their stations. I created a simple graphical user interface (GUI) so that operators would be able to change key electrical parameters without having to edit the source code. This enabled our results to be more consistent as fewer variables were inadvertently changed due to operator error.
Once the initial version of the test software were implemented, I continued to maintain the code base and improve the performance of the program based on the needs of the users. I made sure to stay informed on how their needs changed over time, and made several more versions of the program to meet these needs. Eventually, when my time at NanoDx was coming to a close, I ensured that all documentation related to the test software was up to date, allowing for a seamless transition to my replacement.
Through working on this project I learned to believe in my ability to be resourceful and teach myself new skills. I was not working under a senior software engineer during this project, but rather relied on online documentation as well as my perspective as an inventor and operator in the lab to develop an effective solution. My test software directly increased the bandwidth of the operators in the lab, allowing the team to gather more data and further characterize the performance of our device.