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


Time for change

On the 31st of January, 2014, I will be leaving Palantir Technologies and a job I love. I’ll be leaving some of the best people I’ve ever met, a really cool set of products, some awesome customers and (not least) an absolutely beautiful working environment. I’ll be leaving a job that’s taught me about client relations, server administration, requirements gathering, large-scale data management, integration and sanitisation, but also how to work with people on different continents and how to deliver outcomes, not services or products.

At this point, you may be asking why? It’s because while all of these things are important, only some of them are me. I am a software engineer, a developer, a coder. I make computers do things, specifically in ways that make sure they get that thing done well. The other stuff is incredibly valuable, but it’s not what I’m best at and it’s not what I love. I’m very grateful to Palantir for the experience, but it’s time to refocus.

So, to that end, I’m joining Sandro Mancuso and Mashooq Badar, two of the best developers and software craftsmen I’ve ever met in my time in this industry, in their brand new company, Codurance. Codurance is a little different from other software shops. It focuses on building software for the long term, which is something I’ve focused on a lot on this blog. I have no doubt we’ll fit together really well.

What this means is that I’m available for hire. If you need someone to help your team improve the maintainability and stability of a product, add test coverage to help you avoid breaking things, or even run training programs to get your developers up to scratch with the latest and greatest in Extreme Programming and Software Craftsmanship practices, get in touch.


Go make a sandwich

I was originally planning on writing something about the Cake pattern here, but after reading a lot more about it, I’ve decided it’s not as bad as I thought. I mistook one variant of it (which involved essentially having all methods of all classes available to you) with something a little more sophisticated. If you want to know about the pattern, I recommend Real World Scala: Dependency Injection (DI) by Jonas Bonér.

Here’s something fluffy that I’ve wanted to write about for a while. Often, when working on something, we become fixated. We understand that there are other possibilities, but we don’t consider them; the solution we have in mind is so good that if we could just get it working, everything would be amazing. Unfortunately, people in this position never seem to actually get the work off the ground.

Almost always, getting into this position requires a simple mistake made early on. Often, it will be an invalid assumption, but a typo or an error are just as likely. They all boil down to one thing: not thinking enough, but just doing. After several minutes or hours of banging our heads against the wall, we wonder what we ever did to deserve this.

And the answer is simple: we didn’t allow ourselves to think differently.

There are many ways in which you can achieve this. Taking baby steps is a great approach, as long as you know which direction you’re walking. Sometimes, though, you need a better catalyst. At that point, you should go and make a sandwich. Or have a nap. Go for a swim. Read a book about vampires, pirates and dinosaurs. Lie in the sunshine (or the rain, if you’re in Britain like me). Go home, play some video games, chat to your partner about their day and have a good night’s sleep.

When you come back, things will be different.

The human brain is an exceptionally powerful machine, as long as we operate it right. It’s not a computer. It doesn’t have distinct rules on how input gets translated to output. Sometimes it’s important to think about anything but the task at hand if we want to really consider all approaches to solving the problem.


Complicit Implicits

Imagine we have a calculator, written in Scala.

class Calculator {
  def run() {
    val printer = new Printer
    printer.print("The answer is always ")

object Calculator extends App {
  new Calculator().run()

It does one thing and it does it well. (Not the thing it says on the tin, but we’ll get there.) It makes use of a Printer, which is a type of object that knows how to print things.

import java.io.PrintStream

class Printer {
  def print(value: Int)(implicit out: PrintStream) = out.print(value)
  def print(value: Double)(implicit out: PrintStream) = out.print(value)
  def print(value: String)(implicit out: PrintStream) = out.print(value)
  def newLine()(implicit out: PrintStream) = out.println()

Read More