Maciej Kaszubowski

Software Developer at AppUnite, Computer Science student

Maciej is a backend developer at AppUnite, where he's been using Elixir for almost 3 years now. Currently, he's mainly interested in broadly defined complexity theory and general systems thinking, which he tries to apply to both developing software and creating better teams.

Past Activities

Maciej Kaszubowski
Code BEAM Lite Amsterdam 2018
30 Nov 2018
12.25 - 13.05

The big ball of nouns

All projects tend to get more difficult to maintain with time. Sure, Elixir and Functional Programming can make things much simpler, but after many months, the complexity will creep in anyway. Why is that? The code is just a set of functions, without the complexity associated with Object Oriented languages. So what’s wrong?

You see, the code is not the whole story. Each code has to operate on some data, which tends to introduce a lot of coupling, no matter the paradigm. With real-world examples, I’ll show you how you can reduce this additional complexity by focusing on behaviour, instead of data. You'll learn how to prevent your entities for growing and becoming too coupled. After the talk, I hope you will have concrete ideas on how to make your application more modular, easier to change, test, understand and reason about.


Everybody knows that good boundaries make software easier to work with. In the Elixir community, Phoenix Contexts put a lot of emphasis on this. The problem is finding these boundaries, when everything seems to be so connected together, especially when the project grows.

Maciej wants to show how you can make this boundaries stronger by focusing on behaviour, instead of data/entities. This approach usually leads to much smaller and better isolated parts, which are really fun to work with. To do so, Maciej will show some examples (taken from real-life projects) and describe the mindset he uses when designing the architecture.

Maciej Kaszubowski
Code Elixir LDN
18 Jul 2019
10.20 - 10.40

Error-free Elixir

Error handling can greatly increase the complexity of the system. In Elixir, the default way of reducing the error-handling code is to use the "Let it crash!" approach. But there's another way.

In this talk, you'll learn how to eliminate errors by redefining the operation semantics, all supported by real-life examples. By doing so, you'll be able to not only reduce the need for error handling, but also simplify the entire codebase, make it smaller, more testable and easier to understand.


Teach how we can reduce the amount of error-handling code.


All Elixir developers - because we're way too used to using error tuples and this should change.


Maciej Kaszubowski
Code Elixir LDN 2018
16 Aug 2018
12.20 - 13.05

It’s scary out there! Discovering distributed systems in Elixir (ADVANCED)

Elixir is often advertised as a great platform for building multi-node applications. While there’s some truth in that, there is nothing easy about distributed systems. We will see what nice things we have available thanks to the Erlang VM, learn how these features are actually implemented and what guarantees they give us. With this knowledge, we will think about example problems to be solved and explore possible solutions and their trade-offs.

Have you ever wondered how Phoenix Channels or Phoenix Presence actually work, why there’s so many different solutions, what’s the difference between :global and :pg2 modules, or whether these “CRDT” things will solve all of our problems with distributed computing? If so, come and discover the scary and fascinating world of distributed systems.


This talk will try to show that distributed systems are hard and full of tradeoffs and that Elixir cannot solve all problems. It's important to know available tools and understand their tradeoffs. That's why we will see what tools do we have in our toolbox and which problems can be solved using them.