thoughts, musings, and other stuff.

The CS2103T/CS2101 Project is coming to an end. Well, close enough. This seems like a good time to reflect upon the lessons learnt.


This project is vastly different compared to most other projects. Its twinning component meant that the entire thing was a delicate dance between two parallel, related sets of deadlines and deliverables. Some complementary, some not so much.


The common thread here, however, was the team that we had to work with. Since forming our teams in week one, we basically had to work together for all the assignments.


Team Dynamics

The biggest lesson that comes to mind is team dynamics.


This lesson encompasses two main parts, Conflict and People management. In particular the answers to the questions: what problems arose, how we handled them and how we could have better handled these problems.


For the most part, the lessons here are intangible. I cannot tell you that I’ve learnt to do xBecause I haven’t.


Team Dynamics is not as straight forward as Computer Science. It is an art. There are no axioms here. What is applicable to this team, might fail miserably in another. That being said, our experience here is not for nought.


What is important, is that from this experience you calibrate your personal compass with respect to communicating with others.


You learn to better work in teams, based on empirical data that you consciously/unconsciously collect. You learn to judge situations and become more aware of subtle things. You learn to read people, make better guesses on what they are thinking. You learn to make better decisions.


It might seems odd that the largest take away from a Computer Science Module is not the Computer Science, not even vaguely related. But in my opinion, this is way better.


Truth be told, the Computer Science taught in the module can be easily learnt/picked up online. The same cannot be said for team dynamics. In addition, the actual application of soft skills during the course of our project(s) is something you can’t really google.


Closing thoughts

To be honest, my initial impression of these two modules have not really changed. I recognise the need for their existence but posit that there are better ways to achieve similar objectives.


For instance, I feel that Software Engineering could be taught in a less direct manner. Rather than teaching SE specifically, all at once, it could be scattered across multiple core modules that slowly but surely drive home the points that this module it trying to teach us.


For CS2101, I believe that the contrived scenarios of our oral presentations trivialise their purpose. If the purpose of these oral presentations are to hone our presentation skills, I contend that we would be better off presenting something we feel strongly about.


When you actually have a point to make, a point to get across, presenting becomes less of what to say and more of how to say it. The difference is subtle, but the latter, in my opinion, should be the goal. What could possibly be worse than speaking when you have nothing better to say.


§168 · 20/10/2012 · Uncategorized · (5 comments) ·

5 Comments to “Lessons Learnt”

  1. Sally says:

    -1 for the misuse of the word “axiom” #unconstructivecomments

    +1 for the closer

  2. Civics says:

    After working in a project group for nearly a whole semester, I still prefer individual work as like what you had mentioned, I cannot predict and shaped the team dynamics as how I want it to be. However, I know that it is not possible to avoid working in group, so I am willing to learnt on how to drive team member engagement or prevent some situation from happening with my experiences in this project group. Every time when I experienced bad feeling, I will try to remember why this happened and how I can avoid it from happened instead of how I solved it. Although it seems unlikely to happen on me twice, I want to avoid causing it to happens on others too.

  3. Pallav says:

    I would like to comment on three specific lines from your post:

    “This lesson encompasses two main parts, Conflict and People management.”
    I whole-heartedly agree with the points you raise about people management. A teacher of mine often says that even in a technical field like Computer Science, mastery of platforms, tools, and technical skills is just a facade. What is of real importance is the understanding of people (psychology, quite literally). This hypothesis may or may not be easily proven, but examples can certainly be given in its favour (this course being one such example).

    “Team Dynamics is not as straight forward as Computer Science. It is an art.”
    Well, I’m sure the argument could be made that Computer Science, too, is an art. Although, on further thought, the importance of people-management in the field (as discussed above) may very well be the reason for this.

    “I recognise the need for their existence but posit that there are better ways to achieve similar objectives.”
    I’ve shared the very same sentiment with people I’ve talked to about these modules. While I think the effort being made by the faculty in teaching us these relevant skills is quite appreciable, I would question the effectiveness of presentations and formal blog posts in teaching us the same. (However, I also recognise my own inexperience in teaching such skills to others, so I can’t definitively give an well-formed opinion)

  4. cgcai says:

    I second your sentiment about team dynamics being the main takeaway from these two modules.
    Someone from FASS once told me that working in a team is about a constant process of “negotiating your ability to contribute with respect to everyone else’s”. In my opinion, this experience was an interesting exercise of how a few people with quite different competencies can negotiate their participation in a way that maximizes the group’s productivity as a whole. Apparently, this is hardly intuitive, and does take a concerted effort to pull off. I’m not so sure how well we did here, but being able to strike a balance between varying abilities would have been a decent achievement itself.
    The software engineering principles taught are not particularly novel; people tend to pick them up as they go. Teaching ‘patterns’ authoritatively in my opinion, has the potential to do more harm than good. I wouldn’t be surprised if we start to see Singleton being abused anywhere and anywhere for the next few compulsory projects.

  5. rahij says:

    Nice point there about the module teaching more of team dynamics rather than the CS part itself. While this is true and the skills can be learnt online, the same cannot be said for a person to actually follow it. I think the module additionally serves as a platform to implement the practices one learns in software engineering be it online or in this module. This makes us stick to them when writing code. So, I think the CS part though little actually has more to it than it seems.

Leave a Reply

Skip to toolbar