It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a programming also represents a way of thinking. Having only way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving and contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.
Perhaps even more problematic than being stuck with a narrow view of paradigms, is being stuck with a dysfunctional view of each paradigm. For instance, many developers working in languages and frameworks that support object orientation have a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.
This session explores the strengths and weaknesses of different programming styles, patterns and paradigms across different programming languages, past and present.
We all have legacy code, meaning profitable code that we’re afraid to change. It doesn’t matter who wrote it, in which language, nor when. It matters that we feel the fear now and need to deal with it. Rewrite or refactor? How do we write useful tests? There’s so much to change; how do we get started? When do we stop? Will it ever get any easier? In the typical programmer’s day job, there’s no time to learn how to do this. We’re already behind schedule and the cost of fixing the legacy code is crushing us. We need a way to learn how to do this safely, correctly, and eventually, even quickly. That’s what Surviving Legacy Code is about.
Everyone is talking about APIs, be it simple services or complete ecosystems that you want to expose via API. With all the tooling available, that is quite easy, is the first thought. But it is not.
The challenge of an API is not its implementation, but its design: What needs to go into the API, what do I leave out? How do I present it in a way that users find it good? What else do I need to take into account if I want my API to be a success?
In this workshop we will take a practical approach to the design of APIs using several case studies. We will intersperse short theory blocks that we try to put into practice, turning widespread bad practices into good ones.
This way, we will learn good functional API design step by step - aha-experiences included.
This is an online guided workshop that accelerates your tech leadership journey. This workshop will boost your skills, accelerate your career development, offer you tools and tricks to lead technical teams and guide you through the journey from maker to multiplier.
At the end of this workshop, you will be able to:
- Understand what technical leadership is, and why it’s important for successful teams
- Explain what effective technical leadership looks like
- Describe your Technical Vision in depth
- Outline 8 foundation principles of effective technical leadership
- Identify the different behaviours of Makers and Multipliers
- Use 5 foundation skills that Multipliers draw upon a daily basis