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?

Short sighted learning

Focus
Originally uploaded by Dani Ihtatho

I've been enjoying learning about a number of aspects of the .net world over the last year or so. Recently, I've been creating WCF Services - being new to the service creation world, I had to start from scratch, which is always a good place to start.

My problem, however, is that I wanted to learn enough just to get something up and running. I find that the problem with learning by google (or Stack Overflow, MSDN, blogs) is that there's no one pushing you to get the complete view of a topic - not that people don't offer the information up, it just seems irrelevant at the time when you're working so hard on the basics.

My lack of understanding was highlighted when doing some performance testing. I thought the service would create threads per call, but there are limits to the number of threads (which, of course, makes sense) - but what happens with those that don't get through to the service? Do the requests time out? What happens when the requests are being pased through from a DMZ? A standard request that worked normally as a one off test starts failing under load. None of these issues are problems within themselves, but a lack of understanding about how services generally work, how to queue up requests, how to handle concurrent requests all come crashing back to bite when you get an unexpected problem.

Talking about a different project (one that I wasn't involved in), I was saying to my colleague that I think it's not wise to check something in if you don't understand what it's doing - which I still think is right - but I didn't even know that I didn't know what I was doing!

To help my shortsightedness, I think I need to define some kind of learning plan that outlines all the parts of a new topic that I'm working on, even if it's just a quick read over a msdn article to see what 'bits' are talked about so I'm aware of their existance. I've even been considering buying books! The more I look at it, the more I think a good book is a great basis for learning a new topic - they're usually comprehensive in covering a topic, even if they don't touch on the detail of all aspects - google can come into help then.