This essay was originally written for NHS4001: Critical Reflection (Old) | (nus.edu.sg), a reflection class at the end of university.

I have always been optimistic about the power of programming as a skill. I thought programming was powerful because I had the freedom to build anything I wanted, giving me unquestioned power. For example, when Mark Zuckerberg first thought of taking the college experience online, he quickly built a prototype that was launched soon to become an instant success on college campuses. Therefore, I was always fascinated with spotting a problem or opportunity and then building a product myself to address it. When asked during the USP admissions interview why I chose Computer Science as my major, I reasoned that with programming in my toolkit, I could walk into almost any classroom in any faculty and help solve a problem they face. However, through my experiences in building a side project and doing internships, I realize that the power of programming is not unchecked, and there is more nuance to this power than I previously thought.

My debut first-hand experience in witnessing the power of programming came in my first year. In CS2040, I noticed the problem of attendance taking in the classes at the School of Computing. Attendance was taken either by name-calling or passing a sheet through the class. I thought the current approaches were time-consuming and hurt productivity (the process took about 5 to 7 minutes for a class of one hour). I decided to use programming to solve the problem. I came up with an idea for a telegram bot to simplify and speed up the attendance- taking process and brought on two friends to form a team. We developed a prototype during the recess week and started using it in one of the tutorials one of our friends was teaching.

As seen in figure 1, the attendance bot allowed a teacher to open “sessions” with a designated capacity where students can take attendance with a unique code that the teacher shares with them. The bot does not allow the capacity to be exceeded and shows an error message to the user (not shown in the image) when the attendance count exceeds the designated capacity. Since all the data is logged in real-time on a Google spreadsheet, the teacher can quickly open the sheet to tally the records and take cognizance of the situation. This solution reduced the time taken for attendance to a mere 2 or 3 minutes from the previous 5 to 7 minutes and reduced errors (e.g., a student ticking the sheet for their absent friends). Therefore, what started as a fun side-project quickly gained popularity via word-of-mouth and was later adopted as an official attendance-taking solution in CS1101S and continues in use today. At this point, I was highly elated to realize the power of programming to enact real-world change. The quick process from ideation to prototype and then to a fully-fledged solution reaffirmed my previous idea of the power of programming. With the ability to quickly build and ship products such as the attendance bot, I felt like a wizard who could just spot problems and use the tricks in his bag to solve them.

But what I did not realize was the limited scale of our operation: we were building only for about one thousand users. What happens when we try to develop software for bigger audiences? My experience working as an intern for the first time in the industry showed that the process of building was not as straightforward, and the wizard-like power was not unchecked when working for larger audiences. During the initial covid-induced circuit breaker, I was stuck in my residential college, and just like other international students, I relied on expensive food deliveries for sustenance. This was when I thought about splitting food delivery costs with other students since our delivery address was the same. Since I was working at PayPal during that time, I proposed the idea of a Telegram Bot to allow residents from the same building to order together and split delivery costs to the senior staff in PayPal Singapore. However, instead of quickly moving to ideation on the solution directly, there was much more consultation and discussion.

Unlike the attendance bot project, my power was not unchecked: I had to first draft an internal wiki page to document the project and discuss with more senior staff members and peers to reach a consensus. PayPal staff explained to me how more conversion and dialogue were part of the process for building for such a large userbase was much more intricate than building a bot for a group of university students. Staff also explained how I had to persuade engineers and business leaders within PayPal to come on board, see how it made “business sense,” and support the idea to “take it forward.” As figure 2 shows, the goal of the entire project initially was only to “brainstorm and possibly develop” a prototype, indicating the project’s initial goal was not directed toward building a working solution in the near future. These discussions also led to more ideas on how telegram bots could be used in PayPal in general. As seen in figure 2, an idea was to build a Telegram bot for Small and Medium Enterprises (SMEs) to sell online. This new idea was more merchant-focused than customer-focused and thus in a very different direction compared to what I initially wanted to build. Therefore, the power of my programming skill was checked via discussions and consensus.

I further noticed this checked power during my second internship at Garena. While I was used to building side projects solely based on what I wanted to build, I had to work on an internship project based on my team’s requirements at that particular point in time. My team worked on a live streaming service, and I was tasked with measuring the server-to-client latency, the time delay between when a video file is sent from a server and when it is played on a mobile phone, for our service.

Figure 3: Slide from my Garena Internship Presentation explaining my project on measuring server to client latency in our live streaming player.

As figure 3 shows, my project was about “measuring server to client latency,” which involved minimal programming but much more experimentation, as seen in the image in the slide showcasing the experiment setup. Similar to the PayPal internship, this project involved much more dialogue and discussion than the attendance bot. The results from this experiment were to be used to decide how to build the next stages of our live streaming toolchain. The pace of development in this project was again slow, but this project was a crucial step in deciding the next steps for our live streaming service. Therefore, while I could not build whatever I wanted, I was still able to have a significant impact.

Throughout these experiences, I had the opportunity to use my programming skills to build something that was not necessarily a finished or deployed product and not always what I had initially wanted to build. While my first-year self would probably reckon the inability to build something I wanted to build as being power-less, I would now disagree as I have a more nuanced understanding of the power of programming. I realize that in the same way I have power as a programmer, so do many engineers who work in tandem at companies to build products, and we cannot build a product each for each engineer’s wants. Therefore, there are checks to the power in the form of consultations with seniors and peers. Thus, instead of being a wizard, a programmer is perhaps akin to a lawmaker in a democracy who, while possessing power, needs to build confidence and support to enact change. Hence, in addition to the traditional data structures, algorithms, and software engineering principles taught in my home faculty, I would also need skills such as persuasion, effective communication, and negotiation to utilize the true potential of the programming.