Skip to content

Latest commit

 

History

History
113 lines (91 loc) · 6.88 KB

README.md

File metadata and controls

113 lines (91 loc) · 6.88 KB

Stop, Go, Continue notes

Immediate changes

  • Week 4: Everyone commits to washing their dishes as soon as they've used them
  • Create a suggested workshops issue on the FAC6/book repo and add to it
  • From Week 8 onwards, start reviewing other teams' code on each project day, ending in a review of all three teams' projects on Friday morning
  • Stop giving too many options (e.g. ways of doing auth) - make the cohort aware of the different ways of doing things, but whittle them down to two options
  • FAC6-wide discussion around processes for Coding For Everyone (getting people on the Gitter channel, introductory talks, general process)

Ongoing actions for FAC6 course

  • More lightning talks
  • Week 4 - keep booking speakers, they love them
  • Create template for readmes on Tuesdays
  • Best practice READMEs, e.g. Node starter kit
  • Stop working when you're supposed to be reviewing people's code
  • Start keeping the volume down during reading days - and less rowdiness in general (but mainly Monday mornings)
  • Start - a forum for unanswered questions - FAQ repo within FAC6 to raise issues on

Morning challenges

  • Solutions for morning challenges must be put up on GitHub
  • Morning challenges are solved as a class from scratch again rather than talking through one person's existing solution
  • Continue - morning challenge solving other people’s problems using github readmes

Mondays - now Research days (used to be workshop day)

  • 10:00 Show & Tell on cool websites and technologies the students have found
  • Provide a practical task associated with the research topics, so that you know what you're trying to achieve with the research
    • If this isn't possible, provide more directed questions so people don't spend large chunks of the day researching irrelevant information
  • Jigsaw classroom all day (this is still a hit in week 4), with presentations of what is ready just after lunch
    • Presentations will take place without a projector
  • Keep structuring the research topics well, week 4 is a good example of what worked well
  • Post projects to a readme in the morning so if people want to know what it is we can do so (++ this keeps being requested, again in week 4)

Tuesdays - now Workshop days (used to be Research on Learning outcomes)

  • Workshops for half to two thirds of the day, with the last half or couple of hours of the day dedicated to starting the project
  • 15h00: intro the project, then create READMEs + do wireframing
  • As part of workshop include a session on reviewing modules and discussing best practices / patterns

Wednesdays & Thursdays

  • Don't write code until the README is done
  • Add mid-project code review at lunch
  • 18h00: everyone writes on a wall what their biggest learning (or what they struggled most with) from the day was
    • People now know who to go to for help with those topics

Fridays

  • Definitely keep code reviews first thing in the morning
  • Continue pairing to provide feedback on that week's projects
  • Seriously, stop closing issues you haven't opened
  • Start using labels (i.e. "fixed") in your repo issues
  • Whiteboard diagram walk-throughs as a chance to ask the questions from the week



FAC7

Actions before FAC7

  • Changes to pre-requisites:
    • Add in some DOM manipulation stuff
    • Remove jQuery (added as homework for first weekend)
  • Agreed: FAC6 will run a pre-course Git party for FAC7
  • Agreed: FAC6 will run a pre-course install party for FAC7

Curriculum changes for FAC7

General

  • Make sure people know from the beginning:

    • The emphasis of projects is on learning, not on finishing every possible thing on the project or presenting a beautiful product
    • Everyone has to commit to wash up straight after using their dishes

  • If Pivotal Tracker is introduced (and the feeling in the room was that it wasn't a helpful tool for the task at hand) this should be done at the very beginning of the project, not on day two

  • GitHub issues seems to work very well as a project management tool (instead of Pivotal tracker) and should be introduced earlier in the course (for FAC6 we introduced it on week 12 officially, though we talked about it throughout)

  • Simplify teaching of Auth

  • Commitment was low for a good portion of students in week 12. It was discussed that this was because:

    1. Everyone needed a break - people were tired and definitely needed time off to rest
    • A lot of people were attending to 'life admin'; things that had been piling up for the previous weeks
    • It was the week before the first set of MVPs and everyone spent a good chunk of time locking down the scope for those

List of things to review every week

In week 12 it was agreed that there should be a list of things up on a wall of things that everyone should keep in mind at all times. This includes:

  • This is a learning experience, not a competition
  • Remember to switch driver every 30 minutes or so when pairing
  • Always take time to push your code and update the issue you're working on before you leave in the evening
    • i.e. Ensure that someone else can easily pick up where you left off
  • Readme driven development - pretty much every PR should include a contribution to the readme

Week 1

  • Have a(n external) speaker to speak about how to do pair programming the right way
  • Review use of Jekyll
    • Pros: introduces templating and file structure
    • Cons: wasted a lot of time trying to understand Jekyll-specific things that won't be useful, SCSS file confused everyone
    • Whatever we choose have to ensure everyone know exactly what they're supposed to take from it before the week 1 project starts, i.e. which bits to focus on and which to ignore (like SASS) (FAC6 also requested this!!)
  • Start with a simple exercise to learn Git and talk through it again as a class before we move on
  • Add jQuery course to the weekend assignment for week 1 (people won't use it but must be able to recognise it)

Week 2

  • Consider adding to week 2 learning outcomes: CORS, JSONP and callbacks
  • Definitely continue giving students 3 different APIs, they really liked comparing the use of different APIs

Weeks 9-12

  • Introduce more practice on splitting up problems into tasks to be divided amongst a team earlier on
  • Maybe students can pitch ideas for projects to ensure everyone is working on something they enjoy
  • Working for one week in a team of 8 in a very valuable experience - the feeling in the room was that this would not be enjoyable for more than one week
    • These larger teams should have a scrum master (this should be enforced rather than suggested)
    • Some people became unengaged because there was less pressure to deliver as individuals - keep the pressure and accountability up