Observations about the human at work, building software.
| Date | Event | Location | Title | Materials | |
|---|---|---|---|---|---|
| ⏳ Nov 2026 | Heapcon 2026 | 🇷🇸 | Belgrade, Serbia | Software Estimates and the Illusion of Control | Schedule |
| ⏳ Oct 2026 | TDC 2026 | 🇳🇴 | Trondheim, Norway | Did My Deploy Degrade Production? Detecting Bad Deploys with Math | |
| Jun 2026 | Voxxed Days Luxembourg 2026 | 🇱🇺 | Mondorf-les-Bains, Luxembourg | Did My Deploy Degrade Production? | Video Slides Schedule |
| May 2026 | PyCon Italia 2026 | 🇮🇹 | Bologna, Italy | Stop asking me how long it will take | Slides Schedule |
| Apr 2026 | VoxxedDays Amsterdam 2026 | 🇳🇱 | Amsterdam, Netherlands | Why smart developers write silly code | Video Slides Schedule |
| Mar 2026 | Codemotion Roma 2026 | 🇮🇹 | Rome, Italy | It'll Take Two Weeks: Why Software Estimates Are a Pipe Dream | Slides Schedule |
| Nov 2025 | J-Fall 2025 | 🇳🇱 | Ede, Netherlands | Your Brain Is Sabotaging Your Code, But We Can Outsmart It | Video Slides Schedule |
| Oct 2025 | Swiss Python Summit 2025 | 🇨🇭 | Rapperswil, Switzerland | Software estimation: False sense of certainty | Video Slides Schedule |
| Jun 2025 | Voxxed Days Luxembourg 2025 | 🇱🇺 | Mondorf-les-Bains, Luxembourg | Software estimation is a delusion | Video Slides Schedule |
| Apr 2025 | PyCon Austria 2025 | 🇦🇹 | Eisenstadt, Austria | Software Estimation is a Delusion (or Maybe Just a Misused Tool) | Slides Schedule |
| Mar 2025 | Meetup of Meetups | 🇸🇮 | Ljubljana, Slovenia | Why do developers like to argue so much? | |
| Sep 2019 | Python Meetup Ljubljana | 🇸🇮 | Ljubljana, Slovenia | Applying Marketing Techniques to Developers' day-to-day | Slides |
| Oct 2017 | Python Meetup Ljubljana | 🇸🇮 | Ljubljana, Slovenia | Fluent Python: How to write Python as if it were your first programming language | |
| Apr 2017 | WebCamp Ljubljana 2017 | 🇸🇮 | Ljubljana, Slovenia | Conquering JSONB in PostgreSQL | Video Slides Schedule |
| Oct 2016 | StripeCon 2016 | 🇸🇮 | Ljubljana, Slovenia | 10-ish Things I Learned from Programming an E-Shop for a Year | Slides |
Interested in having me speak at your event? Here's what I talk about.
Of course, we learned statistics. We went to university, there was a course, there was an exam, we passed it. But we don’t really use it at work… when writing code, except…. that we love proving a point with a good chart. That would be a harmless quirk if we were bakers, but our code now decides who gets a loan, whose claim gets approved, when the doctor sees you. Software engineers have somehow become some of the most consequential decision-makers in society, and we cope with it by pretending we’re just typing.
What makes us really calm when deploying code to production? A green test suite with 100% test coverage. But then we merge, deploy, go to lunch… and somewhere out there a user does something so creative that production goes down anyway. There’s no amount of tests that makes the bugs go away. We wish test coverage was a magic number, just like we want to believe in the power of other metrics (LOC, story points, DORA, …). This talk grapples with two questions: what our tests actually catch, and why we keep reaching for these numbers.
Software estimation has turned into ritualized guessing. We are pushed to estimate, but nobody is teaching us how to do it. Our estimates are deemed crucial, but the project’s specs keep changing mid-work. It’s time we abandoned long-term estimates and focus instead on managing project risks.
There’s an entire field dedicated to getting people to read what you write, developers just aren’t in it. We’re trained in precision and completeness. Marketers know people only skim, they decide in 3 seconds, and only care about what’s relevant to them. This talk steals their tricks for standups, PRs, proposals, and that email nobody answered.
When you deploy some code, do you know its impact on your production stats, like memory usage, request duration, error rates? If you wanted to know if your code improved or deteriorated the speed of SQL queries, would you know where to get this data? In this talk, I’ll walk through a real-world system we built to automatically detect pattern changes to metrics without having to set thresholds manually. (And with no LLMs.)
Knowing about cognitive biases is like debugging our brain. Devs spend tons of time fixing bugs in code, but biases are the mental bugs that mess with our decisions. They make us overconfident, they make us ignore users and fight for bad ideas. But it needn’t be this way.
Every API is doing its own thing. Authorization, headers, rate limiting (devs are creative people, so we just like to invent our own rules). After integrating 40+ APIs into the same product, I have a lot to say about handling failures of remote APIs.