Cognitive scientists tell us that we are more productive and happier when our behavior matches our brain’s hardwiring—when what we do and why we do it matches the way we have evolved to survive over tens of thousands of years. One problematic behavior humans have is that we are hardwired to instantly decide who we trust. We generally aren't aware of these decisions—it just happens. Linda explains that this hardwired “trust evaluation” can get in the way of working well with others. Pairing, the daily stand-up, and close communication with the customer and others outside the team go a long way to overcome our instant evaluation of others. As Linda helps you gain a better understanding of this mechanism in your behavior and what agile processes can do to help, you are more likely to build better interpersonal relationships and create successful products.

As developers, we don't deliver just code. We deliver change in the world.

• The value of software is in its connections to the wider system: in its use.
• Growth never stops until death; software is “done” when it’s out of production.
• We don’t grow -in- an environment; we grow -with- an environment. Influence is healthier than control.
• Teams are like forests. The whole forest is communicating underground through a network of roots and fungi. The essence of a team’s work is out of sight, in
• the knowledge we exchange with each other and embed into the software.
• Developers are like trees in a forest. Sometimes management can’t see the “team” for the “resources.”
• Trees are green because intensity isn’t everything. To go fast is less important than to keep going.

How can we apply technology to drive business value? For years, we've been told that the performance of software delivery teams doesn't matter―that it can't provide a competitive advantage to our companies. Through six years of groundbreaking research, the DORA team set out to find a way to measure software delivery performance―and what drives it―using rigorous statistical methods. This talk presents the findings of that research, including how to measure the performance of software teams, what capabilities organizations should invest in to drive higher performance, and how software leaders can apply these findings in their own organizations.

Systems performance studies the performance of computing systems, including all physical components and the full software stack to help you find performance wins for your application and kernel. However, most of us are not performance or kernel engineers, and have limited time to study this topic. This talk summarizes the topic for everyone, touring six important areas: observability tools, methodologies, benchmarking, profiling, tracing, and tuning. Included are recipes for Linux performance analysis and tuning (using vmstat, mpstat, iostat, etc), overviews of complex areas including profiling (perf_events) and tracing (ftrace, bcc/BPF, and bpftrace/BPF), advice about what is and isn't important to learn, and case studies to see how it is applied. This talk is aimed at everyone: developers, operations, sysadmins, etc, and in any environment running Linux, bare metal or the cloud.

Many codebases contain code that is overly complicated, hard to understand and hence expensive to change and evolve. Prioritizing technical debt is a hard problem as modern systems might have millions of lines of code and multiple development teams — no-one has a holistic overview. In addition, there's always a trade-off between improving existing code versus adding new features so we need to use our time wisely. So what if we could mine the collective intelligence of all contributing programmers and start to make decisions based on information from how the organization actually works with the code?

In this talk, you'll see how easily obtained version-control data let you uncover the behaviour and patterns of the development organization. This language-neutral approach lets you prioritize the parts of your system that benefit the most from improvements so that you can balance short- and long-term goals guided by data. The specific examples are from real-world codebases like Android, the Linux Kernel, .Net Core Runtime and more. This new perspective on software development will change how you view code.

Databases are everywhere, but did you ever wonder what goes on inside the box? In this talk we’ll dive into the internals of Neo4j - a popular graph database - and see how its designers deal with distributed systems challenges now and in the future. Borrowing heavily from the academic literature, we'll see why computers are far too easy to program and why oppositely distributed systems are far too hard. We'll follow that with some approaches to making distributed systems safer and contrast that with conflicting approaches that make systems more scalable! If that doesn't sound nightmarish enough, we'll finish up by showing how we can build systems that are safe and scalable by borrowing and gluing together a bunch of ideas from folks who are smarter than me. Come experience the last 10 years of my harrowing day job in less than an hour. You might even enjoy it, or at least empathise!

Continuous improvement is based on balancing what we desire with the practicalities of time and effort. Continuous improvement gives us control of our changes and our situation, guided by feedback and reflection. But change is not always ours to control and, if we are honest, some changes are better carried out discretely than discreetly.

Change from outside can arrive gradually and then all at once. It can be a surprise because we could not have known, or it can be a surprise because we chose not to know. Most changes described as disruptive were there all along and, in truth, are only disruptive because of attitude and entrenchment. But whether the change forced upon is sudden and catastrophic because it is sudden and catastrophic or simply because we didn't know better, we may find that evolution is forced upon us.

How can we respond?