Parkinson’s Law

You look at the calendar and it says November. “Wow, how did time fly by so fast?” It’s almost the end of the semester, but not quite. You reflect on the past few weeks. It’s been crazy. Sometimes you catch a breather and think you’ll get through this. Sometimes you get thrown curveballs at the worst of times and you think, “I’m just not good enough for this”.

But you realise that this semester was full of firsts, and that means loads of lessons too. Learning to juggle commitments, learning to work with people of different working styles, personalities, work ethics. Learning to breathe, take a break and slow down once in a while. Learning how to squeeze productivity out of every waking hour. (I have kept a working approximation of time spent on CS3216 viz-a-viz other modules, and it’s pretty fascinating to look at the statistics at the end of the semester.)

This week, I am reminded that Parkinson’s Law is pretty relevant in our (college student) lives… How often is it that our productivity seems to rise when we are particularly busy? How much time do we spend idling or wasting on useless pursuits if we had the benefit of time to complete assignments? I’m not sure, but maybe being busy is one way (though not particularly the best, nor recommended, nor healthy) of maximising productivity? But perhaps the most important takeaway is that it’s good to take a break sometimes. Feeling recharged, we can better focus on what needs to be done.

While this week has not been kind, I am grateful to my friends and team mates for being awesome. Friends have helped me when I needed it, and needless to say, I am thankful for having such great team mates. Graphite has come pretty far! It’s been a huge project and there are still one or two missing pieces. Last week, I’ve been working on the front end, which has been annoying at times, but I also got to work on the icon and am pretty stoked about that gif too, heh.

It’s not always going to be a smooth journey, but let’s always appreciate what we have and look forward to even better days ahead.

“Dwell on the beauty of life. Watch the stars, and see yourself running with them.”
― Marcus Aurelius, Meditations

Advertisement

Remember when

That one time when you explicitly told yourself you wouldn’t sleep so late…😂

Posted using telekinesis at 3am…🙃

Euler’s Tour

As the semester comes to an end, more assignments are being given out so the amount of stress and work can be graphed as y = e^x. Other modules are competing for my attention and I feel rather guilty for ignoring them…

For the past few days, I’ve been working on wiring up some of the front and back end. In order to better visualise the data, I decided to play with the populate and faker gems to create rake tasks for seeding our database. As it turns out, the gems were extremely useful. Indeed, it is true that we don’t need to reinvent the wheel. Whenever another developer has kindly provided a library with the tools we need, all the better to use it! Then, we have more time to focus on the other features of our project that cannot be easily abstracted out with the use of a library. Despite the pain in debugging, etc, it’s been fun building and working, especially with my teammate, Joe for the past few weeks. STePS will be coming soon and I’m sure it’ll be a blast too.

“It is good to have an end to journey toward; but it is the journey that matters, in the end.”
― Ernest Hemingway

On a less “work-related” note, I miss reading my books (I confess, I have been sneaking in articles from my Pocket now and then). And I’ve fallen sick again. So I’ve decided not to stay up so late and to completely abstain from heaty food for now…

It’s funny, reflections on life:

“Happiness only real when shared.”
― Christopher McCandless

If you don’t know where you’re going

Last week’s lecture was on communication and selling our product, with tips about how to better create a first impression, like emphasising your name, and keeping introductions short. Some argue that sales makes the product. Others argue that product is the only thing you have. There are basically two camps sitting on both ends, but ultimately both factors interact with each other in complex ways that often make it hard to untangle a product’s true main cause of success. Personally, I would think that you have to have a solid product first. Combine that with awesome sales in the initial phase. But who am I to say… Having read Zero to One, it seems equally probable to go the other way. I guess the best way to test it out is through multiple real-world experiences, conducting our very own experiments in life. Ultimately, I felt that last week’s most memorable learning point came from the video Cheryl played at the end, which reminded me that rejection is ok, and not only that, you must always try first, because 1. you may not get rejected, and 2. rejection can give surprising lessons. It’s always been a fear of mine that I’d get rejected even if I try, so it’s the video did give me a good reminder about overcoming rejection.

“If you don’t know where you are going, you’ll end up someplace else.” – Yogi Berra

On the final project, we have been progressing albeit it seems with spurts and bursts (truly sprints) of work. One day I’ll get a chance to work on other stuff, and another day I’ll spend an intensive whole day working solely on CS3216. This is contrasted with my previous assignments whereby I spent almost every single day working a couple of hours on CS3216. Before today, I felt that the roadmap and tasks were not as clearly defined. This is especially since we did not have any milestones to guide us! Well, it’s basically the real world knocking and telling us that we don’t always get a well-defined list of goals to hit. We have to communicate and talk to our clients, settle and reach an understanding on their needs and what we can provide so as to have a better definition of the product requirements and what we need to do. So although I have been able to gain a couple of days of respite from CS3216, I believe that work will be gearing up even more. Nonetheless, I’m pretty excited to see our MVP fully formed and ready for action. Here’s to more learning and pain.

“If you don’t know where you are going, any road will get you there.” – Lewis Carroll

Better late than never

Last week was the UX Review with Colin and Su Yuen, but unfortunately I could not make it because I was down with a fever. Nonetheless, thanks to my helpful teammates, I’ve been able to catch up on the suggestions and improvements recommended by them. Instead, I could only make it for a workflow meeting with En Chou. We’ll be meeting with the clients again this week, so we should be able to get even more feedback.

On one hand, developing an API for other developers to use has been a fascinating experience. Usually, and in the past, I’ve been “consuming” others’ API and reading others’ documentation. Now we have the chance to develop a good API. Documentation must be clear and easily understood, with examples. I have lost count at the number of times that I’ve come across obscure or “useless” documentation that does not help me in understanding the functions at all. We would definitely be sure to produce documentation that is clear and easily comprehensible. On the other hand, the front end is important, and a simple UI that just works will be our goal. Having been working on the API implementation for the past week, it has been quite an interesting experience learning and making use of Grape instead of our normal Rails routes.

Respite (Not, ha.)

In economics, the free rider problem occurs when those who benefit from resources, goods, or services do not pay for them. – Wikipedia

Having completely burnt out after assignment 3, with a lack of time to study for the midterms properly, among other best left unsaid crises, I’m not sure how I survived the-time-between-the-end-of-assignment-3-and-now. I am somehow, to a certain extent, weirdly (highly qualified sentence here), glad that week 7 was midterms and I was able to grab some time “away” from CS3216. In particular, it was really exciting to learn more about the RSA encryption algorithm and Fermat’s little theorem. Plus, it was fascinating to discuss whether if a set could be a partition of itself. Number theory can be so very cool.

I’m not sure if I’m still “alright” after assignment 3, but I’ll hang on, for now.

As I had midterms on Monday, I was unable to attend the class, but reading others’ blogs, it seemed that one of the most resonant and memorable points was doing what you truly cared about, doing what you like. This reminds me of the standard college “trichotomy” though… And the sad thing is that not everyone can get to do what they like. (Of course, what you care about and what you like may be different things, but what you care about tends to be something that you like.) (Other blog posts also mentioned teammates in CS3216. Thinking about it, I guess you could say that a project is non-excludable and non-rivalrous within the group…)

There is still another midterm to go but the final project is kicking in and ramping up soon. After this short “break”, I’m sure there will be much thrilling coding adventures (as well as, let us not forget, pain) ahead.

“Man is not worried by real problems so much as by his imagined anxieties about real problems”
― Epictetus

2 things

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

Working with caches…

“Whatever it is you’re seeking won’t come in the form you’re expecting.”
― Haruki Murakami

6 is a Perfect Number

I swear, CS3216 takes a toll on both my health and my wallet. Throughout the semester, I have been nagged on by my mum to sleep earlier even as I code through the night. I begin to have headaches randomly. I guess it is not a good idea to sprint through a UI revamp in one day just because.

A perfect number is a positive integer that is equal to its aliquot sum. An integer’s aliquot sum is the sum of its positive divisors, excluding the number itself. 6 is a perfect number.

Week 6 was more pitches. It is interesting to see what fellow CS3216 mates have come up with. Pair this with Paul Graham’s advice on start-ups and you begin to realise that the same points come up: is your idea really solving a (highly annoying) problem for at least a significant group of users? In some media and articles, it is often criticised that Silicon Valley solves the problem of young, white males. Yet, others write that we should come up with solutions to problems we face, so that we have a better understanding of the issue at hand and can better grasp the UI and UX to solve the problem. It is no wonder then that critics would say that of the current state of apps (and they are pretty spot on, mostly). It begs the question of how we can better connect the people who need help with problems and the people who can use technology to solve such problems.

“Success is stumbling from failure to failure with no loss of enthusiasm.”
― Winston S. Churchill

Despite the failure that was assignment 1, I am determined to make assignment 3 a better project and work harder. It has been an <adjective> experience. (My brain can’t seem to find the right word now.) AngularJS, Ratchet, Ruby. For some inexplicable reason, I woke up thinking about our assignment’s algorithm (okay, maybe it’s not that inexplicable, given the amount of time CS3216 takes up in my life right now). At first, I had thought that one possibility is using linear regression to check the validity of the contributed reports of bus sightings. (Our app, nexbus, relies on crowdsourced data to determine the arrival timing of NUS shuttle buses.) However, supervised learning in this case would be pretty much ruled out, it seems, because unless we station ourselves at the stops, we’d never know the true labels for each instance. (Ain’t nobody got time for that.) Consequently, I thought about how we could apply the knn (k-nearest neighbours) algorithm instead. Simply classify the incoming reports according to their similarity, plotting service against time. One issue I am foreseeing is that the reports would come in a stream. It is not static as what we would expect. I guess I could do more research and reading up on this…

“If you expect nothing from anybody, you’re never disappointed.”
― Sylvia Plath, The Bell Jar

Expectations can often be dangerous. Instead, simply appreciate and live in the present.

A Questionable Case of Pushing Limits

“Whenever you find yourself on the side of the majority, it is time to pause and reflect.” – Mark Twain

Yet another week in the whirlwind that is CS3216… The journey of assignment 3 has started and it has already been filled with twists and turns. We came up with various ideas and settled on one but pivoted just the next day… From the conviction of our group however, it seems like we’d have a much pleasant time this time round in getting things going and running. I’ll be working on the front-end again. To be honest, I would prefer to have the chance to touch the full stack (well, you can’t have your cake and eat it too, right?) but still, since we’re working with Rails, instead of Node.js + Express, say, there might be more learning opportunities in Angular after all. Front-end for mobile is a pain though.

Developing for mobile is like developing for ants.

Week 5 (Did I get that right?) was external pitches. I would say that some of the ideas were intriguing but some of them could certainly be more engaging. Perhaps this might be due to the inexperience of some of them in designing pitch decks. It takes a lot of effort to capture the attention of an audience. A lot of ideas today are not particularly mind-blowing though, one might argue that there is some kind of innovation stagnation. Of course, a breakthrough can happen, but it’d (obviously) be unexpected. Or maybe I’m just pretty bad at coming up with cool ideas. The world as it is is pretty nice, in the sense that the number of problems you can solve with software alone are not that varied… it feels. ._. (As I mentioned, it’s probably because I’m bad at brainstorming…)

During one of our meetings, Joe mentioned that the mechanical process of entering milestones into our trello board was actually pleasant. I have to agree. In the rush of everything, being given a chance to slow down, not think, just do, is kind of nice once in a while.

“You can have it all. Just not all at once.” – Oprah Winfrey

On Estimation and Standard Errors

“Sure, everything is ending,” Jules said, “but not yet.” – Jennifer Egan

So in a few days it’ll have been a month since the start of CS3216. The deadline for assignment 1 just passed last Friday. There are perhaps too many thoughts in my brain to be put into words here. Mostly because my work from other modules is piling up, but partially because they would be too personal to share here. Still, a reflection is apt, if only for some form of relief.

“My thoughts are stars I cannot fathom into constellations.” – John Green

First off, I think it could have been so much better. I would be the first to admit that I lack experience in web development. But I’m definitely willing to put in the effort to learn more and improve my skills. Given the high calibre of the rest of my teammates, however, I believe that the product should have been better.

The thing is, I’d like to believe that because of this experience, I’d have learnt more than if it was just a smooth sailing exponential graph of epic progress through software development. Instead, turns out it was a sine graph drawn by some drunk dude.

Lesson #1: Team Dynamics
I’ve worked on multiple projects before, and maybe it is the nature of the project or people that made the difference. I believe that our team could have improved on taking the initiative and decisiveness so as to give our project a direction. Obviously, I can’t speak for the rest of my team, but I feel that we could have done better if there was someone to give greater direction and management over the project. Certainly, this seems to be more related to the personalities of the team members.

Lesson #2: Communication
Communication (and the lack thereof) is key in any project. This is probably closely connected to the lack of a clear management over the project. No communication means no decisions made and no progress made on work. (I assume you’re going to get X done, you assume I’m going to get X done, nothing gets done.) In a team, there should be a clear laying out of the goals and work to be done. Communication should also be much more open and in fact, one might even argue that greater discussion, particularly debate, will help to clarify any confusion and put the project in the right path.

Lesson #3: Taking Initiative
In retrospect, working on the front-end, I could have done more to integrate with the back-end to avoid the last-minute rush. As it turned out, while the layout was mostly there, I could have done more reading up as well as learning about the integration that we had to do. Nobody is going to hold our hand and guide us every step of the way. It’s better to take initiative and keep the momentum. (Don’t ask for permission, seek forgiveness, always be learning.)

There are plenty of thoughts and stuff I learnt from this assignment, and towards the end of the project, I thought a lot about our progress. For one thing, you can have all the technical skill in the world, but with a time crunch and poor estimation of the complexities (time, people, technicals) of a project, you’d still fail (maybe not completely, but it wouldn’t have been as good as it could have been). C’est la vie.

“You never know beforehand what people are capable of, you have to wait, give it time, it’s time that rules, time is our gambling partner on the other side of the table and it holds all the cards of the deck in its hand, we have to guess the winning cards of life, our lives.” – José Saramago