Resume and Career Goals

Professional Summary:

Picture the scene:

Disaster struck, and we have a few hours to figure out how to fix it now using just what's on that table over there, or lives/the project are at risk. While I definitely don't want that to be a common occurrence, if/when it does happen, you'll be glad you had me on your team. Ideally, I would have prevented such an issue from popping up to begin with. Though not listed on my resume, my first part time job was working as a student at the Vanderbilt Dining Hall, to help pay for my tuition. Although most of what I did was scoop food prepped by the professional chefs, I moved as quickly and accurately as I could, since I was serving fellow students, and I knew we had places to be. My hard work earned me the compliment, "Oh good, Patrick has arrived, we can all relax now", as well as generous portions of my favorite foods whenever I came back to eat as student. (Shh, don't tell)

In both work and life, I always strive to find ways to do things better, without losing sight of the big picture, and fixing what isn't broken. Click the links for anecdotes that explore my points in further detail, or continue reading for more concrete details about my career goals, resume highlights, and projects I've worked on.

Looking for the other Patrick Meng that also went to Vanderbilt, currently located in Washington DC? Click here for his LinkedIn. 

In my detailed resume section, or in my projects, I will go into more detail about the specific accomplishments I did at my former role. But I will say, we often had tight deadlines to finish experiments, and things didn't always go smoothly. There were times when we either did the neuronal recording that day, or the data was lost because the window passed, and we just discovered a new thing we needed to implement to cover for a new complication that we just figured out the day before. 

And I'm proud to say, there were plenty of times when I showed up, was told we needed to get a fix for "some problem", and within a few minutes, I had whipped up the code or a quick fix to get us by, and then designed a more permanent solution once it was over to either prevent it from happening next time, or to have something robust for "repeated use".

For example, one time, we had a ton of micro wires that attached to a specific neural probe, and we needed it to interface with an entirely different model of neural probe. There was a lot of noise (caused by interference from the ungrounded wires just floating in air, and when capturing neural signals, even the extra signal from Wi-Fi, cellular, and the literal wires carrying electricity in the walls can be picked up and make the data unreadable), and the professor originally suggested we try soldering them together, but the wires were also shielded, and we didn't have a microfine wire stripper that would have gotten the job done. I then suggested, we have medical saline, and we have beakers, why not just immerse all of them in the conductive salt water, and then run a grounding wire into the same beaker? The professor was skeptical, but since it would take only a minute to try, and we didn't have other ideas, we gave it a go.

It did in fact work, and funny enough, when we tried to come up with a better solution, despite spending a few hours trying to do the soldering/ wire stripping by hand when we had more time and the proper tools, it turned out the most efficient solution is "the bucket of salt water" as I had jokingly called.

Getting Better Every Day, In Part By Not Fixing What's Not Broken

At my high school, my principal repeated this phrase to us, "Get Better Every Day" or GBED for short. That's overall good advice, and I enjoyed my interactions with him as a high schooler. However, the more specific adage I heard, is "it is not the tallest boulders that impede your progress most in climbing the mountain, but rather, then stone in your shoe". 

I was able to take both pieces of advice to my prior role. After losing valuable data due to a simple oversight, I pushed for having a checklist instead of just "doing it by memory", even though we had amassed plenty of experience in that area since then. I continuously refined the UI for software I wrote for fellow lab members to use, whenever they brought up a feature they had struggles with.

But I also made sure to pay attention to the small details. (The stone in your shoe). For example, when I was explaining how to use a piece of code to a coworker, I noticed the spacebar on his keyboard would get stuck. I asked, if it had been doing that. And he said yes, it had, and he had just been dealing with it, because most people don't like to rock the boat over "little things". I immediately replaced the keyboard with a perfectly functioning one from a computer we weren't going to be using for a couple of weeks, and placed an order for 2 replacement keyboards, since keyboards are cheap, and in a world of distractions, the last thing you want to worry about is unresponsive keys.

Adopting the latest tech can sometimes trivialize a previously difficult problem. However, its good to keep in mind why something works, and not just improve efficiency just for sake of efficiency. To illustrate that example, let's talk about the US National Parks. A task of the park rangers, is to clear fallen trees of the trails. For the longest time, they had went in with handsaws, and carried the wood away on foot. An outsider would consider, they should use a truck, and a chainsaw. Oh, trails not accessible to vehicles? Wheelbarrow and chainsaw? 

But let's think back to why people visit the park in the first place. For the quiet, and the chance to reconnect with nature. It's only sensible that the rules set out from the beginning banned all motorized vehicles, as well as equipment. Nothing would ruin a nice hike more than the din of a chainsaw. As for why the wheelbarrow isn't used, its because the traditional interpretation of the rules is that "no wheels", since bikes aren't allowed on most trails either, and as "the role models" the rangers thought it was only fair to not be hypocritical and use a wheelbarrow.

Some might argue its stupid, and that "we have the better technology, it would be faster". Faster is often better in business, but not always, its good to think about what you lose with speed. You can listen to music at double speed and hear twice the amount. You can eat your food faster by chewing harder, faster and fewer times. But its important to ask, what do you plan to do with all the time you've saved?

I'm happy to adopt some new tech if it has essentially all upsides and minimal downside. Sometimes, something just works. It's easy to focus on how some new tech can speed things along by some metric. And perhaps it does. But switch over at your peril, and after many hours, you might notice the 10% time savings was completely erased by the multitude of other problems that arose once more, that had previously been "invisibly handled" by tried and tested ancient technology.

I heard the story about the parks from a podcast called 99% Invisible. I've included a link to the episode in question here.