CS3216 Learning Outcomes

In the Fall of 2019, I took a truly transformational class CS3216 at the National University of Singapore. The class is no ordinary class - it asks more of you, and gives more to you. At the end of the class, I wrote out the following reflection of my learnings from the class, and I decided to re-produce it here because these are learnings that serve me well to this day!

This is a long post, so here is a tl;dr. These are some of the things I learnt in CS3216:

• Raise the bar and push yourself
• People need to take responsibility and own their tasks - take pride in your work
• Make decisions in time
• Keep the big picture in perspective
• Take positive and negative feedback in the right stride
• Document your progress
• Learn to be flexible

So, what DID I learn in CS3216? I’m not sure where to start. This has been a crazy journey with plenty of disappointment, pondering, complaining and satisfaction - and there was time for each in just 12 weeks of perpetual deadline dash.

By the numbers, it has been a very busy semester:

• 3 different teams to work with (in my case)
• 4 different assignments
• 2 presentations
• Product pitches
• user testing
• thirteen writing assignments
• three consultations.

This is more than any module in NUS has asked of me, and while I’m pretty sure my other mods have taken a good beating, this is as much as any module in NUS has taught me.

Hindsight is 20/20, and so it’s probably the best way to learn some lessons.

I learnt to be a better developer, I learnt how to work with different styles of teammates and push as hard as possible, but my key learning points have been the finer things in here:

Forget the requirements

Every project in university begins with looking at what the course requirements are. Prudent as that may be, this is a major way I’ve held myself back, instead pushing to make my work that much better. Working on projects by just trying to keep pushing forward with improvements is the only way you’ll push the boundaries of what you know, and learn something new. 

So sometimes, it’s best to set your bar higher than you’re required to.

Responsibility is a necessary teammate

People often think that finding the most skilled developers, designers (and whoever else you project needs) is the most important thing. Past a basic threshold of skill, those who take responsibility for their part in the project are always the better teammates. When the going gets tough, if people don’t take responsibility for their parts, it either piles up on the others, or is completely lost in the team. Either way, it’s not easy to tide the difficult times.

People who take pride and responsibility in their work contribute to a better team environment.

Decisions, decisions, decisions

Making the right decisions is not just about knowing the right things. It’s about actually pushing through to make sure that decisions don’t hang about longer than they have to, and that they are made by the right people.

Starting to feel that the stack is going to constrain you? Worrying that you’re deviating too far from the main course? Are you having growing concerns about code quality?

Sometimes, nobody wants to be the one to make a decision. If you discuss the same topic over and over, it gets more and more stale, and it becomes the status quo to leave a meeting without resolving issues. Bringing up the right issues isn’t enough. You need to see it through to the end and ensure that the decision is made.

Big picture vs Details - Don’t lose perspective

One of the major takeaways from the consultations we had with Prof Ben during the final project was that we regained some perspective of the “big picture”. It’s easy to be convinced that an idea is good, and get lost in the details before you’ve done your due diligence regarding validating an idea.

Always have a sounding board, and don’t dismiss their opinions as uninformed. After all, you’re building the app for a user base, not just yourself.

Taking feedback the right way

One of the best things about CS3216 for me was how tight the feedback loop was. Every submission, assignment and task had some sort of feedback loop, and I actually found that to be quite useful.

We got plenty of feedback on our work - sometimes positive, sometimes negative. Taking this feedback the right way was an important lesson I learnt. Trying to take the negative comments as challenges to overcome, and thinking of them as personal milestones worked quite well for me. Getting recognition for both good and bad work from the Prof gave me drive to try harder.

Document your process

In the absence of accountability, processes break down. If you don’t have a backlog you regularly look at, or an audit trail of what decisions were made when, things will eventually devolve into a lot of confusion.

Every meeting should have minutes.

Learning to be flexible

Having a balanced team is important, you need some developers, some designers and someone to be a manager. But sometimes, when people don’t naturally assume these roles, try to take the initiative, and assume the role the team needs the most. You may not already have the skills you need for that role, but the onus is on you to discuss that.

If your team needs a better (manager/devops/PM), then you should try to become that person.

Working with the people in this module has given me so many good opportunities to learn. Thanks to everyone who helped me learn in this course and best of luck to you guys with the rest of your mods!

Thanks Prof Ben for the great speakers, the inputs, and the continuous feedback you have given us throughout this module.