PDFIn order to succeed in the bootcamp, it’s important that we begin with a shared understanding of how the bootcamp will be conducted on a day-to-day basis.

Respect

What we are setting out to do in these 12 weeks is challenging enough; there’s no reason for any of us to make it more so. One way we can all help is to treat each other with consideration, compassion, and respect.

Given the intensity and aims of the bootcamp, the instructors will sometimes appear critical of students’ work; however, we do aim to give criticism in a constructive, respectful fashion, and to interact with students with patience—and to apologize when we fail to do so.

We expect a similar level of consideration and respect from the students—for each other, and for Deep Dive instructors, coaches, management, and support staff. In particular, racist, sexist, homophobic, or transphobic comments, or any kind of personal attack—whether in the classroom (in-person or virtual) or in a community medium such as Slack—will not be tolerated. Further, we recommend that conversations on political or religious beliefs not be conducted in the classroom or in community-accessible areas of Slack.

Teamwork

In addition to the capstone projects, there are a number of design and development activities that students execute in teams. Team projects and activities are evaluated on a team basis: In grading, we don’t assess the contribution of individual team members, but of the team as a whole.

Part of the coaches’ role is to help the students build their team coordination, collaboration, and conflict resolution skills—and the coaches will be available (balancing their other time commitments, of course) for consultation on issues in these areas. Beyond that, we expect any serious issues within a team—that the team members are not able to resolve themselves—to be brought to our attention in a timely fashion. For example, capstone teams start working together early in week 7; if some members of a team come to us (coaches or instructors) in week 11, saying something like “team member X hasn’t been pulling their weight in the project for the past 4 weeks,” there’s very little that we can do in the way of constructive intervention at that point.

Schedule

Class starts promptly at 8:00 AM each day. Students are expected to be in their seats, computer on, ready to work at that time, whether the class is being conducted in the classroom or online. If in the classroom, we recommend arriving 10–20 minutes before, depending on how much time you’ll need for your morning coffee, cereal, bagel, etc. Usually, an instructor arrives to open the classroom by 7:40 AM. (If you arrive before the instructors, remember that the CNM_TLS wireless network is available in the open area in front of the classroom.)

Lunch is from 12:00 noon to 1:00 PM. We begin working right at 1:00 PM; just like the morning schedule, you need to be in place and ready to begin the afternoon work at that time.

Class ends at 5:00 PM—except on Fridays, when it ends at 3:00 PM. At least one instructor typically remains in the classroom area until 5:30 PM, Monday–Thursday.

We take two 10-minute morning breaks, and similar breaks in the afternoon. Sometimes, we take additional shorter breaks, but these are the exception, rather than the rule.

We assume that students will act—and deserve to be treated—as responsible members of a development team. Thus, if you need to get up from your desk from time to time—to stretch your legs, get a drink, visit the restroom, etc.—you should do so, with no need to ask the instructor for permission. However, when doing so, please distract the other students as little as possible—not only when leaving the classroom, but also when catching up on your return. (Keep in mind that as a rule, the instructors won’t be able to stop the class to bring a returning student up to speed. This is also the case for students arriving late in the morning, or returning late from lunch.)

Participation in class activities

Much of the work we do in the classroom (even when the classroom is virtual) consists of guided, hands-on programming or other activities, where all students are doing the same (or similar) work, under the instructors’ supervision or following the instructors’ lead; this is particularly true in the first 6 weeks of the bootcamp, Even this work, however, is expected to be completed by every student, and then—for coding or design exercises—committed to Git and pushed to GitHub. Under normal circumstances, it is not acceptable for a student to declare “I’m just going to watch for a while, and not do this one.”

Questions & answers in the classroom

The instructors have no interest in a one-way, “teachers lecture, students listen” style of instruction. We frequently ask questions of the students, and we encourage them to ask questions of us as well, and to engage in discussion—subject to the needs of the classroom in the moment.

Depending on the material being presented, and the level of classroom discussion, the instructors reserve the right to do any of the following, alone or in combination:

  • Declare a raised-hands-only question protocol.

  • If the class is being conducted online, declare that questions must be asked through the chat or “raise hand” features of the conferencing software.

  • Postpone answering a question or responding to a comment. (We’ll try to keep track of these, and address them at the end of the morning or afternoon instruction.)

  • Request that the student ask the given question or make the given comment at a later moment. (In this case, it will be the student’s responsibility to keep track of the item and raise it again later.)

  • Explicitly decline to answer a question or respond to a comment.

Practices specific to online participation

  • When the bootcamp is being conducted online, we do not insist that students keep their cameras on during class—with one important exception: Starting early in the bootcamp (week 1 or 2) and continuing through to the last day, class will usually begin with a short scrum stand-up meeting; we expect students to appear on-camera for these meetings, if at all possible.

  • As a rule, if any student is attending remotely, all lectures will be recorded and posted online, for students to use as study aids, exam review materials, project reference materials, etc. The instructors will generally edit this content only minimally before posting (primarily to trim “dead air” from the beginning and end); however, if an instructor notices that a student or instructor, while sharing their screen, has displayed content that would be considered confidential or otherwise inappropriate for posting, it will be edited out. Students are expected to participate in this “flagging” process: if a student notices such content, and it does not appear that an instructor has noticed it, we expect the student to bring it to the instructors’ attention.

  • In online breakout rooms, or in online meetings other than that used for daily scheduled instruction, video recordings will not, as a rule, be captured by the instructors. In these situations, a student may request the instructor/host’s permission to capture their own video recording via Zoom—in fact, it is that student’s responsibility to request this permission, if a recording is needed.

  • It is often the case that a student having difficulty completing an assigned task will need to allow the instructor to look at their screen, to observe the issue as directly as possible. (It is not reasonable to expect an instructor to provide effective assistance in resolving non-trivial problems while “flying blind”.) Students needing assistance are expected to permit this, whether online or in the physical classroom.

    Similarly, students’ code will be seen not only by instructors, but—for example, during code reviews—by their classmates as well. We recognize that showing your code to the instructors—and often, to the entire class—can be intimidating; however, it is often necessary. In fact code reviews—which involve reviewers reading and commenting on developers’ code—are an important practice in many development organizations (including this bootcamp).

    Important: If you are showing your screen contents (via screen share or in-person) to an instructor or classmate, while they are helping you resolve a problem, or reviewing your code for any other purpose, please don’t scroll the window contents or switch to a different window, unless/until asked to do so. Also, please resist the temptation to anticipate an instructor’s directions (for scrolling, making changes to the text, etc.) while they are assisting you.

Communication

As stated in the syllabus, it is each student’s responsibility to keep instructors informed of any course-related issues that the student might be having—regarding attendance & participation, grading, hardware & software environment, difficulties in completing assigned tasks, etc. Please note that direct communication is expected: Asking a classmate to relay a message to an instructor does not absolve the student of their responsibility to inform the instructor directly.

The expectations outlined above also apply to communication with coaches and other Deep Dive staff, on issues relevant to their roles and responsibilities in the organization.

Most day-to-day bootcamp communication/coordination—outside of verbal communication in the classroom (physical or virtual)—will be conducted via Slack. E-mail will also be used for some course communication, as will the cohort-specific Brightspace and GitHub Pages web sites.

Students are expected to monitor Slack, e-mail, and the course web sites regularly for new messages and other content. Additionally, students should plan for the possibility of internet outages, and configure access to these services not only from their laptop computers, but also from phones or other devices. Failure to read e-mails and Slack messages will not be considered a valid excuse for missed or late completion of assignments communicated by such messages.

Potential distractions

We recognize that web surfing and social media are large parts of our students’ everyday activities; for some, the same is true of streaming media content and computer games. In general, we won’t place many limits on these activities in the classroom; however, we do have guidelines and a few strict rules:

  • Real-time multiplayer or time-limited gaming is not permitted in the classroom (physical or virtual) during bootcamp hours. (Of course, if we’re developing a game application, playing the game for the purpose of testing or debugging will be necessary at times, and is thus one of the very few exceptions to this rule.)

  • Absent explicit direction or permission to the contrary from an instructor, headphones or earphones must be used for any audio content (other than those produced by system or application alerts, warnings, and errors) played on students’ computers in the classroom during bootcamp hours.

  • During lectures, presentations by guest speakers, and other instructor-led activities, if an instructor has the assessment that a student’s surfing, messaging, streaming, etc. are distracting from the content being presented—for the student in question, other students, or the instructors themselves—we may ask the student to curtail their online actions for the duration of the classroom activity. In a physical classroom, there will even be times when the instructor asks students to close their laptops. Students are expected to comply with such requests.

  • During quizzes and exams, there will be no gaming or use of social media (except as directed by the instructors).

  • Deep Dive bootcamp shared spaces, whether physical (classrooms, meeting rooms, lunch rooms, etc.) or virtual (Slack channels, discussion forums, Zoom meetings, etc.) are both workspaces and learning spaces. Any content which would be considered inappropriate in either of those contexts is certainly inappropriate here. (Please keep in mind that in a shared space, your opinion is not the only one that matters when it comes to judging whether content is appropriate or not.)

  • From time to time, instructors or guest speakers will lecture or lead activities using whiteboards, handouts, digital presentations, videos, or manipulatives (e.g. cards, dice), without writing code (or expecting the students to write code) in real-time. Sometimes, it will be the instructors’ assessment that the attention required from the students precludes the use of computers and phones altogether for the duration of such an activity. In that event, we expect students to comply with our requests to close their laptops, turn off external monitors, refrain from using their phones, etc. (Obviously, we won’t request either of the first two when the bootcamp is being conducted online.)

In the end, most of the above comes down to being aware (and acting in accordance with that awareness) of the distraction potential of surfing, streaming, social networking, and gaming—for you and those around you.

Development environment

As stated in the syllabus, each student is responsible for maintaining his or her development environment (including an Android development target environment, whether hardware- or software-based) in working condition throughout the bootcamp. In general, if a student has a system crash or other issue, the instructors will do what they can to help the student get back up and running; however, such assistance is always constrained by the needs of the class and the curriculum. In other words, the instructors can’t allow any one student’s equipment problems to prevent or distract from teaching the entire class.

As with other problems you might encounter in the bootcamp, it’s very important that you keep the instructors or coaches aware of any issues you’re having with your development environment that could interfere with your ability to complete an assigned task. It’s also important to do this in a timely fashion. For example, if a homework assignment, project component, or practical exam is due on a Monday morning, and you tell the instructors that same morning that your computer crashed on Friday, so you weren’t able to complete the work, that won’t be considered an acceptable excuse for late completion.

Kitchen/lunchroom

When the bootcamp is conducted in a face-to-face (or hybrid) mode at the CNM STEMulus Center, the kitchen is generally stocked with coffee, tea, and a few snacks. A few times during the bootcamp, we will provide lunch for the students. Apart from that, students should plan on providing their own lunches. Please mark any food placed in the refrigerator; unlabeled items will generally be considered “community food”—apart from the contents of the drawers, which are reserved for the instructors and staff.

As a matter of healthy work practice, we encourage you to avoid eating in front of your computer every day. At the STEMulus Center, there are suitable tables in the lunchroom, around the fountain in the Galeria, on the plaza, and even in the classroom, on either side of the room. Of course, you can leave the STEMulus Center altogether for lunch, as long as you return on time.

The water in the Keurig coffee maker generally needs to be refilled after every 6–8 cups dispensed. If you notice it getting low, please refill it using the water bottle refilling station.

If you notice that the kitchen is running low on something, please let the instructors know, and make a note of it on the whiteboard in the lunchroom.

Students are expected to wash their own coffee mugs, water bottles, and (non-disposable) plates, bowls, & utensils.