Talks

What I wish I knew as a first time Tech Lead

The path from being a developer to a Tech Lead seems like a scary transition. As a developer, you could focus on constantly learning new tools, libraries, frameworks and programming languages. It was mostly you and the computer. The Tech Lead role feels like a path where you will no longer get to code. You feel like you know what makes a good developer, but you’re unsure about what makes a good Tech Lead. In this talk, Pat Kua will reveal the lessons he wishes he’d learnt as a first time Tech Lead.

The seven righteous fights

It’s empowering for developers and other people involved in the inception of a project to have tools for making the project better long-term.

This talk highlights the seven things that should be considered very early in development:

1. Localization. Are you ever planning on selling this to someone in another country?
2. Security. Don’t be the organization that has to pay someone for disaster PR. Building in security early saves you a bunch of time and user churn later.
3. Extensibility. What makes you so sure this API will always be internal?
4. Documentation. People do not buy software solely based on PowerPoints. You need public documentation. It has to be more useful than Stack Overflow.
5. Affordance. UI is not actually a word. People change how they feel about you based on your microtext and error messages.
6. Acceptance. Have you shown this to any actual humans? Who are like the users?
7. Accessibility. We all use computers different ways. Does your software allow that?

Leaving these considerations to the end is like baking a cookie and then trying to poke chocolate chips into it after it’s done.

The journey from monolith to microservices: a guided adventure

Are you starting a new application and wondering whether to go with a monolith or take the microservices path? Do you have an existing application that is getting too big to deliver business value with a predictable velocity? Ever wonder how to regain the agility you had when an application was smaller?

The current discussions around application architecture with microservices seem like an all or nothing journey without any stops along the way to catch your breath. This talk outlines questions to ask yourself to drive decisions along the way. It also demonstrates one possible path for future growth, complete with intermediate stops along the way where you can pause to evaluate your next step. This path avoids implementing too much complexity early in the process.

At the end of the journey you will not only have ideas to guide your own path, but tools that you can use to make the journey easier and less costly.

The wonderful world of webhooks

In an increasingly connected world, APIs are key to great tools and effective workflows. What is better than an API? A webhook of course! Webhooks are the modern way for integrating systems and allowing them to react to one another. This session will cover what a webhook is, and where we might see or use them in our day-to-day activities. We’ll also look at how they can become part of our workflow, by bringing information into our chat channels, integrating with other tools such as Zapier or Hubot, and generally oiling the wheels of our daily work.

How to make a sandwich

Feedback is one of the most important skills when collaborating with others. Giving and receiving feedback with honesty, integrity and empathy is hard. Doing so consistently takes practise and requires learning and practising feedback and listening techniques.

In this session, Dan discusses a number of feedback models and techniques, and shows you where and how you can apply them. He explains the infamous and much-misunderstood “sandwich model” of feedback, how it works and why it usually doesn’t, and looks at some of the failure modes of feedback. Are you using feedback to help your colleagues and yourself to grow, or are you using it to coerce and control them? How do you know? And what does any of this have to do with Systems Theory?

After this session you will be better equipped to offer feedback, more resilient when receiving feedback, and maybe more aware of your own motivations for doing so.

How do you get an engineering team to eat their vegetables?

Many factors contribute to developer happiness. However, as engineers, we’re often singularly obsessed with the idea that our job satisfaction comes solely from solving only the most interesting technical challenges. In reality, research shows that we perform best when we are rested, feel valued, and feel connected to a cause so we can focus on high-priority work.

This talk will focus on ways engineering teams can foster excellent working environments and cultures with minimally felt process: much like sneaking vegetables into desserts.

Writing Modular CSS with CSS modules

This talk will introduce WebPack and will demonstrate how to write, bundle and use CSS Modules.

"I know just the person!" - networks and hiring in tech

In a fast developing industry such as tech, the acquisition and retention of talent is a crucial success factor. Often, hiring through personal networks can lead to a quicker and more successful hiring process than traditional methods – and sometimes contacts can even encourage under-represented groups to apply for positions they wouldn’t consider otherwise. But there’s a downside: personal networks are significantly different in size, structure and utilisation depending on a person’s social origin and gender. Does hiring through networks lead to an exclusion of whole social classes? Do contacts influence retention time positively for men yet not for women?

This talk presents current research results and provides suggestions on how to tackle talent acquisition in tech without giving up on representation and diversity.

Telling stories through your commits

As your codebase and development team grow, being able to communicate how and why your code has evolved is crucial to your ability to continue to change it.

Our version control history is a living, ever-changing, searchable record that tells the story of how and why our code is the way it is. The ability to document your code effectively using Git (or any other version control system) is an invaluable skill which allows your team to make informed decisions about future code changes.

This talk will outline some of the key practices which can be adopted to make your version control history tell a valuable story about your codebase, and how you can embed these practices with in your team.

Building new on top of old: the argument for simplicity

The software industry is surrounded by complexity, with new solutions to old problems appearing daily. Creators of software constantly face questions about how to best navigate changing technology tides while still building their “ships”. Building these ships, or building software, requires picking challenges and making sensible technical choices to move fast without compromising stability.

In this talk, GitHub’s Senior Director of Infrastructure Engineering, Sam Lambert, will explore how GitHub steers its ship—the world’s largest software host serving over 11M users—on top of stable, proven systems and services. He’ll speak specifically about how these practices can be translated to any type of software creation by focusing on:

• The importance of pragmatism during building and maintaining software systems.
• How a company like GitHub moves fast and breaks as little as possible by carefully choosing what problems to tackle.
• The role new technologies can play in informing decisions and approaches around what problems to solve.

How to crash an airplane

On July 19, 1989, United Airlines Flight 232 was en route to Chicago when a mechanical failure caused the plane to become all but uncontrollable. In this unsurvivable situation, the flight crew saved more than half of those onboard. How did they do it?

Flight crews and software teams actually have a lot in common, and there’s much we can learn from how the best crews do their jobs. What can we learn from the story of United 232? While this talk won’t earn you your pilot’s license, you’ll definitely come away with some fresh ideas on how to make your team even more amazing.

Leadership. By the numbers.

A series of simple numbers can represent a useful and memorable corpus of hard-earned leadership experience. This talk will succinctly explain essential leadership lessons that you can either heed or simply wait to experience.

Hacking verbal communication systems

This talk will outline how to achieve better communication by replacing parts of your talking protocols.

Tour of language landscape

There seems to be a new programming language every week, and for us busy developers we just don’t have the time to keep up with them. But have you wondered what we might have missed out on whilst we’re busy working in our language of choice?

Having spent time with numerous programming languages the past few years, Yan Cui has learnt something new from each. In this talk, he will give a whirlwind tour of the interesting concepts and ideas he has encountered, from F#’s type providers and Rust’s borrowed pointers, to Elm’s signals and Idris’s dependent types to name a few.

Addressing Imposter Syndrome

Impostor Syndrome is the feeling that you aren’t really qualified for the work you are doing and will be discovered as a fraud. Many women, People of Color, QUILTBAG persons, and others from marginalized groups experience Impostor Syndrome, especially when they’ve (we’ve) been socialized to value others’ opinions of work above their own. People developing new skills (something we must do constantly in tech) are also prime sufferers. Want help overcoming your Impostor Syndrome and decreasing its incidence in your community? This talk is for you.

How not to burn out your monitoring team

Bad monitoring, alerting and logging has made Gil Zellner very frustrated in some of his previous positions. It seems that almost nobody gets this exactly right. This will be a talk about the most annoying issues he has come across and advice for how to fix them.

Leading Leads - Lessons from a growing team

Leading a growing team is exciting – it means you’ve earned the trust to expand out and your team is able to take on new, bigger challenges. It also means your team might outgrow you, and you need new lead developers to help things scale. Congratulations, you’ve just entered a totally new scope of leadership, leading a lead!

Leading other leads is an exciting and scary step to take. It’s now your responsibility to set expectations and goals, provide feedback, and support your team. This talk will highlight lessons learned from Monika’s own transition to leading leads. She’ll talk about challenges in reframing your role, as well as the opportunities for your own growth when your team member has a team to lead of their own.

Working backwards from the customer

Amazon is built on top of fine grained services that have a strong ownership model – you build it, you run it. These services are created by small teams to make it very easy to innovate. You can imagine this to look like a large group of startups within the walls of a bigger company. Each service needs to meet the needs of the customer, be it an internal or external one. To ensure this we use a process called “Working Backwards” in which you start with your customer and work your way backwards to the actual service or product. The goal of this process is to drive simplicity through a continuous, explicit customer focus. Thomas Lobinger will share how this process worked out for him at Amazon and what you can learn from this for your own projects.

How to deal with the culture divide and internal advocacy within a distributed team

Having timezone issues, international flights, planning logistics, communication and dealing with different cultural norms, working with teams distributed across the world provides challenges to overcome and a great way to learn how to work in a different manner at times.

Scaling company culture is hard enough when the majority of your company is in the same office. Nowadays this is rarely the case most of the time you’re split over multiple continents it can seem like a monumental task. In this talk Laura will break down the cultural challenges faced when working in a distributed team, the cultural communication, and look at some solutions that can be brought in to help you and your team.

How to succeed at hiring without really trying

Hiring good people can be hard. Keeping good people can be hard. It’s made easier though if you can set your company apart as a place that people want to work at. But how do you make the community aware that that’s the case?

Developer evangelists typically evangelise products to developers, but what if the thing you’re trying to sell is the team itself? How can you get your entire team sharing with the community what you’ve built and how you work?

This talk will examine why you should evangelise your team from an individual, team and community perspective, and give concrete examples of how to encourage your team to do so.

Rebooting Culture

Overhead, not downtrodden

There are many super-important roles in software teams that are also financial overhead, e.g. QA, Support and Bugfix. They’re necessary, but they require people that would otherwise be working directly on business goals. For leaders of these overhead teams, it can be frustrating, having to justify keeping them well-staffed. We often point to the problems in the business that they address: “We need a big bugfix team, look how many bugs we have!”

But what if we flipped our thinking? Instead of denying that we’re overhead; we embrace it. Instead of using the size of the problem to justify the team size; we aim to reduce both. “Let’s halve our bugfix team by halving the bugs we ship in the first place”. In this talk, using personal examples from JIRA QA and Bugfix, Penny Wyatt will describe how this flip in leadership mindset can lead to happier engineers, teams, stakeholders and customers.

Welcome from your conference chair