PyCon Australia

This talk is for Python users who work with time series, messy data, or production data workflows and want a practical case study rather than a theoretical forecasting talk.

What does it mean to be productive? If you work in software development that generally means shipping code, or at least changes to code. There’s always been a tension in how to measure the output of a software developer though, and that’s partly due to the at least partially creative nature of the work we do. So when a tool comes along and promises to make you more productive, how do you assess that? Yes, this is a talk about LLMs. It’s a talk about the effects of LLMs and what they mean for people in the software development industry. We feel like there’s a discussion to be had around what the role of a software developer was, what it is now, and what it could look like in the future. Productivity is a term that is used a lot but that has a meaning that can be hard to pin down. LLMs make some people more productive. They make other people less productive. They make other people feel more productive even when they aren’t. We’ll be talking less about the LLMs themselves, and more about their relationship to how software engineers work or are expected to work, and what it is we’re actually meant to produce. Join us for a discussion of what it means to be productive, not just to us as software engineers but to everyone.

Have you ever wondered what it actually takes to deploy your Python/Django or any application to Kubernetes - and build a platform around it? Or if you already have one, whether you'd build it the same way in 2026? This talk introduces Kubernetes as LEGO: building a real platform one block at a time, starting from raw primitives, layering Helm and Kustomize where they genuinely earn their place, and finally writing a custom operator in plain Python using kopf. At each step, we ask: Does this next block solve a real problem, or create a new one? You'll leave with a composable mental model and a sharper instinct for when to stop. Platform engineering has a complexity problem. The default playbook - install everything, abstract it all away - produces platforms that are expensive to operate and painful to debug. This talk is for Python developers who are Kubernetes-curious but find the ecosystem overwhelming, and for engineers already using Kubernetes to visually reflect on and revisit their experience with it. The talk progresses through three levels, each justified by what the previous one couldn’t handle: - Level 1 - Raw primitives: Pods, Deployments, Services, ConfigMaps. A grounded walkthrough of what plain Kubernetes already gives you - and how far a Django application gets before any extra tooling is needed. - Level 2 - Helm and Kustomize: Helm for consuming and distributing packages; Kustomize for environment overlays of the apps you own. Where each shines, where they create friction when combined, and the hybrid pattern the industry has converged on. - Level 3 - Python operators with kopf: when the built-in API can’t express your domain logic, Custom Resource Definitions (CRDs) let you extend it. kopf maps Kubernetes event handlers to Python decorators - making operator development immediately legible to any Python developer, no Go required. The through-line is a single question asked at every layer: what problem does this solve that the previous level couldn’t? That question is the decision framework attendees take home. No prior Kubernetes experience assumed; familiarity with Python or Django is helpful.

The talk begins by introducing the use case: an AI-assisted IT support ticket resolution system that takes a ticket’s title, description, comments, and log files as input and produces a one-shot resolution. This application serves as the running example throughout, but the framework applies to any domain where RAG is used to ground LLM responses in a knowledge base (e.g. customer support chatbots, travel agency chatbots, internal knowledge assistants).

The tech industry is notoriously fixated on solving things. All products are "solutions", all problems are fixable, all friction is anti-productive waste that deserves to be eliminated. We've hacked our workflows and our homes and our lives, automated the boring stuff, and Gotten Things Done. Throwing LLMs into the mix has only amped up this rhetoric. But not all friction is waste. Some of the things that we call "problems" are doing the necessary work of teaching us something, building our capabilities, and raising important opportunities to ask questions and double-check assumptions. Optimising this type of problem away creates a short-term win, but the longer-term losses are often much harder to see. We've also taken steps into a landscape where many everyday acts of problem-solving are being delegated to webs of AI "agents", who will autonomously "decide" which things are problems, solve them on our behalf, and ping us to tell us when they're done. But how often do they create additional problems as they solve others? How well can humans understand and build on the "solutions" that emerge? And what does it do to the development and maintenance of human expertise along the way? This talk digs into why problems, friction, and "inefficiency" are our some of our greatest allies, especially with AI in the picture. We'll look at what researchers like Robert and Elizabeth Bjork and Renée Gosline have shown about the importance of friction, discuss how to distinguish problems worth solving from problems worth preserving, and interrogate the reasons why we are compelled to solve certain problems in the first place. You'll leave this talk with ways determine which problems deserve your tools, and which ones deserve your time. (With apologies and thanks to Allie Brosh for the title.)

Changes are scary. Changes in production are scarier, especially if you haven’t done them before. Ideally, you’d have pipelines and staging environments, and everything just gets handled automatically. Unfortunately, reality isn’t always ideal, and you’re faced with having to “yolo” a change; implementing something without waiting for everything to be perfect. The aviation industry has spent decades operating safely in environments where not everything is known in advance. It relies on shared attitudes, behaviours, and simple checklists to help people make good decisions under pressure. In this talk, I’ll draw on those ideas and apply them to platform engineering, looking at how to recognise when to commit to a change and when it’s safer to abort and try again. This talk is aimed at SREs, Platform Engineers, or anyone who works on a production “thing”. It is a high‑level, conceptual talk that bridges two domains, aviation and platform engineering, and focuses on decision‑making and safety when conditions are less than ideal.

At Atlassian, we take accessibility seriously enough that we have entire teams dedicated to it. There are experts on hand to provide feedback on designs, and answer questions about implementation details. There's a team that runs audits of new features before they're launched. It's honestly pretty good. But obviously not everyone has the resources available for this kind of setup. So what can you do instead? I'm going to talk you through a range of tools and processes that we use to improve the accessibility of our products, what each does well, where they fall short, and what they cost to implement. You can then use this information to figure out which solutions best fit your particular situation, and how you can get the best bang for your accessibility buck.

This talk goes beyond just detecting objects in an image: I cover the realities of hand annotating hundreds of training images, transforming model predictions into calibrated target co-ordinates, inferring scores from geometry, wrangling with validation, and making the whole thing usable in the field.

Training people (and ponies <3) to problem solve under pressure. A discussion on neurorigidity vs neuroflexibility during emergency response. It will expand on how different kinds of incidents, working styles, experience levels, team structures etc create different needs. The speaker has spent 8 years as an SRE, DBRE and Support Engineer working with major New Zealand and international companies, responding to P1 incidents that affected millions of people. She has also spent 20+ years as an amateur trainer of horses. I want to talk about training people to problem solve under pressure - and I’m going to compare and constrast training SREs with training horses. Spoiler alert - its very similar! Many of the tradeoffs are the same. Here are the general headings of what I will talk about - neurorigidity and checklists, vs creativity and neuroflexibility - skills based runbooks vs specific problem resolution runbooks - low context vs high context problem solving - automation/automatic responses - planned one off big bang migrations All of these things have really interesting tradeoffs. Different kinds of incidents, working styles and experience levels, team structures etc create different needs. It will have lots of fun anecdotes and also cute pictures of ponies

Dictionaries are one of the first tools Python developers reach for: fast, flexible, and easy to use when building something new. But when do they stop being enough? And when it's easy to generate data classes and classes, how do you know if that structure is actually useful?

Before the advent of Cloud Computing, owning all your servers and keeping them in a server room or a leased datacenter was the norm if not the only game in town. But despite The Cloud having turned into The Hyperscalers, owning your platform from the switch plane on up is still available... and it rocks! I am going to take you on a little tour through a platform stack. At my workplace we own and manage the full stack of our computing platform from booting, OS install, software, networking, service mesh, to our end-user facing application software. We’ve been building this since 1999 on standard Linux foundations with some enterprise-scale solutions judiciously sprinkled in, and we keep it connected to the world with Wireguard and BGP. We do this with 4 people, and we’re having a good time! If you’re sick of Terraform state conflicts, cloud provisioners that never converge, and PAAS offerings that are built for nobody’s real-world requirements, consider joining us on the hand-cranked side of building platforms.

Every team has at least one go-to person that gets others out of sticky situations! Are they being recognised for contributions to building a cohesive team, or getting bogged down in work that isn’t part of their job description? Let’s get stuck into the concept of glue work, and how handling it properly can help your team bond. This talk is geared towards anyone who works with other people! It’s a love letter to those engaging in tasks that often go unacknowledged, and an invitation to those who experience lots of focus time and visible credit. This session revisits the concept of Glue Work as introduced by Tanya Reilly in her talk “Being Glue” from 2019, and presents a five-step framework for more intentional management of such work. I will talk about: - What glue work can look like - Where it exists - Who usually does it and who doesn’t, and how it affects different team members - When it can be a helpful and when it might cause problems - How we can handle it better

This talk explores using skills as a first-class abstraction in your agentic engineering practice. Drawing from real-world experience building an architect agent to navigate enterprise processes, I’ll show what a skill looks like, how skills compose, and what changes when your smallest unit of work is no longer deterministic. I’ll also be honest about the challenges of managing regressions, evaluations, and failure modes that surface within a non-deterministic world.

Every day at 2pm, our microservice crashed. Same traffic patterns, same infrastructure, same code - yet the database deadlocked and our SLA burned. Logs showed nothing. Metrics showed capacity. Something we couldn't see was destroying our system. This is a story about unknown-unknowns: the failures you can't predict because you can't observe them. Join us as we retrace how OpenTelemetry exposed what our existing tools hid, guided by the principles of observability (or "O11y" as we'll affectionately call it). We'll explore: - "The three pillars" of observability - OpenTelemetry Tracing with auto- and manual-instrumentation in Python - High cardinality, high dimensionality, and intelligent sampling - Querying and visualising traces to debug production mysteries Leave knowing exactly where to start instrumenting your own services—and why you should, before 2pm strikes your system. This talk is designed for Python developers who have relied on logs and metrics for production debugging but haven’t yet adopted distributed tracing, as well as SREs who appreciate a good production war story. No prerequisites are required, basic familiarity with Python, HTTP services, and databases is helpful but not required. The session uses a narrative mystery format: a microservice that crashes daily at 2pm despite appearing healthy through traditional monitoring. Through a live dashboard of metrics, a “real” on-call alert, and real-time tracing data, you’ll see how OpenTelemetry tracing solved the mystery. The talk includes staged architecture diagrams, code walkthroughs of Python instrumentation, and live querying of genuinely generated trace data. You’ll leave knowing exactly where to start with OpenTelemetry’s auto-instrumentation (and how to move into manual-instrumentation when you’re ready) in your own services, and with mental models for when tracing succeeds where logs and metrics fail.

Python 3.13 was the first Python version released with a free-threaded mode. Although the default interpreter still utilizes the GIL, it provides provisions that enable us to run a free-threaded version of the interpreter with the GIL disabled. Through this talk, we’ll set up and run the free-threaded interpreter, benchmarking it against the GIL-enabled version for various tasks. We'll assess the impact on single-threaded vs multithreaded code and test the performance across CPU-bound and I/O-bound tasks, aiming to identify scenarios where free-threaded Python excels. For decades, the Global Interpreter Lock (GIL) has been one of Python’s most debated design choices. It simplified memory management while limiting true parallelism. With Python 3.13, that story begins to change. This talk explores Python’s new free-threaded mode, introduced through PEP 703, which allows running the interpreter without the GIL. We will explore how to enable it, how it behaves, and where it makes a real difference. We’ll start with a quick look at the history of the GIL and why removing it has been so challenging. From there, we’ll unpack the key ideas behind PEP 703 and the criteria outlined in PEP 779 that guide its path toward becoming a fully supported feature. The core of the session focuses on hands-on experimentation. We’ll set up and run the free-threaded interpreter, compare it directly with the traditional GIL-enabled version, and benchmark performance across different workloads. This includes CPU-bound and I/O-bound tasks, as well as understanding the trade-offs (especially the impact on single-threaded performance). By the end, you’ll have a clear understanding of where free-threaded Python stands today, when it provides meaningful benefits, and how it might reshape the way Python applications are designed in the near future.

SRE is all about simplicity. So why do so many of us have a copy of The Google Book sitting on our desk? So much of what we build seeks to emulate companies with millions (if not billions) of customers, while we have neither the scale to justify such effort, nor the runway to still be around when we’re finished. This talk asks - does my medium-sized scale up need Chaos Engineering, circuit breakers, and a 10 tier severity matrix… or does it need a spreadsheet? SRE suffers from a rather serious problem. We are a group of people who love working on complicated problems. We want challenges and ways to show what we know about reliability. And when we can’t find them… we create them. This hurts any business. Work that doesn’t help your customers, hurts. But for small start ups and scale ups, it can be fatal. The wrong project can leave you with a lot of burnt runway, fewer customers, and a business that is no longer willing to invest in reliability. Worst of all - none of this is done cynically. Most SREs genuinely want to do good, but need better tools to understand what matters. SREs need to be practiced in the art of understanding what their business needs now, and what can wait. This talk proposes the humble CUJ (Critical User Journey) as the foundation upon which we can practice that art. It will show engineers how to find their product’s CUJs, use them to drive Observability and measurement where it matters, to break the age-old deadlock of prioritisation using language the business understands, and to understand when reliability work can genuinely afford to wait.

Do you ever go to a talk and find that the speaker doesn't talk about quite what you expected? Do you ever wish you could tell them, mid-talk, to talk about something else? Well, this is your opportunity to guide me through my own talk! I'm going to tell you all about FastAPI. Why it's my web framework of choice, what makes it easy to use, develop and test. How it empowers you to focus on the important stuff instead of spending loads of time on boilerplate. There's far too much in one framework to talk about it all in 30 minutes though, so you'll get to vote on which topics I should focus on, which examples should get more detail, and what matters to you. I’ve used a lot of web frameworks over the years. First I was a student and used Flask. Then I was a consultant and used Ruby on Rails. After that, I used Django at a startup. In Big Tech I used Java’s Spring framework. Now I’m the CTO and co-founder of my own startup, and got to pick my own framework to use. So why did I pick FastAPI – one I’d never used before – and why would I recommend it to anyone building a new web app today? As I talk, you’ll be able to vote on your phone, with live results onscreen, to control what talk you get to see. Some of the topics you might encounter in this talk include: - OpenAPI and Automatic Documentation - Typing and the Wonders of Pydantic - How I made this voting interface And if you follow the right path, you might even get to the secret ending and discover my Great Big Secret about All Development Work!

Application security is not getting easier. Despite better tools, more CVEs, and widespread shift-left adoption, vulnerabilities continue to scale with system complexity.

This talk is for those who are interested about the future pipeline of home-grown coders. I intend providing a high-level summary of what sorts of skills underpin the senior Digital Solutions syllabus, as well as personal observations in what skills are being valued and those that are likely to be neglected as students enter tertiary pathways or industry.

In 2025 and 2026 our university rocketry team launched several high-powered 12ft tall competition rockets with a custom Python-based process manager framework.

Girls do not leave STEM once; they leave three times. By being openly honest about my fear, connecting code to real hobbies, and normalising failure out loud, I turn anxiety into curiosity.

At the start of 2026 I decided I wanted to build my own Coding Agent. The goal was to build the tool that would let me do the work of a Software Engineer, but without reading the code.

How do you get teenagers to care about what data they share online? Come along to see how I took a concept that I wanted students to care about and broke that down into hands-on activities.

As AI agents outpace humans in code output, we are entering a time where vibe-coded pull requests are checked in because they look right, even if they have silently re-introduced security vulnerabilities.

Pull request reviews are often the single biggest bottleneck in software delivery. This talk explores why PR queues stall and the practical techniques that can dramatically reduce your time to merge.

Have you got neurodivergent kids who you would like to teach coding to? Let us look at some strategies for designing coding projects for school aged students.

With IDEs like VS Code wanting to autocomplete your entire file, how on earth do we write assessment that actually tests the skill of our students, rather than the skills of Claude?

Python powers the world most critical research, yet the software behind the science often remains hidden. This talk distils four years of insights from Research Software Engineering Stories.

Authentication continues to fail because our systems rely on humans managing reusable secrets. This talk examines why password-based authentication fails and introduces passkeys as a solution.

This talk introduces a novel data pipeline architecture, enabled by an open-source Python library, to solve complex compliance requirements including data encryption and deletion in a single action.

Balancing short-term and long-term objectives during software development forms an underpinning tension which often exhibits during code reviews, sprint planning and prioritisation.

When students can use AI to generate code, explain syntax, and accelerate routine development tasks, the challenge for teachers is no longer just how to assess coding.

Porting a scientific software library from a proprietary language to Python can potentially increase its user base, but the porting process itself can be tedious and error prone.

In October 2025, Python 3.14 was released and with it t-strings, which promise to help python developers write better, and safer python code.

PyConAU Education Track Student Showcase, giving Australian high school students the chance to present their Python projects on the conference stage.

Every few years somebody swears the newest tool will boot developers out of a job. Yet here we are, still coding, still shipping. Come along for a quick tour from COBOL to today LLM powered vibe coding agents.

What does a trauma ICU nurse have in common with an Information Security Officer? More than you would think. This talk charts one nurse unconventional path into cybersecurity.