I've been speaking at conferences and user groups since 2008. I have given talks at conferences all over the world, from high-level keynotes aimed at a wide audience to deep-dive technical talks about REST APIs and hypermedia.
If you'd like to invite me to speak at your conference or meetup, please drop me an email to firstname.lastname@example.org and let's chat.
Here are the talks I'm giving at conferences and user groups in 2019. If you're interested in inviting me to speak about something else, get in touch.
- The Cost of Code
- The Art of Code
- How To Be a Rockstar Developer
- Architecture: The Stuff That's Hard to Change
- Apps, Algorithms and Abstractions: Decoding our Digital World
- Life, Liberty and the Pursuit of APIness: The Secret to Happy Code
- Ctrl-Alt-Del: Learning to Love Legacy Code
- Domain Architecture Isomorphism and the Inverse Conway Manouevre
- From Amdahl to Zipf: Fundamental Laws of the Physics of People
- The Web That Never Was
- Real-world ReST and Hands-on Hypermedia
The Cost of Code
Coders code. That’s what we do. We write functions and classes and modules, and we conjure amazing systems out of thin air. Electrons dance at our command; with a few keystrokes we can solve the most complex calculations, find hidden patterns in the data of our everyday lives, and send information flying around the planet at the speed of light.
The world uses our code to book flights, pay taxes, talk to friends and family… and before too long, our code might be driving cars, diagnosing illnesses and convicting criminals. Code runs the world. And when our code goes wrong, the solution is almost always… more code. We ship millions of lines of code every day – and, in these days of smartphones and networks and IOT, a single line of code could be running on millions of devices within minutes of us deploying it to production. But have you ever stopped to consider the real cost of those lines of code? Your code might end up running in production for years, maybe decades.
It’ll become one small part of a giant global codebase that’s using literally trillions of processor cycles and hundreds of billions of kilowatt-hours of electricity every year. A codebase that’s hiding countless vulnerabilities, flaws and dependencies. A codebase that’s driving users to buy millions of new laptops and smartphones and tablets every year because the old ones are too slow, or won’t run the latest apps. A codebase that is literally changing the world we live in - and not always for the better. In this talk, we’ll take a stark, sobering look at the real cost of the code we’re shipping every day. What’s the real cost of code - to our organisations, to our society, to our environment? How can we help our teams and users understand that cost? And what can we do to reduce it?
The Art of Code
Software and technology have changed every aspect of the world we live in. At one extreme are the ‘mission critical’ applications - the code that runs our banks, our hospitals, our airports and phone networks. Then there’s the code we all use every day to browse the web, watch movies, create spreadsheets… not quite so critical, but still code that solves problems and delivers services.
But what about the code that only exists because somebody wanted to write it? Code created just to make people smile, laugh, maybe even dance? Maybe even code that does nothing at all? Code that was created just to see if it was possible?
Join Dylan Beattie - programmer, musician, and creator of the Rockstar programming language - for an entertaining look at the art of code. We’ll look at the origins of programming as an art form, from Conway’s Game of Life to the 1970s demoscene and the earliest Obfuscated C competitions. We’ll learn about esoteric languages and quines - how DO you create a program that prints its own source code? We’ll discover quine relays, code golf and generative art, and we’ll explore the phenomenon of live coding as performance - from the pioneers of electronic music to modern algoraves and live coding platforms like Sonic Pi.
How To Be a Rockstar Developer
We’ve all heard about the idea of the ‘rockstar developer’ - maybe you’ve heard your boss talk about hiring a ‘rockstar’, or maybe you’ve seen the job adverts looking for ‘rockstar developers’ on IT job boards. But what if EVERYBODY could be a rockstar developer?
In 2018, Dylan Beattie created Rockstar, an esoteric programming language designed for creating programs that are also rock song lyrics. Rockstar was initially created as a joke - a parody specification that combined features from programming languages like VBScript, Perl and Ruby with lyrical conventions from classic rock artists like Bon Jovi, Meat Loaf and Deep Purple. Then people started submitting issues. Then they started submitting pull requests. Then somebody created an implementation… and another, and another.
Before long, Rockstar was on the front page of Hacker News, the front page of Reddit, and was even featured in Classic Rock magazine. What started as a joke had become a fully fledged open source project - and so, in 2019, Dylan and a few dedicated ‘Rockstar developers’ set out to create a formal reference implementation, complete with a parser, an evaluator, a specification and change control process, and - of course - lots of awesome Rockstar swag. In this talk, Dylan will share ideas and insight from working on the Rockstar project. It’s partly a talk about programming language design; partly a talk about running an open source project - and partly the true story of what happens when you try to implement a programming language that was invented in a bar.
Architecture: The Stuff That's Hard to Change
We’ve all heard of the idea of ‘software architecture’. We’ve read books about domain-driven design and event sourcing, we’ve been to conferences and learned about micro services and REST APIs. Some of us remember working with n-tiers and stored procedures; some of us are still using them. But the role of a systems architect is still one of the most misunderstood things about the software development process. What does an architect actually do? If you’re working with a systems architect, what can you expect from them? And if you are a systems architect, what is your team expecting from you?
In this talk, Dylan Beattie will share his own insights into the idea of architecture as part of a software development process. We’ll explore some popular architectural patterns and processes – and a couple of obscure ones as well – and look at how, and when, you can incorporate those patterns into your own projects. We’ll talk about how the idea of software architecture has changed over time, and share some tips and advice for developers who find themselves working with architecture as part of their role.
Apps, Algorithms and Abstractions: Decoding our Digital World
It’s a familiar scenario. You’re on the train, your phone goes ‘ping’, you take it out of your pocket and hey — someone sent you a message! Awww… it’s a picture of a cat doing something funny. You send back ‘LOL’, you put your phone back in your pocket – but have you ever stopped to think about what’s actually involved in making that happen? Inside even the most basic smartphone there are literally hundreds of innovations, algorithms and inventions — but how do they really work? How were they developed? And what’s the next generation of algorithms and applications going to look like?
In this talk, we’ll take a deep dive into the technology behind those everyday experiences, and demystify the algorithms and abstractions that make our digital world go round. We’ll talk about cellular data networks, signal processing, the fundamental principles of filesystem design, compression algorithms, and even a bit of quantum physics. Whether you’re a programmer, a product owner or just somebody who loves using the latest tech, after watching this talk you’ll never look at your phone in quite the same way again.
Life, Liberty and the Pursuit of APIness: The Secret to Happy Code
We spend our lives working with systems created by other people. From the UI on our phones to the cloud infrastructure that runs so much of the modern internet, these interactions are fundamental to our experience of technology - as engineers, as developers, as users - and user experiences are viral. Great user experiences lead to happy, productive people; bad experiences lead to frustration, inefficiency and misery.
Whether we realise it or not, when we create software, we are creating user experiences. People are going to interact with our code. Maybe those people are end users; maybe they’re the other developers on your team. Maybe they’re the mobile app team who are working with your API, or the engineers who are on call the night something goes wrong. These may be radically different use cases, but there’s one powerful principle that works across all these scenarios and more - and it’s called discoverability.
In this talk, we’ll draw on ideas and insight from user experience, API design, psychology and education to show how you can incorporate discoverability into every layer of your application. We’ll look at some real-world systems, and we’ll discuss how how discoverability works with different interaction paradigms. Because, whether you’re building databases, class libraries, hypermedia APIs or mobile apps, sooner or later somebody else is going to work with your code - and when they do, wouldn’t it be great if they went away afterwards with a smile on their face?
Ctrl-Alt-Del: Learning to Love Legacy Code
The world runs on legacy code. For every greenfield progressive web app with 100% test coverage, there are literally hundreds of archaic line-of-business applications running in production - systems with no tests, no documentation, built using out-of-date tools, languages and platforms. It’s the code developers love to hate - it’s not exciting, it’s not shiny, and it won’t look good on your CV - but the world runs on legacy code, and, as developers, if we’re going to work on anything that actually matters, we’re going to end up dealing with legacy. To work effectively with this kind of system, we need to answer some fundamental questions. Why was it built this way in the first place? What’s happened over the years it’s been running in production? And, most importantly, how can we develop our understanding of legacy codebases to the point where we’re confident that we can add features, fix bugs and improve performance without making things worse?
Dylan Beattie worked on the web application stack at Spotlight (www.spotlight.com) from 2000 until 2018 - first as a supplier,then as webmaster, then as systems architect. Working on the same codebase for nearly two decades has given him an unusual perspective on how applications go from being cutting-edge to being ‘legacy’. In this talk, he’ll share tips, patterns and techniques that he’s learned from helping new developers work with a large and unfamiliar codebase. We’ll talk about virtualisation, refactoring tools, and how to bring legacy code under control using continuous integration and managed deployments. We’ll explore creative ways to use common technologies like DNS to create more productive development environments. We’ll talk about how to bridge the gap between automated testing and systems monitoring, how to improve visibility and transparency of your production systems - and why good old Ctrl-Alt-Del might be the secret to unlocking the potential of your legacy codebase.
Domain Architecture Isomorphism and the Inverse Conway Manouevre
Most of us have heard of Conway’s Law: ‘Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations’. Once you accept that systems end up reflecting the structure of the teams that create them, it’s clear why many software projects don’t go according to plan. Your architect says you’ll use an API instead of direct database access - but then you sit your developers next to your DBA and give them a deadline; what do you think happens to your API? Or you have a DBA in London working with an app developer in Prague and a web team in Kyiv, and then wonder why your system’s communication layers are causing performance problems…
In this talk, we’ll look at communication structures and how those structures affect the outcome of the systems you’re building. We’ll discuss how to apply design patterns to your teams as well as your code, and how to sell the idea to your boss before you start moving desks around.
From Amdahl to Zipf: Fundamental Laws of the Physics of People
It’s all too easy to think software is magic - but it’s not. Most of the time, it’s not even sufficiently advanced. Like everything else in our world, the people you work with and the products they build are subject to the fundamental laws of nature. Based on an original idea by Pieter Hintjens, this talk explores the laws of our universe - from the fundamental laws of physics to the eponymous laws found in the IT industry.
Dylan Beattie shows you how Newton’s Laws of Motion can explain why big organisations struggle with agile development, how the Equivalency Principle explains why so many startups fail, and why Heisenberg’s Uncertainty Principle makes it so hard to estimate and report on your software projects. Finally, we’ll look at three of the oldest laws of software engineering - Moore’s Law, Amdahl’s Law and Conway’s Law - and how they can prove that if you don’t stop having meetings, the internet will stop working.
The Web That Never Was
The story of the web is a story about freedom. It’s a story about information, breaking down barriers, and creating new ways for people to communicate, collaborate and share their ideas. It’s also a story that has as much do with marketing, money and meetings as it does with research and innovation. It’s a story of mediocre ideas that succeeded where brilliant ideas failed, a story of compromises, rushed deadlines and last-minute decisions. And it could so easily have been very, very different.
What if IBM had hired Digital Research instead of Microsoft to develop the operating system for their first PC, way back in 1980? What if Marc Andreessen and Jim Clark had gone to work for Nintendo in 1993 and never founded Netscape? What if one of the team at CERN had said ‘Tim, won’t it sound a bit silly if everyone spends the next 50 years saying double-you-double-you-double-you all the time’?
So strap in, hold tight, and join us on a journey through… the web that never was.
Real-world ReST and Hands-on Hypermedia
So you’ve built your HTTP API, and now that it’s live, you’re suddenly dealing with a whole new set of problems. Do you really need to PUT the entire customer object just to change someone’s email address? Why does it take you 25 API calls just to render a shopping cart? How do you find the bottlenecks when just drawing a web page requires 50 HTTP requests? What happens when one of your API consumers accidentally tries to GET your entire customer database?
In this talk, we’ll look at the problems of running ReSTful APIs in the real world, and the architectural patterns that exist to help us solve those problems. We’ll talk about hypermedia - how it works and why it matters. We’ll look at resource expansion, and how it can reduce your server workload and speed up your client applications. We’ll talk about how to implement PATCH properly, how to handle security and authentication for your APIs, and what tools and services exist to help you design, deliver and debug your HTTP APIs.