I’ve watched software developers (in the broadest sense—programmers, designers, testers, managers, coaches, etc.) struggle with the idea of “one-piece continuous flow” for a long time.

Recently I was reminded of my favourite metaphor for this. I was in Brooklyn Coffee (the best little café in London) and watched the staff (there’s typically 3 people working there at any given time) work. I was waiting to place my order, but there were two people operating the coffee machine and one handling something in the back, so I had to wait about a minute before one of the baristas (who happens to own the place) came to take my order.

The most efficient way to implement a piece of software is to do it all yourself. No time is wasted communicating (or arguing); everything that needs to be done is done by the same person, which increases their ability to maintain the software; and the code is by default way more consistent.

Of course, we don’t make large pieces of software this way. We work in teams.

Turns out “more efficient” doesn’t mean “faster”. When there are more people working on the same problem, we can parallelise—do more at once.

When we break work up across a team, in order to optimise for the team, we often have to put more work in, individually, to ensure that the work can be efficiently parallelised. This includes explaining concepts, team meetings, code review, pair programming, etc. But by putting that work in, we make the work more parallelisable, speeding up and allowing us to make greater gains in the future.

I’m getting pretty excited about the idea of a completely decentralised World Wide Web.

Last year I went to the Mozilla Festival. I loved it. I could only make one of the two days, but it was enough for me. The highlight was the Beaker Browser, a browser that’s able to request and serve web pages over a secure peer-to-peer networking protocol called DAT.

Over the holidays, I decided to serve my website over DAT using the Beaker Browser, just to see how it goes. And I discovered something really interesting.

Today, I’m 29.

Here’s what I’d like for my birthday.

I’d like you to ask yourself why you do what you do.

And then I’d like you to post that online somewhere public (even if it’s bloody Facebook), and leave a link in the comments, or email me, or tweet me, or… you get the idea.

That’d be the best present I could ask for.

I believe, like all jobs, programming will be fully automated. The question isn’t “if”, but “when”. I believe in specialised AI for this role, not general-purpose AI, because most software problems are caused by incomplete understanding, and only a machine that can fully understand the technical landscape of a given piece of software will be able to meaningfully improve it.

I was listening to Amanda Palmer’s song, In Harm’s Way. It helped me realise something.

This post stems from a discussion with Constantina and others on the Codebar Slack team.

In JavaScript, callbacks can be unpleasant to work with. Callback Hell has a great explanation about how to make them work well, but it doesn’t change the fact that a programming style that lends itself to misuse can be problematic, and callbacks are misused all over the place. Even in documentation.

One of the big problems with callbacks is remembering to handle the error. This is the if (err) { … } pattern you see a lot. If you find yourself copying and pasting error-handling code all over the place, you might want to use promises instead.

Last week, I spoke at Computer Science Noobs on the subject of type systems. I’m still in the process of writing up the talk (and make no promises about if and when it will be finished), but I realised something that I wish I’d realised sooner.

It turns out I really don’t like talks.

This post is loosely based on a discussion with Beverley Newing and others on the Codebar Slack team.

---

You don’t need to rebase.

I think branch-based development is now the most common workflow when using Git: everyone develops on a branch that belongs to them (for some definition of “belongs”, depending on the team), then when they’re done, they merge the branch into a shared branch (often called master, latest or develop), from which they release.

On Saturday, I helped run the Cambridge instance of Coderetreat, 2017 edition as part of the Cambridge Software Crafters.

It was a really fun day, and I enjoyed it thoroughly. Today, though, I’m not going to talk about the whole day. (If you want to read about what it’s like, I wrote a post about it five years ago.) This time, I want to concentrate on just the first session.

This one was new to me, but Amelie and Alastair been doing it in Cambridge for a long time. The task is the same as always: implement Conway’s Game of Life. The constraint, however, made a lot of people uncomfortable.

Pen and paper. No computers.