Tips from Woody

I hope you all enjoyed having Woody here this morning. It was a real treat showing him around the mobs and see him interact with y’all.

Over lunch me and Jakob had time to chat with him and we got a few general tips for you to think over in your mobs:

1) Try to not interupt the driver. We don’t need to interupt someone to correct their typing. The tools, error statements and failing tests should help us. By learning to understand them we will become more proficient programmers.

Try as an exercise for a day or so: do not interupt the driver until they ask for help. See how it changes the dynamic in the team.

Here’s a short, top-of-my-head list of things that we should all be familiar enough with to not be interupted.

Say this	And write this
Declare a function called apa	function apa () {}
Declare a function apa that takes a parameter banan	function apa (banan) {}
Declare a function apa that takes two parameters	function apa (a, b) {}
Declare an arrow function called apa	const apa = () => {}
Declare an arrow function called apa that takes a parameter banan	const apa = (banan) => {}
Declare an arrow function called apa that takes two parameters	const apa = (a,b) => {}
Create a constant apa	const apa
Create a constant apa and initialize it to an empty string	const apa = ''
Declare a constant apa that is an array	const apa = []
Create a new empty object called apa	const apa = {}
Add a name field to that apa object	const apa = { name: ''}
Create a describe-statement for the Apa module	describe('Apa module', () => {}
Create a new test for empty input	test('empty input', () => {})
Add an assert that checks if two strings are equal	assert.equal('', '')

2) Try to not interupt eachother. In the same manner - let the person finish speaking before interupting someone.

As an exercise you can try to have the person navigating standing up and then ask others for help. This is not the preferred way of working but can be a good little exericse to get us into the feeling.

Another pretty cool way of doing this, that Woody tipped us of is the Liberating Structures app which starts you off in conversations on how we are going to work together and might end up in writing team agreements to further help you progress. These exercises can be run as retrospectives if you want to.

3) Try to speak on the domain level - not the code level. Try to express the problem we are trying to solve without using code terms, before diving into arrays, maps etc.

A really good way to do this is to diagram it on a whiteboard.

Aspirations

The above are aspirations and not something that we might be able to do right away. Remember that this is a school where we, for example, are learning to write code and where to put semicolons etc.

As an excercise sit down and talk about your ways of working and see what you come up with. Use my suggestions as … suggestions.