Jeroen Leenarts, the host of the AppForce1 podcast, invited me to record a special episode in early November, while I was still writing my book. We recorded the interview in late December 2020, when the book just came out, and Jeroen published the episode (after much editing—sorry!) in late January 2021. That was a long wait!
You can listen to this special episode on BuzzSprout and hey, while you’re at it, consider subscribing to Jeroen’s podcast (if you’re into this sort of thing). I don’t listen to podcasts, but Jeroen has interviewed some big names in iOS, and the interviews are fun and personal.
As I said, I don’t listen to podcasts, so I made a transcript for all you nerds who don’t either.
Introduction
Jeroen: [00:55] Hi and welcome to another special edition of my podcast. I’m here with Yuri Karabatov. Yuri is an iOS software developer, and he has been working with Babylon Health. And before that, he was developing at TAOlight and Ungert Design. He’s been organizing developer meetups in Moscow as well. And he wrote the book “Junior to Senior.” Hi Yuri, how are you doing?
Yuri: [01:18] I’m doing fine. I just launched my book :)
Jeroen: [01:21] How did the launch go? I think you’re still in the soft launch phase. You just wanted to get it out and still needed to do some marketing. But the initial impressions, how does it go?
Yuri: [01:32] Yeah, as you’re saying, it is basically in soft launch because my main goal for writing the book was to finish it. I never had any big writing projects before, and it was basically an experiment for me to see if I can make it. Even halfway through writing I wasn’t sure that it’s going to turn out well. And because of the soft launch, I still don’t have any substantial reviews yet.
I’m selling the book through Gumroad and I have a few five star ratings there, but I didn’t yet get any reviews that go into detail on the book. The timeframe was compressed because I only had one and a half months to finish the book. Even a bit less than that, so five or six weeks—six weeks.
(If you’re curious, I wrote a huge post that goes into (excruciating) detail on why and how I wrote “Junior to Senior.”)
Why write a book?
Jeroen: [02:35] What made you decide that you wanted to write a book actually, or at least try to write a book because you said it was a big experiment?
Yuri: [02:42] Since I’ve left my previous job at Babylon Health, I’m on a sabbatical, so to say. So right now I am free to do something else and I decided to use that time first to see if I had something worth sharing with other people.
Well, I am a developer. I know I can write code and I have some projects that are on and off that I’m working on right now. But I wanted to do something different and find if I had something to share that came from my own experience, and that for which I didn’t need to look for any references or to do much research.
If you know, there’s Daniel Vassallo (who is also working for Gumroad now) who has become recently popular on Twitter with his idea of making small bets—basically, publishing something quickly and seeing how it does, and iterating based on that.
In one of his tweets, he said that your first product might be something that you can produce really quickly from your own experience. It should feel as if you’re writing it without the need to do any research, it should come easily. And I decided to look for something like that also because I wanted to practice writing. It’s a bit complicated, why exactly I decided to write a book, honestly, because it’s all about experimenting.
Jeroen: [04:43] If you look at the book, it’s called “Junior to Senior: How to Level Up as a Software Engineer.” On the product page, you state that you have written this book after being a software developer for ten years. And you wanted to write a book that you wish you had at the beginning of your own development career. That sounds like you have a sort of archetype reader in mind of your book. So can you tell a bit about who you have written this book for?
Yuri: [05:17] Pretty much I had in mind a few of my friends who are self-taught young engineers. There are some actual people whom I’ve written this book for. In them, I see myself a few years ago when I was just starting in the software development career.
The windy path to iOS
Jeroen: [05:43] You’ve been a systems administrator before you became a software developer. When did you start working, what year was that?
Yuri: [05:50] I don’t have a degree, partly just because I didn’t finish university, but I studied for four years at two different universities. In the end, I moved to another city for a job and I never finished studying so I didn’t get my degree. I started working at 16 when I just entered my first university where I studied physics, and I started working basically as an IT support engineer. I’ve been working there while I’ve been studying. I started working in 2004, I think, and when I left in 2008, it was for a job as a systems administrator.
After that, I kept working as a systems administrator. But I decided to become a software engineer because I knew that I had to grow my career, and a “default” systems administrator is a very office-based role, like, you know, there are DevOps who manage the clouds, and then there are the sysadmins who are local to the office. So I was the second one.
Jeroen: [07:32] You have to have the hands on the machines to actually be able to support them.
Yuri: [07:35] Yeah, yeah, exactly. It was fun. I liked it because my core skill is solving problems, and being a sysadmin is solving problems all day. So that was fun, and I like working with hardware. But at that point I had a choice either to become a DevOps (yes, I know “DevOps” is not a role) or become a software engineer. And I chose to be a software engineer.
Jeroen: [08:09] So then what did you need to do? Because you were a systems administrator, you are familiar with computers, but software has to be written, so you need to do programming. As a systems administrator you of course do some scripting to automate installation processes. So was it a big leap for you to switch from systems administration to software development?
Yuri: [08:32] Yeah, that was a bit complicated. I never—well, I did program a little bit at the university. I even went to the ACM programming competition, if you know that. So I did some programming, some competitive programming at the university, but I never worked as a programmer after that. I chose iOS because at that time I bought a Mac, I liked how it worked. I liked iPhones, basically, so I decided why not? It could be a good starting point since iPhone apps were something that you could touch. It’s a very attractive notion to create something that you can interact with.
I started to learn iOS development through the Stanford course. I did a lot of false starts, I guess. I worked on my own app for a while. Then by chance I found a designer who wanted someone to implement an app that he designed. It was a passion project, it was not freelancing, so we decided to try it out. We never finished it in the end, but both of us have got some experience. And after that, I was at a level where I was able to find actual work through a friend. Well, after that, I kept working already full time.
Jeroen: [10:18] What I find interesting, if I look at your résumé, is that you spent a large amount of time in Russia, in Moscow, but then there’s Ungert Design in Hong Kong.
Yuri: [10:33] Oh, that was a really fun story. My work history is just all over the place, really.
Working remotely
Jeroen: [10:40] Quite literally. But how did you end up in Hong Kong then?
Yuri: [10:46] The thing is, all this time I’ve been working remotely. After I had a brief stint as a web analyst doing Google Analytics and writing JavaScript for different people as a freelancer, I worked again as a sysadmin for a while when I started learning iOS development. And then I worked as an iOS engineer at a friend’s company, but remotely.
Jeroen: [11:20] You mentioned that you wanted to get out of systems administration because you are tied to an office building, really. So the move away from systems administration was also to be able to work remotely? That was something that was sort of mandatory when you would work for someone, or how did that work?
Yuri: [11:38] What happened was we moved out with my wife into the suburbs. So going to Moscow into an office required traveling for one and a half or two hours one way, and working at an office was just impossible with that commute time.
I knew I could find something remote. And at that time I think I read Tim Ferriss’s “The 4-Hour Workweek,” and I decided to get out more on Twitter. I knew that was possible and I wanted to try working remotely. So being able to work remotely was a prerequisite.
Jeroen: [12:29] Was it hard to find your first job remotely or how did that work out?
Yuri: [12:38] The first few ones, they really fell into my lap. So at first I tried to make my own app. Then a friend referred me to a company of their friend. Then another friend called me to work with them because they knew I was a decent person. I mean, I was learning to be an iOS engineer. I wasn’t a really great software engineer, but they knew me as a person—that I would be able to do it. They hired me and I worked with with that company for a while. But after that, Ungert Design was my first company that employed me based on my skills. And that was a big breakthrough for me. Also, the fact that it was in Hong Kong, of all places.
Jeroen: [13:37] OK. And then you you went on to, let’s see, TAOlight and then Babylon Health, also both development roles.
Yuri: [13:46] Yeah. Ungert Design was a startup that made an app for coworking space management, but it didn’t work out in the end. It was really small. We had a little bit of capital, but it didn’t last too long. Yeah, it was a startup that didn’t take off. It was really fun to work with. All the people that worked there are my friends, so I think it worked out pretty well. But after that, the founder had to look for a job, basically because the startup didn’t work out. And at the company that he got into, TAOlight, they were looking to start their own mobile team. As the engineers from the startup, we were hired to be on that team. It was a really quick and short transition. And I spent a few years there.
Jeroen: [14:52] From your LinkedIn history at TAOlight, I see that you also did some writing for junior developers, so writing guidelines for them. Is that also based on your idea that you want to give something to junior developers, because the book that you’ve written is also “Junior to Senior” and the book that you wanted to have when you were a junior software developer. Is there a link between these two things or…?
Yuri: [15:16] Now that you mention it? Probably. Probably. I like to teach people in the sense that I use my knowledge to help out others if I can. But usually it is very personal. If I have some friends that I know, then I help them.
Jeroen: [15:38] After TAOlight, which is a connected lights, technology-related firm, it seems, you went to Babylon Health in London.
One company or job-hopping?
Yuri: [15:50] Notice that there was a break of a year between them.
Jeroen: [15:55] Did you take time off for a year or what happened?
Yuri: [15:58] I left TAOlight on my own because the company kind of changed direction a little bit. It was mostly about me rather than them. But maybe my main issue was that I didn’t grow as much as I wanted. Now, looking back and looking at my own advice that I’ve put in the book, I could use that place as a place for growth, actually, because the company trusted me and I could choose any direction I wanted. I could move into web, for example, or experiment more with the iOS app. Looking back, I think it was an overreaction on my part.
Jeroen: [16:44] It’s actually interesting what you mentioned there, because I myself sticked at my first job for over nine years and I learned a lot there and actually grew a lot as there well. I was not even out of that company for half a year and I don’t have any regrets for sticking with them for nine years, but in hindsight, I would have said I should have left that company after four, maybe five years just to broaden my horizon and just see a different way that a company can do the business.
I still have good relations with many of my old colleagues there. And it’s a company that I worked for—that’s already 10 years ago. But a number of people I still have in my network. That’s something that I noticed myself, actually. That I’m not one of those people that’s a fan of really hopping around a lot from place to place, but I do think that there is a pitfall in sticking with one place for too long if it’s at the beginning of your career. But that’s my personal opinion, of course.
Yuri: [17:54] Yeah, I talk about that in my book. Basically, in my experience, I didn’t spend much time anywhere just because, well, I’m such a person that I quickly get bored of something, if you know what I mean. I’m not “bored” bored, but after you’ve mastered your work, if you are not pushed to grow, when you are forced to learn by yourself and not from the requirements of your work, it can become a little bit underwhelming. Right?
Again, looking back, I would say that I’d rather choose to learn by myself and spend the extra effort than look for a job that pushed me to grow. Because when you’re doing self-directed learning, you have a little bit more freedom to learn what you want. And it’s less stressful. But again, being in a job that forces you to learn, that has high demands but doesn’t stress you over too much, then that is a great place for learning too. These are two things that are hard to choose between. I try to mention and discuss all of that in my book.
What I recommend to junior engineers, looking back at my experience, is to stick at a company for a few years until you are a middle engineer, until you understand the project, and until you do research to understand if you’re missing learning compared to where the industry is moving. There’s nothing wrong in staying at a company for nine years, for ten years, if you are growing, if you are changing roles. And this is also something that I talk about in the section “You are not your role.” It means that in five years, you will likely not even use the same programming language.
Jeroen: [20:18] That’s true.
Yuri: [20:18] That’s because the job changes from under you. Even if you don’t move on purpose, the industry moves on and you will use new libraries, probably a new programming language, you will work on a different project. And that will give you learning opportunities, too. So there’s nothing wrong, really, staying for a long time working at one company.
But you have to look around to see if you’re missing on jumping on the train, basically, because if you keep working on the same project, doing roughly the same things, then there’s a saying that you can have the same year of experience five times instead of having five years of extra experience. When there comes the time to leave this company, because it may come sooner than you expect, maybe your department will be reorganized and you’ll be let go, or something. You never know. You might discover, if you never look around, that the industry has moved on and your skills are obsolete. But if you watch the industry and what’s happening around you and learn new things, then there’s nothing wrong in growing at one company, if it challenges you.
Staying relevant
Jeroen: [21:52] If you want to stay relevant as a software developer, it’s good to look outside of your current role. If you’re just doing your day job and and you’re just having fun—at least that’s what I hope most people have when they’re working—what is a way to actually stay aware of the direction that the entire field of software development is going, or at least the parts that are relevant to the technology that you’re working on?
Because, for instance, if you look at iOS development, we worked with Objective-C for quite a while, but nowadays you wouldn’t start a new app with Objective-C in most cases, and you would probably even start a new app with SwiftUI and not with UIKit as the main user interface framework. What I have noticed is that quite often if new tech arrives, there’s always this time frame that it’s still unclear whether or not it’s the actual new direction, whether or not the technology is stable, whether or not it’s a valid direction to go.
Yuri: [22:59] What I would say is that you do not have to spend much time looking into stuff and even learning things. For example, I can honestly say, I don’t know SwiftUI. I never spent the time to learn it because our app Babylon Health couldn’t use SwiftUI yet because we needed to be backwards-compatible. SwiftUI is now two years old, but I never learned it—yet. I know I have to in the future, I know that it exists, I know some of its pitfalls and its strengths because I’m just basically reading two newsletters. That’s it. And I’m just watching what happens on Twitter. I don’t spend much time doing that.
There is this recent controversy in software development where people would say, like, you need to do side projects or you’re not a real developer. If you don’t spend your nights tinkering on something, then you are not a real developer. But you can only do software development at work and keep up with the industry at work by reading a couple of newsletters. You don’t have to watch everything closely or experiment with something, because if you don’t need it at work, then, well, you can just be aware of it and learn it when it comes along.
If something becomes really big, like Swift, you know, then you will probably notice that. It’s hard not to notice, unless you’re literally living under a rock. Because Swift just took over iOS completely and it’s really hard not to notice that.
Being an early adopter
Jeroen: [25:15] With Swift, I still remember the language transitions between version one and version two and version three.
Yuri: [25:22] That was great.
Jeroen: [25:25] Indeed, that was great. It was a lot of fun. New Xcode version came around and then, oh, we’re not making the sprint this time around. Why not? Well, there’s a new version of Xcode available and we need to update our Swift codebase before we can continue. That makes for a happy business sponsor, I can tell you.
Yuri: [25:43] Actually, this happened while I was freelancing. A bit of advice is that you can become an early adopter of that thing and leave the experts behind, because everyone starts at zero. That is what I did with Swift since I wasn’t employed full-time. Working with Objective-C at the time, I had a little bit of time—a few months—to really dig down and learn Swift and that directly got me a job.
Having an emergency fund
Jeroen: [26:21] At some point you were working at Babylon Health. That was until May 2020. But why give up your job and just be on your own for a while without any responsibilities besides just living your life?
Yuri: [26:34] There were some internal changes at the company that involved reshuffling the mobile team a lot. Since I was a contractor, I was let go before the end of my contract. It happens, it’s fine. But I decided that since it worked out for me last time, I thought that it would work out this time too.
Before I got a job at Babylon Health, I also spent almost a year not working. I can say that I’m really lucky that I can do that because of the structure of my expenses. Basically, we tried to keep expenses really low so that we have a decently sized emergency fund that we can spend without worrying too much about money. So I’m really lucky to have that.
Jeroen: [27:32] Which is actually very sound financial advice, to have a nest egg that is either like half year in size or maybe even a year in size. It takes a bit of effort. But just knowing that whatever your company throws at you—or maybe they throw you out—knowing that you still will be fine for at least half a year to a year without any financial support is actually a very comforting thing to do. And I can highly recommend that to anyone who is able to get that together on their bank account, really.
Yuri: [28:05] That is pretty much something that I’ve been doing on purpose. After I left TAOlight, I decided that I wanted to work again in a remote international company that paid well and where I could be a senior engineer, finally. I launched a small app, I worked on my interviewing skills, I researched how careers worked and all that. I talked to a lot of people and I’ve been looking for companies that fit what I was looking for. I found Babylon Health on Twitter where a recruiter said that they are hiring remote and all that. Right now, when I’ve had to stop working at Babylon Health, I’m taking a break to upgrade myself again while I have the time and the means to do so, because I purposefully work on being able to take these breaks.
Do I even want to still do iOS?
Jeroen: [29:15] And then you had the Gumroad experience, the 14-day challenge and then you decided to continue on that challenge and make it into a full book. Or how did that work out for you?
Yuri: [29:30] I decided, do I even want to do iOS anymore? That was a big question for me, because I don’t like the long Swift compilation times, I’m not a fan of the overall direction Swift is taking.
I still like the excitement of doing something interactive. But at the same time, I decided to look more into, for example, the indie hacking development, people launching web services and different stuff. And Swift is my only working language that I’m really proficient in. I can do something in Python and JavaScript a little bit, but not too much. So Swift is my only working language, and I don’t like that. It doesn’t really become something outside of Apple platforms. Sure, it has a Linux version. You can do some web development with it. And we did some services at Babylon Health, but still it’s not moving in a direction that allows me to use it everywhere.
Jeroen: [30:56] It’s not ubiquitous like, Python, Django or Ruby on Rails or PHP, that there’s not a lot of job postings out there, hey, we are looking for somebody capable with Swift for our server.
Yuri: [31:08] It’s not like it’s a problem per se. I was just looking to expand my skillset.
The process of writing
Jeroen: [31:16] So, the book “Junior to Senior” and the writing process—what did you use to actually do the writing itself? Was it like an outline that you created, even though it might have been just a draft and that you then started fleshing out, or…?
Yuri: [31:32] I decided beforehand that I’m going to write in Markdown because I have lots of notes. All my notes are in Markdown and the book was going to be in Markdown too. How to write it… for me it turned out that book writing was very linear. I did some research throughout writing to back up my claims, but it was pretty minor.
First I just jotted down random thoughts and I spent the first day doing that, just jotting down random thoughts that I could talk about in relation to moving from being a junior to a senior engineer, upgrading your career and working on your skills, interviewing. So basically, anything that I could talk about. It wasn’t structured. It was really random.
And then after that, I collected these notes, which were just a huge text file and made an outline out of them. And after that, I could work from this outline.
Jeroen: [32:50] As you already mentioned, you initially started with the book due to the challenge of Gumroad one day starting a new author platform. And you wrote the book specifically targeted at people that you had in your own network. I think you said colleagues or friends that are actually starting out as software developers. And so how did that work out? You had a bunch of notes. You had a target audience. How did you combine the two and created something that was comprehensive?
Yuri: [33:21] Making an outline helps me focus on just several points rather than going in different directions. For example, a very similar book is “The Pragmatic Programmer.” I was kind of aiming for creating something like that, but from my own experience and more non-technical.
What are junior engineers missing?
Jeroen: [33:42] It’s interesting that you mentioned “The Pragmatic Programmer” because the 20th anniversary edition just came out last year. Quite recently, I again suggested that specific book to somebody who is self-taught, trying to get into a software development career and who basically had the question, OK, I kinda know how to program, but how do I become a software developer?
A lot of people doing programming and who want to do it professionally have a hard time gaining the skills, gaining the knowledge to actually be able to consider themselves software developers. Because to me there’s a big distinction between programming something or developing some software. And I do see that in your book, you try to provide a person with suggestions on how they can, in a quite deliberate way, improve their skills that are relevant and worthwhile in a business scenario. Was that on purpose, that you want to teach your friends how to be a valuable software developer?
Yuri: [34:50] Yes, and this was actually the section that I did some research for. I had some hunches and in my experience, actual software development work and working in companies is not too much and not only about programming. It’s also a lot about interpersonal skills and how you communicate, how you work on a team.
And this research confirmed my hunches—it specified what the business, the companies saw as lacking in new engineers who have just left a bootcamp, who have just left a university. They know how to program, they know how to create something—to create products, maybe—but they do not know specifically how the workplace works. What do you do at work? How do big software projects get developed? Even if you’re working alone on some piece of code, you’re still working within the framework of the company. You work with design, you work with product people. You maybe work with business people.
It’s also important to know that it’s not enough to just write code. Learning how to behave and communicate and how the business works is not knowledge that you get by osmosis. Basically, you have to go out of your way to find out how the company works, if you’re a junior software engineer.
Jeroen: [36:43] And so that’s the specific area that you want to provide guidance so that people able to write some code can actually become a true software developer?
Yuri: [36:54] It’s useful knowledge because it allows you to be more efficient and more useful to the business, because, again, if you want to maximize the potential of your career, then—and if you want to continue working—you have to know how the business works.
“Considerate communication”
Jeroen: [37:19] In my mind, teams that truly collaborate with each other as a whole get further, but also the individuals within the team professionally achieve more for themselves. I don’t think it’s a zero-sum situation. The business gains—the team gains—a lot. And individuals also get equipped with more skills and more worthwhile abilities that they can then, at a later stage in their career, actually do very useful and required things with for themselves, the business and whoever they come across in their career.
Yuri: [37:59] Yes, exactly. One of the things that I think is particularly important is what I call “considerate communication” in the book. This is primarily the act of not wasting anyone’s time, including yours. I make a big fuss about not bothering other people more than necessary, but also spending this time thinking about other people to improve yourself.
There may be two extremes, basically, either you ask other people for help at the first sight of a problem and then you are unlikely to learn much because other people will be doing the work. And it’s not respectful towards them. And the other extreme—that is actually quite frequent in software developers—is to have this notion that you have to do everything by yourself to prove that you can finish the task, that you know how to code something.
This is also an extreme that is not beneficial towards improving yourself because you will spend too much time floundering about, and trying, and bashing your head against the problem when you could reasonably spend some time on the problem, and if you can’t get a solution, then you can ask someone. That saves the other people’s time since you don’t ask them right away. But also it saves your time because you don’t spend several extra hours not making any progress at all.
The goals for the book
Jeroen: [40:08] Why should people buy your book? Why should people read it?
Yuri: [40:13] That’s a really good question. As I said, I wrote the book primarily to directly help some people I know and also to prove to myself that I can write a book not from second hand experience or something else, but write a book with advice that comes from my own experience that is worth something. These were my two primary goals.
But as the structure of the book came into view, what I can say about it is where it can benefit people is that it is non-technical, first of all. What I see a lot in the developer world, a lot of people are writing technical books, but not many people share career advice or how to improve in not only in your career, but as a developer—not in some particular language or by doing some particular thing.
My book is an abstracted way of looking at your career, at your knowledge, and it gives some frameworks how I think about my career and the knowledge maps that people could use in their journey to improving themselves as software engineers.
I know I’m not perfect, but I’m interested in systems and frameworks, especially mental frameworks of how to approach things, how to do things “the right way.” And I thought a lot about how to approach learning in software development and the software development career. These two bits of knowledge are distilled in my book.
Jeroen: [42:27] To me, the book comes across as to be aware that there is some level of control that you can exert as a software developer on the development of your own career. It’s not that you are, as a software developer, left to the whims of the company that you work for—if they promote you or if they give you more salary—but that it’s actually you as an individual who can take control and do things that have impact on the long term of your own personal development. Is that a correct assessment?
Yuri: [42:57] Absolutely. For a lot of people, a job is just something that pays the bills and they don’t want to think about their job after work. I personally am not satisfied with myself, with my skills, with how my career progresses sometimes. I try to see what points of control I have and how I can maybe either exploit them or work on myself that I become better.
Plans for 2021
Jeroen: [43:30] Now, you’ve published your book. You also mentioned that you still need to do some marketing with the book. You did a soft launch and now you’re going to do the real launch in a few weeks, I guess? So then the book is selling or it’s not selling. What are your plans from now into the next year?
Yuri: [43:53] As I said, after I left my previous job, I thought about improving myself a little bit more in a more purposeful way, I guess. For example, I started this new blog of mine, NorikiTech, which has zero posts at the moment (not anymore! –future Yuri) because this Gumroad challenge came along, and this book idea popped into my head, and I decided to write it instead of writing something else. This comes back to my intention of improving my writing and being more visible and sharing my knowledge.
I looked back at what I did before and I noticed that I’m mostly a knowledge hoarder rather than a knowledge sharer. But sharing knowledge at the same time gives you more learning opportunities for yourself, both to teach others and to learn the material better yourself. New, exciting opportunities can come out of it.
Writing is one of my plans for the new year. I want to really make an effort at writing some very interesting posts on my new blog, both exploring some technical things and career things. If my book is about improving careers, then I’m going to write about that.
I also want to write about some technical stuff. For example, I worked on my game and I learned C++ to write custom font rendering for it because I needed some, well, strange layout that nothing supported. That’s an interesting thing, so I wanted to write about that, too. This is one of my goals for the year and another is to—believe it or not—catch up on computer science. I noticed that this question came up a few times over the past years. I’m self-taught, so I never studied it formally and I never needed it for iOS, really.
There isn’t much from computer science that you actually use in iOS development for some reason, except maybe for some graphics. There is not much, really, and I’ve done a lot in iOS. But again, I want to be a software engineer who can do more than just iOS, and for that, I need to close the gaps in my knowledge and also be more articulate about sharing what I know. So these are the two things that I want to work on for the next year.
Links
Jeroen: [47:14] If people are interested in your book, where can they find it online?
Yuri: [47:18] Either on Gumroad—you’ll find a link in the description of the podcast—and also it’s pinned to my Twitter profile, which is my surname. The book is also on Goodreads so you can just look for “Junior to Senior” and you’ll find it. It has a black and yellow cover.
Jeroen: [47:36] OK, this is Yuri. He just published his book and he clearly indicates that he wants to grow more in the next year by actually sharing more. And I think being on my podcast, this is a nice small step in that direction. It was fun talking to you, Yuri. If people have any questions, how can they reach you?
Yuri: [47:58] I’m most active probably on Twitter. My handle is my surname that you’ll see in the title of the podcast. From there, I have a link both to my new blog and to my book. So that’s probably the best place.
Jeroen: [48:14] Yuri, very much thank you for your time and I hope to see you someday in the future in person, maybe, if conditions permit. So thank you very much.
Yuri: [48:29] Thanks for having me. It’s been fun to be on a podcast. That’s my first podcast!
Jeroen: [48:35] Glad to be of service.