Course Description

This course uses intuitive animation-based programming to introduce fundamental concepts and design process commonly used in computer software and app development. Key topics include basic programming blocks, program logics, loops, conditionals, functions, event handling, debugging, and iterative development process. Upon successful completion of this course, students will have gained a good understanding of computational principles, important skills to create animations and apps via low-code systems, and a solid foundation for continuing their education in computer science.

Course Content and Learning Objectives

Each lab, you will work on a different programming assignment. If you cannot complete the assignment during lab, you will have until next lab to complete the assignment. Most assignments are drawn from “The Beauty and Joy of Computing” (BJC) curriculum, which is based on the AP CS Principles curriculum. These assignments are designed to teach computer science concepts, while avoiding the learning curve of traditional programming languages. Consequently, these assignments use the Snap! block-based programming environment. Depending on how the semester progresses, later assignments may use Python, a more versatile programming language which is still beginner friendly.

You are also expected to attend weekly recitations. Recitations will include discussions and other activities. If you cannot attend a recitation session, you may submit recitation materials online using Gradescope; in this case, you must also explain why you could not attend recitation.

Grading

Grading is pass-fail. To pass the course, you must:

• Submit an on-time, best-effort attempt for more than 80% of the assignments, and
• Participate in at least 80% of recitations

Time Expectations

To get the most out of the course, regular in-person attendance of lab and recitation is expected. As a half-credit course, you are expected to participate in 90 hours of engaged academic time over the course of the semester. Weekly time expectations are detailed below:

• Lab: 1.25 hours
• Recitation: 1 hour
• Homework (assigned readings, finishing assignments, etc.): 3.75 hours

Since the semester has 15 weeks, the total time commitment comes to 90 hours.

Policies and Miscellaneous

The official administrative business of this class will be conducted by email

Explanation of absence, etc. will be processed via email so that we both have a written record of what was agreed. Feel free to discuss in person but an email follow-up is required for the official record.

Attendance and discussion/asking questions are expected

If you must be absent, please contact me in advance to let me know why you won’t be in class, and you must make up for the missed class and keep up with the course work.

Computer use policy

You are welcome to use your own device to work on course assignments during class. However, do not use class time to work on other homework, check email, or surf the web. Such activities can be distracting to other students.

If your device has a small screen, we encourage you to use the lab computers – this will make pair programming easier, and will make it easier for us to see your code.

Assignments are due on time

That is, at 11am on the listed due date, with additional 59 minute courtesy time.

Plan your work accordingly: work diligently during class, ask for help when you get stuck, and seek help outside of class if necessary.

No special make-up work will be accepted after the end of the semester

In the event of a documented major medical problem, a grade of Incomplete will be given pending the submission of complete work. However, make up work “to improve one’s grade” will not be accepted.

Pair Programming

In this course, you’ll use a collaboration technique called pair programming – writing computer programs in teams of two. One partner, the driver, controls the computer. The other, the navigator, helps catch errors and keeps track of how the code being written fits into the overall plan. The navigator is also in charge of reading the lab pages out loud. Aim for equal time in each role, switching about every five minutes. To collaborate in pair programming:

• Keep talking. The driver should constantly explain the reason for using each block. The navigator should interrupt with questions: What about doing it this other way? How does this program avoid such-and-such bug? Don’t we have to deal with this requirement and that requirement at the same time? We’re pretty much repeating this other piece of code over there; could we hide that code in a block and use the same block in both places? And so on.
• Listen. Try to understand each other’s thinking before you disagree.
• Work as a team. If you find yourself being defensive about feedback, remember that nobody’s code is perfect right away. It’s the navigator’s job to find problems in the driver’s code, and when you switch places, the new navigator will repay the favor. You’re a team, not a competition.
• Work toward consensus. Don’t bargain; if you have disagreements about how something should be done, don’t say “well, you can do this your way if I can have this other thing my way.” Both partners should listen to each other’s reasons and work together to find a solution that meets both needs.
• Speak your mind and work out your differences. That doesn’t mean you should try to disagree, but if you do, you can still be friends. Work out the conflict by listening and understanding each other, rather than by giving in just to end the argument.
• Regardless of experience, take turns. Don’t let the more experienced programmer overwhelm the other partner. Make sure both partners are comfortable contributing, in either role. A group is almost always better at problem-solving than any of the people in the group is alone.

How not to do pair programming: The biggest mistake in pair programming is for the navigator to tune out and let the driver do all the work. The navigator has to be paying attention; otherwise you’re just taking turns doing the entire work instead of making use of the benefits of having two people.

Adapted from “The Beauty and Joy of Computing.”

Academic integrity: cheating and plagiarism

Academic integrity is a basic value for all higher learning. Simply expressed, it requires that work presented must be wholly one’s own and unique to that course. All direct quotations must be identified by source. Academic integrity can be violated in many ways: for example, by submitting someone else’s paper as one’s own; cheating on an exam; submitting one paper to more than one class; copying a computer program; altering data in an experiment; or quoting published material without proper citation of references or sources. Attempts to alter an official academic record will also be treated as violations of academic integrity.

To ensure academic integrity and safeguard students’ rights, all suspected violations of academic integrity are reported to the College Board. Such reports must be carefully documented, and students accused of the infraction are notified of the charge. In the case of proven academic dishonesty, the student will receive a sanction, which may range from an F in the assignment or course to suspension or expulsion from the University.

The complete academic integrity policy is available with Academic Advising at:
https://web.clarku.edu/policies/detailpolicy.cfm

Do not, under any circumstances, copy another person’s code or show your assignment code to other students (unless they are part of your programming pair). Incorporating someone else’s code into your program in any form, or allowing someone to do so with your code, is a violation of academic regulations. In addition to the definition of plagiarism in the handbook, with respect to this course, plagiarism is specifically defined to include (but is not limited to) the following:

• Copying any part of someone else’s assignment/program, even if you have permission and/or have modified the code
• Sharing or giving your assignment/code or even a subset of your assignment/code to another student
• Reviewing another student’s solution (including from past semesters)
• Reviewing solutions on the internet

You may not publish your solutions to this course’s programming problems in a way that could compromise their utility as pedagogical tools.

If you have any questions about these matters, please consult the instructor.

Welcoming class atmosphere

I strive to make this course welcoming and productive for all students. Please let me know what name and pronoun you prefer to be called. Please bring any issues or concerns to my attention.

Students with academic accommodations

Clark University is committed to providing students with documented disabilities equal access to all university programs and facilities. If you have, or think you have a disability and require academic accommodations, you must register with Student Accessibility Services (SAS). If you have questions about the process, please contact The Director of Accessibility Services. If you are registered with SAS and qualify for accommodations that you would like to utilize in this course, please request those accommodations through SAS in a timely manner. Clark University is committed to providing students with documented disabilities equal access to all university programs and facilities.

Disclaimer

The instructor reserves the right to make changes to any information contained in this syllabus at any time during the semester. Changes will be announced, and an updated version of the syllabus will be posted online.