13 posts tagged with "school"

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.

Unlike solving problems in an exam paper, building a product starts with defining a problem worth solving. Problems can come from pain points that we endure going through our quotidian life. Or, they can be astute observations of obstacles that people around us encounter. Some issues might seem mundane, while others have half-decent, duct tape solutions(a better analogy nowadays is a combination of Excel, Google Docs, and Whatsapp). I will be elaborating on three lessons I have learned in the recent UIUX workshop, in terms of product ideation and validation.

The first key lesson that I learned from the workshop (on Beauty is more than skin deep) is to be wary of bad ideas. We want to build something that stands out from existing competitions. We want mass adoption from human beings who have an innate tendency to prefer stability over change. If the above is true, we need to be able to answer the following: Is the problem that we are describing real? Does the proposed solution solve it? It's easy to see the relevance of the first question. During the workshop, we had a group proposing a product idea to help students find mentors easily. Critical response from the audience was how that product would provide utility to people who avail themselves as mentors. Assuming that the product does help their target users(students), it lacked the consideration of another significant group of involved parties(potential mentors). To go deeper into the above example, the proposed solution might not effectively address an inherent issue at hand: perhaps there's a lack of motivated mentors?

My second learning point is on making a product that offers better solutions. I would like to share an anecdote that resonates with the content of the workshop. I was reading blog posts by Kent C. Dodds (a software engineer and OSS educator) and came across his open-source project named "split-guide". It is a tool to help generate code for his workshops. Quoting the problem and the proposed solution highlighted in the repository's Readme for context:

Problem: Managing workshop repositories. A great way to do a workshop repo is to have exercises and exercises-final directories. The problem is keeping these two directories in sync. Solution: This allows you to create a template for both of these in a templates directory. Based on special text in these files, you can specify what parts of the file you want in exercises and exercises-final. This allows you to co-locate what you're going to be showing workshop attendees and what the final answer should be.

Having done many coding tutorials, I can see why managing workshop repositories can be a pain. However, it turned out that "split-guide" is no longer maintained. In the latest Pull Request (https://github.com/kentcdodds/split-guide/pull/24), Kent remarked that he thought the solution was neat but complex. The better solution/alternative that Kent settled for? "copy/paste/modify". This is such an apt illustration of how a solution that has more friction can go south.

The last point is on the importance of user validation. A surprising fact that I got out of the UX critique session is how much we can gain from iterations with a simple design and a group of target users poking at it. Feedback from users can guide us in making design choices that meet the eye and lead users down the intended happy path. One of the more striking comments that I remembered from the session was that users might not appreciate the sophisticated algorithms underneath if they are not motivated to use the product.

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

Goals​

Here is a mid-year update to the goals that were mentioned in my "hello world 2020" article:

• Secure one summer internship (or NUS'CVWO)

I managed to secure both NUS CVWO and an internship position at a local startup (I chose to go with the latter).

• Continue to write CS & web dev related stuff (at least on a Bi-weekly basis)

I wrote an article or two and had a few in the pipeline, but did not follow through with the promise of bi-weekly publishing. I need to reconsider this due to my other commitments.

• Be great at one module each semester (aim to TA for it)

I am fairly happy with what I learned in CS2103T Software Engineering, though I can't say I am great at it (result unknown as of now). I started to be active in the class forum right after midterm and that was fun. There were interesting discussions and I benefitted from peer learning.

• Put in efforts to develop one of my ideas to fruition

I am excited to start working on my ideas in the upcoming summer.

• Do one open-source project

Same as above, looking forward to contribute to possible open source projects under NUS in the second half of the year.

• Be wholesome and happy while doing the above:)

---

School​

Maybe it's time for me to write reviews for the modules that I have taken:

CS2100: COMPUTER ORGANISATION​

Low level stuff that computer science students might be interested to know. Lot's of 1s and 0s. Overall an interesting module that has a somewhat similar vibe with CS1231S Discrete Structures. Most content can come off as surprising and complex at first glance, but once I start to get familar with the topics, things like control, MIPs instructions and other binary stuff seemed less scary. Certainly not a module that I mastered, but I feel that the information in the module is good to know.

CS2101: EFFECTIVE COMMUNICATION FOR COMPUTING PROFESSIONALS​

A compulsory communication module paired with CS2103T Software Engineering. Focused on class interaction, group presentation and ended with essay writing. Because of my tutor's enthusiasm, it was easy to participate in class. The opportunities to practice group presentations served as great way to receive constructive feedback on individual communication shortcomings.

CS2103T: SOFTWARE ENGINEERING​

My highlight-of-the-semester module and I think it has an excellent coverage and great delivery. The course taught me things that software engineers should at least be aware of. This include UML diagrams, test case design heuristics and things like software project management. I would say it is fairly comprehensive and I picked up lot's of nuggets of wisdom that could possibly help in my future software engineering projects. Prof Damith and the teaching team were considerate and responsive.

The module also served as a playground to create and contribute to small to mid size code bases. The collaborative nature meant that one has to work with their team mates and participate in a range of team activities such as weekly meeting and peer review and discussion of issues as well as pull requests.

ST2334: PROBABILITY AND STATISTICS​

Another compulsory math module for CS students. Builds on top of JC H2 Math Statistics knowledge. Pretty much self-study.

DMY1401TT: DESIGN YOUR OWN MODULE (Machine Learning in Practice)​

Not as expected and I could have self taught the content provided. Mostly surface level stuff with some in-depth knowledge that was communicated at the surface level.-.

GER1000: QUANTITATIVE REASONING​

No intention to put any efforts into this module and going to SU.

IS1103: ETHICS IN COMPUTING​

I understand what this module is trying to do and appreciate how it at least requires minimal efforts each week. I won't explain much because of the super low workload.