About Assignments

How are Assignments delivered?

Each assignment will be delivered as a directory in the class repo that contains a README.md file; for example, the pre-class assignment: 00 -- Ready Player One. This file will contain all the instructions for the assignment, a list of the minimal requirements and some "level-up" goals when you complete the minimums. Over time, the assignments will provide fewer and fewer explicit instructions, expecting you to fill in the details.

What is the goal of these Assignments?

• To introduce you to and reinforce your understanding of the pieces and parts of web development.
• To give yourself an indicator of your ability to work with those pieces and parts.
• To give us an indicator of your ability.
• To provide you an opportunity to practice -- and thus, improve -- your ability.

Many of the assignments will seem larger than you can complete in the time allotted. Part of your job will be to analyze the assignment, prioritize sections, and apply time constraints to your work to ensure that you complete some of every part of each assignment. Always turn in what you have. It's very important that you understand that you can learn by struggling with difficult work, whether you complete it or not.

When is my Assignment due?

Assignments are typically due at 12:30am on the morning of the next lecture day. Note that while an assignment given Tuesday is due 12:30am Wednesday, an assignment given Thursday is due at 12:30am the following Monday. The reason for a midnight due date is to prevent you from staying up to all hours of the morning trying to complete your work. No one homework assignment is as important as you being fresh and ready for the next class meeting. Keep that in mind as you progress through the cohort.

How should I turn in my Assignment?

These are the bare minimal instructions you should follow for every assignment. Additional instructions or direction may be provided in the assignment file, but always ensure that you follow these steps:

• Create a Work In Progress (WIP) Issue in the class repository for every assignment:
  • Name your WIP Issue according to the assignment number with your name appended, e.g. 00 -- David Rogers
  • Copy and paste the task list (i.e. check boxes) provided in the assignment file as the description of your WIP Issue; this is just a starting point...
  • Fill in more details! You will be expected to break down larger tasks into smaller ones; if you're daunted by a large task in the checklist, break it down! If you're having trouble with that, ask for help early
  • Estimate each major piece of the assignment with T-shirt sizes: Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL); these should be relative measures of complexity, difficulty and risk and not time estimates.
• Work in small increments of time so that you remember to save and commit your work regularly and take breaks. Using the Pomodoro Technique -- working in 25 minute increments with 5 minute breaks -- is one way to meter your progress.
• Check off tasks as you finish to demonstrate progress and watch the progress bar in the Issues list fill up! Some tasks will involve reading, researching, or writing code... or just English. Return regularly to your WIP Issue to stay on task.
• Create a new Work In Progress (WIP) Branch for the assignment in each repository that you'll be working with. That will always be another repo that you control, not this one.
  • Name the branch per the instructions in the assignment! This is how I will find your code to evaluate it, so please pay attention to the names of anything that appears as preformatted text.
  • Commit all your work into your WIP Branch and only that branch. You'll probably mess this up a lot at first. Don't Panic. As soon as you realize your mistake, come get help, but don't stop working. Everything is correctable.
  • Push your branch to Github regularly to show progress. Don't wait until you're "done" to push your work! Who knows, you might run into a problem pushing (or just plain forget to). Having nothing to show is way worse than having broken, disorganized code to remodel.
• Edit and commit the requested WIP Files. Each Assignment will contain a list of files and folders that are expected to be included in the submission, and we'll be looking for those specifically.
• Open a Pull Request (PR) to demonstrate your work:
  • Name your PR after the part of the Assignment it addresses. Each Assignment will have named pieces that will require work in different repos and may have unique branch names. I'll try to always name these parts something fun. Please make the name of your PR match.
  • Add your checklist for that part of the Assignment to the description. Turns out that PRs are a special form of WIP Issue, so putting a checklist on them generates a progress bar, just like with WIP Issues.
  • Set the BASE branch for your PR appropriately. Each PR has a from (HEAD) branch that should always be the WIP Branch; each assignment will specify a into (BASE) branch, typically master. Please ensure your PR os for the correct branch!
  • Add a link to your WIP Issue in a comment on your Pull Request. This links the PR back to your WIP Issue and displays the progress bar in the comments.
  • Remember to push your WIP Branch often! The PR will update automatically as you push more work to the branch, so open the PR early (as soon as you have at least one commit) and push your branch frequently to show progress. Do this step as soon as you have a commit; don't wait until the due date!

If you're really confused about this "branch" and "push" terminology, GitHub would love to explain "branching" to you... And pretty much everything else git-related, too.

IMPORTANT -- Some assignments will be long-running and will span several branches and PRs. Leave each PR open until you start the next Assignment, which should inform you which PRs you should merge.

You may also be assigned groups or pairs for certain Assignments. The Assignment will dictate whether you both need code and branches in your own repos or if you're expected to share repositories for a project. You should always create a WIP Issue in the class repo and link your work to that.

How will assignments be graded?

Your WIP Issue will be assigned a Label for grading purposes, feedback will be provided as comments on either your WIP Issue or your linked PRs, and your WIP Issue will be reassigned to you to review and close. If you don't close your WIP Issue in a timely fashion, we will require you do so before future submissions will be graded.

If you have further questions about any of the feedback provided in your WIP Issue or PRs, please ask in a comment and bring it to our attention. If you write us directly via chat, email, Twitter or otherwise, we will redirect you to the appropriate WIP Issue. This is for our protection as well as yours as it keeps our conversations on-the-record.

Incomplete [RED]

Your WIP Issue...

• Does not contain links to your work in the expected repos (leniency extended for branch names early on)
• Does not match the requirements for branch or file names (leniency extended for the first week)
• Does not contain the deliverables enumerated, i.e. missing one or more WIP Files.
• Only demonstrates minimal effort towards submission.

Essentially your work is difficult or impossible to evaluate because you didn't follow the turn-in process. Your assignments for the first week or so will be graded more leniently as you get accustomed to that process, but by week 2, we expect your work to be submitted correctly.

Not Yet [ORANGE]

You have submitted the work correctly and included all the parts that the Assignment required. However, your work...

• May demonstrate a conceptual deficiency that requires additional study or practice.
• May not be functionally complete: broken code is still better than no code.
• May demonstrate a focus on the target while missing the goals: the learning objectives.

If your WIP Issue is assigned a "Not Yet" label, we will include feedback for improvement or further practice. We may also comment on your WIP Issue or linked PRs to give directed feedback. This feedback is for personal improvement only, and is not expected to be incorporated before merging your PR.

Grades will not be revisited once assigned.

Satisfactory [GREEN]

Your work was submitted correctly, includes all the expected pieces, and demonstrates satisfactory understanding of the key concepts and learning objectives.

Good work!

Your PRs or WIP Issue may still include feedback for continued improvement as comments. Please consider this feedback for your next submission.

How do I know if I'm cheating or just collaborating with others?

You are expected to justify your own work. Even in pair- or team-based projects, you should be able to understand and explain any piece of code used by you in your project. If you utilize code from another source, you take ownership of the maintenance and continued development of it. If you do use code from another source, be sure to attribute in a comment where it came from and who authored it. Therefore, exercise caution when playing "copy-paste-tweak" and always attribute your source.

Explicit Plagiarism -- "the practice of taking someone else's work or ideas and passing them off as one's own" -- is forbidden. The wholesale copying of source code and passing it off as your own work will only hurt your long-term success as a programmer and will be met with severe consequences in the class such as forfeiture of Demo Day privileges and job placement assistance or even expulsion from the cohort.

ASIDE: How The Iron Yard is like Fight Club...

Your homework for this week is to pick a fight ... and lose.

-- Tyler Durden, Fight Club (EXPLICIT)

One of the best ways to get drastically better at something is to fight with it, win or lose. Your experience with the homework should be like Reggie Miller's experience playing pick-up basketball alongside his big sister, Cheryl: arguably the best player in the history of women's basketball. Reggie spent years getting blocked, thrown into the rose bushes, and generally trounced every game. If Reggie were judged based on whether he achieved the goal of winning those games, he'd be a failure. He may never have won a single one of those games, but struggling against an unbeatable opponent, keeping track of his own strengths and weaknesses compared to the standard she set, and continually trying to get better had the effect of making him better. Reggie Miller was a five time NBA All Star, and you can watch part of his story.

Learning and developing any technical skill -- programming or pro-level basketball -- requires time spent in focused practice, but also time spent recovering from the effort of focused practice. You will have to work hard in this course, but when you reach the point that your brain hurts and you aren't making any more progress, stop. Rest. If it's still early in the day, return to the homework after a break; but if you have to make a choice between working more on homework and getting a full night's sleep, get your sleep. You'll feel better, and you'll learn more. Staying up to 2am for a whole week while attempting the most mentally tasking activity of your life will lead to mental shut-down.

That being said, fight hard with every assignment, even if it appears unsurmountable. There are baby steps, ways to slice each assignment down into smaller pieces, so that you can always make some progress. Beware the Jabberwock, but remember that it can be slain.