Dev Conversations #6: Krzysztof Zabłocki
Dev Conversations is a monthly series where Swift Toolkit features members of Swift work groups, content creators, and people who contribute to the Swift community, focused on tooling, developer experience and Server Side Swift.
In these talks, we discuss open source projects, tips for professional growth, and many other valuable insights and perspectives from other developers.
Sourcery is one of the first tools in the Swift ecosystem, launched back in 2016. Its author, Krzysztof Zabłocki, got tired of writing boilerplate code, such as Hashable and Equatable conformances (before they were automatically generated by the compiler), and decided to create a tool to save time doing it for him and many others.
But long before that, Krzysztof’s journey into programming began when he was a kid. He entered the world of iOS development even before the public SDK was released, and before that he worked on game and graphics development. Krzysztof built custom UI and Physics Frameworks for games, among other lower level libraries in C++ and renderers.
Throughout the last 17 years, and alongside his open source contributions to the community, Krzysztof worked with iOS at various companies, such as Mashable, led the iOS team at the New York Times, worked at The Browser Company (behind Arc), and also built his own indie apps at Pixle. In 2024, he decided to leave his full-time position at The Browser Company, and focus on consulting and launching a course about developer productivity, SwiftyStack (use code SWIFTTOOLKIT for 20% off).
In this episode, Krzysztof joins us to talk about his career, the history of Sourcery, and what led him to leave solid positions to become independent, and focus on what is important to him, in both professional and personal senses.
If you prefer reading or listening instead, you can find the written interview and the podcast links after the video, along with relevant links discussed in the chat.
Also available in your favorite podcast player 
Swift Toolkit
Hey, Krzysztof! How's it going?
Krzysztof
Hey, nice to be here.
Swift Toolkit
Thank you so much for accepting my invitation. I think the last time we met was in April last year (2024), in Italy for SwiftHeroes. And I already had the website, but I didn't have yet this series.
We spoke a little bit about the beginning, I wanted to have you here. Because it's one of the, not sure if oldest tools in Swift, but definitely one of the first.
Krzysztof
Definitely one of the more impactful, right? Because I saw it adopted by so many different teams across the years.
Swift Toolkit
Right, and we'll soon get into Sourcery a little bit, into technical details. But first, for those who don't know you, would you mind explaining a little bit what are your career highlights?
Krzysztof
Sure. So it's been a while since I started programming. I actually was eight years old when I started. But iOS, started before public SDK came out. So they announced the first iPhone. There wasn't an SDK you could use. You could only add a Cygwin script. So you can build on a jailbroken device, and that's how I started.
I started building iOS apps through building a press publishing platform, which is interesting. Because that was my first project and I had a couple other projects. And then I ended up working for Mashable, the New York Times, so news related for many years. I led the New York Times for almost six years. Worked on the rewrite of the news reader application. So they decided that they want to switch from Objective-C to Swift and they're just gonna start fresh. That's when I joined and I led the team to do that.
Swift Toolkit
That's a lot of CoreText, no?
Krzysztof
Not really, because in the Times application, the articles are actually not native. So, from technical details, we used Texture for text rendering. We didn't directly use UIKit because it was too slow, as we had to avoid collision with images. And that's double pass for rendering text, very complicated in terms of efficiency.
But yeah, generally it was like building the whole architecture, coming up with the whole architecture when I joined, almost no one knew FRP (Functional Reactive Programming). And the question was, do we want to teach people all of those complicated details? And as you know, hot and cold all those things really trip people out. So what we decided was to build a simplified version of FRP, which is an observable signal. It didn't have errors. didn't have failures, which is value over time.
One of the main reasons I built that from scratch is because the available libraries back then weren't tested. I looked at some of the code and they had a lot of different implementations and very little tests. So I wrote all of it test-driven and surprisingly it has worked for so many years.
It was 2016 when I joined and until I left in 2021. It was still running the majority of apps at the New York Times with they library that I built from observable. And when Apple came out with Combined, they simply wrote functions to convert one to another.
Swift Toolkit
RxSwift came after you wrote that I assume?
Krzysztof
RxSwift existed, but was extremely complicated. Again, it was a lot of different paradigms that no one knew. I knew because I use FRP but other members didn't. And we needed something that people could easily learn. So the idea of a value that can change over time is pretty easy to understand. The idea of hot and cold trips people out and then you have a lot of weird bugs.
A lot of the work I've been doing in the last now 12 years has been developer tools and architecture. So the biggest thing isn't building tools and frameworks. The biggest thing is how do I get people to actually use it? And for me, that comes down to it has to be pretty straightforward to learn and the cost of removing it if it doesn't work, especially for tools has to be low. Because if I build something that's extremely hard to integrate or remove, people will be afraid to start using it and they'll never experience the power it can bring. So that's the main premise behind the stuff I built.
Then, after I left the NYT, I went to work at The Browser Company where I was a principal engineer working on DevTools specifically. Usually because of the level I'm at in terms of what I do, I drive my own work stream. So I come up with ideas for a lot of different tooling. At The Browser Company, I build a lot of tools related to the Composable Architecture.
Apps I worked onSwift Toolkit
And when in that journey you decided to write Sourcery, and technically, where did you begin from?
Krzysztof
When I joined the Times, I also provided consulting for a couple of clients before that. And every time we had to write equality and hashing that didn't exist with back then. And I was so annoyed by it, because I became a computer programmer so can automate stuff. I just I had to do the same stuff over and over again and almost never differ. So I had a client where I decided: I'm going to automate this.
I wrote a very simple minimal tool that could generate equality. And then that was 2015. And then I told them: "Guys, I think this is interesting. You should open source it. I'll give you a year. If you don't open source it, I'm going to build a much better and more powerful version of it."
And so 2016 came in. I went to the Times. I thought, well, they didn't open source it. So I wrote a completely new version using templating language. The previous one was hard coded.
And so I wrote Sourcery, the first version. It was actually called Insanity, because of the quote "Insanity is doing the same thing over and over again...". And some people suggested a new name, because it was using ableist language. So I renamed it, I didn't care about the name.
Sourcery has been extremely popular when I released it. Even today, macros are inspired by Sourcery. It's very clear, because a lot of the examples that Apple gave us when macros came out were simply copied from Sourcery. It is still more powerful, because Sourcery allows you to do things that macros simply won't ever be able to do, the main reason being macros work with the visitor pattern.
Swift Toolkit
From a technical standpoint, how does Sourcery and macros differ?
Krzysztof
With macros, when you have the evaluation of AST (Abstract Syntax Tree), it reads the type definition, it sees all the functions and variables, and then executes your code to generate more code in the macro. The thing is, that only works at the place where you assign the macro to, attach the macro to. So if I have a type defined in one file and 10 different extensions in other files or other modules, my macro won't know about those extensions.
Sourcery, in contrast, first scans all code base, aggregates all of the AST abstract syntax tree information, and only then runs the templates. So it knows about all the types and all the functions and all the variables, across different files and modules.
One of the most common things that large companies do is type discovery. Imagine you have hundreds of frameworks and you want to define a widget. Let's say you have an app similar to Instagram, where each post could be of a different type. You could store all of them in different frameworks, adhere them to one protocol, have Sourcery find all instances that implement a specific protocol, and automatically register that in your main application.
So you wouldn't have to do parsing, you wouldn't have to do integration, all of that stuff. I actually teach that, I have an example of that in my course. I used this in a lot of different apps, and it's an extremely powerful pattern. It makes maintainability a lot easier.
Sourcery ProSwift Toolkit
That's very interesting! And you wrote all that on top of SourceKit?
Krzysztof
Yeah, in the beginning, we only had SourceKitten. I used SourceKitten, and after a few years SwiftSyntax came out. I didn't switch immediately, but AirBnb pinged me that the Sourcery performance was slow for them. So they started rewriting their own parser.
Then I spent a week, and I rewrote the whole parser for Sourcery, making it up to 12 times faster. I just pushed to main because I had so many tests that I could rely that I'm not going to break it. Back then around 40,000 or 50,000 teams used Sourcery. Extremely scary to push to main. But my tests covered.
Swift Toolkit
If tests are green, push it!
And do you have any maybe interesting learnings from the Sourcery being open source?
Krzysztof
I have an interesting learning in terms of community, because it's the largest project in terms of contributions that I had. I have around 20 open source projects, so I've been doing this for a while. One thing you have to let go when you do open source is... it's not going to be the same quality you want to write your own production code. Because if I get a PR and I asked for the smallest changes, usually what happens is the PR just gets left over. I remember I asked for just some styling change, and it was hanging for a month.
So the rules I learned with Sourcery: do not break old tests. And if you add new features, add new tests. That's the only requirement. And of course, just don't do anything really stupid. I need to be a little more flexible. So it's not the quality I would write it. I understand people contributing. Most of them are also doing this for free.
Swift Toolkit
Of course, you also need to be pragmatic.
And nowadays you have your own course right? SwityStack.
Krzysztof
Yeah, so I left the browser in May 2023. I I took two or three months off. And then I recorded SwiftyStack. I first did an MVP version of it. So the whole idea of SwiftyStack is, my expertise is developer tools, architecture, just generally improving efficiency of teams, right? That's why people hire me. I can save them hundreds of thousands of dollars in yearly costs by optimizing.
I thought, "Let's make this available to regular developers". So I recorded the first version of it, which was just 90 minutes in total. I never do MVPs, I usually polish my products, but I just wanted to see if anyone was going to be interested in it. I didn't expect much, and at one point, I considered maybe not even releasing it: "Maybe this is not my way of teaching, I enjoy live speaking, running workshops with teams."
But my friend told me: "you already recorded it, just try it". So I released it, and in a couple of days, it sold well and I made around $30,000 or something. And was like, "Holy shit, I need to extend it!. I need to make it better because it's my name." So I spent the next month working from 8AM to 8PM, creating a much larger and longer curriculum. The course now has almost eight hours and 80 lessons.
Swift Toolkit
And how much does it cost?
Krzysztof
It's currently going for $179. I think it's pretty cheap for what it offers. And it's unique in the way that it doesn't teach you about a specific framework, because that you can just go to documentation and read. It shows you how to save time in all the different areas of iOS and Swift development.
I am 100 % sure you will be able to save at least a couple hours per week. If you look at the hourly salaries of engineers, how long until you pay for the course? For most people, it pays for itself the first few days you start using these techniques easily. It's all applicable.
I also mention a bunch of tools that other people build. I mentioned some commercial tools, which I got a deal for the people that bought SwiftyStack. So I don't get any money from it, but I just wanted to promote things that I think are valuable. I got from the authors discount code. So if you get SwiftyStack, get, so the course costs 179. I think discounts in total add up to over $250. So there's more in discounts than the course costs. But the idea is: get the course, become better.
Swift Toolkit
The whole course is about improving efficiency in general. How do you feel about investing in your own career and skills?
Krzysztof
I found over the years is people think about time and money a little wrong, in my opinion. Think about it: let's say you have to go to the office for eight hours, right? So you can keep doing what you're doing and just work eight hours and deliver the same amount of work. Let's say you spend a couple of hours here and there and you get a little better. So now you can deliver the same amount of work in a little bit less time.
Let's say you spend seven hours. Now in your eight hour window that you're at the office, you have one hour for learning. You no longer have to use your personal time. Now you can use that time to get even better and shorten this time more and more. And you get to a point where, it becomes a wheel that starts spinning and it just gets easier and easier. You get to the point where the work that used to take 8 hours now take 4 or 5 hours.
You can keep spending those spare hours to get better and better and shorten this time loop, or you can start splitting it. Once it's a big number, you can start splitting it. Let's say, I was able to do in 4 hours what normally an engineer would do in 8. You can spend 2 hours learning to keep getting better and 2 hours building stuff for yourself, either tools or products, commercial products.
It also makes you less reliant on the job. It's such a great way to approach efficiency. It's not about finishing your work sooner and doing nothing. It's about just getting into the momentum. Once you get the momentum going, it's a lot easier to keep doing this.
Swift Toolkit
That takes us to the last topic I want to touch, which is the subject of some of your recent talks, work-life balance, and lifestyle design.
Krzysztof
There's three different areas that come into play. So you have financial independence, right? That's one of the main parts. The other is how do you actually want to live? Lifestyle design. And then that integrates into work-life balance.
When I was younger, I had very ambitious goals The 1st one was to buy an apartment. The 2nd goal was a larger one: I wanted to be financially independent. I had a number in my head, an arbitrary one. When I reached this number, and the number went up. Then I reached the next number, and it also went up. And it kept going up.
Swift Toolkit
It's a constant chase, we want more and more and never stop chasing.
Krzysztof
Yeah, you're chasing, chasing, just chasing. Every year I would say, this is my last year working full time. Then my friend Felix Krause recommended me a book: Die with Zero. It's an interesting book that talks about having two curves in your life. One curve is your net worth. You have your salary goes ownership goes up, so you have more and more money. But the other curve is your health. And it doesn't matter how healthy you eat, doesn't matter how much you train, that's going to keep going down.
So you have to start thinking about living in decades. All of those ideas in your bucket list, they have an end date. Because I can jump from airplane when I'm 30. It's very unlikely I'll be able to do it when I'm 70 (unless it's going to my last jump). I used to grind, I would just work, work and spend very little money. But I realized I had this year when I made the most money back then. And rather than being happy, I remember, I looked at my tax slip, and then I looked how my year looked. I tried to remember the cool things I did that year: I had three that weren't work. So I thought: I don't think this is the way to live. I was around 27 years old. And I realized that I could earn 20, 30 % less, but enjoy life more.
I completely switched my approach and I started focusing on experiences. I don't need the newest gadgets and stuff like that. But experiences are really worth the money. I can jump from airplane seven times, for the same price of an iPhone! And I remember I jumped in from airplane in 2015 and I'm probably going to remember it until I die.
Swift Toolkit
I assume that way of thinking allowed you to go full independent.
Krzysztof
So finally, in 2023, I fully decided to leave my full-time job, because I wanted to start family in the coming two years. So if I start a family, it's not going to be great time to start being on your own, having new businesses, new ideas. It's too distracting and I want to be a present parent, that's very, very important to me.
So I decided to leave. I went for two weeks to Italy for Swift Heroes, before the conference. And then I was burned out for like two months. I didn't want to code at all after working for so many years. And then I did the course and the course exploded, very successful. And so far, I don't need to work as much. And I make more money, or at least the same amount of mone.
Swift Toolkit
I don't think you regret this change. Any tips for people considering going independent?
Krzysztof
If someone wants to switch to consulting or going that route rather than full time, I think the most important thing is to have good money in the bank so that you don't worry too much and you can select clients well. Because if you don't have savings, then you're going to be under time pressure to find the next gig. And that usually leads to bad gigs. To be honest, you want to have the freedom to choose what you work on. That's one of the goals.
I only have 2 hours scheduled per week with clients. Everything else is mine. Just 2 hours of calls. That's such a difference from my full-time jobs where had every day I had calls.
I want to be present. I want to have time for my friends. I want to have time for my girlfriend or future wife, for my children. I want to be able to work from anywhere. Those were the things I wanted. And once I wrote this, I realized I need some money for that freedom, but it's not the number I was chasing. That number doesn't exist. It doesn't matter because I'm still earning money. I'm still doing what I love.
So I realized, "Well, I can just quit now". So I can already live like this and I don't need to deal with toxic people. Don't need to deal with being annoyed. I can just wake up and decide, "Well, today I'm not going to work. It's a nice weather. I'm just going to go outside". And that's, that's what I do sometimes. There are days where think: "Yeah, I'm not working today". And there are days on the weekends where the weather sucks, everyone is busy, so I'm like: "I'm going to do some work today".
Swift Toolkit
It for sure requires a lot of courage to let go of working full time.
Krzysztof
And it was hard also because when you have more experience, you must come up with your own tasks. The clients have an idea what they want you to work on, but you have to decide what needs to be done, which is harder than if someone tells you what to do. If someone tells you what to do, just go and do it.
Swift Toolkit
Definitely, you're are a complete owner of what you do.
Thank you so much for sharing your experiences and lessons and learnings over the years. These are topics that we usually don't touch in regular talks or conference talks. So it's nice to have a fresh and different approach.
Thanks a lot for joining. We'll be in touch.
Krzysztof
Thank you! Bye