Apple Podcasts Google Podcasts Spotify

Have a look at our new "Complete Guide to Optimizing Slow Tests"! Discover →

Back to the list
Filip Hraček
Episode 44, Sep 14 2021

Unicorn Developers With Filip Hraček

Featuring Filip Hraček, developer relations engineer at Google.
Apple Podcasts Google Podcasts Spotify

In this episode of Semaphore Uncut we welcome Filip Hráček, developer relations engineer at Google, and talk about what’s great about Flutter, how to out as a developer, and the importance of keeping your motivation up.

🎧 Key takeaways:

  • The art of finishing projects
  • The pros and cons of tinkering with side projects
  • How to keep motivation up and keep learning
  • What are unicorn developers?

Listen to our entire conversation above, and check out my favorite parts in the episode highlights!

You can also get Semaphore Uncut on Apple PodcastsSpotifyGoogle PodcastsStitcher, and more.

Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

Edited Transcript

Darko (00:02): Hello, and welcome to Semaphore, a podcast for developers about building great products. Today I’m excited to welcome Filip Hraček, Phillip, thank you much for joining us.

Filip (00:11): Thank you. Thank you for having me.

Darko (00:13): Yeah, please just go ahead and introduce yourself.

Filip (00:15): My name is Filip Hracek, I am a developer relations engineer at Google and I’m working on the Flutter team.

Darko (00:21): Great. Can you give us maybe a path how you ended up doing what you’re doing today?

Filip (00:27): I started programming on a typewriter before we had a computer. I was enamored in programming after reading a book for like several times, and then I just, we didn’t have a computer, but typewriter was kind of looked like a computer. So I started writing programs on that. I started programming in a very young age and then continued programming for a long time. And then when I was in my teenage years, I realized to my horror that my father is approving of this turn of events. My father was like, oh yeah, that’s great. You’ll have a stable job with a lot of money. That’s great. And of course, I was an idiot, so I needed to do something else. My training is in journalism, so that’s my university degree is in journalism, but I still stayed close to the programming.

Filip (01:18): And in the end, this kind of rebellion actually was pretty good for me because when I joined the workforce, I guess. I started kind of merging the two things. So I knew programming, but I also knew how to talk and write about stuff. And so this kind of naturally led into me being kind of a trainer and like an explainer of things. And that’s what I’ve been doing ever since basically. So I’ve been at Google for 13 years now. And for the past 10 years, I have been helping developers understand and views as the case.

What is Flutter

Darko (01:59): Great. And coming back to what you are focusing on today, it’s as far as I know, related to Flutter, right?

Filip (02:06): Yes. Yes. So I’m a developer relations engineer on Flutter, which means that I work on code samples on videos, on documentation about that particular thing. Some people might know it, some people mightn’t. So Flutter is the gate for building apps for Android, iOS, desktop web, all the platforms. The main selling point, I guess, is that it ships with its own rendering engine. And therefore it looks the same on all of those platforms. And it also runs very well on all those platforms because it doesn’t need to go through another third party rendering engine or anything like that. So, yeah, so that’s Flutter and of course the team is pretty big now. So I specialize, I specialize in performance. I specialize in state management, and I specialize in that kind of interface between designer and developer.

Unicorn developers

Darko (04:43): And you also mentioned that you are somehow helping developer designer relationship is what you’re focusing on. Can you expand on that?

Filip (04:52): Yes. So this is really my passion kind of, because of my history as well, because I did audiovisual design in school and stuff like that. I think if you look at, this is a cliche, but if you look at our day-to-day as users, we have screens everywhere. There’s a bunch of things happening on the screen all the time. Just now I have four screens around me, and it’s not even like a special thing. This is normal and also new and exciting things are coming to the hardware of screens. Right? I just learned about these translucent screens. So experience that you can look through, like in Minority Report and, Star Wars, that’s exciting. And that’s something that we as developers need to deal with. And I think it really, really makes you as a developer, a lot more valuable and employable if you know, design, if you know how to deal with these things.

Filip (05:54): And if you have part of you, that kind can think in colors and typography and motion design and so on and so forth. So I think this is a Microsoft thing, but they said that when they found a developer who knew design, they called them unicorn developers because they were rare, but they were also very valuable because when you have all of that in one hat, you don’t need to spend time explaining between one another, the things that can be done and should be done. Right. And the third thing is that in this world where we have so many screens, so many different form factors, it is more and more important to think about procedural design and what I mean by that. It’s not something that you can design in Adobe after effects or some, Figma, it’s something that needs to automatically translate to the environment. Like an app that knows that it is on a big screen, but also there is another component to it that is running on a smaller screen. And that screen is to the left. And now it’s to the right of the big screen, right? So now you have to fluidly do something. And this is an extreme example, but there are so many things that you can’t do as a static design you have to do in code.

The art of finishing projects

Darko (08:41): Moving from here. Is there maybe something else working over time that is now become the maybe focus of how you see things and what are important?

Filip (08:51): Yeah. I’m thinking there are a few things. One thing that I realized recently was the art of finishing, basically how we as developers are really good at tinkering and optimizing. Yeah. I’m generalizing, but a lot of us are really love looking at stuff deeply and thinking about stuff.

Filip (09:14): And then it’s really hard for us to finish, unless we have some pressure from outside, right. So if you’re in a team, then it’s pretty easy to finish because everyone else is kind of pushing on you, but I’ve seen it on myself and on others. If you’re building something of your own, maybe you have a side project, then it’s really easy to just keep working on that side project forever and then come up with a new one and then work on that forever. And never finish. The thing is as you know, as a founder, something that feels like the last 20% of any project is actually the 80% of any project. And it’s often the most boring and least motivating part of the project. I think in this, not a board, they say, right? If you are bored, you’re on the right track. Isn’t that the case?

Darko (10:07): Well, there are many indicators I can agree that could be one of those. Yeah.

Filip (10:14): So, so anyway, I think that’s important to realize that it feels much better if you actually launch and finish something, even if it’s a side project, but a lot of people will not do that because it means a lot of, kind of self-discipline and sometimes pain that you have to go through. But again, it’s really nice to be able to say, yeah, I’ve finished something and now it’s out. And I always say, this is why God invented product managers because without product managers, some of the engineers would just keep tinkering and working and also discussing something. So this is a tangent, right. But I can’t count the number of hours that I’ve spent reading and clicking through like hacker news and Reddit about stuff that really isn’t that important, but it feels really important and it feels really good. It’s like juice for my brain, but it really isn’t that important.

Darko (12:30): That industry of game development is notorious for, some games are five times over the budget and deadline and all that, but what would you maybe pull out as the three things that you would share on finishing projects and putting you in that mindset of, okay you’re going to succeed and do this, this and this.

Filip (12:52): First of all, I think it’s, alcoholics anonymous, you have to understand that you have a problem. Right? A lot of people are like well, I don’t really want to finish it because I have a new project. So I think that’s the first step it’s like, no, no, no, you actually pick a project and say to yourself, I need to finish it. And it can’t be, oh, I finished an experiment. No, you have to actually launch something. So that’s the first, that was a really important step for me for a long time. I was like, oh, I’m just playing. But no, that doesn’t count. That doesn’t count as much as when you actually launch. So that’s first. Second, understand that building a product is a lot of boring kind of grind in the end. Right. And if you see it, instead of backing away immediately, you should be like, oh, this is what it feels like to finish and kind of go through it.

Filip (13:49): It’s not all grind of course, but it’s definitely, you lose that first few months of doing any project. It’s like, oh, this is exciting. And I’m doing so much progress. That’s not what finishing the product feels like at all, but in the end you finish it. And it’s really great. It feels really great. And the third one, and that’s something completely lifted from that article that I’m talking about is just having a launch date or having something that you tell others that, okay, I’m going to work on this and I will finish it by January, 2023 or something like this. And then you have to be the PM of yourself in a side project that I recently finished. I had to do all these things like creating a spreadsheet and figuring out which features will take how many weeks and then actually slashing some of these features, actually most of these features and thinking it as a PM really helped.

How to learn

Darko (14:54): Yeah. Great. Just wanted to add to the second point that you were presenting, if you’re alone in it, at first there is that self-doubt, especially when you get to that boring stuff. Okay. Maybe it shouldn’t be like this. This is now assigned a time now in some deadlines three that I shouldn’t be in because it feels that way. And once you learn that there is a period in project where usually have that feeling of like doing that last five iterations on small and boring stuff, as you said, oh, that’s what finishing feels like. And maybe connected to this, to some extent, tinkering with things. It’s great. It’s what education for a lot of us is when you’re playing on the side of the things that is the way you learn, so that finishing things and learning and helping people they just these new SDKs and so on. Are there some patterns that you might be seeing that you might give advice to people who are onboarding Flutter, any other SDK, how to approach it, how to set the goals, boundaries, or structure milestones for yourself?

Filip (16:03): Yes. That’s a great question because we’re thinking about it a lot in Flutter, especially. Flutter excels in kind of UI and kind of this short iteration time. So it’s very good for tinkering and that is both good and bad, right? Because sometimes you just get enamored and making a little changes to some project and then it kind of flickers out and you don’t really have anything. So my advice, if you’re trying to learn a new SDK, everyone is a little different in their approach, but I think most people will love to have some motivation for learning that new thing. Right. And I mean, not an abstract motivation as in like, I want to make money, but more concrete. Like I want to build this particular thing. And I think the best approach is to say, okay, I’m going to do the first tutorial, because that’s often needed, go through the official tutorials first to learn stuff, and that’s kind of boring, but it’s important.

Filip (17:13): And then take that information and then just start tinkering and working on something that you care about, but make it small, at first do something like, oh, I want to do a little app that will track, I don’t know whether and the main goal, for example, is to put it into your portfolio. Maybe you’re starting out, there’s an engineer, so you want to have something there. Right? And so you start doing that. And then by being motivated in building and finishing something, you will have a lot more motivation to learn. The stuff that people are talking about. What I’ve seen is some people will kind of start just learning, like in school, they will start reading articles, but they don’t understand why they actually need to learn that, until they actually face it in their work. And they are like, oh, okay.

Filip (18:10): Now for example, in state management, they will try tinkering in with some kind of naive approach, which I think is fine. You shouldn’t wait until you understand everything. You will start with the naive approach. Then you will find how that naive approach can be bad. And then you read about how to make it better instead of trying to learn without any experience about the best possible approach. And then applying it religiously through everything and not really knowing why you’re doing it. I think that’s the best way to learn SDKs, and new technology in general.

CI/CD is like magic

Darko (18:50): Great. These are great advice. And then it ties to what we were talking about previously, if there is that small app, which can be a weather tracker or calculator or whatever in that new thing, but if you want to finish it, then you will also probably get to some boring stuff like packaging and shipping and your release management, which I know for me personally, it was not ever super exciting part, but it has to be done. And you has to go through that last chapter for the book. Usually in my mind, there is in any programming book, there are those last two chapters, is there release management or something like that, that you never want to touch in our events, particularly. For some things, my personal experience, I ended up pushing through maybe even a couple of years without really digesting that. Or I could here in the beginning, but just wasn’t interesting.

Filip (19:43): Yes, yes. And it’s also by actually doing these things and forcing yourself to do these things. You will demystify them for me, like CI/CD a few years ago, it was just magic. It was like, I don’t understand what this does. And I probably am not smart enough to understand this, please, someone else do this. And then you are forced to use it. And you’re like, oh, it’s actually just some computers running your code somewhere. You know, it’s not that complicated. It’s just, you have to force yourself to do it.

Darko (20:20): We are not running in danger of ending the episode of CI/CD. Is something that is carrying out there. And I can just encourage people. No, it’s not, it’s not there. Just get through it. And I would just add that when people, especially, maybe non-technical people ask me to explain what CI/CD is and the CI is, is that it’s a communication tool. That’s a tool that helps you communicate with your fellow developers around the office. So we know what our state is.

Filip (20:55): That’s a clever way to put it. Yeah. But yeah. So let’s not end on CI/CD. I want to go back to the UI stuff. I think if you’re an engineer, it doesn’t matter if you’re new or actually with the experience, please go and pick up a book about design. I found a book called something like universal principles of design, which kind of, it has, for every principle of design just has one page. And this taught me a lot about how to structure things and then allow yourself to experiment with UI. I’m a big, big nerd into sci-fi UI. Like what they call futuristic UI. The stuff that you see in movies used in Alien or Minority Report. And I feel that it’s time has come because in some ways, of course the movie UI is made to look nice and it isn’t necessarily made to be used well, but we are now in a time where we no longer need to describe everything in terms of metaphors.

Filip (22:06): When I was starting with UIs back in nineties, everything needed to be very, very clear because for a lot of people, computers were new. You know, every icon had to have the safe button. But now if you look at who’s using computers, nobody needs that anymore. So you can be a lot more free in how you build your UIs. And especially if you think about all the translucent screens or foldable screens, you can now imagine and develop pretty crazy UI that you would normally see in a sci-fi movies only, and that are actually helpful and look good and are usable as well. So if only one person listening to this podcast takes it up and actually make something cool like that. I’m happy.

Darko (23:05): Great. Yeah. Which also made me realize that maybe time has come that with that translucent screen we could have something Minority Reports, and it’s not something to happen in 50 years. Yeah. Great. Well, thank you so much. It was very interesting talk and I hope as our listeners are going to pick at least one thing, which they can apply to their day to day lives from this episode. Thank you again and good luck.

Filip (23:30): Thank you for having me. It was great. Good luck to you.

Meet the host

Darko Fabijan

Darko, co-founder of Semaphore, enjoys breaking new ground and exploring tools and ideas that improve developer lives. He enjoys finding the best technical solutions with his engineering team at Semaphore. In his spare time, you’ll find him cooking, hiking and gardening indoors.

twitter logolinkedin logo

marko podcast host