Your communication skills affect your career prospects, the value you bring to your company, and the likelihood of your promotion. This session helps you communicate better in a variety of professional situations, including meetings, email messages, pitches, and presentations.

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.

Mentorship has a reputation of taking a lot of time and work. But what if it wasn't? Here are ways to get a mentor, be a mentor, and how to navigate it. I have always worked on getting mentors in every corner of my engineering career. I have mentors that do not even know they are my mentor. But I like it that way. I will go into how to get a mentor at any stage of your engineering career and how to be a good mentor/mentee.

One way to get a good groan from your team is to mention the word “process”. Engineers in particular worry that process will mean their momentum will get slowed or halted, and usually have experience to justify that worry. With an understanding of workflow and high-level individualization, this doesn’t have to be the case. As a tech lead and now manager that has converted many process skeptics, I’m excited to show you my processes for process.

In this discussion together with speakers we will try to figure out job hopping's advantages and disadvantages, how it might influence on career and personal growth.

You start as a junior developer, happily delivering lines of code. Life is easy, you love your job, you are learning a lot. And then someone approaches you saying: "We need a tech leader for a new team, and you are the most experienced person available". You either become miserable or find your new calling, but your job is not really what it was before. And then someone approaches you saying: "We are looking for a new engineering manager, and you are the most experienced person available".

Is that really the most optimal career path? What could we do differently? Let's have a look at your talents and the talents needed for the job.

There are many different jobs in tech: writing code, leading teams, managing people and projects, helping others use your technology, teaching, research, debugging.

We’ve all experienced the job application which required us to do an online coding test. You have to brush up on your algorithms, data structures, time complexity, and by the end of it you’re cramming as if it was a university exam! Now that we’re the ones usually interviewing candidates, a good question to ask is: “are online coding tests the best indicator of a candidate’s proficiency and competence?” In this talk, we’ll explore:

• The pitfalls of Leetcode-like tests

• What we should be looking for in candidates

• How pair programming is the best way to see how a candidate would work with the team

• Plus a little mini demo on a remote pair programming interview

Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?

In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.

The field of developer relations or DevRel is rapidly increasing in popularity, with roles for developer advocates, evangelists, program managers, and directors appearing seemingly everywhere. It could very well be that you too have colleagues who work in the field. DevRel is a unique discipline aligned with every part of the business from engineering and product, to marketing, and even sales, and acts as a bridge between the company and the wider developer community. Our aligned incentives with engineering leadership are especially obvious in the fact that we exist to serve and enable developer audiences, whether external or internal.

For engineering teams, working closely with your DevRel teams provides a great opportunity to better understand your developer audiences, raise the profiles and skills of your colleagues, and make your company more attractive for hiring. Yet, despite many DevRel teams being highly technical, because of DevRel’s perceived lack of focus, our departments are often dismissed as “just marketing” by engineering.

In this talk I will answer the question of “what is it that DevRel people do”, and present some approaches for how DevRel and engineering can best collaborate and break down silos to benefit everyone, from the company to the wider developer community.

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.

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.

“Maybe I’m fooling everyone… I’m not good enough for this, and at this point, it is a question of time until everyone figures it out” these might be the words that cross your mind as your coworker compliments you for doing another fantastic job at delivering a new feature. As you grow in your career, so does your uncertainty. You put in the extra hours, learn all the new technologies, and join all the initiatives you can, but at the end of the day, it never feels enough. At this point, that feeling is leading your actions and decisions. It is the thing that is driving your career. Only one question persists: Are you really an imposter?

If you’re a human being, chances are you’ve felt like an impostor at some point in your life. One of the biggest issues with this syndrome is that is easy to get stuck with this feeling. One does not simply overcome Impostor Syndrome. It requires offering yourself compassion and vulnerability instead of judgment and self-doubt. But... how exactly do you achieve that? We'll look at techniques for achieving this and overcoming the syndrome.

I know developers feel doubts of choosing the IC role over a manager or vice versa. I'll tell about my own road how to find own purpose doing things I like.

Let's throw away everything and start fresh. Sounds great, right? While this can feel very good it rarely speeds up anything. I'll show you why a complete rewrite is usually not what you want.

We all have been through companies’ reorgs, probably more than once. If some are understandable and produce good outcomes, others aren’t — creating insecurities, lack of confidence in leadership, unnecessary changes, and even more complex paths of communication or decision-making. What is the difference, then? Is there a well-proven way of scaling or changing the current landscape of companies’ organizations? Yes, there is. In this session I’ll go through, supported by an actual study case in the industry, Conway’s Law and the importance of teams’ landscape and interactions, and how well-designed teams charts can improve independence, autonomy, motivation of the teams, leading to a faster and better rate and quality of delivery.

A lot of us when changing jobs or accepting a promotion feel overwhelmed by the offer and either don't ask for more or ask a percentage more than the offer. Let's talk about why that's not enough and how we can change our attitudes towards negotiation.

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.

Discussion will take place in spatial.chat. Link will be available for ticket holders on main conference page on the event date. Speakers:

Stefania Ioana Chiorean

Ziv Levy

Daniel Afonso

Discussion will take place in spatial.chat. Link will be available for ticket holders on main conference page on the event date. Speakers:

Mo Khazali

Anton Kazakov

Shivangi Das

Alex Ptakhin

Alex Moldovan

Marek Kalnik

Discussion will take place in spatial.chat. Link will be available for ticket holders on main conference page on the event date. Speakers:

Stefania Ioana Chiorean

Anton Kazakov

Daniel Afonso

Erin Fox

Discussion will take place in spatial.chat. Link will be available for ticket holders on main conference page on the event date. Speakers:

Peter Nijenhuis

Daniel Afonso

Shivangi Das

Alex Ptakhin