Here are some module planning advice for undergraduate students studying at NUS, based on my experiences. Many of them may only be relevant for computer science majors. These are my personal opinions so take them with a pinch of salt, and also take into consideration how well you stand against the rest of your cohort. Note that the situation might have changed after I penned down some of these points, so do check the official NUS channels for updated information.

If you're making a module planning decision that isn't listed here and you think there is a good chance that I would have sufficient experience to share, feel free to reach out to me about it.

If you have some module planning advice that you'd like to share, do tell me about it, and if I agree with it I may add it here (and credit you for it). Only advice related to coursework will be considered.

General information for BComp(Computer Science):

• I find it helpful to place the computer science degree requirements (ignoring internship and FYP) into three main categories:

  • “Normal” CS modules — CSxxxx modules that are conducted in usual lecture/tutorial(/laboratory) style, usually with final exam and without a large project component. These modules are very unlikely to have any kind of group project.
  • Project modules — Computer science modules with a large group project component, such as CS2103(T) and CS3203. CP2106 (Orbital) goes into this category too, but do note that it is graded on a CS/CU basis.
  • Communication modules — Modules where a large part of the grade comes from presentations or essay-writing, such as ES2660 and CS2101. It is arguable where IS1103 fits in, but for most purposes we can consider it to be a communication module.

  I consider GER1000 to be a hybrid module — it contains elements from all three categories. In the computer science degree requirements, I don't know of any essay-writing modules that are not also communication modules, but such modules are quite common in the GEH and GES module groups. The category of your GEH, GES, and GET module depends on the actual module that you choose to take, and it may not be categorisable in this system.

On study planning:

• A study plan specifies the modules that you intend to take in your studies at NUS. This plan should guide you through your undergraduate career, and it will influence how you do module balloting, arrange for exchange programmes, and just about anything else relating to your studies. You don't need to submit this to anyone, but it is extremely useful for making decisions on modules and ensuring that you graduate on time, and I strongly suggest that you have it planned out by the start of your second semester at NUS.

  It should (at least) include the following:

  • All the modules that you intend to take, including possible alternatives
  • Graph of all those modules, specifying prerequisites and corequisites
  • Whether those modules are offered in sem 1 only, sem 2 only, or both
  • How you're going to satisfy the focus area(s) that you're intending to complete

  As you go along your study journey, you should regularly update your study plan to reflect what you have completed, and make amendments as necessary (e.g. if your interests change or if a module isn't being offered anymore).

• Past year exam papers can often be retrieved from the NUS Libraries website, and these can give you a good idea of the content and “flavour” of the module (e.g. if it is math/theory-heavy, has proof questions, is subjective, or has questions requiring lots of elaboration), to help you decide if it is something that you'd be interested in taking. Also read the reviews on NUSMods and from other sources.
• Prioritise modules that have long dependency chains. For example, if you intend to take CS3211 (where the chain is CS1010/CS1101S → CS2100 → CS2106 → CS3211), you should try to clear CS2100 quite quickly after you are done with CS1010/CS1101S. Chains do not seem to be very long for the algorithms, programming languages, and parallel computing focus areas unless you are intending to take some graduate-level modules (i.e. CS5xxx/CS6xxx modules). If you happen to be doing a mathematics or applied mathematics degree, take note that the mathematical analysis chain is quite long and some of those modules may not be offered in every semester.
• Try to clear CS2030, CS2040, and CS2100 by your second semester if possible. If not, doing two of them might also be okay, though less ideal. If you fail to complete at least two of them by your second semester, there will not be many normal CS modules available to you for your third semester, and you may be forced to clear some of your GE and communication modules then.

On module and tutorial balloting:

• NUS School of Computing (SoC) often hires undergraduate TAs (these are undergraduate students who are currently studying at SoC, just like you) to conduct tutorials and labs, so you will often find modules (especially the CS1xxx and CS2xxx modules that have a large enrollment) that have some tutorials/labs taught by postgraduate TAs and others taught by undergraduate TAs. The general consensus seems to be that the undergraduate TA usually teaches better. While this may seem counterintuitive at first, know that postgraduate students are required to conduct these classes while undergraduate students choose to do so on their own (with appropriate remuneration and subject to the module coordinator's approval). It is said that this means that the average undergraduate TA is more knowledgeable and helpful than the average postgraduate TA.
• It is generally possible to figure out (e.g. from seniors) about which TAs are better and which sessions they will be conducting — try to ballot for their tutorials/labs. This is less important if the lecturer teaches well, and more important if the lecturer teaches poorly.
• If you've ended up with a TA that can't teach, and you hear from your classmates that their TAs are much better, try asking the better TA if they would let you have a copy of their slides or allow you to sit into their class. It never hurts to ask!
• The module balloting system works by assigning each ballot for a module with a priority score that depends on things like your seniority, your specialisation, and (for CS students) your focus area. While your seniority can't be modified, you get to redeclare your focus area (and perhaps your specialisation, depending on your course) every semester, so use this to your advantage. You can declare two focus areas instead of one, and it appears that the first focus area gets a higher priority score than the second one.
• If you intend to take CP2106 (Orbital), which is conducted across the summer vacation between your first and second years, look out for the email that marks the opening of registration. It was so hotly subscribed in 2019 that the class was full within the first two hours of opening. Find a partner early (it is a pair project), look out for the email, and apply immediately when registration opens. If you aren't an SoC student, you're unlikely to have the chance to take this module due to the high demand within SoC. Hopefully the SoC administration will do something to ease the demand, such as lowering the number of MCs or converting it to a letter-graded module.

On normal CS modules:

• Normal CS modules usually allow a cheatsheet in the exams. Try to continually update your cheatsheet weekly after every lecture. Doing so reinforces what you have learnt in the lecture, and allows you to refer directly to the cheatsheet when working on your tutorials and assignments. Use tutorials and assignments to figure out if your cheatsheet is missing useful information. The benefit here is twofold: firstly, summarising the information that you've learnt improves understanding and retention; secondly, preparing for the final exam becomes much easier — just review your cheatsheet and then start trying out past year exam papers. This also applies for modules that are open book — having summarised notes still brings about the two benefits mentioned above. (Practically, following this advise may require that you type out your cheatsheet, so that you can insert or remove content as you go along. Typing out your cheatsheet does take a bit more time, but I think the flexibility it confers outweighs the cost.)
• Avoid grabbing cheatsheets off the Internet — making your own cheatsheet reinforces your understanding of the concepts, and you'll have a very good idea about what information you have and where they are located on the cheatsheet. Of course, looking at other cheatsheets to figure out what yours is missing is fine.
• If you don't fully understand what is happening in lectures or tutorials, or do not understand the rationale behind some of the concepts, do clarify as soon as possible — with your lecturer, tutor, classmates, or anyone else. Many computer science modules have exams that force you to apply concepts to novel situations, and they also tend to avoid memory work — this kind of exams will be a disaster if you simply memorise. Furthermore, the more you understand, the less you will need to memorise.

On project modules:

• You should figure out if a module has significant group projects before the start of the semester, as well as how grouping will be carried out. You can find out from those who have already taken the module. It is extremely important to get a strong group for such modules. Try not to enroll for a project module without a pre-agreed group, especially when the group size is large (e.g. CS2103(T) and CS3203), because you're likely to end up with the people whom nobody else wanted to form a group with, and these people are not likely to bring much to the table — despite what some others might say, some elementary game theoretic analysis should allow you to conclude for yourself that this has to be true if students are rational actors. This applies in the other direction as well — if you need to find a good group, try to portray yourself as someone who is knowledgeable in computer science or experienced in software engineering (whether or not you actually do have such skills is another thing, but it usually takes someone with significantly more knowledge and experience than you to accurately determine your true level of competency).
• Project modules can take up quite a fair bit of time, and are generally quite incompressible with respect to time (i.e. you usually can't cut corners and still expect to obtain most of the points), so try not to end up with more than one such module in a semester. They may also come with frustrating late-night debugging sessions when nearing deadlines, so avoid having too many other commitments at those times.

On S/Us:

• If you think you can get at least an average of “A−” (maybe around 70th percentile) for normal CS modules but are not a particularly charismatic speaker, you should prepare to S/U your communication modules (I S/Ued all three of them). For communication modules, you will need a lot of presentation practice and some amount of luck to tread through arguably subjective grading requirements to get an “A” — this, to me, is a disproportionately large amount of effort compared to normal CS modules. It is also extremely difficult to fail a communication module if you put in a minimal amount of work. Coupled with my interest being strongly skewed towards the normal CS modules and software engineering modules, it was unjustifiable not to plan to S/U all three of my communication module requirements (and I eventually did S/U them). Fortunately for me, I managed to finesse two of these modules into my first year, which allowed me to save on the 12MC of S/Us that can be brought forward beyond the first year.
• After your first (i.e. freshman) year, all normal CS modules and project modules cannot be S/Ued (because they will have at least one prerequisite — either CS1010/CS1101S or CS1231), which leave only communication modules and GE modules to spend your remaining S/Us on. It appears to me that it is not difficult to get an “A” for GE modules (perhaps except those with MCQ exams and steep bell curves), and I postulate that this is a result of many students just wanting to pass these modules with a minimal amount of effort. I got “A+” for both GES1019 and GET1001, despite them being non-STEM modules that are graded mainly in the form of essays and lengthy reports. I recommend that you choose GEH, GES, and GET modules that you are interested in (which I did), and enjoy those modules and actually put in effort for them. Save your S/Us for your communication modules and GER1000 instead.