On Friday, I gave a talk at the Joy of Coding conference. The topic: “Teaching a Machine to Code”.

In this talk, I explained why we at Prodo.AI are working on next-generation tooling for developers, leveraging neural networks alongside traditional static analysis to find problems faster.

I also gave four (live!) demonstrations of how we can use machine learning and other more “human” techniques to detect and repair defects in code.

But mostly I talked about the difference between humans and machines, and how we can rebalance software development in favour of creativity.

Every successful agile transformation goes through five stages.

Denial

What are you talking about? What’s this “Agile” bullshit? We don’t need it!

The first stage of an agile transformation is resistance. Perhaps the CEO is convinced, or perhaps there’s a ground-up movement from one of the software development teams, or maybe there’s a solo designer, engineer, tester or other developer pushing for change. Either way, we don’t like it. And we’re not listening.

It’s just another fad, anyway. It’ll blow over.

I’ve got a new look.

I’ve been wanting to get my blog off Tumblr for a while. It’s finally done.

I’m now running on Hugo, which is a pretty shiny static site generator. I like it a lot. It has a bunch of rough edges but I’ve mostly got my head around them now.

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.