PyCon UK 2023 Raw Notes
Notes on this year's PyCon UK conference held in Cardiff: talk highlights, quotes & thoughts.
Due to a combination of the Covid lockdown(s) and having 2 children it sure has been a long time since I attended an in-person Tech Conference.
I was lucky enough this year to attend the first 2 days alongside my colleague Modasser from Doist, who traveled over from Bangladesh for the weekend for his first conference.
I ended up taking a fair few notes and getting a lot out of it, so wanted to share the highlights below. Where possible I've added links to the videos that PyCon have kindly made available on their YouTube channel.
Beforehand though I'd like to extend the warmest thank you to all the organisers and volunteers who made PyCon UK happen. It's the friendliest conference I've been to by far, we were well looked after and the talks put on explored a wide range of interesting subjects.
Also there was a rather ridiculous quantity of yummy Welsh cakes!
Friday
Keynote: Technical Neglect by Kevlin Henney
Kevlin is a rather excellent speaker based in nearby Bristol who did an excellent talk on technical debt, the terminology we use for it and how we can approach resolving it.
He argued that we don't have a debt problem, we have a neglect problem.
Software structure deteriorates as we add to it, unless work it done to maintain it.
Maintenance was the key word. It isn't "fixing bugs", it is "housework".
The first design is almost never the best possible. Flexibility to improve it is essential
Shipping first time code is like going into debt. A little debt is fine, it speeds up development, so long as it is paid back promptly with a rewrite.
Technical debt is often an intentional trade off, it's not necessarily the debt.
The problem is unmanaged debt.
With technical neglect developers end up programming in the past, working with incomplete knowledge, slowed down, shackled
New features depend on the underlying quality of technical excellence they are built on. Continuous attention to technical excellence is key to moving quickly.
I circled this one in my notes a few times 🙂
Developers are drawn to complexity likes moths to a flame, usually with the same result.
Do the simplest thing that works. It is so rare that architecting for future requirements leads to a positive result.
Domain Driven Design by David Seddan
David from Kraken at Octopus Energy did a fantastic introduction to DDD with a focus on building a domain model in any engineering context.
He talked about how often there is a linguistic divide between domain experts and developers, leading to confusion, misunderstandings and misimplementation.
Domain Driven Design at its core is a way of coming up with a conceptual model that is shared between domain experts and developers, where the language is ubiquitous and used consistently across product, engineering, support, even in the backend code and the way we name things on the UI.
David discussed 3 key steps which you can start doing straight away without company buy-in.
Embrace Pure Concepts
- Start with a data model, a non technical model which looks a little like an ER diagram that simply explains the properties of objects and relationships between them. The data model should form the basis of how the system is discussed and implemented
- When starting a new feature or project, start with drawing out a data model
Explore Alternatives
- Before writing any code, keep iterating over the data model thinking about how it could be improved, simplified, anything that may be missing or unclear
Seek Early Review
- Once you have a data model get it infront of stakeholders as soon as you can, and before implementing. They can help validate, suggest missing information or inconsistencies and help improve the design before proceeding
David then went on to discuss how, from a coding perspective, we can isolate the domain to separate out the boilerplate code from the domain language, so our code reads in a way that allows us to more easily understand the business rules being executed. (Talking through layered architecture, onion architecture, and refactoring code to abstract away anything not related to the domain into separate functions)
Adventures in Unicode by Alistair Lynn
A fascinating, Destroy All Software style talk on unicode, how it treats special characters and the strange behaviour you get with things such as reversing unicode strings, or counting their length.
For example the 🇪🇸 Spanish flag emoji is two unicode characters (U+1F1EA, U+1F1F8), which is ES, the country code for Spain.  If you string reverse the flag it becomes 🇸🇪, the Swedish flag which consists of these characters: U+1F1F8, U+1F1EA, which are SE.
I can't do justice to the talk here so I'd highly recommend watching the video, it's a short talk.
The main takeaway for me is the concept of "Grapheme" symbols instead of characters, which are, in unicode terms, the logical grouping which prescribes meaning to the individual unicode characters. Using the grapheme library for Python allows us to treat special unicode symbols as 1 character, no matter how many underlying characters they consist of. The downside being that the library is much slower then using standard string functions.
Interactive web pages with Django or Flask, without writing Javascript by Coen de Groot
An interesting exploration into using HTMLX with Django / Flask to generate web pages that queries a backend Python API and refreshes the UI without writing Javascript.
Similar to Blazor on the .Net stack, or less recently the ASP.Net Razor syntax, for building interactive UI using C# instead of Javascript.
More something that's useful to be aware of, especially if bootstrapping a demo UI with a quick turnaround.
Saturday
Keynote: If you can’t give me poetry, can’t you give me poetical science? by Emily Holyoake
A fantastic, engaging talk from Emily on the transition theatre went through during Covid lockdowns, the types of digital theatre that formed and interestingly a transition to interactive fiction for herself using the Ren'Py visual novel engine.
A wider point the talk discussed was what exactly "theatre" is, can you still call it theatre if it is online (but live?), what if it isn't live in the traditional sense (like a visual novel?).
Investigating Environmental issues with Python by Mx Chiin-Rui Tan
An excellent, blood boiling talk if you're an environmentalist hippie like me; this one broke down how many Sewage Storm Overflows polluted our waterways in the UK (spoiler: 14,500 times sewage was legally spilled in 2022).
The talk itself showed how to use Jupyter to pull a set of data, cleanse it then then visualise it on a map.
The big takeaway (apart from the continuing failures of the UK Government) was that "Data Science is 80% cleaning data".
How to keep your database happy by Karen Jex
If you are a responsible for a Postgres database you MUST WATCH THIS TALK.
I don't think I've ever seen such a useful dump of key information in such a short space of time. Karen went through how to change the default Postgres settings to be production ready, what each setting meant and how to work out what the values should be based on your environment.
The Sound of Your Footsteps can Predict for Dementia by Debayan Das
The most mind blowing talk for me: Debayan talked through how his company had worked using research into the correlation between reduced mobility and dementia to build a device that could listen to the footsteps of a care home resident, then would out if there is a deterioration over time of their stride / gait that could be indicating an increase fall risk and/or progression towards dementia.
A rare utopian use of AI and machine learning, it was fascinating to hear the process they went through and the types of data they collect.
Subclassing, Composition, Python, and You by Hynek Schlawack
I'm a huge type system nerd, hence my ongoing love of F# and excitement at the contents of the Python typing library.
Hynek's talk then was of great interest, discussing with examples why composition over inheritance can often make sense.
Notably, when it comes to base and sub classes:
- The leakiness of Python base classes (their ability to modify sub-classes through
self, the lack of accessibility modifiers in Python) - bidirectionality - How a hierarchy of base and sub classes can make it difficult to reason about the behaviour of an object - increasing complexity
- Conflicts and override behaviour of subclasses
- Having to remember to call
super().__init__() - Tighter coupling, harder dependency inversion for testing
With the suggestions being:
- Using
typing.Protocolto add structural subtyping where implementing code doesn't have to explicitly implement the behaviour, but you have still created a contract of behaviour like a base class would - Using composition (like the strategy pattern) to create unidirectional relationships where it's clearer what is happening. It also creates looser coupling, removes any hidden hierarchy or need to be aware of super classes
Caveated with, as always, "It Depends", with scenarios where inheritance does make sense. Â Hynek's argument was we should aim for composition over inheritance in most situations.
Notes and examples from Hynek can be found here
Young Coders Presentations
A note here: PyCon UK had a few tracks for those new to development: one was DjangoGirls (a workshop intended to help women learn web development with no prior experience) and the other was Young Coders who had a day of hacking away at projects that they then got to stand up and present to us all.
Was glad to see this presentation got the largest applauses of all that weekend.
Closing Thoughts
Overall an excellent conference, I wish I was able to stay for the Sunday and Monday too, next year I certainly will!
I sometimes think about the difference between attending a conference in person vs watching the videos afterwards, after all most conferences record and distribute their sessions for free. PyCon UK put forward an excellent case study in why attending in person is valuable: the talks were deeply engaging, I got to meet plenty of fellow Python devs & it was all very well organised.
There's also something about being able to focus in and properly absorb the content in a way you'd struggle to do watching it on YouTube.
Also I got an Octopus (which then went immediately to my daughter Ellie, who adores it) from the Kraken team, along with a tonne of Python related stickers, so I'm happy.