#developer challenges

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.

Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.

When combined with a custom rendering function, JSX can be used to quickly build a custom domain-specific markup language. I will show you how to approach this using the example of creating builds in Minecraft.

When refactoring large code bases, Find and Replace even with Regexes, can only get you so far. When that fails don’t fallback to painful manual updates instead reach for Abstract Syntax Trees (AST). In this session we introduce AST’s and show how they can be used to reason about / generate code. You will leave with a greater understanding of how you can automatically update code and new insights into how code linters work under the hood. 

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.

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.

What makes a component library good? In order to create a component library that people want to use you need to navigate tradeoffs between extensibility, ease of use, and design consistency. This talk will cover how to traverse these factors when building a component library in React, how to measure its success, and how to improve adoption rates.

More and more, React is being used for complex apps that accommodate numerous types of users, workflows, and mechanics. Sometimes it’s different people who each use part of the app, but a single-user multi-workflow scenario isn’t uncommon as well.In this session, we’ll learn about our options when building multiple experiences within a single React app — without losing our sanity. I’ll use some examples from what we do at Wilco.

Usually creating web and mobile apps require different tech stacks, and it is pretty hard to share code. This talk will show how I added a React web app and a React Native mobile app in the same monorepo using Nx, and how I optimized codeshare between react web app and react native mobile app.

In this talk, you will discover how to manage async operations and request cancellation implementing a maintainable and scalable API layer and enhancing it with de-coupled cancellation logic. You will also learn how to handle different API states in a clean and flexible manner.

If you must have legacy code, you want it written in statecharts. We'll break down the mental models required for understanding unfamiliar UI code, and compare the maintenance costs with and without statecharts.

TypeScript is great, but migrating an existing app to it can be a pain. Codecademy took multiple existing React apps and converted them to TypeScript. We'll cover how to make those kinds of conversions successful from both cultural and technical standpoints.

In 2020, Rangle partnered with the Survey Monkey team to migrate a legacy codebase to React. Survey Monkey’s best-in-class digital products were being held back fragmentation and complexity, which created a lot of rework and wasted effort for their engineering teams. Working together, we implemented a number of process and architecture changes that cut the complexity and improved workflows, letting our blended team deliver results with speed and consistently, even early in the engagement. These were not one-size-fits-all solutions, but solves that were unique and fitted to the needs of the engineering and product teams. The success of the project was due to Survey Monkey’s motivated teams that were: 1) Ready to embrace change; 2) Able to keep a firm focus on the outcomes; and 3) Readily understood the complexity of the project.
This allowed us to co-create some non-intuitive solutions that engineers at similar enterprise-level companies should know about.