Last week, I spoke at NewCrafts Paris 2019 on the topic of “Teaching A Machine To Code”, a talk I also gave last year at Joy of Coding.

(If you just want the content, it’s up.)

Before I talk about my talk, something really important: NewCrafts is a wonderful conference. I’ve never seen one run so smoothly. It was marvellous to see. Massive credit to the organisers for making it work so well.

Since Joy of Coding, a couple of things have changed. Firstly, the models themselves have evolved, and we’ve become more focused on the models that are likely to deliver—specifically “autofixing” code, and type prediction. We’re focusing on shipping at least the former soon.

Secondly, we’ve achieved much more clarity. Rather than an end goal with very little idea about how to get there, we see a lot of power in the combination of machines working to gather as much data as possible. Humans have always been good at seeing the patterns emerge from information, and we want to get as much of that information into your eyeballs so you can be more effective.

As always, you can read the entire talk contents (except some references to Thinking, Fast and Slow, which I improvised). I hope you enjoy it. Please send feedback!

On Saturday, I finally finished Advent of Code 2018 (and pushed my solutions to GitHub). I did the whole thing in Swift (except for a couple parts which I did by hand), but I tried to avoid Xcode as much as possible, knowing that it would make automating things a whole lot harder. Instead, I ran everything directly in the command line. It took a while to figure out how to do this, with little official documentation on the subject, so I thought I’d explain how I did this so that anyone searching for it would find the information in one place.

I’m going to focus on command-line applications, though I expect the tips will also be useful for those of you looking to make macOS GUI applications.

Last night, I gave a talk at the very first Reproducibility and Productivity in Data Science (“RAPIDS”) meetup on the relative unimportance of code, the state of data management, and what we at Prodo.AI are trying to do about it.

As (almost) always, I wrote the majority of the content ahead of time, so if you weren’t there (and I know you weren’t), please take a look. I think you’ll enjoy it.

It focuses on an open-source tool we’ve been building to help us manage our own data problems, Plz, which I also encourage you to check out for all your data science and machine learning needs.

Here’s how it starts:

There’s a misconception that software developers have.

We think software is important.

Because of this, we often focus the majority of our attention towards the code that makes up the software. You know, the Python, or Java, or Ruby that the programmers write. We spend a lot of time grooming it, making it more maintainable, more readable, and generally prettier.

Unfortunately, we spend almost no time at all regarding the data that flows through our programs. Typically we’re content with a few examples for our test cases, a couple of edge cases so that we can verify our systems work in some sort of staging environment… and that’s about it. We tend to look at “production” data when there’s a bug.

This is kind of funny, when you think about it, because the software isn’t important. The data is.

Let me know your thoughts, and if you do try Plz, please file as many issues as you like. We want to help bring data science into the 21st century.

Check it out.

Originally posted as a Twitter thread.

I’ve been thinking a lot about serverless architecture and I’ve realised what bugs me about it.

This is gonna be a long one. Not gonna lie, I wrote a draft first. If I hadn’t, this thread would end right before it got interesting because I’d get distracted by a butterfly.

At its heart, serverless/FaaS/lambda/whatever-you-call-it works for me because it ties action to cost. The more I do (or the more inefficiently I do it), the more I pay. More users, more money. Gojko Adzic wrote about this years ago. It’s not new.

The problem, I find, is that in doing so, it breaks your application apart. Now we have many applications. They all work with HTTP, or message queues, or some other data interchange layer I don’t care about when I’m designing functionality for a user.

I was listening to Ron Jeffries and Chet Hendrickson on the Cucumber podcast, and I heard something that helped me reframe agility and craft in a way that was very meaningful to me.

He was prompted by Sal Freudenberg talking about asking for permission to use techniques such as test-driven development, rather than treating it as part of the job.

Chet Hendrickson: I think you’re right; it seems odd that we ask permission. We believe we have to have permission to do good work. I believe that on the first day of a new greenfield project, the codebase is perfect. It does exactly nothing, and it does it in zero lines of code.

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.