Our tutorial IDs are different from LumiNUS. Format: CS2103T-W09
means a tutorial of CS2103T
module, held on
Wednesday
at 0900
, and so on.
Module | Venue | Time | in LumiNUS (don't use this!) |
Our Tutorial ID (use this!) |
Tutors |
---|---|---|---|---|---|
CS2103T | COM1-0210 (SR 10) | Wed 11:00 | CS2103T-W11 |
Damith, Yuan Chuan | |
CS2103T | COM1-0210 (SR 10) | Wed 12:00 | CS2103T-W12 |
Joanne, Andrew | |
CS2103T | COM1-0210 (SR 10) | Wed 13:00 | CS2103T-W13 |
Jacob, Benjamin | |
CS2103T | COM1-0210 (SR 10) | Thu 09:00 | CS2103T-T09 |
Jeffry, Yuan Chuan | |
CS2103T | COM1-0210 (SR 10) | Thu 10:00 | CS2103T-T10 |
Jeffry, Tejas | |
CS2103 | COM1-B103 | Thu 11:00 | CS2103-T11 |
Damith, Brian | |
CS2103T | COM1-0210 (SR 10) | Thu 11:00 | CS2103T-T11 |
James, Jeff | |
CS2103T | COM1-0210 (SR 10) | Thu 12:00 | CS2103T-T12 |
Jun Rong, Brian | |
CS2103T | COM1-0210 (SR 10) | Thu 13:00 | CS2103T-T13 |
Xiaowen, Yuan Chuan | |
CS2103 | COM1-0210 (SR 10) | Thu 14:00 | CS2103-T14 |
Gilbert, Yuan Chuan | |
CS2103 | COM1-0210 (SR 10) | Thu 16:00 | CS2103-T16 |
Kyler, ZhiHui | |
CS2103T | Thu 17:00 | CS2103T-T17 |
Jun Rong | ||
CS2103 | COM1-0210 (SR 10) | Fri 09:00 | CS2103-F09 |
Jonathan, Keith | |
CS2103 | COM1-0210 (SR 10) | Fri 10:00 | CS2103-F10 |
Jonathan, Keith | |
CS2103T | COM1-0210 (SR 10) | Fri 11:00 | CS2103T-F11 |
Jia Hao, Yuan Chuan | |
CS2103T | COM1-0210 (SR 10) | Fri 12:00 | CS2103T-F12 |
Ayush, Yash | |
CS2103T | COM1-0210 (SR 10) | Fri 13:00 | CS2103T-F13 |
LongBin, Yash | |
CS2103T | COM1-0210 (SR 10) | Fri 14:00 | CS2103T-F14 |
Alfred, Yash |
What happens during the tutorial:
Relevant: [
If you do not have a laptop or prefer not to bring the laptop, it is up to you to show your work to the tutor in some way (e.g. by connecting to your home PC remotely), without requiring extra time/effort from the tutor or team members.
Reason: As you enjoy the benefits of not bring the laptop; you (not others) should bear the cost too.
The role of our tutors is different from tutors in other modules.
Relevant: [
This guide is mostly about getting tech help, but it also applies to getting clarifications on module topics too. e.g. what is the difference between refactoring and rewriting?
We want to move you away from 'hand holding' and make you learn how to solve problems on your own. This is a vital survival skill in the industry and it needs practice.
Whether it is a technical problem (e.g. error when using the IDE) or a doubt about a concept (e.g. what is the difference between scripted testing and exploratory testing?) the teaching team is happy to work with you when you look for a solution/answer, but we do not do it for you. We discourage unconditional direct help from tutors because we want you to learn to help yourself. Yes, we believe in ‘tough love’😝.
The question you should always ask yourself is, 'how do I solve this problem if the lecturer/tutors are not around to help me?'
What not to do:
What to do:
Check what is given: Check if the problem/concept has been discussed in the lectures, textbook, or the list of resources given to you. Yes, it is easier for you to write an email to the tutor/lecturer instead, but that shouldn't be your default behavior. We know that sometimes it is difficult to find stuff in the resources we have provided. But you should try first.
Search: It is very likely the answer already exists somewhere in the cyberspace. Almost every programming-related question has been answered in places like stackoverflow.
Don't give an opportunity for someone to ask you to STFW.
Pay attention to the error message you encounter. Sometimes it also contains hints as to how to fix the problem. Even
if not, a web search on the error message is a good starting point.
Ask peers:
Ask your team members.
Ask classmates using the module forum. Even if you figured out one way to solve a problem, discussing it on a public forum might lead you to better ways of solving it, and will help other classmates who are facing similar problems too. If you are really shy to ask questions in the forum, you may use this form to submit your question anonymously which we will then post in the forum.
Rubber duck debugging is an informal term used in software engineering to refer to a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug his code by forcing himself to explain it, line-by-line, to the duck.
[for more, see wikipedia entry]
Ask the world using programming forums such as stackoverflow.
Here are some tips for posting help request:
PLEASE search for existing answers before you post your question in those public forums; You don't want to appear as a 'clueless' or 'too lazy to do your research' person in a public forum.
Learn to isolate the problem. "My code doesn't work" isn't going to help even if you post the whole code online. Others don't have time to go through all of your code. Isolate the part that doesn't work and strip it down to the bare minimum that is enough reproduce the error. Sometimes, this process actually helps you to figure out the problem yourself. If not, at least it increases the chance of someone else being able to help you.
How to isolate problematic code? Delete code (one bit at a time) that is confirmed as not related to the problem. Do that until you can still reproduce the problem with the least amount of code remaining.
Generalize the problem. "How to write tasks to a text file using Java" is too specific to what you are working on. You are more likely to find help if you post a thread called (or search for) "How to write to a file using Java".
Explain well. Conversations via online forums take time. If you post everything that is relevant to your problem, your chances of getting an answer in the first try is higher. If others have to ask you more questions before they can help you, it will take longer. But this doesn't mean you dump too much information into the thread either.
Know what these stand for: RTFM, STFW, GIYF
Talk to the lecturer before or after the lecture. The lecturer will be at the lecture venue from 30 minutes before the start of the lecture.
Request our help: Failing all above, you can always request for help by emailing the lecturer.
Resources
Relevant: [
Timing/venue:
Grading:
Tutorials are not graded. However, your conduct will be reviewed by team members and the tutor which will determine your participation marks.
[Exchange students only] Registering for tutorials:
We use the TEAMMATES online peer evaluation system to conduct several rounds of peer-evaluations. All peer evaluations will be taken into account when determining your participation marks. The system also allows you to give anonymous feedback to your teammates.
Extra Requirements: [considered for participation marks]
The purpose of the profile photo is for the teaching team to identify you. Therefore, choose a recent individual photo showing your face clearly (i.e., not too small) -- somewhat similar to a passport photo. Some examples can be seen
in the 'Teaching team' page. Given below are some examples of good and bad profile photos.
If you are uncomfortable posting your photo due to security reasons, you can post a lower resolution image so that it is hard for someone to misuse that image for fraudulent purposes. If you are concerned about privacy, you may use a placeholder image in place of the photo in module-related documents that are publicly visible.
Peer evaluation criteria: professional conduct
Peer evaluation criteria: competency
Giving constructive feedback to others is a valuable skill for software engineers. It is also an intended learning outcome of this module. Half-hearted/trivial feedback will not earn participation marks.
Here are some things to keep in mind:
Thanks for all the hard work!
and negative ratings (e.g. Equal share - 40%
) to the same team member is not being honest.Your tutor will serve as your project supervisor too.
The supervisor's main job is to observe, facilitate self/peer learning, evaluate, and give feedback.
Tutorial time is the main avenue for meeting your supervisor. In addition, you can meet the supervisor before/after the tutorial, or any other time, as many times you need, subject to availability in his/her schedule.
Note that it is not the supervisor’s job to chase you down and give help. It is up to you to get as much feedback from the as you need. You are free to request more feedback from the supervisor as necessary. Similarly, it is not the job of the supervisor to lead your project to success.