
Adele Carpenter
Software Engineer at Trifork Amsterdam
Amsterdam, The Netherlands
Actions
Adele is a Software Engineer and Consultant at Trifork Amsterdam where she is working on systems for the educational sector. Most of her work day is spent in the JVM/Spring and React ecosystems, although increasingly she plays a pivotal role as trusted advisor to Trifork’s customers.
Adele is an experienced international speaker, having spoken at multiple editions of NDC, goto, Devoxx and JavaZone. As a speaker, she uses her exposure to real-world customer projects, experiences outside of tech and passion for story-telling to distill complex ideas into their essential parts. All with an air of good humour.
When she’s not at her computer or on stage, you can find her in the gym pumping some serious iron as she pursues the sport of powerlifting.
Links
Area of Expertise
Topics
10 Things I Hate About Java
Using Java as an everyday language can be absolutely infuriating. It's verbose and clunky, with all roads seemingly pointing to null. These are faults that users of other languages (especially of C#) love to point out.
At the same time, Java is mature, stable, backwards compatible, and runs just about anywhere. The community is pretty cool too!
This talk takes a light-hearted, warts-and-all look at some of the more frustrating aspects of Java, how the language has evolved over time and where it's headed next.
Expect to laugh, and yes maybe even cry, as we try to make sense of the beast that puts food on the table for millions of developers worldwide
And if you're not currently a Java user, don't worry, we will explore the consequences of language design decisions in broad enough terms that you will still get a lot out of this talk!
We will cover:
- Pivotal early design decisions such as checked exceptions and generics and how we still pay for those decisions today (that is, why do lambdas suck so bad?)
- How Java has influenced the development of other programming languages, and vice versa
- Most controversial language design decisions of late and the associated fallouts
Java developers will leave this session feeling validated and with a renewed love for the language that keeps a large chunk of the world running. C# developers will leave this session with a renewed level of smugness.
A Teacher, an Economist and a Developer Walk Into a Bar
Have you ever wondered what a teacher, pilot or economist could teach you about software delivery?
As technology leaders, we often lean on heuristics and truths that we collect throughout our career. For example: start small and scale up later, iterate and ship often, good enough is good enough. These are actually pretty powerful insights that can be applied in other areas and not just in software development projects.
What if we flip the script? What if we look at other disciplines, like teaching, personal training, economics and aviation? What do people in these industries and professions just “know”? And can we apply it to our roles as Project Managers, Scrum Masters and Tech Leads?
This is an exciting question, because delivering the right thing at the right time for the right cost requires a lot more than just technical skills. It also requires an understanding of the behaviours and contextual factors that can drive success of the project. This intuition and understanding can take years to develop. We’re going to do it in an hour.
So if you’ve ever asked yourself or your team questions like:
- Should we continue along this course of action or pivot and try something else?
- How can we better evaluate our alternatives?
- How can we facilitate a continuous improvement culture in the team?
- How can we deal with unforeseen events in a more methodical way?
Then you are going to get a lot out of this talk.
I’ll be using my experiences as an economics major, powerlifter and aviation enthusiast to lead you to the necessary “ah ha” moments years ahead of schedule.
Are Rewrites Always a Bad Idea?
It’s an age-old story. Dev meets legacy code base. Dev gets frustrated. Dev embarks on rewrite. Company spends money. Rewrite fails. Legacy stays in production.
Ask most senior developers and they will tell you that a rewrite is rarely a good idea. And they’re right. But under what circumstances is rewriting or porting an application actually the best path forward?
I faced this question with my team in a recent customer project. We were responsible for running and maintaining a service written by an academic in C++. The only problem? We are neither academics nor C++ developers. With the customer keen to add features to the ageing service, we asked ourselves, do we dare to rewrite?
In this talk I will share my experiences on this project, including what it was like to take my first steps into a leadership role simply because I knew the most math.
Using this project as a backdrop, this talk will cover
- When a rewrite can be a good idea
- How to choose a tech stack for your rewrite and why we chose Kotlin
- Taking a leadership role as a junior dev
- Geeky stuff from the domain: leveraging Kotlin’s standard library to turn academia into code
Whether you are just at the start of your rewrite journey, you’ve already started, or you’re not sure how to broach the topic with management, then you will get a lot out of this talk.
Mayday! Software lessons from aviation disasters.
What can aviation teach us about software? More acutely, what can aviation disasters teach us? Aviation is an industry that has committed to relentlessly learning from its mistakes, in the name of making the skies safer. Where the cost of the next iteration is potentially counted in human lives, then that relentlessness is not seen as a noble commitment but rather as the bare minimum. As software professionals, we have it easy. The costs of our decisions and failures are far far lower. For now.
As software permeates ever wider through our lives, the cost of failure gets higher. Societies are becoming cashless, and doctors are carrying a different kind of tablet. Smart phones have led us to smart homes. In a world where everything is connected, it’s time to learn from the industries where disasters are avoided at all costs. And in the face of disaster, instinctively running toward scrutiny rather than away from it.
This talk is not doom and gloom. It is a practical look at the methods and insights that almost 100 years of investigating commercial aviation disasters can teach us as software engineers.
Mayday Mark 2! More Software Lessons From Aviation Disasters.
What can aviation teach us about software? More specifically, what can aviation disasters teach us?
A lot actually.
In the first edition of this talk, I focused on the human factor of aviation disasters. An important element of both software engineering and aviation. But that is just the tip of the iceberg.
In this talk, I will go deeper into the technical oddities of some of the most famous aviation disasters. Buckle up for more case studies, more geeky stuff, and yeah, also some more human stuff.
We will cover
- Most common causes of aviation disasters and how that has changed over time
- Redundancy in systems
- Deadly UX
- Project failures and (wrong) incentives
Despite the subject matter, this talk is not doom and gloom. It is a practical look at the methods and insights that almost 100 years of investigating commercial aviation disasters can teach us as software engineers.
Swetugg Stockholm 2025 Sessionize Event
CloudBrew 2024 - A two-day Microsoft Azure event Sessionize Event
J-Fall 2024 Sessionize Event
NDC Porto 2024 Sessionize Event
Techorama 2024 Netherlands Sessionize Event
Copenhagen Developers Festival 2024 Sessionize Event
NDC Oslo 2024 Sessionize Event
Techorama 2024 Belgium Sessionize Event
CloudBrew 2023 - A two-day Microsoft Azure event Sessionize Event
NDC Porto 2023 Sessionize Event
NDC Oslo 2023 Sessionize Event
CloudBrew 2022 - A two-day Microsoft Azure event Sessionize Event
Build Stuff 2022 Lithuania Sessionize Event
NDC Sydney 2022 Sessionize Event
NDC London 2022 Sessionize Event
Microsoft JDConf 2022 Sessionize Event
droidcon London 2021 Sessionize Event
JNation 2021 Sessionize Event

Adele Carpenter
Software Engineer at Trifork Amsterdam
Amsterdam, The Netherlands
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top