Thoughts​

This semester has been intense. Much of the stress I attribute to the heavy workload of CS3216. It has indeed lived up to its reputation and I am just glad that it's over. Other than that, I am happy with my selection of modules this semester. Many of them turned out to be modules that I would recommend or won't mind doing. Note that my reviews below are not meant to be comprehensive but just my random thoughts.

Module Review​

CS2102: Database Systems​

Before taking this class, I had a surface understanding of SQL and databases based on my previous experiences doing web development work. There was a time when I first started working with MySQL and had to create database schemas, I was lost and so wanted to take a proper introductory module about databases. Now that I have taken this introductory-level database module, I do appreciate database systems more and have a better idea of the syntax and the power of SQL. In this module, I learned about the design and analysis of relational databases. We started with learning about ER diagrams to capture the requirements of a database application. With that, we explored SQL statements to define the table structures and query from the database. Advanced features such as triggers and functions were also covered. For the second half of the semester, we looked into analyzing the redundancy and dependency preserving properties of database schemas. Functional dependencies, BCNF, and 3NF were also highlighted. I went through the first half of the semester barely wrote a single line of SQL. That was a poor decision and I only came to appreciate SQL better when I started to work out the lecture examples and tutorial exercises. Overall, I would recommend this module as a great source of general knowledge about databases.

CS2105: Introduction to Computer Networks​

The computer network is something that I often treat as a black box. In rare times when I had to fix my internet connection or try to configure my router, I realized that I hardly know what went on in these much-needed devices. This module does a quick overview of the five layers of the internet protocol stack. The content is not math-intensive nor difficult to understand. The assignments could take a while to figure out how to handle the input/output as we had to create programs that somewhat simulated how UDP/TCP server operates. But, they are at a reasonable difficulty and could be solved before the deadline. An important concept that I learned from it is about the reliable transfer of data. Given the unreliable channels of communication, how can we create a protocol that delivers data efficiently, securely, and without errors? It is amazing to me that mechanisms such as sequence number, ACK/NAK, a timer can provide a simple solution to these hard problems. Of course, the details are more complicated in real-world systems. I feel that this module provided me with a rough idea of how certain difficult problems have been solved in practice. For example, how IP addresses can be used to identify the hosts in the network across the globe. Overall, I would say this module's workload is reasonable and not extreme. While content can be technical and plain at times, I do think that it's good to know about them even if you don't remember all the details afterward.

CS3216: Software Product Engineering in Digital Markets​

I have posted my reflection about this module here. To say the least, I think different people will experience this module differently. It was a good challenge that I decided to take on and I was fortunate enough to participate. Even though this is a 3K CS module, I learned more non-technical knowledge from the prof, the TAs, my peers, and the various invited speakers. Overall it was a good run and apply if you want a challenge too.

CS3243: Introduction to Artificial Intelligence​

I borrowed the textbook for this module and indeed CS3243 only covers a selection of topics in Artificial Intelligence. I find this module interesting as I am sure many will agree, simply because it's just cool to learn how we are going to build intelligent agents with code (and also the hardware). Starting from searching with heuristics to Constraint Satisfaction Problems (CSP), I learned about how solutions can be discovered by representing them well. Later topics such as MDP and Q learning showed me a way that we can build programs to explore and learn. The projects were fun to work on and the course was well-organized. Overall I will recommend this module!

CP3108A: Independent Work​

I took this module as a way to consistently contribute to Open-Source projects. In my case, I worked on MarkBind, a tool for generating content-heavy websites from source files in Markdown format. It is also the tool behind the course website for CS2103T. I have my progress report available here. I am happy that I took this module and was given an excuse to properly learn an unfamiliar repository and help to resolve pending issues. It could be somewhat boring if you just want to build features. I spent most of my time trying to understand the code and experimenting with solutions to solve an existing bug. It was also a good practice for me to write my PR descriptions properly and document my code well. Some fun that I had doing this module includes finding out how absurd the idea of Open-Source can be. While we all know the collective effort can bring us to greater heights, relying on someone's passion to contribute without any potential reward is almost against human selfish nature. There were a few times that I ran into old issues in OSS repositories where the author had moved on and the rest of the world still keep on asking questions and wanting help with certain packages. It is not uncommon to see abandoned packages lying around. The workload for this module is reasonable as Prof Damith who is in charge of monitoring your progress provides a frequent update to let you know how much work is needed to fulfill the requirements. Overall, I will recommend taking this module if you want to explore OSS.

GEQ1000: Asking Questions​

It is a required university-level module so I took it to clear my graduation requirements. While I admittedly did not spend much time going through the materials, I would say that the module is well structured and conducted professionally. Topics from different disciplines are covered to promote learning about all aspects of questioning. There are many pre-recorded video series to watch as part of the weekly lecture (it seems fine to skip them). The bi-weekly in-person tutorial is very manageable. The tutor for my group was able to facilitate the lesson well. Overall I think this module is low maintenance and well organized, suitable to take it in a semester of high workload (this module is pass-fail-based).

A few years ago, I chanced upon the video "The Last Lecture" given by Randy Pausch. Randy, a computer science professor at Carnegie Mellon University, delivered a lecture titled "Really Achieving Your Childhood Dreams" in which he talked about his life lessons. The one thing that I took away from his talk was his point on failure and setbacks. In particular, I printed a photo of a brick wall and taped it on the wall right in front of my desk to remind me that:

"Brick walls are there for a reason: they let us prove how badly we want things". I was, therefore, excited to enroll in CS3216, a module modeled after a course taught by Randy. Now it's over => finally time to review and reflect! If you don't know what this module is about, see here for the official course website and assignment details. Below I use "A1", "A2" etc to denote the four major module assignments (again, full and official details are available here).

A1​

The assignment required us to find a problem worth solving and design a solution for it. Even though we do not have to implement the solution, it was not a breeze. In a short amount of time, we have to (as a team) decide on a probable idea and validate it with the target audience. I have never done so many user interviews before and I have to say that the whole experience drives home the point that users matter. Defining a problem that needs to be solved and having potential customers that are ready to give advice and feedback are not that easy. But, they are truly valuable. Taking our team's project on improving the module registration workflow as an example, our testers pointed out various blind spots in our design, where we thought that a certain feature would be useful to the target audience but none of them actually noticed it during testing. These 'talk to your users" practices made me realize that when we build products for other human beings, it makes no sense to not listen to them attentively. I may have overlooked the users way too often in pet projects or assignments of school modules. A1 was a much-needed reminder.

A2​

In this assignment, we had to identify an innovation on the market and make a presentation for it. The added challenge is to do it the Pecha Kucha way (20 slides, auto-advance every 20 seconds). While this is certainly a test of our presentation skills, the technologies that we discussed and heard from our peers were what I found to be interesting. Our team gave a presentation on Neuralink, a "mind-blowing" piece of technology that aimed to create a human-computer interface to drastically improve the lives of paralyzed patients. During the research, I realized that even though the idea of an implant that inserts threads into areas of the brain can deter many of us, the methodical approach with the help of precision surgical robots gave me great confidence that the future may be wild. It was refreshing to look at the current work done by others in the industry and ponder about what counts as innovative today.

A3 & A4​

A3 is an assignment that required us to build a progressive web application, from "front" to "back". Not only do we have to think fast, but we also need to act even faster. In retrospect, I think this assignment is all about execution. Within the short 2-3 weeks, the team needs to produce an application that works with a database and handles authentication, among other things. Personally, I got to work on the backend and played around with Django REST Framework. Knowing web development and being familiar with the relevant tools beforehand are going to be helpful.

Following the end of A3, we moved on to our final project phase. A4 is an open-ended challenge to solve a problem with a (creative) solution. I may have hinted in my previous paragraphs that finding the right problem to solve is hard, but an innovative solution is equally hard to come by. I am not going into the details about these two assignments because, at this time in the semester, the fatigue and the workload started to drain all my energy. Jokes aside, I think my experience may not generalize well. Of course, I learned about how to work in a team and deliver a product. But, more importantly, I learned that life is more than CS3216/School/things at hand.

Guest Lectures & Writing assignments​

The weekly lectures and writing assignments turned out to be rather enjoyable. I learned many things from the various guest speakers. One notable aspect of it is how "CS" or technical people view problems and optimize for a solution. I joined in the lament that "people problem" is the harder problem to solve. On writing assignments, it was fun to try, over the semester, to appeal to Uncle Soo's taste and get that coveted full marks for each writing.

Final thoughts​

Just like the last lecture given by Randy, CS3216 is all about head fakes. What you will learn will be drastically different from the intended outcome. Coming into this module, many people, myself included, were looking forward to practicing and gaining technical skills in a team setting. In the end, this module may have disguised itself as a project module, but it is not all about the projects you build, it is all about YOU.

P.S This essay was written as part of my final writing assignment. All I can say is...What a module!

Explaining to someone without a technical background can be challenging. That challenge is compounded by the creative names developers give to their products. If we are not careful, people may get confused when terms like Go, React, or Flutter slide into our conversations without explanations. The fact that we have so many software products around, sometimes solving the same issue in a slightly different way, has always raised a question in my mind. We can see how Occam's razor can be applied to benefit developers who bear the cost of deciding and picking the right tool for the right job. Why do we continue to have more software doing similar things and add to the complexity?

Of course, I can always defer the argument by citing that things exist for a reason. Bearing in mind the why, the sharing I attended (on Cross Platform Application Development) last night was insightful on the practical considerations when selecting a desirable framework for the job. I experienced a similar conundrum when I was settling on a framework for mobile development. Similar choices between React Native and Flutter. My answer back then: Flutter. I will explain some of my considerations (or the lack thereof) with what was mentioned by the speakers.

First Look​

As a student, I like the fact that we do not always have to consider aspects of software durability or robustness when choosing something to learn or use in a side project. When picking a new tool or framework, the first thing that I would do is to take stock of what tools I already know. Though not entirely accurate, that would have given me a rough idea of how well-received and how much support for that technology online. One thing that I learned from the talk is to look at more data points such as Github stars and issue counts. As an example, React-native has 97.5k stars, and Flutter has 129k stars. The popularity of Flutter was one reason why I decided to take it up. Another aspect of popularity is the issue count, which I am still ambivalent about what it portrays. React-native has over 1k issues when Futter has over 5k issues. While I understand that more users might mean more complaints, other factors might also affect this metric. Whether the maintainers of these frameworks actively listen and patch the software to fix pertinent issues can be crucial when the software plays a huge role as a framework that drives the entire code execution.

Familiar VS Trendy​

While the above point explains why I would prefer a trendy framework, I also understand the importance of familiarity (language or otherwise). It is especially true when development velocity and product quality are critical. A constant theme mentioned by the speakers was that developers would like to iterate on their products, frequent and fast. Therefore, choosing a familiar tool that most developers are aware of, will make onboarding and upskilling less a hassle. To illustrate, I only got to know Dart as a language used when working with Flutter and my experience with it is only within the period of mobile development that I have done. During the live coding session last night, the presenter was facing a bug due to the displacement of a variable. Looking at the code, I thought that it might be due to the incorrect assignment of the variable, which was not the case! It was the result of not me being unfamiliar with the tool used. Especially in frameworks with a lot of conventions AND configurations, developers might have to slow down significantly. Choosing something that we get exposed to frequently is a fair bet that we can adopt it fast and have it work for us in a reasonable amount of time.

The Right Job​

Mobile applications have an unfair advantage of wider outreach and convenience. The ability for mobile frameworks to work cross-platform is, similarly, the biggest selling point that they have against native toolchains. As the sole developer or part of a small team, the right job often includes maximizing output and reducing maintenance costs. To have one framework that builds for both IOS and Android is a bargain that we cannot ignore. To relate to my example, I chose Flutter also because even if I started developing with the sole focus on IOS, it would be a breeze to account for the minor differences so that it works well on Android. An interesting point that I learned from the Shopee example is that sometimes tools can work together to generate greater yield. I have never thought of situations like isolating the support service into web pages(because of the significant number of custom service personnel that use it). If we can put more emphasis on our target audience and to find ways best benefit them, the user experience and the developer experience can both increase dramatically.

It is fascinating that we say to pick the RIGHT tool for the RIGHT job when there is no clear definition for what is RIGHT. Worse still, what is RIGHT is going to change in no time. My conclusion: do research, try things out, adapt and change when necessary.

P.S. This is repost of my writing assignment for CS3216.