《Structure and Interpretation of Computer Programs》collab work

6.001 Policy on Collaborative Work Most people learn more effectively when they study in small groups and cooperate in various other ways on homework. This can be particularly true in programming assignments, where working with a partner often helps to avoid careless errors. We are very much in favor of this kind of cooperation, so long as all participants actively involve themselves in all aspects of the work--not just split up the assignment and each do only a fraction We are structuring the work this term into two types: problem sets(including both the problems that you should do on-line as you watch each lecture and the on ne problems that you should turn in weekly in association with a pair of lectures and projects. Please abide by the following guidelines with regard to these different types of work Problem sets(all the on-line work) are designed to reinforce key concepts. These should be completed by each student individually, though seeking tutoring help from Lab assistants or other staff is perfectly appropriate. Projects are designed to be larger scale activities, in which group activity in brainstorming and design is often a key component. For these projects ye encourage you to work with one or two other people. When you turn in your project, you must identify with whom you worked. We expect, however, that you are involved in all aspects of the project, that you write and comment your own set of code, and that you write up your results separately When you hand in material with your name on it, we assume that you are certifying that this is your work and that you were involved in all aspects of it. Do not just turn in a copy of a single file; write your own version. This means that you create this file yourself, and not just annotate a copy that you received from someone else. We know that this may sound like replication of work, but an important part of learning the material is making the process an active one, particularly with respect to editing executing, and debugging software, which you do by ensuring that you create and explain your solution Here is an example scenario of how a good collaboration might work Both(all) of you sit down with pencil and paper and together plan how you're going to solve and test things. You go together to a cluster and sit at adjacer machines. You check after each problem to make sure that the others have working implementations and are all caught up. When one of you has a problem the others look over your shoulder. For example, your partner has a bug on one part, and you are able to point out where the bug is and how to fix it. On each part of the problem, you write your own code and solution, seeking help from the others when you have difficulties. On the write-up each of you lists the names of a∥ of your collaborators Here is an example of an inappropriate collaboration

6.001 Policy on Collaborative Work Most people learn more effectively when they study in small groups and cooperate in various other ways on homework. This can be particularly true in programming assignments, where working with a partner often helps to avoid careless errors. We are very much in favor of this kind of cooperation, so long as all participants actively involve themselves in all aspects of the work -- not just split up the assignment and each do only a fraction. We are structuring the work this term into two types: problem sets (including both the problems that you should do on-line as you watch each lecture and the on￾line problems that you should turn in weekly in association with a pair of lectures) and projects. Please abide by the following guidelines with regard to these different types of work. Problem sets (all the on-line work) are designed to reinforce key concepts. These should be completed by each student individually, though seeking tutoring help from Lab Assistants or other staff is perfectly appropriate. Projects are designed to be larger scale activities, in which group activity in brainstorming and design is often a key component. For these projects, we encourage you to work with one or two other people. When you turn in your project, you must identify with whom you worked. We expect, however, that you are involved in all aspects of the project, that you write and comment your own set of code, and that you write up your results separately. When you hand in material with your name on it, we assume that you are certifying that this is your work and that you were involved in all aspects of it. Do not just turn in a copy of a single file; write your own version. This means that you create this file yourself, and not just annotate a copy that you received from someone else. We know that this may sound like replication of work, but an important part of learning the material is making the process an active one, particularly with respect to editing, executing, and debugging software, which you do by ensuring that you create and explain your solution. Here is an example scenario of how a good collaboration might work: Both (all) of you sit down with pencil and paper and together plan how you're going to solve and test things. You go together to a cluster and sit at adjacent machines. You check after each problem to make sure that the others have working implementations and are all caught up. When one of you has a problem, the others look over your shoulder. For example, your partner has a bug on one part, and you are able to point out where the bug is and how to fix it. On each part of the problem, you write your own code and solution, seeking help from the others when you have difficulties. On the write-up, each of you lists the names of all of your collaborators. Here is an example of an inappropriate collaboration:

You send your friend a copy of your code so far. She works on it to complete the procedure you had not finished, and she fixes a bug in another procedure You each submit this shared code and solution. Even though you list the names of each other as collaborators, this is inappropriate collaboration because you were not both involved in all aspects of the work- you did not each write your own implementation even if to a common plan and you shared a common set of code and write-up Not listing the name of a collaborator will be deemed cheating. Similarly remember that copying another person's work and representing it as one's owr work is a serious academic offense and will be treated as such In general, we strongly encourage you to work as a group It is a very effective way of catching conceptual and other errors, and of refining one's thinking and understanding. Also note that if you are having trouble solving a problem, please take advantage of the Lab Assistants. Part of their responsibility is to answer questions and provide advice and guidance on the course material

You send your friend a copy of your code so far. She works on it to complete the procedure you had not finished, and she fixes a bug in another procedure. You each submit this shared code and solution. Even though you list the names of each other as collaborators, this is inappropriate collaboration because you were not both involved in all aspects of the work -- you did not each write your own implementation even if to a common plan, and you shared a common set of code and write-up. Not listing the name of a collaborator will be deemed cheating. Similarly, remember that copying another person's work and representing it as one's own work is a serious academic offense and will be treated as such. In general, we strongly encourage you to work as a group. It is a very effective way of catching conceptual and other errors, and of refining one's thinking and understanding. Also note that if you are having trouble solving a problem, please take advantage of the Lab Assistants. Part of their responsibility is to answer questions and provide advice and guidance on the course material