Learning in the open - mobprogramming

One of the best things about mob programming (#mobprogramming on twitter) is the way that the team shares learning.

Our team recently worked on a tool to remove unused AWS stacks, dedicating quite a few lunchtimes to the cause. We decided it would be a great opportunity to try some mob programming, as it was a project that we were all excited about.

In the process we

• Learnt some emacs
• Learnt about using the Serverless framework (AWS lambda under the hood) for the first time
• Worked out how we were going to test our application
• Familiarised ourselves with recursion and promises in javascript
• Came up against deployment and runtime problems

While each of these could have been done solo, mob programming gave us the opportunity to:

• Talk the problems through, coming up with better design
• Get comfortable asking for explaination when we're unclear - showing that we don't know it all
• Bring something new to the table that other people don't know - even if we've just found it ourselves
• Teach others
• Share the joy of seeing something working that we've worked on so closely together

One of the biggest benefits is individuals showing they don't know everything. Often as software developers we suffer from imposter syndrome, but just exposing that we're all learning can encourage a better culture where people are happy being vulnerable - where they feel they can ask questions without judgement.

Have you tried mob programming? What do you think are the benefits? Drawbacks?

Starting on the wrong foot

I've just joined a new project as a team member - my role is to write software. I'm keen to start off with domain driven design, really connecting with the users that know the processes and understand why things happen. At the moment we're writing some code to test some of our ideas to make sure we've got the skills we think we do.

I do think that domain driven design will be tough, especially getting buy in from managers to take the time of their domain experts to work through how they work and how they think, but that's all yet to come - our business analyst has done some great work on gathering initial requirements, so I think people are ready for the discussion that will come soon.

One of the big surprises for me is the lack of 'project team' or culture that has been created. Now, I work as a 'resource' (how good does that make you feel?) underneath my manager who has been more involved in the planning phase, but now that I'm actually part of the team, surely there should be some feeling of being part of a team? Bas de Baar of Project Shrink has quite a lot of articles about the culture in projects - well worth your time to have a look at. So I'm wondering what to do about this. It's got me quite frustrated over the last few weeks, especially as having tough conversations is made harder if you don't have a basis to work from.

My current plan is to organise a lunch outing, it'll at least be a start. I'd also be keen to go lawn bowling, but I'm not sure if anyone else would be keen, so it might not be so much of a winner for team culture.