I was warned, by multiple people, that this would be a very difficult role. Then the person who was supposed to show me the ropes quit two days before I started. On the first day, the tech lead pushed back hard — they can’t add another item to the list. They’ve got too many things going on. They are already working on high priority things that cannot be switched out.

I was working for KFC, in a leadership role, when during the stand-up a problem came up. I had previously worked extensively on the database system there, so I knew that it could be solved easily with a couple of SQL statements. After the standup, the people who were involved with the issue stayed behind as I shared my screen, loaded up DataGrip (this was before I fell in love with neovim) and started rattling out the SQL queries.

I’d not been interviewed very often. For my first job, sure, I sent around my CV to a bunch of places and did a bunch of interviews. I then started my own company and ran that for nearly two decades, everything largely self-taught. After that, because of the peculiar shape of my CV, and “falling between a lot of stools” as a friend pointed out, interviews were… tricky! I remember one such interview a few years ago. He was good at diffusing any anxiety and it was a pretty relaxed interview. He wanted to know if I knew architectural design patterns - a term I hadn’t heard before. He gave me examples, circuit breaker, pub / sub and a third one I can’t remember anymore. I recognised pub / sub and the other one I think - but was not aware of circuit breaker. He explained it to me - something about reducing the risk of a downstream service failing.

In 2008, we all watched Pivotal crash and burn. They’d taken a year and nearly £900k to build a new ticketing system for the fringe. On launch, they realised that it could serve only one customer at a time. We built an interim ticketing system for them over the weekend . It was time for kraya to take a leap. We should take the megabus.com ticketing system to the next level and build a distributed ticketing system that could potentially scale infinitely.

I knew as soon as my phone rang what it was about. It was the same every time. I would drag myself up to answer the phone - my body, my mind screamed at me, but I had gotten good at overriding every instinct through sheer willpower. I could hear the apologetic tone on the other side, and I could recognise some of the voices after a while. I mustered up all of my strength to be and sound as awake as possible. I needed to be professional even if I was still in my underwear.

2008 was a heck of a year for kraya, and for me. We were already operating megabus.com in the UK, USA, and Canada, along with Oxford Tube, the sales website for coach usa - all for Stagecoach. We were also working on the fringe website. We integrated the website with the brand spanking new ticketing system - which cost nearly £900k. We were also hosting websites for Boots, Kellogg’s Food Service and dozens of other clients.

Two ticketing systems. Same client. Same payment provider. We were moving fast — that was the explicit choice, theirs and mine. The kind of fast where you know something will go wrong eventually and you price it in rather than try to prevent it. We’d done the sensible thing and shared the payment code between them — DRY, less surface area for error, obvious call. Then the larger system needed PostAuth. We updated the code, added a scheduled task to catch anything the non-deterministic bits missed, moved on.

In 1999, I was building websites in ASP (before there was .NET) and MSSQL Server. We had a Windows NT server that I had to restart every week — not because of updates, because it would get slower and slower until a restart was the only thing that would fix it. We had one ADSL connection coming into the office and three of us. I wanted to share the internet. Windows NT didn’t support it cleanly — it had a way, but it was clunky enough that no internet was arguably better. We’d paid hundreds of pounds for it.