This summer I got the chance to intern at Octant on the Software Engineering team. Over the course of this 12 week internship I learned about Octant’s software stack, chemistry workflows, and exciting approach to drug discovery. For my project, I recreated the experimental design tool used by our discovery chemists to include a more performant and user-friendly interface, which led to an improved process of reaction optimization to make potential drugs.
At Octant, we screen thousands of molecules a week searching for compounds that could be good drugs. We explore local chemical space iteratively through experiments we call high-throughput structural activity relationships (for more on HT-SAR see here). This approach involves performing coupling reactions between a “core” and a whole class of compatible fragments. These cores are derived from molecules that show activity against the target and are custom synthesized to contain a reactive handle, which facilitates coupling with the fragment class. Using robots, we can run ~10,000 coupling reactions in parallel, giving us many chances to find hits.
Before we synthesize 10k-member libraries, we first must perform condition scouting, a crucial step in ensuring that our libraries assemble properly. Here, our chemists test tens of conditions across the core and a few coupling partners, varying the types of acid, base, activating agents, and reagent stoichiometries. LC-MS is then used to determine which condition leads to the highest quality library. Since condition scouting sets the stage for full library synthesis and screening, there is a clear impetus to invest in robust software tools to facilitate this process.
With an influx of Compute resources over the past few years, we have been able to simplify and expedite the process of condition scouting for scientists. Initially, chemists relied on a visual basic tool in Excel to plan condition scouting experiments. But as our Compute team grew, we could devote more resources to adapting the tool into an R Shiny app called “chemHub.” Despite the significant advancement it marked relative to Excel-based experimental design, chemHub was still very prone to issues. It would often freeze– sometimes even crash– and would be hard to fix or develop features for by our primarily Python-proficient programmers.
To remove the pain from chemHub experienced by users and developers alike, I sought to re-implement the code in a faster, more reliable Django/React stack and migrate it to our main internal application for scientific experimentation, Argo.
After a few weeks of onboarding, getting my feet wet with starter tickets, and meeting with chemists to understand their pain points to get a better idea of what features I wanted to develop, I started development of Condition Scouting in Argo.
The first glaring issue I fixed was reducing the number of fields that chemists had to manually fill. Since chemists had to copy and paste information from an Excel spreadsheet into chemHub, I decided to implement an Excel upload that would automatically fill in all the necessary information for chemists.
In addition to this, I implemented new features like importing, table views, filtering, stupid fast APIs, and guard rails in case of bad inputs in order to make the software feel significantly easier and more fun to use. To make debugging easier for developers, I made it so that any errors will be explicitly announced. Most of the input is managed through an Excel spreadsheet with robust validation during import, reducing the necessity for chemists to make input adjustments within the software. This approach effectively eliminates a significant category of user errors.
As part of the development process, I met with users every week to get feedback on the latest features. With good feedback, several iterations, and many a latte from the company espresso machine, I rolled out the whole workflow. Overall, with TypeScript and explicit Python type safety, I was able to develop a very robust application that was well tested and defined.
Why do all of these changes matter? Previously, chemists would spend hours designing experiments on the old software. Part of this slowdown was because of the UI and its implementation but also because of bugs and crashes that were hard to diagnose and rectify. Moving the condition scouting workflow to Argo corrected 90% of these issues with a fresh UI and a testable, debuggable codebase.
Additionally, with improved input and workflows, chemists were able to reduce their experiment generation time from around 2 hours of total time to only 20 minutes even before they were used to using the new software.
Being able to use software as a tool and not deal with it like a roadblock makes the process of doing actual science more impactful and seamless. Instead of spending time figuring out software, chemists can spend their time doing important work that can one day benefit patients everywhere.
My favorite parts of Octant outside of the technical development were definitely the people and the culture. Everyone here has been very welcoming and helpful, and I’ve always felt that others value my contributions to the team. The friendly culture additionally manifested itself in fun after work activities with the team! Board game club, tennis, and soccer club were my favorites to attend!
I also absolutely loved the espresso setup at the office. I was able to continue to enjoy my hobby of espresso and latte art at Octant while surrounded by a surprising number of people who were equally interested in coffee. Here are some pictures of latte art I made!
My time here at Octant helped me solidify my decision to pursue a PhD. While I didn’t get a chance to delve deeper into more research-y areas like the work done by the Data Science team, I still had tons of fun and lots of great mentorship that guided me toward wanting to do grad school. In fact, I am in the process of applying to PhD programs this cycle and hope to start Fall 2024. I’ve also found software development very fun. More specifically, I’m surprised by my appreciation and enjoyment of frontend development since I previously disliked working on frontend parts of my apps due to my lack of experience. At Octant, because of the sheer amount of existing code as well as others on the Compute team offering guidance every step of the way, frontend development felt like a breeze. While I wait until next fall to matriculate into a PhD program I am staying at Octant as an apprentice, where I’ll continue sharpening my software skills and getting more exposure to wet lab techniques and data science. Overall, working at Octant has helped me gain the skills and confidence needed to succeed in graduate school and I’m so excited to spend the next year here!
.jpg)