Here is a page where you can access different software and class resources to help you succeed. We will use two programming languages during this course: Pyret and Python. We’ll start in Pyret and switch to Python in November.
Learning in Lecture and Lab
Lectures in the course will involve a fair bit of hands-on activities and discussion. Learning happens when someone is actively thinking about material and making connections between new material and already-known material. The lectures are designed to facilitate this, but you have to meet us halfway to make this work.
In particular, you are expected to participate in small group discussions as they arise during lecture. Sharing ideas on problems helps both you and your classmates (in hearing and responding to ideas of others, you strengthen your own conceptions of material).
Similarly, when we share out ideas from small groups to the class, talk and respond to each other, rather than expect the professor or staff to mediate. We'll hop in if we think a point is being overlooked, but we want to encourage discussion within the class (again, because this is how you'll learn the material better).
In part, this means that reading notes and watching lecture capture will only get you so far. We provide these as tools for reviewing content or catching up if you have to miss a day here and there, but they will not be good substitutes for being in class and participating in the activities and discussions.
Learning to Program
Learning to program involves developing several skills. We present this list not to overwhelm you, but to help you manage your learning. Each of you will find some of these skills easier to master than others. Paying attention to which skills you’ve mastered and which need more practice will help you focus your time and efforts in the class.
-
Writing computations in the structured and precise notation of a programming language
-
Understanding how the computer evaluates/runs programs in a given programming language
-
Breaking down problems into individual steps that you can express in the programming language, then combine to produce a program that solves the give problem
-
Reading existing programs (your own or others) to understand how and why they (don’t) work
-
Locating and correcting errors in programs
-
Communicating the design and intent of your programs to those who may read them later
-
Testing that your program does what it is supposed to do
Learning Tips
Write code, don’t just read it
Learning to program involves internalizing the patterns within code: what statements are needed, where do they go, what statements are used for which tasks, etc. When you have internalized a code pattern, your brain can retrieve and reproduce it when you are given a similar problem to solve. You internalize code patterns by actually writing them down, not by reading them (writing and reading exercise different processes within the brain). This is also important because the order in which we write lines of code and the order in which we read them tend to be different. You need to practice each skill (reading and writing) independently.
Tip: When we cover new programming concepts, the notes will often list some additional practice problems. Try a couple of these to help your code writing come naturally, without your having to look back on your notes.
View CS as learning processes, not facts
In some courses, you basically need to learn a bunch of facts and formulas and when to apply them. Programming is different: much of it is about learning a process of creating something or solving a problem, not about memorizing stuff (there’s a bit of memorizing stuff, but memorizing isn’t enough). Don’t expect to learn the material by reading it over and over. Instead, work on learning the steps we take and the questions we ask to make progress on problems. This goes back to the previous point: you won’t learn CS just by reading.
Tip: As you study, try to articulate the steps that we took to solve each problem. Don’t just try to memorize solutions.
Manually simulate how code runs on paper
We understand concepts by building models of how they work. Think of a model as a high level map that helps you see how the various pieces of a problem fit together and evolve over time. If you develop a model of how programs work, for example, then you can use the model to understand and predict how new lines of code should fit into the program. Models are also important because they can break a larger problem into the sub-parts that you need to understand to make sense of the whole problem. Working through models can help you (and us) figure out the actual part of the problem on which you are stuck.
Tip: We will show you various models of how programs work and how data ties together. Practice using these models for specific programs, until you are confident that you understand how your programs run. Bring your models to office hours if you aren’t sure about how they work. Working with the models targets the low-level building blocks of learning to program.
Don’t believe in a "geek gene": you can learn this with practice
People often believe that programming and computer science is something that some people are "born" to do while others are not. At this level, this idea is false. It is true that different people absorb the techniques faster than others, but that doesn’t mean that only those with the "geek gene" can do well in CS. Approach CS as something that you can learn with practice; don’t tell yourself "I can’t do this because I’m not a CS person". There’s much interesting research on something called mindset: very roughly, it says that if you assume intelligence is fixed rather than flexible, you engage differently with material.
Tip: Don’t fall into the trap of thinking that you can’t learn this. Some of your classmates have programmed before. Not surprisingly, that means they are better at it than you are right now. That doesn’t mean that you can’t learn to do this too. Work with the practice problems and the course staff.
| Problem | Ed | Debugging Hours |
Conceptual Hours |
Professor Hours or Appt |
|---|---|---|---|---|
| Fix/Debug Code | small issue | larger issue | ||
| Understand Error Message | yes | yes | yes | yes |
| Conceptual Question | yes | yes | yes | |
| Review Study Skills | yes | yes | ||
| Questions on Drills | yes | yes | yes | |
| Private Issue | appt (email them) |
Labs (required) run each week to practice programming material.
In general, we strongly encourage you to use Ed for small/quick questions. You can post code to Ed in private posts. If you feel you need to post a lot of code, your question is probably better suited to face-to-face SignMeUp office hours (schedule is in the calendar). We have a good-size team of TAs handling Ed in the hopes of getting answers to you quickly.
If you have a clarification question, we prefer you to make a public post (can be anonymous) on Ed. If we feel a private question is of general interest, we may turn it into an anonymous public post, so more people can see the answers.
Milda's office hours will be open, not one-on-one. This means you are welcome to join the session anytime and ask questions or discuss material (whether from class, homework, or CS in general). These hours are not meant for helping individual students with code.
If you feel you need individual help with how you approach problems in general, make an appointment with Milda. Also make an appt with Milda if you have a concerns of a personal nature.
You have only 15 minutes for one-on-one appointments, so being prepared is important (and it keeps the line moving for other students).
In class, we will be learning a design process in which you write your code after written other artifacts (such as behavior examples or task plans, which we will teach during the class). These other artifacts are critical to figuring out where you are actually stuck on a problem. We therefore expect you to show these artifacts to your TA when you come in for debugging hours, unless your question is not about figuring out why your code isn't working.
Having you learn design skills is one of the goals of this course (we're not here just to show you how to produce code). This policy supports this goal.
We’ll talk about design steps in lecture throughout weeks 2-4 of the course.
- The Pyret Programming Environment, called CPO, runs within a web browser. To save programs, you will need to log into the environment (there should be a login button on the front page). You can use any google-authenticated email address for logging in. Files will be stored in the Google Drive account for that email address (in a folder named code.pyret.org, which Pyret will create for you). If you don't want to use your Brown Google account for login, you are welcome to use/create a separate Google address for login and file storage.
- Pyret documentation
- Pyret Style Guide
- Notes from the staff on using CPO (code.pyret.org)
- Documentation for working with Pyret Tables
If you need accommodation for your physical and mental health, please feel free to reach out to Milda - we want to support you as much as we can in the most comfortable way for you. It is important to note that TAs should not be handling health and accomodations information, so inquiries should be directed towards Milda only.
Please check out the following links for resources on physical and mental health in Computer Science.