---
# System prepended metadata

title: Untitled

---

### STOP


- being so serious lol
- rushing code 
- panicking (not easy but something to remember and work towards)
- Using guys and getting pronouns wrong - I'm talking about myself :P


### CONTINUE
- Co-authoring +1000
- Starting as a 4 to get the structure in place
- not working OOH, we did a nice strict job this time :)
- listening / providing space
- making sure everybody understands code 
- swapping partners & velocity
- working on the parts we find hardest



### GO
* Comment code more
* Decide about spending more time on Facbook
* Spend a bit longer at beginning planning
* Better Commits
* Have more fun
* Music breaks? Stretches? tea?
* Breaks - let other pair know when a break is being taken, so that we align breaks 
* Think more of learnings rather than MVP
* Have learning goals like one of the other teams
* Buy Neville a new wifi router :P & Laptop +1
* Be in the room more
* Emulate one of the other teams with their tight focus on roles
* Finish velocity stuff - actuals

### Notes:

Being serious: topic is overwhelming, people focus on learning, also our first time working together. 
Reflection on putting up hands - also might help for wifi issues.
Rushing code - e.g. modularising issue on own - better to do as a pair for the team's learning. 
Co-authoring - good for people's career prospects and inner happiness :grin:
Working as a 4 at start - nice structure to work flow. Also depends on project, whether we're happy with the setup etc being routine. Also depends on the team's learning level. E.g. deployment isn't routine yet, so we should at least be in pairs for next week. Decide as a team!
Well done team for not working out of hours. READMEs - they could help the rest of the cohort if we spend extra time making clear and informative. Putting stuff in the readme as we went along was helpful.
Well done everyone for listening well and making time for learning
Well done for swapping pairs after every task completion - we all got to work with each other. 
We did well to assign tasks based on things people found difficult. 
Commenting - too much can be hard to read, and should not be a sub for readable code. But judicious use can be very useful.
Plans - we should spend a bit longer doing this: kanban breakdown, plus when they need to be done by. THINKING about it more. Maybe taking some time apart to do some thinking would help here. 


#### Actions:
- chill out more next week
- put up hands to speak
- make sure deployment is at least in pairs next week.
- get rid of the console.logs once they've stopped being useful. 
- Meet sunday evening 8-9pm to kick off carrying on Facbook. 
- Spend more time planning next week: take some time apart for thinking. 
* Music breaks? Stretches? tea?
* Think more of learnings rather than MVP
* Have learning goals like one of the other teams
* Emulate one of the other teams with their tight focus on roles
* Include actuals in velocity



