#team productivity

After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.

Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Everything we do, from the way in which we write our emails, to the method in which we provide negative feedback and evaluate performance, governs the performance of our teams. And understanding how culture impacts our efficacy as a team can drastically improve our day-to-day collaboration. In this session you'll learn: How different cultures communicate, How different cultures evaluate performance and give constructive criticism, How different cultures make decisions, How different cultures trust, How different cultures perceive time.

I've flip flopped between engineer and manager three times already. I'm quite aware that this is not an unusual thing to do. There's a heap of flip floppers out there! At Atlassian I'm in a new managers group. Interestingly there are many managers in the group that have previously been managers but joined Atlassian as an engineer.
So what's wrong with us? Why do we keep changing our role? Is it boredom? Are we crazy? I think there's actually method to the madness. Each time we make a change it's intentional and there's a purpose, and whilst some say it can hurt your career, I'd like to take you on a journey to explore why flip floppers are a very valuable breed!

In this lightning talk, we will explore the significance of code reviews in open source projects, specifically within the React ecosystem. We'll discuss the benefits of code reviews for maintaining code quality, encouraging collaboration, and upholding project standards. By emphasizing effective feedback, respectful communication, and the use of relevant tools, participants will gain practical insights on conductingimpactful React code reviews. Join me to learn how code reviews can enhance the development process, encourage knowledge sharing, and contribute to the success of open source projects in the React community.

Hardly any people in Tech like when there's a lot of tech debt. And most of us would like when there's not too much of it. But how do we understand how much exactly we have of it? Where exactly does it sit? Which part of it is actually the most annoying? What would be the benefit for us if we spend time getting rid of it? When it comes to planning how you tackle your tech debt, all these questions deserve answers. Especially when we're asked about the ROI on our efforts to eliminate some annoying legacy stuff and build a new shiny module or service. Also, when we work on tech debt, we do want to tackle the most impactful parts of it first, don't we? This talk is about all of that: how we measure our tech debt, how we interpret the results of these measurements so that they give us the answers to the right questions, and how we guide our decision making with those answers.

Engineering team often face difficult challenges with constrained resources. If the job requires 1 engineer, we put one on the job. If it requires 2, we split topics into actionable chunks and assign them to individuals.
But there are several benefits to do things in pairs: It helps to catch errors and bugs, it allows for better communication and collaboration between team members and it can also lead to more efficient and higher-quality code, as engineers can challenge their peer's assumptions and suggest alternative approaches.

As we’re working to build the best possible software engineering solution, we encounter many decisions we must make. Daily. Sometimes this involves very active and passionate conversations, which might sometimes go down the negative path, creating a bad atmosphere in the team. On top of that, it’s a huge waste of time. But what if those daily decisions could be much easier and simple? In this talk I’ll try to attack and eliminate the pain points of decision making in software engineering and will show how I helped my team benefit from a lighter decision making process.

As your team grows and becomes multiple teams, the size of your codebase follows. You get to 100k lines of code and your build time dangerously approaches the 10min mark 😱 But that’s not all, your static CI checks (linting, type coverage, dead code) and tests are also taking longer and longer...How do you keep your teams moving fast and shipping features to users regularly if your PRs take forever to be tested and deployed?After exploring a few options we decided to go down the Nx route. Let’s look at how to migrate a large codebase to Nx and take advantage of its incremental builds!

Building software is all about hitting the right spot between features and quality. But we rarely talk about how to measure quality. Let’s look at how a gamification system (points & leaderboard) within a GitHub action helped developers on my team care about quality!

What does Conway's Law have in common with the video game League of Legends? They can both teach us about how to organise development teams that achieve collective intelligence. When it comes to the art of software development, it's never a game of chance

Do you want to release your applications more rapidly with lower risk? Feature flags make this possible. This talk will concretely demonstrate that this is possible and easily within your reach.

Orders of magnitude matter. Things don't go up order of one every time. Organising people in a group requires disseminating information and its interpretation and, most importantly, its distribution. Remote working and asynchronous collaboration have become the norm, meaning that distributed teams have taken their silos of knowledge with them. The impact of this has compounded any organisations experiencing a skills gap with a skills distribution problem, increasing the importance of good documentation and transparent interaction processes. In this session, we'll go over the fundamentals of requirements engineering, looking at how orders of magnitude scale alongside the expansion of scope and additional requirements. Lastly, we'll discuss how you can apply elements of platform thinking to your everyday projects.

Developers want to ship and create value for our users. Why, then, do so many teams struggle with getting things to production quickly? In this talk, Jason Lengstorf will look at the impact our frontend architecture and infrastructure has on our teams’ ability to build, iterate, and deploy software — and how it affects the quality and risks of deployment.

Retool is a front-end as a service tool that is similar to React and can be 10x faster than coding a web app from scratch. We’ll focus on how and why it is used for internal tools at some of the fastest growing companies and take a minute to walk through how it works, where it’s a good fit and where it’s not.