Each week you will have one challenge specifically designated as a solo challenge. This challenge is different, and needs to be addressed on its own terms.
Solo challenges are designed to provide you the opportunity to work on your own and see how confident you are with the learning objectives. These challenges are meant to show you where you are in your abilities at the moment.
From the instructor's perspective, solo challenges provide us with an example of your work. We use these to assess how you are doing and give you feedback. We want to see that you are following the process we've outlined (pseudocode, initial code, refactor, reflect) and are demonstrating your familiarity and ability to implement the objectives. We do not expect your code to be perfect; we expect it to show how you work through a problem on your own.
**Solo Challenges draw on the various learning competencies you are covering in that particular week, and are in the middle in terms of difficulty. It would be a good idea to go through the other challenges prior to completing the solo challenge.
##Expectations
We ask you to follow a different protocol when researching for these challenges because they are meant to be an example of your work and current abilities.
- Please do not consult anyone (including friends, family, cohort-mates, or DBC staff) on any part of the challenge. This includes office hours. Sorry!
- Keep your research limited to questions relating to syntax, documentation, or programming concepts. The methodology for solving the challenge should be entirely your own.
- Abstain researching or using solutions to the challenge. See plagiarism section below for details.
One of the goals of Phase 0 is to teach strategies for solving problems and learning effectively. This is why we ask you to follow each step with every challenge (where applicable). When completing your solo challenges, it's important that each section is complete and descriptive. We will be evaluating each section, not just your initial or refactored solution.
Your pseudocode should break the problem down into easily-implantable pieces. You don't want to put too much into one step, or have overly long sentences. Challenge yourself to really break the problem down into code-like English. See these guides: Pseudocode Standard or Pseudocode Overview. NOTE: Pseudocode is not required for HTML/CSS solo challenges.
For the week 1 HTML/CSS solo challenge, no pseudocode or refactoring is necessary. For week 2 a wireframe should be included as pseudocode.
Remember writing essays? Usually you would write a sloppy rough draft that would get your ideas out there and then (assuming you had time) try to remove typos and edit for clarity. Refactoring should be the same. You don't want to spend your time writing a completely new solution, instead you want to to simplify your existing solution, improve the naming and readability, and remove any unnecessary code or implement the code using new methods. Try reading this article "What is Refactoring?" for guidance. If you find yourself wanting to completely change the interior logic of your solution, make sure you explain why you decided to make that shift.
Your reflection is important in all challenges, but especially in your Solo Challenges. When writing reflections, write for your future self or another reader, not to yourself in the moment. You want to focus on describing what made the challenge difficult and being specific about what you did. Did you have difficulty implementing a method? Did you not understand a concept? Did you spend ages trying to fix a bug only to realize you misspelled something? Your reader doesn't know the process you went through, and he/she only sees what you put in your solution gist. So be clear about what problems you faced, what research and sources you used, and what you learned. This is your chance to teach your audience and describe your experience.
This may seem silly, but studies show that reflection is a valuable and important part of retaining your learning and improving in the future. Make sure you leave time for yourself to do that.
Now for the part we all dread...Plagiarism. So what is it exactly? In this context it's submitting work that did not come out of your head. In the past, students feared the solo challenges because they considered them a test that had a "right" answer. But let's be clear, there are no "right" answers at Dev Bootcamp. There are solutions that work, and solutions that need work. We want you to learn, and we know that oftentimes learning comes from failure.
What we mean to say is, if you are stuck and can't get a working solution, DO NOT panic and submit a solution that you found online. You will be cheating yourself of the learning opportunity and we will consider you out of integrity. If you find yourself in a situation where your code is not doing what you expected or want, explain what's going wrong (i.e. what you expected to happen and what's actually happening). Then take a break and sleep on it. Don't ever continue to struggle for hours in the hopes you will come to it. You'll be amazed how much better you'll feel after taking a break, and doing so will increase your chances of finding errors.
Even if these strategies do not lead you to a working solution, it's better that you include something that is your work with an explanation of what's wrong with it, and not a working copy of someone else's code. It is your responsibility to be able to explain every. single. piece of code and why it's necessary. You are not getting a grade on solo challenges, so let yourself take the time you need to work on the challenge in a way that helps you learn.
There has been some confusion on researching and plagiarism in the past because programming is often a collaborative experience, and even senior developers will look up solutions. That is generally ok, but there are exceptions. Solo challenges and hiring challenges are exceptions to this norm. Instructors and employers want to see what you can do on your own, how you solve problems, and how you think. That is why it is critical to ensure that everything you write in your solo challenge came from your brain.
If we suspect the work you submitted is not your own, which we determine from seeing if you understand exactly what it's doing from your pseudocode, refactoring, and reflection, we will contact you to set up a meeting to discuss your code.
You will receive a code review and feedback four times in Phase 0 on your solo challenges for weeks 4-7. This gives the instructors time to comment and give you feedback. Each instructor has his/her own style, but many will focus on what you can do to improve. It may sound crazy, but each review takes at least 15 minutes, so we focus on areas of improvement. We want you to think of feedback as helpful to your growth, not an indicator of failure. If you were a perfect programmer, why would you be coming to Dev Bootcamp?
Although we do not give grades, we will evaluate your code to see if you are learning the objectives we are covering. If you seem to be struggling, we will set up a meeting to see how we can help you. You will not be kicked out of the program for having a hard time with one challenge. If you seem to be struggling with the concepts, we will consult your other solo challenges to see how you did with those and come up with a plan.
If you have any questions regarding feedback you received, you should feel free to reach out to your instructor. You will find your feedback in the comments section on your submission gist (on GitHub).