Blog post by ELP Student David Chang (Biomedical Engineering | Class of 2019
Like all great success stories, especially ones that are over a week late (sorry CFE!), my career at Genomenon began in typical fashion. I lethargically stretched out my arms while my head was still dug into my soft pillow. I opened my eyes, and that’s when I saw the bright red numbers. “8:40 AM,” my alarm clock displayed. I jumped out of bed in a panic, put on the first shirt I found in my drawer, and ran out the door.
It was 8:50 AM now and I had 10 minutes to bike three miles to the office. With my quads burning, I arrived at the office building at 9:05 AM. It was a dingy, unassuming brick building across the street from Briarwood Mall, not the kind of hip, modern WeWork office space you might imagine a startup to be located in. I walked in, went up to the third floor as I remembered doing for my interview, and to my surprise, I couldn’t find the office. I must have walked in the wrong entrance. I backtracked, and realized that the entrance was at the other side of the adjacent brick building that was connected to the one I was just in.
When I finally made my way up to the office, I was anxious and ready to apologize for my tardiness, but no one seemed to take notice that I had even arrived. Mark, CSO and Co-Founder of Genomenon, whom I was meeting for only the second time, sat down with me and explained my first task. As we talked, I suddenly remembered that I needed to bring my passport the first day for legal onboarding purposes. I started digging through my backpack and realized that I had left my passport at home. And so, I biked home and back again just to get my passport. What a great start, I thought sarcastically to myself. But things could only get better, right?
(From left to right) Me, Mark, Rayaan and Nick in the intern workspace.
————————-
I scrolled up and down the page for probably the 50th time, and I still had no idea what I was doing. It was already 2 PM and I had accomplished nothing. I had been sitting in the same position all day, my butt felt numb, and my eyes burned from staring at the screen. Finally, Mark, who was sitting right across the room from me, Slacked me.
“You doing OK?” Mark messaged.
RIP, I thought to myself. “I’ve been working on getting the Google Drive API to work,” I said.
“Blocked?” he asked.
“Yeah…I’ve been having some trouble understanding things,” I understated. This was the first time I had ever worked with an API, let alone my first real Python script, and the more and more I read online and searched through all of Google Cloud’s capabilities, the more I realized how much I didn’t know and my head hurt.
As a data processing intern, I was starting off on a project to create a scraper that could automatically extract gene and variant mentions contained in supplemental data files, the extra files attached to research papers that contain extraneous information for the nerds to dig around. This data, however, was extremely important to us. There were customers who were enthused about Mastermind, the genomic search engine and database of genomic variants that Genomenon has created, but had told us that they wanted the database to contain supplemental data before they would throw money on the table. This was one thing that was holding us back from getting more customers, as James, the Client Success Specialist, kept stressing to me. Seeing how important completing this project was to the growth of the company, I felt a real urgency to get the job done. But I was still stuck on step one, accessing the files from Google Drive for analysis.
Mastermind is the world’s first genomic search engine that scientists and clinicians can use to find the most relevant human genomics research articles and gain insights into disease-gene-variant relationships.
The next morning, I checked in with Mark. Overnight, I figured out I could use another Python library called PyDrive that would simplify Google Drive API tasks, but I was running into errors. I tried googling the errors that popped up, but they kept bringing me to these esoteric, janky forums and I was too lazy to actually read through the forums, so I stopped working, hoping that tomorrow someone at work could help me out. When Mark asked me to show him the code I’d written so far, I panicked because I hadn’t written much of anything and rambled through my process of playing around with the API, making occasional breakthroughs, but then hitting more errors.
I could tell Mark was exhausted by listening to me barf out all my thoughts, so he told me to slow down and methodically tell him first what went well and what I was stuck on. We Googled the error and went back to the same page I was looking at before. This time we went through the forum, comment by comment, until we found a suggestion that looked promising. I typed the suggested command into the terminal, and to my delight, it worked.
To help me troubleshoot and improve my problem-solving approach, Mark wrote up a series of questions that I should think about every time I need to communicate to another person about my work and the problems I’m facing. They are the following:
- 1) What am I trying to do?
- 2) What am I using to execute the plan?
- 4) What have I done that has met with success?
- 5) What is my current error?
- 6) What have I done to try to solve/address/understand the problem?
- 7) What help would I benefit from to get unblocked?
Mark really likes to use the words blocked and unblocked, and it’s the first time I’ve ever heard someone use these words in this context, but I like them. There’s a certain urgency I tend to associate with the words, a sense that there’s stuff we really need to get done, and although we will face obstacles, we must find ways to get around them, whatever it takes.
With that, I began to write my code, but quickly found myself getting stuck as I tried to think about how I would extract data from different kinds of file. I had a plan for how I would logically complete my task. Mark called this my pseudo code and had me write out all the steps I would take in plain common English, such as “Iterate through all the excel files and check each cell row by row to get data that matches this particular pattern.” But I found myself spending lots of time trying to figure out the code I needed to do exactly what I had planned out, which sent me on a long Google search.
For example, I spent more time than I should have trying to understand and compare different Python modules I could use to pull data from Excel files. Many of the modules seemed to be able to do some of the things I wanted to do, but none seemed to offer an obvious solution to do exactly what I had in mind. I was hesitant to commit to one possible solution, until I finally decided to try using a module called Pandas. Once I committed to Pandas, I must have spent at least five hours reading the Pandas documentation and stubbornly trying to figure out a way to extract columns that match a certain pattern anywhere in the column, only to be told by another intern that what I was trying to do wasn’t possible with Pandas. It turned out that there was another module called xlrd that was what I needed.
This made me realize that what’s just as helpful as knowing what you can do with a certain tool was knowing what you can’t do. It seemed that asking other people who were more knowledgeable would be a great way to learn these things. As I started to progress in my script, I kept asking my co-workers questions such as “Can you do xyz with this function or module” and sometimes they gave me straightforward answers which saved me lots of time and effort on Google. But often, they would say something along the lines of “I’m not sure, I haven’t worked with that module to do exactly what you’re doing,” or “I don’t know, but have you tried running the script?” And in the beginning, my answer to the ladder was usually no because I was hesitant to try before getting all the available information I could about the task at hand. But I quickly realized that if I wanted to make progress, rather than spending hours theorizing in my head or asking my co-workers hypothetical questions, I needed to simply start trying things on my own.
But if there’s one thing I’ve learned from coding, it’s that no matter how promising something seems or how meticulous I am, I’m still going to get errors. As I began to write more code and test my script, I continued to get one error after another. The process of debugging is extremely frustrating. There have been many instances in which I spent hours and hours trying to get that one line of code to work, but even after all that resolve, I was still getting errors. When I would tell Mark that I couldn’t do this one thing that he asked me to do, he would come back at me with something like “If you can’t figure out that one thing, forget about it. I don’t care how you do it, so long as it works for the most part in the end,” or “Every time I’ve asked you to do something, you’ve found a way to get it done. Have confidence in yourself.”
And Mark was right. Whenever I’ve gotten stuck, I’ve adapted and made things work. The beautiful thing about coding is that there is almost always a way to do what you want to do. It may not be the most elegant solution, and may take a little (or lot) of tinkering, but there is a way. Ideally, you should aim for the most obvious and optimal solution, but when time is of the essence, when deadlines are looming and the survival of your company rests significantly upon the completion of your project, you’ve got to work with what you know and do whatever you can to get things done.
I’ve learned that while persistence is importance, and oftentimes we must struggle for a while to solve our problems, we shouldn’t get too attached to one way of doing things. When you’ve spent all day failing to get one thing to work the way you want, or nitpicking a detail over and over till you’re beating a dead horse, there’s got to be a point when you call it quits and move on. Likewise, there’s not enough time to learn the intricacies of the tools you’re working with and contemplate all the different ways you can write the code. The bottom line is that you’ve got to go with your gut and commit to something. You’ve got to try, fail, pivot and try again.
It’s easy to lose the forest for the trees, or to become paralyzed in the face a daunting problem. Mark likes to remind us of the concept of creating a minimum viable product (MVP), to always take baby steps and only do what’s necessary to complete the current task effectively. Tim Ferriss calls this same approach the minimum effective dose (MED). I like to think of it as the “It’s good enough” mentality.
I often remind myself of the time I did Makeathon, a 36-hour design competition, with my good friend Mikey. We attempted to build a machine that could automatically fold your laundry. For the first solid 5 hours of the competition, we brainstormed all the different ways we could create the product, and 14 hours in we had accomplished literally nothing but come up with the measurements for a box. We started cutting wood, and immediately I was making mistakes, failing the cut the wood perfectly straight or messing up the dimensions. At first, I kept going back and trying to cut the wood better. I kept asking Mikey if things looked straight enough or if the measurements were exactly perfect, and eventually, Mikey got fed up and said “Whatever bro. It’s good enough.” Realizing the time crunch we were in, we stopped caring about making things perfect and just wanted to make something complete, so whenever we found ourselves getting stuck, we’d say those words. And while we didn’t quite make the billion-dollar laundry folding machine we envisioned by the end of the competition, we created something that worked, something that we could be proud of having created that weekend.
“Whatever bro. It’s good enough,” is what I say whenever I start to obsess over a little detail or start beating myself up over trivial errors. I remind myself that it’s alright to make mistakes, and that it’s better to be making mistakes than to be sitting there at my computer, frozen in contemplation. Like Makeathon, the process of writing my first script has been messy. I’m certain that the code I’ve written up to this point is far from the most elegant, but at the very least, it’s delivering results now and not later.
————————-
There are few things that are more frustrating than getting errors in your code. While I can preach all day about how failure is good, and how you need to be willing to fail to succeed, it doesn’t take away from the fact that sometimes I want to just take my computer and smash it against a wall in utter frustration. But what keeps me going, despite the constant errors, is the prospect that what I’m doing matters, and that I’m not slaving away at this program for nothing. Over the past four weeks, I’ve found myself utterly obsessed with my work. There have been nights when I was coding away till 2 AM without realizing the time, not because I really needed to be, but because I just really wanted to make things work. Unlike school, where most of the time I’m working hard to get good grades for myself, I’ve been extremely motivated to do my best at Genomenon because I want to see the company succeed.
I think a big reason for this is the sense of ownership that I have over my project, and the assurance that what I’m doing here really matters to the success of the company. It’s the anticipation that my work will help us get more customers, and likewise the pressure that my failure to deliver will hurt the company gravely.
But what I love most about working at Genomenon are the little things. It’s the moments when I get a Slack message from another co-worker who’s no more than 30 feet away, the times I show Mark a spreadsheet of genes and variants I’ve extracted from a file, and he geeks out, exclaiming “Look at all that beautiful data!” It’s the moments when I finally get that one line of code to work that I’ve been stuck on all day and I nearly jump out of my seat before restraining myself to not disturb everyone else. It’s those moment when we’re all working quietly only to suddenly hear James in the conference room next door making sounds resembling primal mating calls, presumably in preparation for his next sales call.
(From left to right) Steve, Laura, Mike, Candace and Manu in the main office space.
I’m grateful to have been given the opportunity to intern at Genomenon, to work with great, supportive mentors, and to learn so much. At the start, I had little more to show for than an eagerness to work and learn, but Mark and everyone else put their trust in me and gave me a chance to prove myself, and for that, I’m thankful.
————————-
It was 7 PM on a Friday night. I was the only one in the office, and I could have easily gone home and continued working, but something kept me glued to my seat. I had been debugging all day and I couldn’t stop now. I had to finish it. I ran my script and got an error. “Come on,” I said annoyingly. “Why won’t you just work.” I fixed the line of code, and ran it again. Suddenly, I could see the output printing to the screen. My code was doing exactly what I wanted it to. Immediately, I jumped out of my seat, let out a cheer and started dancing around the office. It’s probably a good thing that no one was there to see that. That feeling of finally getting the script to run without any errors, if only for a moment, was pure joy. I knew the script wasn’t done – it would never truly be done. But for now, it was good enough.