Consultant, Trainer, Writer, Editor of 97 Things Every Programmer Should Know

Decremental Development

Less is more. Less is also more effort. Is it worth it? We keep talking about incremental development, but we don't talk enough about decremental development. When we talk about refactoring, we often speak optimistically and vaguely about improving code and cleaner code. In the real world the main activity of any significant clean-up is throwing out and reducing. The less code you have, the less you will have to optimise, to secure, to debug, to rework, etc.; the more of a codebase you will be able to fit in your head and understand and reason about. What can you remove? Dead code, speculative generalisations and needless abstractions. What can you reduce? Accidental complexity, verbosity and first-draft thinking now that we know better. Welcome to the world of decremental development.

Chief Architect @ Headspring, Microsoft MVP, Creator of AutoMapper

Domain-Driven Refactoring

Books, workshops, storming and more, all build up an idealized domain model. All describe great techniques for domain-driven greenfield applications. But what about the code we have? How can we take what's already built, and move it towards a better, more cohesive design? In this session, we'll look at anemic, procedural, boring code and examine code smells that can point us in the right direction. We'll also look at standard design patterns for more complex behaviors and models, and how to recognize when (and when not) to apply them. Finally, we'll cover how to safely apply refactoring techniques to achieve our domain-driven model nirvana.

Senior Software Engineer @ GitHub, Creator @ exercism.io, Co-author of 99 Bottles of OOP

One Small Step

Refactoring sometimes devolves into an appalling mess. You're chasing a broken test suite, and every change just makes it worse. An even more insidious antipattern is the slow, perfectly controlled process culminating in dreadful design. This talk presents an end-to-end refactoring that demonstrates simple strategies to avoid such misadventures.

Software Craftsman and Founder @ Codurance, Author of The Software Craftsman

Rights and Responsibilities of a Delivery Team

There is still a lot of frustration in software projects. Micro management, lack of autonomy, lack of trust, time pressure, personality clashes and lack of motivation are, among many, reasons for a general feeling of dissatisfaction. Behind all that there is an expectation mismatch between business, delivery teams, and individuals. This talk focus on the rights and responsibilities a delivery team should have in order to reduce frictions and increase the chances of a successful collaboration.

Principal Technologist @ VMWare, Trainer @ ‎Bottega IT Minds, DZone's Most-Valuable Blogger

Unit Testing Done Right

Coming soon...

Software Craftsman, Co-Founder, Developer @ Codeborne

The World Needs Full-Stack Craftspeople

Developers and IT people in general tend to specialize and become narrowly skilled. In the past there was always the conflict of DB developers vs application developers, or DBA vs developers vs testers. Nowadays developers split even more into front-end/back-end/Android/iOS/whatever else. This leads to inflated teams, inefficient communication, lack of each developer's responsibility, low team's truck factor, and inability to solve production/design problems once and for all instead of applying patches here and there. The term "full-stack" is often applied to developers being responsible for all aspects of their work, but XP/craftsmanship practices go further — we should also take our communication, requirements, operations, testing, etc. under control. True сraftsmen can be an order of magnitude more efficient than narrowly skilled developers. They not only write code, but solve problems. Surely you want to be one. Let's break it down and see why it works.

Founder and Developer @ CodeScene, Author of Your Code as a Crime Scene

Prioritizing Technical Debt as if Time and Money Matters

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 presentation you'll see how easily obtained version-control data let us uncover the behavior 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.

Founder @ mnogosdelal.ru, ex-Head of IT @ Kaspersky Lab, Author of Jedi Techniques

Certainly Uncertain: Predicting Delivery Dates

As soon as you become a team lead or manager, you immediately become responsible for making vague things certain. When you have no idea what exactly shall be done, you are asked how much it costs and how long it will take. When you give an estimate and commit to delivering to your promise, scope creeps and you enjoy estimation hell again. In this talk, you will learn how to estimate without screwing things up. I will be as practical as possible and will share the real Excel-spreadsheet that implements a simple statistical model of project estimation so you can use it for your projects the next day.

Founder @ Agile Developer, Author of Practices of an Agile Developer, Programming Concurrency on the JVM, Functional Programming in Java

Qualities of a Highly Effective Architect

Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one? Come to this presentation to learn about things that can make that journey to be a successful architect a pleasant one.

Software Coach, Mentor and Consultant, TDD Trainer tdd.training

Integrated Tests Are A Scam

Integrated tests are a scam. You’re probably writing 2-5% of the integrated tests you need to test thoroughly. You’re probably duplicating unit tests all over the place. Your integrated tests probably duplicate each other all over the place. When an integrated test fails, who knows what’s broken? Integrated tests probably do you more harm than good. Learn the two-pronged attack that solves the problem: collaboration tests and contract tests.

Chair @ Cloud Native Computing Foundation, VP OSS Engineering @ Aqua Security, Author of Container Security

Building a Container from Scratch

What is a container? Is it really a “lightweight VM”? What are namespaces and control groups? What does a host machine know about my containers? And what do my containers know about each other? In this talk Liz will live-code a container in a few lines of Go code, to answer

Trainer, Consultant @ Bottega IT Minds, OSS contributor

How to Make Your Architecture Scream with Functional Domain Modeling

We might have heard that Domain Driven Design is Object Oriented done right. Is it, however, always true? Thinking of business processes as workflows and pipelines lets us map our problems into the concepts of functional programming, thus bringing our code to another level. During this session we will apply bits of functional programming into our Java application, discussing their impact, including security, testability, readability, and more.

Elixir Mentor, Author of Elixir in Action, OSS contributor

The Soul of Erlang and Elixir

Whether you're developing a small web site or a large-scale distributed system, Erlang and Elixir are great tools for building server-side systems. Both languages can help you start quickly and deal with highly complex problems at a large scale. This talk aims to explain what makes Erlang and Elixir suitable for such tasks. We'll look past the syntax and the ecosystem, focusing instead on the concurrency model of these languages. Combining a bit of high-level theory and a couple of demos, we'll examine some important properties of Erlang/Elixir concurrency, with a special emphasis on why these properties are very relevant when building highly available systems. The talk targets experienced backend developers, but no knowledge of Erlang or Elixir is required. You will walk away from the talk with a better understanding of what distinguishes Erlang and Elixir from the rest of the pack, and why these languages are very compelling choices to power your next software system.

CTO @ OpenValue, Netherlands JUG Lead

Mastering the Linux Command Line

TLDR: I'll show you everything you need to know about the Linux command line as a developer.

Senior Software Engineer @ Wycomco, OSS contributor

Things Every Developer Needs to Know About Database Indexing

This talk dives deep into a topic that I believe developers don't know enough about: database indexing. There are four sections to this talk: - What's an index? * How to create an index? * Understanding the execution plan * Common pitfalls What's an index In the first part we will learn what an index actually is. And we're talking data structures. How is an index actually represented internally and what are the implications of that. This is important because it makes certain characteristics of indexes much easier to understand.

Solution Architect, Developer and Mentor at Bottega IT Minds, ex-Head of Software Development @ 4Finance

User Stories Considered Harmful

Long time ago there was a role of a business analyst, who would discover and gather client requirements, then together with a system analysts, write them down. Next, they would meet an architect, where they would analyze the impact of those requirements on the architecture, and impact of architecture on business opportunities. This collaboration would provide new ideas for the business, but most of all, would create the analysis that went to developers. Then there were eXtreme Programming (XP). Then came Scrum and Kanban with Scrum Masters and Product Owners. Neither of them had any experience with XP, but since they loathed the old world, they have fired all the system and business analysts. And so, two working methods of requirement analysis were replaced by a single ineffective meeting called “grooming”, where a seven plus/minus three people, without any preparation, try to estimate something that nobody took time to understand. I’d like to show you how we came to this point, why the current situation puts developers in jail, and how to solve this madness.

Developer Advocate @ MongoDB, ex-Technology Evangelist @ Atlassian

The Effective Developer

We’re agile, we’re doing DevOps, we work in cross-functional teams, and we use the latest developer pipeline tooling. With all those methodologies and technologies we should be highly effective, right? Probably not. Most of us still struggle with balancing coding speed and quality, working on the stuff that really makes a difference, and feeling constantly stressed by all the things we should learn. Effective developers don't just write clean, simple, and robust code. They also have a strong understanding of the entire development process and the problem that needs to be solved. They take time to learn, practice, and play. Learn how those developers build effective coding habits, use automations whenever needed, reserve time for deep work, and much more. You’ll walk away from this talk with lots of ideas on how to work smarter, not harder.

VP of Developer Advocacy @ JetBrains

The Silver Bullet Syndrome

We love our silver bullets don’t we? Constantly chasing the dream that the next big thing will solve all our past problems. It doesn’t matter if it’s a language, framework, platform or library, we’re out there chasing it. Why? Well because it’s going to solve our needs, it’s going to solve the business needs. Well supposedly it will. And how much is it going to cost? Not that much, especially if we’re not the ones paying the bills. It’s about time we look at the hard facts and ask those difficult questions. Are we really looking for a silver bullet? Why are we constantly riding the technology bandwagon? Where is the churn going to take us? And at what cost?

Co-founder & Software Architect @ innoQ, Author of REST and HTTP

"Good Enough" Architecture

In this session, we’ll take a look at some of the ways we can determine whether the development efforts we’re undertaking suffer from too much or too little focus on architecture. We’ll examine a number of real-world examples that are intended to inspire either admiration or terror, and try to find some recipes of how we can get more of the former and less of the latter in our own projects.

Senior Developer Advocate @ Octa, Microsoft MVP

Leadership Guide for the Reluctant Leader

Regardless of the technology you know, regardless of the job title you have, you have amazing potential to impact your workplace, community, and beyond. In this talk, I’ll share a few candid stories of my career failures… I mean… learning opportunities. We’ll start by debunking the myth that leadership == management. Next, we’ll talk about some the attributes, behaviors and skills of good leaders. Last, we’ll cover some practical steps and resources to accelerate your journey. You’ll walk away with some essential leadership skills I believe anyone can develop, and a good dose of encouragement to be more awesome!