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.

Over the weekend, I asked a lot of people a few questions about code reviews.

I have an agenda. We’re working on a product that intends to take the pain out of code review. We want to make the best product possible, and that starts with understanding where the pain is.

The data in my survey is biased towards the sort of people that read this blog. So take it with a grain of salt, and if it doesn’t resonate with you, comment! I’d love to hear from you.

Sensei, teach me BDD.

OK, this whole programmer-fascination-with-Japanese-words thing has gone too far.

Also, OK.

Behaviour Driven Development, or BDD, is the idea that you write user stories that turn into executable test cases.

You’ve probably heard of Cucumber, or Gherkin. Gherkin is a format for doing just this. Cucumber runs the scenarios and tells you if they fail.

Over this year, I’ve been delivering a talk/live presentation/workshop on “WebOps”, or DevOps-style operations for the web.

Here’s the premise:

At lightning speed, this workshop will cover the bits that aren’t code that make up a working web app. These include servers, monitoring, deployment mechanisms, logging, alerting, secret management, recovery mechanisms… you get the idea.

Topics include:

• how to set up a web server on Linux,
• deploying changes to a web server with zero downtime,
• keeping an eye on your server to make sure things are working,
• tracking down production bugs,
• managing persistent data (such as your database),
• secure communication over HTTPS,
• and, if we have time, how to do all this in the buzzword of the decade, containers.

The workshop is designed to run on Unix-like machine such as Linux or macOS. If you’re running on Windows, we can make it work, but it won’t be quite so true to real life.