Many people aren’t completely sure what chemical engineering is or what it entails - mainly that it can be a bit rigorous, like other engineering disciplines. When I picked it as my major, I wasn’t sure either, but it sure sounded cool (wasn’t aware of the rigor though). Progressing through the necessary math + chemistry + physics etc. classes did, in fact, inform me on the discipline, which is great news for the return on my student loan “investment”. But after starting in industry, I was able to determine how that knowledge applied to me and how I wanted it to inform my impact in projects and initiatives. The same process happened with 1) participating in research and 2) picking up my computer science minor where I was able to determine what subjects and skills spoke to me the most and why, and how that contributed to my move to data science.
The curriculum gave me the necessary background
This is the most clearcut parallel - my classes that taught what would become the basic concepts of data science, taught me the basic concepts of data science. My Computer Science classes gave the classic undergrad “learning to code” starter pack of data structuers and algorithms + object-oriented programming, and some ChemE required classes like Calculus and Statistics gave the math background needed for machine learning.
But my ChemE classes, particularly the (alleged) weed-out engineering computing classes (HTML, CSS, Linux, Matlab + C++), introduced solving problems and completing analysis with code. I had dabbled in R and HTML/CSS in high school, but this was my first exposure to using code as a tool and the demands of knowing a resource well enough to bend it to your will and solve problems. I loved the class, but it didn’t love me back at first. It was a firm love/hate relationship that I indulged by later becoming a teaching assistant for that class during my last few semesters of undergrad. The best way to slay your enemies is to become friends.
In industry, data science was a means to an end, not the focus
The research I did in undergrad and the basic data analysis it entailed + the aforementioned classes started to come together in my first position out of school. During recruitment, I was debriefed with the prospect of working with color imaging data (which spoiler, I only managed in my next role), but my job turned out to be actually making paint. Most impressive bait and switch of the century. It was made emphatically clear that I was supposed to mix up the formulas that someone else made, but there was so much to be done with our data! So that’s when my coding side projects started.
The company had a scientific coding group centered around how some chemists and formulators in other labs were solving problems in their projects using computational solutions, largely involving Python. As a new hire, the monthly meetings of sharing code, project presentations, and workshops were my first exposure to the subject matter, coatings formulation and chemistry, and coding being used directly for research and product discovery. It was also a “forced” deep-dive into Python, which I had despised due to the indentation and lack of Java-like “punctuation” - had to get over it. Even the transition from research in academia to industry was a learning curve in term of experimental priorities and communication.
The viewpoint I had of my CS background from undergrad to industry morphed from “fun and quizzical” to “utility and purposeful” (but still fun). Using packages was fun to learn how to use (Anaconda, less so), but exposure to new tools led to me thinking “how can I use this somehow”? So when not at the bench, I worked on side projects using new and historical experiment data, like displaying run results in Matplotlib instead of Excel and quantifying sample corrosion with OpenCV instead of measuring by hand. Not much resulted by way of widespread adoption, but through this practice, I adjusted to the idea of data science as a tool for impact, not the main event.
Problems are everywhere, so products are, too
The most profound thing I absorbed in my ChemE product design classes that the purpose of invention is to fill “gaps”, this “gap” being the distance between what people have and what people need. Consumers are “people”, but engineers and colleagues are “people” too (no matter what the others say)! The people that you collaborate with can also benefit from the hodge-podge solutions you make when they’re “product-ized” into clean reusable script + clear documentation. You can try offering your hodge-podge solution to people, sure, but people experience and circumvent gaps all the time. If it’s not easier than circumventing the “gap”, it won’t be used, period. Not their fault, it’s just not the right solution! If you’re able to offer them a solution that is easier than circumventing, then voila- you’re adding value. So there’s always an opportunity for your product to solve problems other than the one in front of you.
So searching for products doesn’t mean “sell, sell, sell”. It’s the point of view that gaps are everywhere and products are just solutions packaged for other humans to benefit from, whether they’re your consumer base or a fellow engineer. When you create solutions for problems, there’s always a chance to “scale ” it into a product and making it easy and intuitive for people to use by using a reliable process.
This section started small and ended up extensive, as all the best things do, so maybe I’ll dive deeper in a later post.
Wrap it up
As a young adult in university, my job was to pursue the things I was interested in, but it was figuring out how to make them come together in a career path that was a consistent worry of mine. Data was the first thing that allowed me to do that seamlessly and with purpose + impact. So not only did I find a nice niche, but it enables my habit of pursuing new interests regardless of relevance or cool factor, because I’ve seen that it’ll all come together in the main plot eventually.