My third and final co-op at WHOOP was the perfect culmination of my engineering experiences. While I was introduced to the idea of firmware at PAX, it was at WHOOP where I discovered that it was my calling.
For my last co-op, I was determined to work for companies that affected the everyday lives of people. It would be very nice to design a small part of a spaceship someday, but my mom can’t use that. I wanted to be a part of something that people in my life were just as passionate about as me. That is when I found WHOOP.
WHOOP is a company focused on helping people reach their highest level of potential by turning the body’s feedback into meaningful results. By tracking your vitals, sleeping patterns, and daily strain, WHOOP allows one to start replacing harmful patterns with positive changes in their lifestyle. What drew me to WHOOP was how accessible data usually reserved for top tier athletes was for everyone. I am by no means the next Lebron James, but I too would like to know why I feel better on some days versus others. WHOOP allows one to understand how to optimize performance not just on the field but in life.
Located in the heart of Boston near Fenway Park, I was beyond ecstatic for my first day at WHOOP. However, in the back of my mind I was worried that I would not get much out of my last co-op. Having previous firmware experience in the consumer electronics realm, I feared that I had already seen it all. There are only so many things that an intern could be entrusted to work on for 6-months. But boy was I wrong.
My entire time at WHOOP felt like I was part of a dumpster fire in the best way possible. I arrived at WHOOP in July 2021 and the Gen 4.0. strap was released in September 2021. This allowed me to be a part of the final stages of production and get a behind the scenes look at the days leading up to a finished product. An experience that I had never had before.
I don’t know if anyone has ever tried reaching a product deadline in the middle of a global pandemic with supply chain shortages, but chaotic would be quite the understatement. The brunt of it all fell on the hardware team who were constantly going above and beyond to produce a fully functional strap. Even when the key capacitive touch hardware on the strap had to be replaced mere weeks before launch, hope was never lost.
Despite all the madness and odds being against us, Gen 4.0. was launched successfully. I know my time at WHOOP may not sound appealing, but it was the most I’ve felt alive. It was like the tunnel scene from A Perks of Being a Wallflower, where nothing else mattered and we were infinite.
In addition to having an exhilarating time at the company, I became a more refined developer. Git is used in a unique way at WHOOP unlike anything I had ever seen before. There were specific rules, MISHRA standards, and QA processes to adhere to. This was also the first time I was working in one code base at the same time as the rest of my team. This meant that I constantly had to be adding or removing dependencies on other people’s branches. Let’s just say that I wasn’t a huge fan of rebasing, and that it may have been the bane of my existence.
My very first task at WHOOP – the one I like to flex the most – was implementing the shipmoder UI.
The pulsing pattern above is the first thing users see when they take their Gen 4.0. strap out of its box. The pattern indicates that the device is currently in a low power shipmoder state and needs a Bluetooth connection before it can start to be used. Knowing that every WHOOP user on this planet has seen the lights I worked on gives me a great sense of joy. It feels good to point to something tangible and say, “hey, I made that happen.”
For some reason, despite my many years of coding, I had somehow managed to evade unit testing. I don’t how I did it, but at WHOOP I became acquainted with the idea of test-driven development. I was given the opportunity to go back and write unit tests for my shipmoder UI code. At the very least I will say, it was quite a humbling experience to see my code months later. . . There were so many more efficient ways I would have written out the logic had I started off unit testing. I saw that test driven development made for a better-quality final product and thus is a viable tool to have up one’s sleeves.
However, my white whale was my design of a complex firmware update procedure for the battery packs. During my time at WHOOP there was no feasible OTA way to make changes to a strap’s battery pack once it was out in the field. I think it’s safe to say that not being able to resolve any field issues remotely is a literal nightmare. What if a problem affecting all units crops up? One proposed solution was to ask customers to manually plug batteries into their computers to update them. Although a possible remedy, that would not have given any brownie points to WHOOP in terms of user experience. This left me with the daunting task of figuring out a seamless cure to this problem.
I say daunting because prior to this I had zero experience working in the bootloader. A bootloader is by far the most critical piece of software on any structure. It is the first thing to be loaded and run when a system initializes. It is responsible for handling all update proceedings. Needless to say, the consequences of messing up in the bootloader are far more severe. Furthermore, I was still familiarizing myself with the finite state machine software architecture used at WHOOP. Finite state machines in an embedded system are composed of multiple states. At any given point, the system is waiting in a state for an event to trigger an action or a change in state. Events can occur due to an interrupt in the system, RTOS signals, timer expirations, or an input from another system module. Creating a new firmware update procedure in the bootloader would require me to create and implement new states from scratch.
Nervous as I was going into this task, I am very proud of what I was able to accomplish. I was able to successfully set up and transition between 5 new states. They were specific to the battery pack update process and consisted of the initial handshake, start, load sectors, end, and check for success states. The initial handshake state checked for certain conditions to be met i.e., the battery pack holding a charge of at least 20%, in order to allow the update process to begin. The start state sent a command to the battery pack to begin prepping to receive byte sectors. The end state sent a command to the battery pack that the byte sectors had finished loading. The check for success state cross checked the firmware version on the battery pack after the update to the expected version. The expected version was obtained from the header of the update image file detected by the system.
The meat of the process was the load sectors state. On top of chopping up the bits into loadable sectors, I had to figure out a way to stuff the bytes as well. Byte stuffing is the process of transforming a sequence of data bytes containing ‘reserved’ values into a longer sequence with no occurrences of those values. The stuffed bytes then need to be destuffed on the receiving end. The most common example of a ‘reserved value’ is the escape character.
Regardless of all 5-states being functional and logically sound, I was never able to see my code in production.
From the get-go I knew that there was an overwhelming chance that my efforts would never come into fruition. It had nothing to do with my capabilities but rather a limitation of the available technology. Wireless connections formed between the system and the battery pack were shaky and inconsistent. While it presented no problem for the pulse charging feature of the battery pack, it did for updating. More times than not I bricked dev battery packs running my code because of the signal cutting out. A mistake you can’t afford out in the field.
Although I sometimes lie awake at night at the thought of my code rotting in dev purgatory- the drafts section of GitHub - I had a very positive experience at WHOOP. It was the first time I got to experience the fulfillment of seeing what I’ve worked on go into production. I deeply enjoyed being a part of a company whose product I genuinely enjoyed and used every day. For testing right around launch, I was seen wearing up to 4 WHOOP straps at once! It was a product I used and promoted not because I had to, but because I wanted to. In fact, I was such a walking advertisement for WHOOP that multiple of my friends ended up signing up during my time there! Nothing can ever top the high of talking my cousin through on how to slide off the battery pack. Knowing that the lives of the people around me were affected by what I was doing gave me a purpose in life.
Anyone who knew me had known my . . . reluctance . . . to stay in the great city of Boston post-graduation. I was adamant about moving as far away as possible from Boston the second I could. Contrary to my proclamations it was for WHOOP that I ended up deciding to stay. That alone should be a testament to how much I loved being at the company.
During my final semester of school, I remained on part-time. During this time, I led the effort to diagnose and debug capacitive touch hardware failures. Moreover, I integrated Memfault metrics to assist with remote debugging of the device fleet.
What was supposed to just be the start of a wonderful journey at WHOOP unfortunately turned out to be the end.
I was slated to start full time at WHOOP after a summer sabbatical. Amidst the surge of tech layoffs in the summer of 2022 my offer was also rescinded. As devastated as I was, I wouldn’t trade that hurt for the bliss of the entire time I was there. I have a lot to thank WHOOP for. Whether it be my unrelenting addiction to Spindrift (the absolute best seltzer water out there hands down) or the skills I’ve learned that have enabled me to be a better engineer. I may no longer work there, but I know that deep down I will always be a WHOOP girl!
