Mob Programming, and the importance of fun at work

It’s been a few weeks since SoCraTes UK 2014, and I’ve had some time to reflect on the event and my learning experiences. Today, I want to talk about the biggest things that stood out for me.

Mind. Blown.

The session that really blew my mind was Gianfranco Alongi's explanation of Mob Programming. It takes pair programming to the next level. Its tagline is "All the brilliant people working at the same time, in the same space, at the same computer, on the same thing", and that’s exactly what it is. A whole team, a keyboard, a mouse and a projector. One driver, and a few navigators, with a decent amount of rotation. I won’t go into too much detail; the website linked above has much more information. This wasn’t why this session blew my mind, though it was a really cool idea.

What really struck me about this session is that Gianfranco and his team have become fast friends. They care about each other, they know about each others’ lives and they all respect and value each others’ company.

They don’t necessarily see their work as a chore. They see it as fun. One thing that Gianfranco pointed out is that work and fun are not opposites, but fun and boredom are. If you’re not bored at work, it must be because you’re enjoying yourself. Even if it’s only a little bit.

This talk set the tone for the rest of the conference for me. I started to talk to people about their jobs, not in sessions, but over coffee or beer. We talked about why they enjoyed their jobs and what they wanted to do better. I found that most people at SoCraTes do enjoy themselves, which is not what I’ve found of most developers in general. I don’t know why that is, exactly, though I could make a few educated guesses.

A Brief Digression

I’ve recently read Drive, by Daniel Pink and thoroughly enjoyed it. The central theme of the book is that financial remuneration is not the most important thing to a creative worker (and a software developer is most definitely creative). The three central drives of someone who works in a creative fashion are autonomy, mastery and purpose. What this means is that the people who derive the most fulfilment from their jobs, and therefore are enjoying themselves the most, are those who have a lot of autonomy over what they do and how they do it, can use their job to help them in the pursuit of mastery, and find a lot of purpose in what they do.

Obviously, there’s a lot more to it, and the book references a large number of case studies and psychological experiments, but the introduction lays the point of the book out plain and simple, and it was obvious to me from the moment I read it that it was true. I and many of the software developers I know derive pleasure and enjoyment from our work, not because we get paid massive amounts, but because of the above three principles. We have control over our work and we do it because we find meaning in it.

And back, full circle

On the evening of the second day, Paweł Duda and I decided to work on my task list kata. I’d run a session around it earlier that day and he wanted to pair on it with me to see how it would go.

It got a bit popular, so we decided to mob, rather than pair. Six of us sat down in front of a projector, a little drunk, way after midnight, and commenced the exercise.

Cue slow progress, lots of discussion and many different ideas about the right way to go. We decided to rotate every 10 minutes (after trying 5 and deciding it was way too little). The refactoring went slowly, but it went well. We tried a bunch of different approaches and settled on one I really liked (though by then it was 2am and we opted to go to bed). Throughout, more people dropped in until we didn’t just have a mob, we had a whole crew.

It looked something like this.

Mob Programming at SoCraTes UK 2014

I found it remarkable how much enjoyed the exercise. The conversations that sprung up were really useful, and I could see the direction we were going was one none of us would have considered individually. That buzz I seek out every day at work from good conversations and solving interesting problems was there from the start, and throughout the exercise, it never left.

And then, a retrospective

Afterwards, a few of us stuck around to talk about the exercise. The conversation veered off in an interesting direction, and really brought me back to what I was looking for all along. After only an hour or so, it was fairly clear that key to mob programming seemed to be empathy for everyone else in the group, especially the driver. It was important to discuss the work, but it was also important to empower everyone to speak up and argue their case, rather than drifting into the background. When we tried to compromise, it didn’t work—people were quite unhappy. And it was paramount to ensure that everyone had the same goals in their head and were working toward them.

Autonomy, mastery, and purpose.

It’s not enough to make your workplace fun. Fuck those Nerf guns you see all over Silicon Valley (and some companies on this end of the planet). They’re a workplace smell, just like company-mandated trips to the pub and “team-building events” (which are generally anything but). If you have to tell people they’re having fun, they’re not having fun.

Instead, give people some control back. Give them 20% time. If they won’t take it, cut off access to the source repositories and force it on people. Give people a space to post up social activities. Give them a budget, too.

People are amazing at making things fun, just as long as you let them.

This post was cross-posted to my company blog.


Rekord: Java Beans must die

In programming, duplication is the enemy.

We see it everywhere. Code, copied and pasted because “we have no time”. Entire pieces of infrastructure lifted from one project to the next, rather than extracted and shared. Domain objects scattered through applications, every one slightly different. API connection layers written again and again, each one in a different style, doing the same, exact thing with new and interesting bugs.

Meanwhile, in Javaland…

These are all serious problems, but Java has one more. We can’t get away from it. No language really helps with duplication of behaviour, but in Java, we also duplicate concepts. It looks something like this:

public class Person {
    private final String firstName;
    private final String lastName;
    private final LocalDate dateOfBirth;
    private final Address address;

    public Person(String firstName, String lastName,
                  LocalDate dateOfBirth, Address address) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.dateOfBirth = dateOfBirth;
        this.address = address;

    public String getFirstName() {
        return firstName;

    // I can't go on. You know the rest.

But wait. There’s more.

public class PersonBuilder {
    private String firstName;
    private String lastName;
    private LocalDate dateOfBirth;
    private Address address;

    public static PersonBuilder aPerson() {
        return new PersonBuilder();

    public PersonBuilder withFirstName(String firstName) {
        this.firstName = firstName;
        return this;

    // So many more methods.

    public Person build() {
        return new Person(firstName, lastName, dateOfBirth, address);

That’s right, we need a builder too.

Oh, and we like tests. Especially clear, readable tests. So let’s make a matcher.

public class PersonMatcher extends TypeSafeDiagnosingMatcher<Person> {
    private Matcher<String> firstName = any(String.class);
    private Matcher<String> lastName = any(String.class);
    private Matcher<LocalDate> dateOfBirth = any(LocalDate.class);
    private Matcher<Address> address = any(Address.class);

    public static PersonMatcher aPerson() {
        return new PersonMatcher();

    public PersonMatcher withFirstName(Matcher<String> firstName) {
        this.firstName = firstName;
        return this;

    // Keep writing methods.

    public void describeTo(Description description) {
        // Very important.

    protected boolean matchesSafely(Person actualPerson,
                                    Description mismatchDescription) {
        // Match against the fields.

OK, now we can use our Person type. It’s beautiful, right? It just needs some annotations to serialize to JSON, then some JPA annotations for persistence to the database, and…


Ugh. So much code for so little behaviour. And not just once. EVERYWHERE. Can we stop this?

Fuck yes.

Read More


A software craftsman is

Someone who aspires to quality.

Someone who considers the means as well as the ends. Alternatively, one who realises that everything has more than one outcome, and that as many of them as possible should be considered.

Someone who does not build unnecessary things.

Someone who does not dismiss things as unnecessary because they are not core to the experience from their perspective, or distant from their areas of expertise.

Someone who understands that every system has several different workflows, and does not optimise for one at the expense of the others without fully comprehending the costs and benefits.

Someone who continuously takes feedback into account, and is constantly improving the various feedback loops they have in place.

Someone who can deliver quickly and iterate upon previous work, taking feedback into the next iteration.

Someone who can respond quickly to unexpected change, and takes action to improve responsiveness whenever possible.

Someone who, while pragmatic enough that they continue to deliver, understands that less-than-stellar work will make them slower and more unresponsive over time.

Someone who respects opinions, but makes decisions based on facts. Where facts are not available, experimental evidence is necessary.

Someone who strives to learn more than they currently know, focusing on techniques, paradigms and philosophy rather than tools.

Someone who has good knowledge of their toolset, and is always learning more about how it can help them create.

Someone who recognises when it is more important to solve the problem with the tools available, and when it is more important to build new tools.

Someone who aims to learn more outside the scope of software development, in both technical areas (such as UI design or system administration) and business areas (especially those core to the purpose of the software) so that they can better understand what they are developing.

Someone who discusses potential solutions with others, in order to reach one that could not be achieved by any of them on their own.

Someone who recognises their deficiencies and weaknesses, seeking to either correct them, substitute them or delegate responsibility to someone who can deliver better in those areas.

Someone with the humility and open-mindedness to accept new ideas and fold them into their own, even when it means their previous work could be considered inadequate.

Someone who is aware that other solutions exist, and will weigh the benefits vs. the costs of changing course without becoming sentimental about previous work.

Someone who fits solutions to problems, rather than problems to solutions.

Someone who writes code for humans, not computers.

Someone who can evaluate code in their head, and when they cannot, strives to simplify it to the point where they can.

Someone who recognises that the definition of “simple” differs from person to person, and attempts to understand others’ definitions before coercing code to their own.

Someone who can communicate clearly and without bias, making sure to include all context in their communication, leaving as little as possible to interpretation or subjectivity.

Someone who recognises that discussion is no substitute for action.

Someone who recognises that disagreement is not an excuse to avoid discussion or debate.

Someone who can keep focused on the topic or work at hand, but does not dismiss or ignore new work because it is not currently relevant.

This list was created without order, though many of these qualities are related. Together, I believe they embody wisdom, open-mindedness, humility, drive, and many other traits I believe are crucial for good software development. Critically, unlike those traits, they are actionable: one can strive to achieve these things in a way that you cannot for something fuzzier, such as “open-mindedness”. From the other point of view, hiring or contracting a software a developer, one can (ideally) look for these traits irrespective of a person’s background, race, gender or any other discriminating factors.

When working in a team, I hope to see these qualities in my colleagues and co-workers.

Whenever I’m working on software, I hope to see these qualities in myself.

Thanks to Ben Summers for provoking this blog post, as well as providing very useful feedback.


Pairing without programming

Pairing is often associated with programming. There’s a Wikipedia article about pair programming, but nothing on pairing in general. And yet, it’s a fantastic technique for getting anything done well, especially when neither of you really know exactly how to approach a problem.

For a week and a half now, I’ve been working with Sandro on the business side of Codurance. From next week, I’ll be heading to a client to do some actual programming, but in the mean time, I’ve been working on recruiting, promotion, client relations, and I’ve also had a little more time to spend on LSCC.

I’ve been really enjoying myself, and with good reason. I’ve never run a company before, and while I’m not really doing that now, I’m helping and learning a lot. This is mostly down to pairing. We pair on a lot: we’ve written the job specifications together, worked on training material, sent emails to clients and customers, debated our approach to apprenticeships and what’s desired of our craftsmen and craftswomen, figured out what we want and need from an office… the list goes on and on. We’ve conceded a number of important points to each other that only made sense because we gave ourselves the freedom to think with instantaneous feedback.

We pursue all these things because they’re what’s going to put food on the table, and at some point, we need to eat. Discussion begets discussion though, and we’ve found ourselves regularly arguing the merits of domain-driven design, schools of TDD, up-front design, architecture, various frameworks and patterns, and pretty much everything else under the sun. (It turns out Sandro and I disagree on a lot.) These are the discussions I’ve missed from working with like-minded software developers; people who care about all the end-results of their productivity, not just the one that you see on the screen immediately, but how that user interface will look three months from now, how simple it is to add functionality and how much joy or suffering you’ll bring the next person who has to work with your output.

Pairing also allows us to comfortably talk about situations that are generally kept quiet between employers and employees. Creating an environment in which we can talk about anything has allowed us to discuss salaries, working conditions, flexibility in working hours and even our own lifestyles. Sandro’s just had a baby and needs to rebuild his life around him; by bringing this to the table as a concern of the company, not just his personal problem, it encourages everyone else to make their colleagues aware of their own personal situations. I’m really hoping this will result in a company which doesn’t just say it cares about its employees, but is designed from the outset to take their needs, desires and aspirations into account. By pairing on the company itself, we can shape it into something we love.

I’m thoroughly enjoying pairing on everything. I’ve only been at Codurance a short time, but it feels like I’ve come home.

Oh, and we’re hiring. :-D


Check your I/O

In Haskell, there’s something known as the IO monad. The way it works is this: if you have it, you can do I/O. If you don’t have it, you can’t. You can pass it around, but you can never produce it from nothing. (Haskell aficionados, the comments are open for flaming in 3, 2, 1…)

Before we continue, I should elaborate a bit on what I/O is. It’s basically anything that reaches out of the safe confines of your executable and touches the system in which it lives. For example:

  • reading and writing files
  • printing to the command prompt
  • drawing something on the screen
  • receiving information over a network interface

In short, if you’re reading or writing, it’s probably I/O.

Now, back to the IO monad. Here’s how it looks:

sayHello :: String -> IO ()
sayHello name = putStrLn ("Hello, " ++ name ++ "!")

That first line is the type signature. It says that sayHello has one parameter, a String, and returns nothing (depicted by the empty tuple, (), sometimes called “unit”) wrapped in the IO monad.

putStrLn is a function that prints to the console, and its type signature looks like this:

putStrLn :: String -> IO ()

It also has IO in there. That’s why sayHello requires the IO monad; without it, it couldn’t call putStrLn.

Read More