Cloudmosa RD Internship 2020 (I)
What it feels like working in a tech startup
This is the first part of a 2-post series recounting my internship in Cloudmosa Taiwan — a remote engine browser startup — as an RD intern. In this post, I’ll talk about the company culture, the colleagues I met and things I learned in general. The second post regards technical notes I made throughout the internship, which I soon came to realize are vital to survive in the industry as a rookie engineer.
For Chinese readers, this post written by Liu An Chi (tigercosmos)2 years ago talks about his internship in Cloudmosa.
The Vibe
Located right between the hustling cram schools on Nanyang Street and the serenity of 228 Peace Memorial Park in Taipei, Cloudmosa Taiwan sits on top of the Fubon Bank, overlooking the Presidential Office Building. The workspace itself is only big enough to allow for the 20+ employees each to have their own comfortable compartment (enough for placing a few laptops, a wide screen and personal belongings like coffee utensils or car models which many of my colleagues loved), a pantry, couple of conference rooms (where sometimes our multi-talented engineers play guitar/violin during lunch breaks), and a frequently replenished cupboard of snacks.
With regular tea breaks on Thursday afternoons and a health attentive vibe among the colleagues that prompts frequent jogs and basketball games after work, the company culture builds up the space cozy enough for us to make good progress (at least for the full-timers, whose developing speed and quality I’d never believed one could achieve).
Profession-wise I felt my colleagues are well experienced, self-motivated in general and showing ambition both for the company and of their own. CEO Shioupyn is resolved on the way he conducts business, but open to internal dialogues down to the level of interns. Software engineers are all seniors proficient in their own fields but eloquent in communicating system designs, their skills flexible to support all products, and are self-prompt to take further steps to tune the products‘ performance. QA engineers on the other hand are younger but responsible and patient in responding users and keen to spot problems to halt SWEs before they expand features and product lines. Other positions I talked daily with, but only knew their expertise through weekly updates. From those I saw each of my colleagues completely reliable and easy to work with.
The reporting line works fast and flat, with not much employees to begin with, most of the full-timers report directly to the CEO, and although I was assigned to only one mentor, everyone were willing to help me when I DM-ed them or simply walked by their desks.
Tracing the code base
Back in July, 2020 when my internship started, I only knew Puffin as a remote browser targeting mainly mobile users, and the websites browsed through Puffin are rendered on remote servers before sending to clients to boost up speed and provide security. I knew nothing about how Chromium (the open source browser our project builds upon) works, let alone how we actually split the intimidating code base to a client-server architecture.
Read Meet Puffin Browser: The Fast, Secure Web Browser that Thinks Outside the Box from CloudMosa, Inc. or How the Puffin Browser Works from Liu An Chi (tigercosmos) to take a glimpse of our product.
I browsed the code base during my first three weeks, at first trying to understand the browser architecture in detail and find entry points to fix bugs or new features worth developing, as my mentor Brian, a music lover who takes full-week leaves for music courses held up in the mountains and a gadget enthusiast who scatters his tech toys over his desk, told me that the company values spontaneity, and that they expect RD interns to experiment on whatever they’re interested in. But soon I found my attempt to understand every mechanisms of the project overambitious, and I started to fear that I might leave without contributing anything.
Brian saw me stagnant, and suggested several problems in our products for me to work on. I realized then that I wasn’t as observant as I thought, and that thinking in terms of user experience was my shortcoming, which in hindsight slowed my progress the most throughout my internship. I agreed instantly on building the file drag-and-drop feature on Linux, while not knowing even where to start, I felt relieved that I had something to work on.
Working on new features
Working on a new feature feels like dropping down a deep pit without knowing when the fall ends. You hop down into the code base, trying to find relevant places to patch by referencing between several terminal tabs, your browser and multiple vim panes. When you finally manage to break on a function in your debugger after a few hours of tracing, you’re hesitant to modify it, for it means a possible few more hours of unbuildable mess, or a few days of constant crashes.
Even when you finally climbed up to a point where no bugs are apparent, and you’re confident enough to send it to code review, your mentors would bombard you with merciless comments of suggestions, decent in words, but destroying your nerves by questioning your conduct of architecture, code style, and careless mistakes you made. (Code review sounds terrifying, but I’ll admit that knowing that someone’s guarding your mistakes from messing up the production is a relief, and learning from their comments turned out to be the most fruitful throughout my internship.)
But even after you passed the code review and hand it to QA, things could go astray. As I mentioned earlier, I wasn’t sharp at spotting UI/UX faults, and I quickly found that bug-free in code doesn’t essentially translate to bug-free in user experience. For example, drag-and-dropping a large file to a website involves uploading it first to our remote server. While directly transmitting the file on dropping sounds functional, problems occur when users drop the file on undroppable areas. Transmission to our server takes time before the website rejects the drop, so a droppable test must be performed in advance. Chromium without a server-client architecture doesn’t resort on this mechanism, so this is when you need to head back and restart the whole developing process.
Such was the development cycle I was used to throughout my internship. Later on when I worked on a notification feature on Linux, the technical aspects were different, but the process felt similar.
RD-syncs on Tuesday then felt like torture when I didn’t make much progress. When every other RDs listed out the bugs they fixed within a week or a whole new product they built in weeks, I could only report something hardly different from the previous week. I was often disappointed in my own incompetency.
Things I learned
Props to Brian and my second mentor Leo, the youngest RD who often bounce around the workspace with vibrant ecstasy, whose eyesight is sharp enough to squeeze his vim into 6 panes and shrink its fonts smaller than I could comfortably read and stated: “More information on my screen so I wouldn’t lose track of what I’m doing”, I benefited from their detailed code reviews the most about coding style, structure and other things to pay attention to.
These include: Writing backward-compatible code, patching third-party code, understanding bug severity (when’s the time to allow server crash and when’s the time to just report the bug or let it pass), when to use smart pointers wisely, and many more. Things like these are too much to fit in one post, so I’ll try to explain them in the next post.
Aside from these, I had a clearer sense about startup culture, in contrast to the corporate vibe I experienced a year earlier in Microsoft, people here are more self-prompt, sometimes developing a side project and in no time turned it into a product line. Business outline here is easier to grasp, and from weekly syncs regarding all company positions, I understood more about the company’s struggles and strategic moves: like how we decided to put more emphasis on security or how Apple’s policy of forbidding third-party browsers once made us hard to survive on iOS.
Regrets
I contributed 2.5 features in total: file drag-and-drop, desktop notifications and site permission settings in the past 7 months (bear with me to count a functional site-setting utility inconsistent with chrome’s as a half), not as much as I expected to. I was also interested in fixing rendering/painting bugs in our products, but those bugs are too urgent and important for me to take responsibility (given my limited time in office and the overhead for me to switch to that part of the codebase).
I barely survived the first few months, often asking stupid questions and regretting directly afterwards. So I wrote a guideline for new comers, just enough for them to get past the first few daunting weeks (I would share some of those in the next post).
I’m grateful to have joined Cloudmosa, and I really hoped that the company would thrive. My colleagues were at least 10 times better than me in coding, so now knowing my position, I’m motivated to move upwards.
