Tell us a bit about yourself.
๐๐ป Hello - I am @peterfriese, a Senior Developer on the Firebase team at Google. I focus mainly on our SDKs for iOS and Apple’s other platforms, but I’ve done some Android in the past (mostly Android Wear, in my first role when I joined Google).
The products I work most closely with are Cloud Firestore, Firebase Authentication, and Firebase Extensions (these are ready-to-use modules that you can add to your Firebase apps, e.g. for image resizing or to easily integrate services like Stripe or Mailchimp into your app).
Before joining Google, I worked at a bunch of consulting companies, building all sorts of apps and systems using a wide range of technologies (J2EE, Spring, Eclipse, OSGi) and languages (Delphi, Java, JavaScript, TypeScript, Objective-C, Swift). One of the companies I worked with was in the business of building a DSL for building DSLs, so I got to implement a couple of little languages myself - one of them actually was pretty similar to SwiftUI.
When I am not busy writing sample apps, drafting video scripts, or writing blog posts, you will find me reading a book, playing the bass, or listening to a podcast - I developed a voracious appetite for podcasts during the pandemic. My favourites are 13 Minutes to the Moon, Decoder, Land of the Giants, and Swift by Sundell.
What do you feel is the most important part of your job?
Mediating between the developers who use our products and the product and engineering teams that build them. As DevRel, our job is to act as the zeroth customer of a product or API and make sure that it actually is useful and solves the problems our customers are facing. This means actually using our products and APIs in a scenario that is as close to reality as possible. To put this into practice, I rebuilt Apple’s Reminders app using SwiftUI and Firebase last year. My goal was not only to figure out whether it’s possible to build a meaningful app using those two large API surfaces, but also to work out how to architect apps that combine Firebase’s APIs (most of which are asynchronous in nature), and SwiftUI, which itself follows a reactive approach. This not only gave me some really good opportunities to connect with our iOS/Apple community but also forced me to exercise Firebase’s APIs in ways that were new. This resulted in the addition of Combine support, made sure the team was aware of async/await support early on and opened the door for some fantastic community contributions for Firestore, Cloud Functions, and the Realtime Database. And since a lot of things have changed since I first built this app, I have just started rebuilding it from scratch in public, using the latest versions of SwiftUI and Firebase.
What is something youโre struggling with?
Time management (side note: I am writing this on the subway on my way back home to make the deadline for the second week of Adventcado)… There are just so many cool things to do, I often find it hard to pick, and so I fall into the trap of overcommitting myself.
Tell us about a time you were inspired by someone or something in DevRel.
I am continuously inspired by the women in DevRel who have to endure being told people would rather speak to “someone technical”, and worse. I have had the privilege to work with some amazing women at Google and other companies, and they are among the finest technical people you will be able to find. So - if you attend a conference or an online event, why not assume both men and women are technical…
Whatโs one change youโd like to see in DevRel?
I think we need to get better at explaining what we do, how we do it, and why it is important. I am looking forward to a time when the job roles of Tech Writers, Developer Advocates, and Developer Relations Engineers will be as widely understood as Software Engineers, Product Managers, and Site Reliability Engineers.
It never ceases to amaze me to see that Developer Relations still seems to be somewhat of an unknown discipline to many people. I guess this is partly due to the job titles we use (not very many people outside of DevRel know what an advocate is - they most likely think it’s some kind of lawyer). Also, still too many people think we’re just marketing. It certainly doesn’t help that some companies still use the term Developer Evangelism - it definitely has a much more marketing-oriented sound to it.