My days at National Taiwan University (NTU) have now completed a full three years. This post records my life from junior-year winter break to junior-year spring in the Department of Bio-Industrial Mechatronics Engineering (BIME). The storyline can roughly be divided into three parts: research, coursework, and extracurricular activities. That said, even though I study in BIME, most of the stories are not actually “BIME stories.”

Research

In junior fall, I started touching browser principles and development. Without noticing, I became very interested and wanted to learn more. So I joined the IT Ironman competition hosted by iThome. By writing technical posts for 30 consecutive days, I strengthened—and forced—myself to learn more knowledge about browsers.

But if we talk purely about principles, by around day 20 I ran out of things to say. I could only admit that my understanding was still too shallow to discuss detailed parts in depth. To keep going, I thought: I can read papers. So I focused on papers related to browser research. Unexpectedly, this let me “carry” the remaining days. The process was: every day I spent around four hours reading one medium-length paper (about 6 to 10 pages), then writing a summary and reflections. Later, my series Let’s Build a Web Browser! was lucky enough to win first prize in the software category of the Ironman contest, which made me genuinely happy.

Still, I only understood a bit more than a layperson. So I wanted to do deeper research, and the idea of finding a professor to do research with started to grow. I went to the CS department website to see which professors might be suitable to advise me. Looking through them, it seemed that no professor’s expertise directly connected to browser internals and development. But I thought browsers are a topic strongly related to “architecture.” Coincidentally, in the CS department’s list of research areas, there were three professors whose specialties included the word “architecture.” They were all linked together near the top of the website: two associate chairs and one head of an institute. I looked at their backgrounds and CVs, and in the end I found that only one professor really fit me—meaning I only had one chance.

Before this, I had already accumulated a lot of experience “dealing with research.” In high school, I approached a physics professor at NTNU for a project. For experimental equipment, I went to contact a researcher at Academia Sinica’s Institute of Physics. Starting in freshman year, I worked as a research assistant in Atmospheric Sciences. In sophomore year, I did research with my advisor in BIME.

Even though I had quite a lot of experiences, the physics professor at NTNU (傅祖怡) and the Atmospheric Sciences professor (林博雄) were probably satisfied with me. But I also had a few failures. In high school, I joined a student research program guided by an Academia Sinica researcher, but in my first semester of senior year I felt I needed to focus on studying, so the project ended without a conclusion. I imagine she must have been disappointed. In BIME, I originally wanted to do deep-learning research related to biomedical topics, but I ended up muddling through it. Fortunately, I was working with my class advisor, so our relationship was closer and I did not blame myself quite as much. Still, those earlier failures left deep marks in my mind. I did not want to repeat the same mistakes again.

When it came to finding a professor, I only had one chance. If I failed, I would probably have to leave NTU to find an advisor. Luckily, I had read many papers while writing my posts, and that became one of my bargaining chips. I also admired 彭明輝 at National Tsing Hua University. I think his stories are worth learning from. One story in particular was: when he went to the U.K. for his PhD, on the first meeting with his advisor, the advisor gave him a few papers and told him to read them and then come back to discuss research directions. He said to the advisor, “Professor, I’ve finished all these papers!” and the advisor immediately looked at him differently. If you want the original story, you can read “A Trip to Cambridge”. The point is: before asking a professor to supervise your research, you should have read some papers and done some homework first—otherwise, how can you say you want to do research? In other words, you should prepare before doing anything.

I chose the professor, and of course the professor also chose the student—but I believed the professor would accept me. I first wrote an email stating my intention to seek supervision and asked whether we could meet to discuss. In the email, I attached several papers I had read and my analysis. I also explained that I had open-source contribution experience and had interned at two companies. I thought any professor who saw such a sincere student would accept them. The discussion went smoothly, and I officially started working with CS Professor 洪士灝.

After so much build-up, my junior winter break was actually spent doing foundational preparation for research: reading a lot of papers and applying for the Ministry of Science and Technology (MOST) undergraduate research program. Just writing the proposal and thinking through research directions and topics quietly consumed the whole winter break. The proposal was accepted. The official project period was from July to the following February; I learned of the approval in mid-June. But of course, I could not wait for results to start doing research. Whether or not the project was funded, I still had to do research seriously. So during junior spring, I met the professor once every two or three weeks.

At the beginning, I was full of passion. But later I gradually realized that browser research is truly hard. Browser software development seems to have reached a plateau, and no one can say for sure whether it is already near the ceiling. Put simply: it is hard to achieve major breakthroughs; progress tends to be incremental. I think the biggest difficulty is the complexity of browsers themselves. If you want to do research with enough weight, you almost have to use a mainstream browser like Chrome as your material. But those are massive projects with millions of lines of code. The codebase is so complex that it is not something you can modify just because you “want to,” and even achieving a comprehensive understanding is not easy.

In this regard, I also feel a bit ashamed. I wanted results, but results are not something you can guarantee just by investing time. I truly did not want to repeat past failures. I had already decided that this time I would do research properly and see it through, because it was a topic I was genuinely interested in. In the end, in junior spring I only did some “imaginary experiments”: I built a system and collected daily backup images of the top ten websites (important research material for browsers). Even though I kept telling the professor that I would modify Chromium in some ways to validate the “imaginary experiment” results, in the end I still did not actually do it in junior spring. I did spend time studying the source code; I was simply not strong enough to accomplish it within the semester.

Not being able to produce results remained a hidden worry, and it put huge pressure on me. I hoped I could produce high-quality research and did not want to disappoint the professor. During one discussion meeting, I asked: how do you ensure stable output? The professor said research requires insight and vision: you have to discover where topics exist, and when you see a topic, you must judge whether it is feasible. This ability must be trained. If you are a PhD student, of course you have pressure to produce research and graduate. If you do not produce impressive results for months, your advisor might worry about whether your ability is insufficient—but if your past performance has been strong enough, the advisor will believe that you can eventually produce results. The professor did comfort me: I was still an undergraduate, and at this stage I was mainly practicing.

Still, I was disappointed in my junior-spring research. I felt it was not up to standard. But the professor still gave me an A+ for the research project. The professor was willing to trust me. My research in the second half of the year could not fail.

Coursework

Next semester, my department had four required courses. I truly think that is too many. In the College of Electrical Engineering and Computer Science, required courses basically stop starting from junior spring, while our department still had two required courses even in senior fall. What is more worth mentioning is that I dropped one relatively unimportant course, and used that time slot to take the CS department’s Data Structures and Algorithms. I also took the CS department’s Operating Systems.

Because I interned at companies from sophomore year to junior fall, I basically did not set aside extra time to take CS courses. Even though I had some software development experience, I lacked the most fundamental training. So this semester I made up my mind to take courses seriously. In the end, I took a total of 23 credits—my highest load since freshman year.

Let me talk about CS courses first. Taking them in junior year is later than typical CS students: for them, one is a freshman-spring course and the other is a sophomore-spring course. But I felt taking them at this time had a special flavor. I had already written a lot of code, contributed to open-source projects, and interned at companies, so these concepts felt more real. It is a bit like learning calculus: at the beginning you may not know what it is for, but in reality you will use it later in almost any engineering field. My learning order is: when solving problems, I discover that my abilities are insufficient, and then I go back to fill the gaps. I think both learning styles are fine—I just happen to be the “missing first, then fill” type. In short, I enjoyed CS courses a lot, and they gave me a happy semester. Even though I keep regretting that I was not directly a CS major, I also think that my current passion for software development exists precisely because my path was so winding.

Among the required courses, there was Fluid Mechanics. There is a novel called October Sky and a film adaptation. It tells the story of high school students in a coal-mining town in the U.S. during the Space Race, dreaming of building rockets. I think it had a big impact on me later. Because I was curious about the universe, I liked physics; because aerospace technology felt fascinating, I liked engineering. Back then I even dreamed of working at NASA. But at that time I was only a middle school freshman. Excitedly, I got two books—Fundamentals of Flight Engineering and Principles, Design, and Fabrication of Experimental Rockets. But after reading the first few chapters, I could not understand anything; the rest was all calculus, which made me very frustrated. Later, for a final report, I thought I could re-study rocket technology and flipped through those books again. I could not help but smile: now reading those books felt easy.

Another required course was Mechanical Elements Design—and it was the biggest crisis in history. The instructor pulled no punches. Let me state the conclusion directly: 10 out of 40 students failed that semester. Before transferring into BIME, I thought mechanical engineering was quite interesting, and I assumed I could handle it. But reality proved otherwise. I realized I am terrible at mechanics calculations. Along the way, I was only able to pass mechanics courses thanks to professors being merciful. So encountering such a strict instructor was truly unfortunate.

This course had four midterm-style exams, and those exam scores directly became the semester grade; the instructor also did not curve. To make sure I passed, I had to keep my nerves on edge the entire time. In the end, I barely passed by a hair, with a C-. But I was already satisfied. With such a strict instructor, it was fortunate I only needed to deal with them once. I both loved and hated this course. The good part is that I had never been so serious about a department required course, and I re-experienced what it means to seriously understand “what mechanical engineering is.” Also, even though my grade looked bad, I truly became less afraid of mechanics. The bad part is that it consumed an enormous amount of my time: after painfully struggling just to barely pass, I could not spend more time and energy on CS.

Several classmates scored near full marks every time. At those moments, the instructor would point to the right side of the “M-shaped distribution” and say: looks like I made the exam too easy again—so many full marks. My dear instructor, do you see the pile of people on the left who did poorly? Even at NTU, social differences are still obvious.

Anyway, this semester I All Passed. For a software engineer to survive a pile of mechanical courses—thank goodness!

Extracurricular Activities

Every year in mid-March, NTU holds the Azalea Festival: a fair for high school students to visit departments and clubs. I participated this year too. Juniors and I were responsible for a booth, and we built a moving octopus robot for display.

default

At the Azalea Festival, I always explained things to high school students very seriously. But I felt that many high school students had a rather casual attitude—those who showed sincerity were extremely rare. When guests are not sincere, the host also loses enthusiasm.

I also gave a talk at the student open-source conference SITCON. The topic was browser internals and open-source experience. Giving a talk is really not easy. During preparation, I also discovered many things I did not truly understand. But knowledge you can really speak out loud becomes knowledge that truly belongs to you. At the venue, I also met a Mozilla engineer, 鄺子進. The open-source project I participated in, Servo, is Mozilla’s, so he understood my topic well. Because of that connection, we had lunch together and talked for a bit—about browser development, differences between Eastern and Western development cultures, and past experiences. I found it all quite interesting. But what I admired most about him was that he attends conferences everywhere and gives talks on many topics, and he can present in Mandarin, English, and Cantonese. Every talk is a new self-challenge for him.

In fact, after this talk, I also got a bit “addicted.” Speaking to an audience of over a hundred people is genuinely interesting. In the summer after junior year, I would give two talks at COSCUP (the open-source conference). I believe I will find more opportunities to keep the momentum.

speaking image

In the remaining time, I also wrote quite a bit of code. There is an “urban legend” that to be qualified to graduate from college, you need to accumulate 100,000 lines of code. I think I probably reached that goal easily. One thing I put more effort into this semester was developing the weather bot. It is a chatbot that can answer any question. I made it support three platforms: Line, Messenger, and Telegram. I spent a lot of effort adding and improving features. Juniors and friends also contributed to development. It reached nearly two thousand users, which feels like a modest achievement.

That is roughly the end of the story. Thank you for reading. The next chapter will be even more exciting—do not miss it!

😊