Thomas Thwaites is a designer with an interest in science and technology. He was a student at the Royal Academy of Arts in London when he decided to build his own toaster. He bought a mass produced one for £3.94 and started by reverse-engineering it. To his dismay, Thomas discovered his toaster consisted of about 400 components made of over 100 different materials. Thomas’s TED Talk recounts his experience of obtaining and forming just a few of these materials for his homemade toaster. Time elapsed? Nine months. Distance traveled? Over 1900 miles. Total production cost? Nearly £1200.
Toasters and Text Messages
I can appreciate Thomas’s dismay at the complexity of an everyday convenience. Ten years ago, I was working in a R&D lab where a colleague and I spent 2 weeks trying to manually send an SMS with a laptop. From a data perspective, an SMS message is very simple. It has a message body, a ‘from’, and a ‘to’ value. If these values are presented to a mobile network operator, it should be a simple matter of addressing the message to the correct device.
The SMS modem we were working with provided access to the GSM network, but little else. We had to manually produce an encoded SMPP message and interact with the modem through the serial port. It was not unlike Thomas Thwaites trying to smelt his own iron: complicated, confusing, and frequently resulted in failure.
We persevered and eventually had a working solution which we were able to encapsulate in a C library for other developers to use. It was my first job and the first thing I had ever made for other developers.
The Great Git Migration
It is an enormous pleasure to build something that other people use on a daily basis. However, just like Thwaites’s toaster, creating something that is both incredibly easy to use and contains a lot of complexity is quite difficult. Taking months or years of engineering and distilling it to a simple interface is no easy task. I suspect my SMS API was a lot like Thomas’s finished toaster, not quite ready for the public.
I’ve helped developers achieve things through software for most of my career. One particularly notable occasion was during a migration to Git at Codehouse. The team was accustomed to using Microsoft’s Team Foundation Server for source control, and the adoption of Git meant learning a whole new approach to managing code.
It was a lot of fun coaching the team on using branching and merging to better manage their work, and this made the process of shipping code much easier. What has always amazed me is the ability of a developer to take some existing tools and create something that surprises me. It wasn’t long before we were using commit metadata to automate releases.
From The First Twilio Powered Text, To Joining The Team
My first contact with Twilio was late in 2012, so I thought I’d try out the platform. Having moved on from C over the years I opted to try out the Twilio Ruby Gem to send an SMS. With a clear memory of how long this had taken me in my first job, in the space of only a few minutes, I had made my phone light up with its characteristic ‘ping’. As it happens, I simply provided a message body, a ‘from’, and a ‘to’ value and Twilio elegantly took care of the rest.
Soon, I had a working IVR system that I was able to A/B test. With a little more tinkering I built an online ‘ice breaker’ that randomly connects pairs of people in a room together on a conference call. Twilio has much more in common with a store bought toaster than Thomas Thwaites’s home made version, or my efforts to build my first API.
What excites me most about joining Twilio as a Developer Evangelist is the surety that I’ll be able to point a developer to an aspect of the API assured that I will be surprised by the creativity and imagination that results, after all – Twilio is clearly not a homemade toaster!