protips

Logo

This site lists the protips that we shared with eachother in the Slack-channel during the courses.

View the Project on GitHub saltsthlm/protips

This site is deprecated and all the content has moved to AppliedTechnology

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.