Frank van Puffelen, Puf — Low-Code, No Fear: Building the Future of Apps With Flutter and LLMs

David:

All right, Puf. Thanks so much for joining us today. It's a great honour.

Frank van Puffelen:

Hey David, thanks for having me. Always a pleasure to chat my friend.

David:

Well, you've been somebody I've admired in the developer community for a long time. Not just Flutter, Firebase community, but just in general. I think that like many people you've influenced me in my engineering career and I think many, many people out there just in terms of if you ever asked a question about Firebase, especially probably you, Puff, weighed in on that and I just really appreciate that. I for sure remember seeing you and definitely helped me along the way.

Frank van Puffelen:

There's a good chance that I answered that question, right? Yeah.

David:

Yeah. Well, I think to kick us off, I think to my knowledge, you're one of the most prolific contributors to Stack Overflow of all time. Correct me if these numbers are right. About 18,000 answers and 600,000 reputation points, top 50 worldwide?

Frank van Puffelen:

And these are the ones that always get mentioned. My favourite number is that I've had 30 million views on those answers, which even when I was at Google is a large number. That really helps when your performance evaluation comes along.

David:

Oh, a hundred percent. Well, and I think it made a name for you, but also helped so many people along the way, and I think in today's world, which I'm sure we'll get into this, where you can ask AI, at some point you had to get help. And I think getting access to help and we at VGV felt it very acutely in the early days with Flutter where there were no answers or people weighing in on Stack Overflow. So I think your commitment to helping the community is really to be applauded and kind of really helped a lot of people along the way. One question I wanted to ask you, it started, you became a very recognisable persona and voice in the community. What was the voice that pulled you in? How did you get involved in technology in the first place?

Frank van Puffelen:

Ooh, there's a lot to uncover there. I always find it so interesting to be sort of like, I often joke that I'm a minor celebrity in a niche of tech, but whenever I get recognised somewhere, that's always a mode of, "Huh, me?" And I was at Google last week, last week, had to think of when it was having coffee with a friend and a, for me, random Googler walks by and says, "Wait, are you Puf?" And he shakes my hand and I never met him, but he was new on the Firebase team and knew my name from that, which I find fascinating.

Yeah, no, I got started in tech a long time ago back in the 8-bit days I would say. Right. So Commodore 64, Atari 600, ZX Spectrum, that type of thing. And initially I thought these were fun devices for playing games on like we all did.

And then I started writing my first code on that and realised that being able to tell a machine what you do and it then listening and doing the thing you said, not the thing you meant it to do, by the way, a clear difference was very interesting for me. So I decided to go to college for computer science and turned that into my career not knowing by the way what type of career that would be. I'm from the era where, don't tell any of my potentially future employers this, but where I would probably have done the same work for a lot lower salary than they paid me. And yeah, I started doing that. Was a software engineer for about two decades before I switched over to becoming more of a speaker. And that started with a conference we did for a few companies ago in Holland where we introduced a new product that I had invented and created. That's when I first learned that work goes into preparing for talks. And then from that I discovered that while I was a perfectly fine software engineer, my speaking abilities were somewhat more unique. Being able to combine technical expertise with also being able to explain that to almost any level is something that essentially I've made my career out of since.

David:

So started as an engineer, found the passion for talking about what we do and then communicating and then getting into DevRel. And when was that? Was that when you started getting involved with the Firebase team or was that before that?

Frank van Puffelen:

I already did smaller public speaking before I joined Firebase, but it mostly ended up being my job there. And yeah, there's a fun story. You might've read it already. Essentially, my job before Firebase was not that interesting. Let's put it like that. So I had brain cells to spare on smarter things, and I was at that point just looking on Stack Overflow and answering questions, random questions that came up in technologies that I knew a bit about. So because that allowed me to learn more, that was the reason I started in doing that. And then I saw questions about Firebase popping up and I'd looked at Firebase probably 2012 when they did the first rollout of that, the first beta. And I found it interesting, it was my second time working with a NoSQL database, so I essentially saw that people had the same concerns that I had the same questions, how do you model your data in a NoSQL database?

So I started explaining that and it was the type where Saturday morning I'm just sitting here, it's like, "How would I model this thing that they're asking about?" And at some point then I started getting votes, which early on it is like, "Oh, look." And then I got a comment on one of my answers that said, "Nice answer, Frank," from somebody else, and it was Andrew Lee and I was like, "Who is this that he thinks I need his validation?" And it turns out that Andrew Lee was one of the founders of Firebase, so it was actually really good. So they reached out to me and a bit and a bit later we were able to make me join and I joined in the developer relations capacity there. I could have joined as an engineer. We were just trying to figure it out, and the biggest need was still in developer relations back then. To people explain, this is around the time that Firebase joined Google. So I'm essentially the only person that interviewed for the same position at both Firebase.com and Google for the same Firebase position. And yet I've been answering as many questions as again about Firebase since then until I left Google mid last year. But even after that, I still spent as much time as I can on Stack Overflow to help people there.

David:

So the sort of push to answer questions originally sounds like was driven out of an opportunity to learn because by answering questions, it makes you think about new problems or questions and come up with the answers?

Frank van Puffelen:

Yeah, very much so. Back then, Firebase was much smaller. It was a database, pretty much, a NoSQL database, and so there's so many things you can do with a database and I didn't always have the ideas, but then somebody else had the idea and a problem implementing that idea. So that made it much more interesting for me. And I learned not just about Firebase, I learned about so many technologies there. It's how I got interested into geo-type stuff. So geocoding, geolocation, distance between two points on the earth with the Haversine formula, all these types of things that I learned because people were having trouble with it, and I was like, "Let's see if I can figure it out and then explain it in a way that works with it."

David:

So as you progress through, and you progress through this activity becoming DevRel engineer, you're answering still questions, but now you're doing it professionally, is the personal quest to learn still at the core of a lot of your activities?

Frank van Puffelen:

I think it is, yeah. Not always, I must say. It depends a bit. It's a mix between wanting to learn and wanting to teach. I would say for things where I know a lot already, I'm more just trying to transfer that knowledge. I still enjoy that very much. For example, I used to classify problems that people would have with Firebase early on, and we had internal trackers at Google for that, but one of the types of questions was always, async is hard, right? Dealing with async APIs is difficult, and NoSQL is hard, is not modelling. NoSQL data search is hard. And for example, the async is hard type questions. I think it took me probably five years to get to the perfect explanation for that, which is it actually got a name afterwards at Google, they started being known as the 1-3-2 problem, which is right.

Normally when you see three lines of code, they actually 1, 2, 3. But when it's async codes and you have a callback that you're in line, it's 1, 3, 2. I tried so many ways of explaining this to people, and you see the success ratio of your explanation. Then finally, when I had a certain way of explaining this, that success ratio, it plateaued pretty much. It was a great success ratio. That's what I love seeing, because then I started giving that explanation and right slowly, you then start closing people's questions as duplicates or whatever. But for me, the most satisfying of that is essentially seeing other people then using my explanation. And that's where it's like, "Oh, I love that," because I, okay, you shouldn't copy paste, but I don't mind them copying a style. It's like, not at all. It's like if my explanation is the best one we found, then by all means use better explanation. Of course, if there's a, right, keep looking for better explanations. But for this one, I think we pretty much got it covered.

David:

I mean, I've heard in my career that sometimes the best way to learn something is to teach it. And so it's interesting that you've had a learning kind of teaching dichotomy in your career. And even that example you were giving around sort of taking years to refine how to explain it, it's like finding new opportunities, new ways, seeing it works, like learning how to be better at even that craft is kind of interesting. How did you, as it progressed through Firebase, like Firebase gets acquired by Google, I'm sure that was a whole huge set of changes and cultural shifts and all of that, and the community grows. How does your role shift throughout that trajectory, and how did you keep the passion going throughout that whole journey?

Frank van Puffelen:

Oh, that's fascinating. So I actually joined Firebase after we were acquired by Google. Now, anyone who was at Firebase when we were acquired swears that I was there too. I always joked that my bank account shows that I wasn't, but I was interviewing before and I was a friend of the team. I was one of the early users, but no, I joined afterwards. But yeah, you could see it very much. And honestly, one of my favourite stories is one of my best friends now, she was hired at Firebase pre-Google as the office manager pretty much, but mostly to keep the developers at Firebase happy. So nothing external facing, but making sure there's the sodas and the cookies and things like that. And honestly, I later read her application letter and it was hilarious to see. I totally got why they hired her, but that was her role.

Then Firebase was acquired by Google and that type of role doesn't exist and definitely not in a product team. So she had to choose whether she would become somebody's administrative assistant or become a programme manager, and that was a hard choice to make. And she became a programme manager, and only then I sort of started working with her. So for me, she was always my programme manager, the person on my team that would help me programme managers and Google two things. It's create order out of chaos and amplify the people that they work with, and that's what I know of that role. So I started working with her and she came in as an L3 at Google initially, like Google has these levels. And through, she was there for a decade, she became an L6 programme manager, one of the leading programme managers at Google.

And that coming from somebody who was hired to make sure they had the right type of cola in the office, there's such growth that you can see there. I found that amazing. That's a talent that clearly was discovered by Firebase and then grew into one of the better known programme managers at Google. But that of course also comes with lots of, when I joined Google, it was 40,000 people. When I left Google, it was about 160,000. 40,000 is a lot, 160,000 is a lot-a lot. And I still see that when I talk to Google friends, they pretend that Google has grown since I left or something. It's like, no, it always was this huge company, right? It's hard to get things moving. If you want something done at Google, it's typically best to either be the boss for everyone or to do it yourself. And I typically found that latter camp that suits me better.

David:

Awesome, awesome. So you started out answering questions, they hired you and were you still sort of answering questions? What else? How does DevRel evolve? Because I think the story arc you're describing, I think DevRel changed over time too, right? You start doing more presentations, more online content and videos. What was the evolution of the DevRel function that you kind of pioneered and pushed as well?

Frank van Puffelen:

You have such great questions. So it was fun for me when I joined Google, I didn't really know what I wanted to do and I'd been to a few conferences before that and I'll be completely honest, I didn't enjoy that. I was the quiet engineer sitting in the corner, so that was very interesting. Even after I joined Google, I went to my first Google I/O, and Firebase was not that well known back then. This was the old Firebase that had just been acquired. I was walking around, it was back then still in Moscone Centre, and I was not having a good time. I was like, "You know what? I'm going to walk back to the office," which is around a corner, "because this is not my thing." Somebody comes up to me and he says, I was wearing a yellow shirt, but he says, "Wait, you're with Firebase?" It's like, "Yeah."

"Hold on."

And he grabs his tablet. I have a few questions for you. They had a list of eight questions about how to use the original Firebase database in a telco company for making phone connections. And I had a blast, and suddenly I realised it's like, ah, what I want to do at the conference is be helpful. The recognised part is not the important bit, but being able to help somebody is what's important to me. And from that, I went to, and DevConf was a conference series back then in Boston, and I was going to attempt to figure out if I still would like that, but somehow my programme manager now best friend, set me up to also do a talk there. And it turned out that I also really enjoyed that. So from that, I became a conference speaker, an online writer answering questions, and then later I started doing video That took a few years. Honestly, I don't enjoy doing video nearly as much as I enjoy being on a stage, you'd be forgiven to not recognise that when you see me doing video, because my lowest level of enjoyment is typically a lot higher than the highest level for a lot of other people. I tend to enjoy the heck out of everything I do.

David:

That's awesome. I definitely want to learn more about how you have you do that, keep that enthusiasm, excitement, but I wanted to zero in on you were saying you started as an engineer and even you'd go to conferences and you're that kind of quiet engineer and then all of a sudden you're able to unlock this ability to get up on stage and talk to a lot of people. And I've seen firsthand the power of an engineer who you encourage to take the leap and they go out and they give their first talk. Maybe it's at a local meetup or something, and they don't know how to, they're embarrassed, they're nervous and fearful, and they're worried about the content and then they do it and they feel so relieved and proud and happy. And then the next one's a little easier, the next one's a little easier. What are your tips or tricks or things that you've learned, advice you would give to a young engineer who to get out there and get up on stage and be comfortable doing that?

Frank van Puffelen:

Oh, it's crazy, right? No, I'm always so proud when somebody does their first talk and seeing them before and after, and the self-doubt is there through the entire journey, something that you and I probably have a lot less because we've just done this more. Also, that doesn't mean that all my talks are perfect. One of the things that you learn through experience, by the way, is dealing with problems. And I love Scott Hanselman. He picked the best words for something I experienced, which is if a demo doesn't work, we don't have a failed demo, we have a shared debugging experience, and I've done so many of these including at something like Google I/O. But there's a few things. There's for public speaking is one of the biggest fears that people have, and there are some cases where I get that doing a TED Talk, I would also probably be nervous, but getting in front of 1,000-2,000 techies does nothing for me. It's like I love doing that. There's no anxiety.

 There is, by the way, a energy level that I need to control better. I noticed often when I start speaking that my voice is a bit wavering. It's like, that's not nerves. That is purely excitement, but it's better if I control that better. Preparation is key for that, by the way. But then I've done lots of, so at Google, I didn't just do the things that people have seen me do. I also built with my programme manager friends and ran the events programme for Firebase for many years and a programme that was pretty consistently inside of Google described as the best events programme they've ever had. And honestly, that was just because I approached it as an engineer, so it's like, why do we go to events? And it turns out there's many things that people don't realise why you go to an event and part of you, this very good ventures sends people to events that they come back much more motivated after an event than they were before they were signed up.

And this is so normal. And with Firebase, we just started using that at some point, getting people to go to events, but then they're first time speakers, so you want to make sure that they have a good time and that means that I was always available to mentor people, but as I got more senior, I was still available, but it got more scary for the people that I will mentor. And then it's like, okay, so let's build a programme where we have mentors and where I just show up one time to say, "Oh, this looks awesome." And that is a part of what you do. It's also a part of showing people that they know everything, and it's one of the things I've learned from doing the videos that I did for Firebase for a long time, the Firebase release notes, so the monthly videos of new software updates, I would quite often reach out to, I would make a list of like, "Hey, what do I see as new," from just reading written release notes and all kinds of repo commit logs, and then you need to tell the story.

And I would often just reach out to the engineer and say like, "Hey, what does this thing do?" And I recall that so often. For one, it's like, "Oh, the Pf reaches out to me asking for that," where I'm like, "Yeah, well, I need info dude." But then it is also so they tell me something and I write it down and then I read it back to them and I wish felt a bit know from Harry Potter, Rita Skeeter?

David:

Yeah.

Frank van Puffelen:

She has this-

David:

Yeah, the reporter. Yeah.

Frank van Puffelen:

I always felt a bit like this, "This is what you told me." I didn't make this up. I just sort of skipped a few words, rearranged some things and turned it into a better story. But the interesting thing is always in the change they make already, and this is one of the things you have to believe as developer relations is I believe that maybe not all, but let's say 80% of the changes that engineers make are interesting because otherwise they wouldn't spend time on them. My specialty is telling that interesting story about them, but I honestly believe that most changes they make are interesting. So that also means that I can go up to them and ask like, "Hey, why did you make this change?" And when they explain it to me, there's a story I can tell, and that's definitely a unique skill, but find essentially your storyteller.

If you're an engineer having to do this for the first time, you have the information you need to give. There's no doubt that. You just need somebody to help you turn it into the story, and that doesn't take a lot of time. I've mentored people where it was a 10 minute mentoring session for a 30-minute talk, and that's all they needed essentially, pretty much for just taking the bits that they had. And it's like, "Hey, if you position them like this, then suddenly you have an interesting story to tell." That's so common that I really hope who still does this, but it's definitely something that I always enjoyed mentoring speakers and just giving them confidence. It's why I love doing talks together with first-time speakers is essentially I have a hundred percent faith that anyone, almost everyone can be a public speaker, a successful public speaker, they just have fear. And since I have no fear, for me it's very easy to just offer like, "Hey, want to do a talk together? And you pick the topic, honestly, you're the expert. I will just be the dumb ass who's on that stage and who asks you the not necessarily dumb questions. It's the questions that make it clear for the audience what's happening." But in a way that is comfortable for the other speaker also.

David:

Yeah, I love that. And it's just finding ways to storytelling, like you're saying, right? You want to tell a story and everything we do, communication is really important. I think as an engineer being able to communicate an architectural change you want to make and be able to explain it in a way that it's not mired in the details, the right levels of people can understand it. Or maybe you're trying to explain something to our junior developer to teach them or answer a question on Stack Overflow or something like that. It's all kind of the same thing. And I think as developers get further along, I think they're closer to being able to communicate. If they're already explaining to their colleagues and coworkers how something works or why they want to do something, it's really no different getting up on stage. It's nervewrecking because they have all these people staring at you and there's this fear of what if I mess up?

But it doesn't matter if you mess up. Most audiences, no one's going to heckle you. In fact, one of the bravest things I've ever seen was we had a developer on our team, Kevin Grey, where he was early on for us at VGV, and he was kind of a very quiet person, and I remember he volunteered to do a presentation at the Flutter NYC meetup. This is years ago, it was probably like 2018 or something, and we were all like, I don't know, he's kind of quiet guy. And he went up there and he fumbled almost immediately and he just paused and he was quiet for almost a minute. It was kind of this awkward pause and everyone, but you know what he found himself, he recovered and he gave this great talk and everyone applauded really strongly at the end, and I always go back and think about that.

It took a lot of courage to get over that moment, but it also shows you that it's only 60 seconds, 30 seconds, you get past that, even if it's an issue, you have to debug live because your demo failed or whatever. That's all part of it, and people actually love it and they love when you overcome that, or even if you don't, you have to pivot to something new as long as you're kind of continuing that conversation and parting some knowledge. So yeah, I think people make it harder than it is, I think, and it's really not such a big deal.

Frank van Puffelen:

So much pressure on ourselves for public speaking where indeed in all these situations where you and I speak, it's like, these are tech people. They chose to come to this talk. They are not the enemy. It is one of my basic rules in life, just assume positive intent. Very much [inaudible 00:23:47] there's this thing where you need, imagine the audience naked or something as one of them where it's like, oh gosh, no, because they're all my friends. They're either current friends or future friends and accept that. When I live coded early on, I would honestly be building. When I joined Firebase, I asked him, "How do we demo?" They said, "Well, we live code a chat app." So I was appointed the Android expert, and so I started live coding a chat app on Android. So I got it down to, it took like 25 minutes to live code a chat app, and later I found that the Android team was very surprised because you cannot live code an Android. That was their statement. Well, nobody told me, right? It works.

But I would always start at that type of talk. I explain to people, "Look, I don't have any snippets. I don't have anything that I copy paste, unless it's from documentation that you also have. And I am going to type everything. In return for that, I need from you that if I make a typo, that you yell it out to me." And the moment you say that, people lean forward on their chair, the front row, and when you make a typo, you feel it in your fingers, yelling stars because now they're part of the experience and you always do it as a joke. I would always say, because otherwise we might be here for a long time if you don't call out the typos, but it's a great way to keep people engaged, much more than when you do a pre-recorded demo. I never have a backup. If I do a live coding demo. I don't have backup recordings. You should. Really, you should. I just don't. It's like, yeah, if it doesn't work, guess what? We'll do something else. It's fine. That doesn't apply for everyone equally by the way. There it helps if you've been on stage enough that you know can pick some other story out of the air.

David:

Well, I think you said something in there too, that is just fantastic advice for anybody who's looking to get up on stage and talk to people. Just assume everyone in the audience is your friend. Assume good intent, assume it's just a room full of your friends who want to see you succeed, and if you fail, they're going to not give you a hard time. They're going to pat you on the back and lift you up and go again. And I love that sentiment. So you also said that your objective is maybe there was this idea of helping people and so you've had such an impactful career already. When you think about the mission and how it's evolved for you personally, and as you look ahead, what is your mission today and how do you see that evolving into the future?

Frank van Puffelen:

It's a good one. I had to think of this when I decided to leave Google, which is way earlier than when I left Google, actually at some point I was at Firebase and everything was still fine, but I realised that I'd sort of reached the level of impact I could reach in that role. And I was like, "So what do I want to do next?" And that comes from what makes me happiest and what do I still want to accomplish. And I noticed that what makes me happiest is seeing people believe that essentially I probably 150 times over 10 years, I live coded the chat app from zero to a chat app on screen. So at some point that becomes butter smooth, and that also means that you can look at the audience while you're doing the thing and see how they're reacting. It's fun because when you see an engineer sitting there, I'm building a chat app and at some point, this is with Firebase, so real-time data synchronisation, and I can see at some point where they're like, "Oh, I can do a counter app with that, or a to-do app," or one of them is in their mind building in multiplayer game.

And that's fun to see. But what I noticed, what makes me happiest, if there's somebody sitting there who is not a real convinced software engineer yet. They sort of might be doing the education but not have the confidence yet that they can build an app. And at some point when I'm building that app, because I take it from zero to a working app in 20, 30 minutes. But then I could see that in those eyes it's like, "Wait, if he can do this in 20 minutes, then I can do it in a day." And that's, seeing that belief for people popping into their minds is so empowering for me because that's what led to my mission in life is to help more people build more apps. That's also when I left Google, it was to join FlutterFlow, a company that had a drag-and-drop type, low-code IDE that would generate flutter apps and very much a different audience, not traditional coders, but more founders and builders, we would say there.

And I very much there noticed that you get a very different type of person building, and I think that is amazing. I want, again, my goal is to have more people build more apps, and that requires that we have tools that help more people and people like myself and others that show them that building an app is not nearly as difficult as we make it out to be. It's also not nearly as easy as it sometimes seems when I do it on stage, but I think a lot of more people can build apps. In fact, we talked earlier about teaching and my poor wife for, I say she's a tech writer by the way, so explains technical stuff to people, but she is often the first audience that I try explanations on. We are doing something new at the company where I work at Firebase, I would be explaining no SQL databases to her, something she has zero interest in.

But first off the point, if she understands the thing and asks follow up questions that are good, then I've explained it well, I've always taught her, she would say, "I'm not technical," and that's phrasing that I really don't like. So I told her, like, "Honey, you can be a developer. You can learn to programme. It's really not something you cannot do." So at some point she was in between jobs and she started to programme and being a tech writer, she of course built a little bookshelf app and she worked on that for a bit and we talked through arrays and stuff like that. It was all fine. Then at some point she says, "You're right, I can programme. I just don't find it interesting."

That's fine. No concern there, but now you can never say that you can't programme anymore. And I now see it, because after that I saw that, for example, she works at Apple and does a lot of their language type things, language work, so language QA, and I noticed that her spreadsheets for comparing things got so much more structured after she learned how to programme.

And I've seen the same with my programme manager friends where if I would show her a formula once of like, "Hey, this is how a formula works," I'd come back a week later in the same spreadsheet, and that formula was like now six times longer. I found it hard to debug, and these are both non-technical roles, but it is like, I don't know, for me, a lot of programme programming is not about the text that you type, but about how you think about data and data structures. And I want people to acknowledge that, and we're living in an age where more and more people can build apps without being a traditional coder like I am.

David:

Yeah. Well, let's get into that because that's probably the big AI is a new thing coming out and to that mission of helping more people make apps. I mean, certainly AI has that promise. I think that there's a lot of discussion around that on both sides around how easy it is versus how hard it is. Does AI create work slop or these other new terms that are being coined? What is your take on it? And you've worked through Firebase, which Firebase was such a big change. It was like all of a sudden all this work that that was required to build an infrastructure, build a back end and get all that stuff working. All of a sudden I had these tools accessible to me and then things like FlutterFlow and Dreamflow and stuff where it's like, "Okay, I used to have to do it away and this is an alternate. It maybe doesn't give me all the things that I could do, but jeez, is it easier in a lot of ways to get things up and running," and now you have AI in this story, so where are you on this? Where are you going? What's the software or the technology that's exciting you next? And is AI part of that?

Frank van Puffelen:

It's definitely a part of it. It's not all of it, I would say. Now I love how you're comparing it to Firebase, right? Firebase made everyone a full-spectrum developer because the back end was handled for you and you only wrote front-end code. And of course you've seen them. I've had to support them. All the news articles about these databases that are not protected where all kinds of personal information is leaked. It's like, yeah, when we make everyone a full-stack developer, there's going to be an educational gap where not every one of those new full-stack developers realises that they need to secure their data or they realise it, but they can do it later. And it's like, okay, people make mistakes. And while at the moment when I had to support those people, I was not happy with those choices. I am in history, I'm very happy that they could do it wrong because if the alternative was not being able to build that app, that is for me not a good one.

And I often compare to, I've done this for a while, so when I started programming, my first professional programming was [inaudible 00:33:23] Pascal, and then they started doing Delphi. Microsoft did Visual Basic 6 around the same time, and Visual Basic 6 was the first time when you could drag and drop these widgets onto a canvas and you would then double click on the button and write. Or for some people, copy paste a line of code from somewhere and you could make it do something. And every salesperson, every manager at every company suddenly started building apps. Those apps were mostly automating their own workflow, their own professional life. So most of these apps had one user, and most of these apps were, we'll be honest, but were horrible. They looked so bad, they functioned so badly, but maybe 1% of those apps actually were usable to a lot of other people.

And of that 1%, maybe 1% actually was a type of app that nobody had ever come up with and that now was being built by somebody who couldn't have built it without that tool. And I want that 1% of apps to exist. That is key for me. I don't care that much about the 99.99% slope that gets created. I'll help those developers, but I do that so that we get that one snowflake app that wouldn't exist without that tool. And that's what we're seeing with AI now. And I have great discussions with friends online about what's the value of AI tools, and I'm trying to be clear there. So normally when I talk about them on the stage, I keep saying LLMs. I intentionally don't use the words machine learning or AI because for me it's a tool. I don't have tool lying around. It's a hammer, it's a new type of hammer.

And I enjoy very much trying to figure out what this tool can help me do. For me, what it helps me do more efficiently, for other people, what it helps them do that they couldn't do without a tool. And for example, I am not a DIY person. I'm not very handy, so if anyone invents a better hammer, well, I'm still not going to be front of the line because I don't have a need for hammering, but it's like I would be their primary audience for these types of tools, and that's how I see LLMs. A very famous one is Peter Levels with the Fight Simulator on Bolt, right? He had built tonnes of startup ideas. His problem was not that he couldn't do it without a tool like that, his advantage was that he could do it a lot faster with a tool like Bolt.

And that's I think a key where it's like, and honestly, I've been considering this, somebody from Google was reaching out. If I could talk, at a DevFest, I'm not sure if I'm supposed to say that, but I think it's okay, and I asked this, "Why do you need me essentially?" And it's like to get the people that use Firebase studio that don't know anything about Firebase to help them there. It's like, "Oh, I love that. These are people that want to build an app that can do the prompting, but we need to get them into a mindset where they don't necessarily think about the code as much, but they do think about data structures, security, maybe scalability." I don't know that one yet. It's like, and this is a part where I'm fascinated. I can see when I'm talking with my wife about apps that I see people building or that I build something, I can see that she's this close to typing these prompts herself.

And that is for me, just fascinating. Also, when we started at Flutter Flow doing DreamFlow, we had something interesting. The company is called Flutter Flow, so very much tied into Flutter. And Flutter Flow itself is a, like I said, low code builder. So you're building an internal data structure that that is proprietary to Flutter flow, and from that it generates a Flutter app. So most of them, what you're doing is actually not Flutter. You're just dragging and dropping some widgets around that happen to look like one that Flutter. Also Dreamflow, the new tool is a Flutter ID. It's a hundred percent backed by your Flutter source codes. And on top of that, there's an AI, and what I found fascinating is to see for the company, it was like how much do we lean into the Flutter name there, right? Because it's essentially DreamFlow is more Flutter-based than Flutter flow, the product is, in a sense. So, picked the wrong name for the product.

But we also realised that for a lot of people that are building with these tools, the fact that it's Flutter is not important. Flutter was still the right technology to use for making that tool, but for the users of that tool, it didn't matter all that much anymore more because they never looked at the code a few months ago, a few months, something like that, A month and a half ago maybe I was doing a comparison of taking one prompt to build A, Everyone is building habit trackers nowadays. So I was like, I had no idea what it was, but I first asked ChatGPT, what's a habit tracker? And then I told a bunch of these five coding tools to generate this, the main screen for a habit tracker, and I did that initially, honestly, we needed to send out a newsletter to our users about DreamFlow, right?

So I did it in DreamFlow first and then I just asked all the other ones. What I saw is that the Flutter-based tools generated consistently what I thought were prettier UIs than other tools. The other tools had a lot of variability by the way. So between the tools that use the same technology, there's quite a few that do react, for example. You could see that there was variation, but the Flutter ones were on average, in my opinion, prettier. I must say that the ring for one, in my opinion was prettiest. In part, it might also be because it used dark mode by default, which it picked my system settings essentially. But you can see that these tools allow a lot of people to build stuff that they couldn't build without them. That also allows a lot of people to build apps that they should not be able to build, and that is a balance.

But I've been dealing with that balance on Firebase where they're all suddenly full-stack engineers for a decade. And before that too, I've never lived in a world where there were too many software engineers. That doesn't mean that it's now possible for every software engineer to find a job. It's actually one of the things that I am worried about, but I hope that that is a wave that we're just going to come back to realising that while there's lots of things we can use LMS for as software engineers, that there's a lot of other skills. Also, I used Cursor for a bit for building a multiplayer game at some point, and I used it very much knowing what I wanted to output, but it was just a faster type and a faster search tool for me. It's like, that is fine. It's very different from how a non-traditional coder might use this tool.

And that's why I asked non-traditional coders, "How do you validate your output?" And the best answer I got by the way, was from somebody who was using FlutterFlow for one app and then Cursor for something else. I said, "How do you validate that because you don't read a code?" He said, "No, I just tell it to add another test."

So where for traditional engineers, adding another test is a unit test with code that we know how it executes. For him, it's just another checkbox in a table. That's like, "Okay. If it's just a checkbox and you sort of know what it validates, then it doesn't really matter what code it is." So moving forward, one of the biggest things that I'm curious about is when I was using the LLM for generating code, what I noticed at some point is that I don't think code is the best mechanism anymore for capturing the output of the LLM for me. I have no idea what the best output, what the best format is. The standard would be an AST, an abstract syntax tree. I don't think that's it, but I don't know what is. So that's one of the things I've been trying to get folks at Google interested in. It's like, hey, that non-traditional engineer with, for him, it's not a checkbox in the table of tests. What is the output of an LLM? How can I best validate the output from LLM essentially as an expert and a non-expert in that domain?

David:

So many interesting comments in there. I mean, I love the framing of LLM is just a tool. I think so many people are getting caught up in this existential crisis of AGI and it's going to replace all these jobs and all these things, but at the end of the day, it is still just a tool and somebody has to go in and prompt it and somebody has to deal with the output. And you're right that we been doing this all along? How many people have gone into Stack Overflow and just copied code that they didn't even know how it worked, but the answer says this is the accepted solution to the thing. So let me just do this. In a lot of ways it's kind of the same kind of output or a tool. You could have a hammer and some saws and you could make something, or you could have a 3D printer. And the 3D printer is a really powerful tool. It can make anything, but it still is up to you to decide, well, am I going to design the shape that I wanted to print? Is it a useful thing? Am I going to manage all the right supplies? It still requires intervention to make sure that you're actually getting something useful at the other end of it.

Frank van Puffelen:

That's the thing. You see, a lot of the negativity now route around AI is I think not necessarily on the tool, but on the over promise. I've been trying to get out of people's like, "Why are you so aggressively against this?" And I see it, and I honestly have to look no further than the GPT-5 announcement. I was watching that keynote, and I'm sorry Sam, you're not going to like this, but worst keynote I've seen in many years, many years. I was excited. The first demo they did was the engineer was giving a prompt to demonstrate in an animated SVG, the Bernoulli principle of airlift. I got so excited because I honestly learned most about that in the science museum in London. Remember we had the Flutter 1.0 launch there and they had a demo setup for that where they had smoke blowing essentially, or water vapour. And you would move the wing of the plane and you would see how pressure essentially builds and how an aeroplane gets lift.

I was like, "This is going to be an amazing demo for an animated SVG." Now what I liked is it took eight to 10 minutes to generate that animation and they didn't hide that. So that was good. But then the animation comes out and keep in mind I was biassed. I expected that science museum thing, and it was honestly a rather sparse SVG animation. I was like, okay, not what I expected, but still this is from a product, a tool that generates working codes. Impressive. So I was like, okay, not what I expected, but still it's impressive, that can do that. But language they then use right after the first sentence is, "See, it can generate anything you tell it to." And I'm like, "Oh my gosh, that is such an over-promise based on a very limited demo you just did." Right? Instead of saying it's like, "Hey, look, with this input, we got working output," just like I just did, and maybe it's not the exact output we want, but this was just the machine outputting something like what can we do in the tool, in the inputs to get the outputs slightly more the way perfected it.

And they've done this, I think there were four or five of these moments in the keynote where they did the exact same thing and I was like, this is so bad and I hadn't caught that the charts didn't line up and things like that, what everyone called out. But this over-promise leads to so much hate against AI now that a lot of folks that should know better are just not willing to even try it. And when we were talking about doing this podcast, you sent me your document of how you prepared it, and part of that was essentially I think ChatGPT, you told it like, "Hey, give me the background of Puff, my guest, in the podcast," and that is awesome. How much time does that save you? That's one of the things these tools are really good at.

David:

Super good at, yep.

Frank van Puffelen:

Honestly, I did the same. Lots of companies reach out to me for help and one of them was... they want me to join, and one of them was LLM Arena, and I was like, "Hey, let's see what it does when I type who is Frank Van Puffelen?" And it did ChatGPT 4.5 and 5 or something next to each other, and both of them were embarrassingly kind to me, but it's one of the things these tools are really good at because the information is publicly available. It's also one of the things where, I love this metaphor. Somebody said, I made this distinction at point in talks using an LLM for something I'm a newbie at or using an LLM for something that I'm an expert at. And else it's really different. Somebody else said that it's like, "An LLM knows 40% of everything. You just never know which 40%."

And this is very much true. So I make a clear distinction between those cases when I'm walking around, I live in San Francisco, and when I'm walking around the city, I sometimes look something up by pointing the camera at it and say, "Hey, what's this thing?" And there I often know very little. So the 40% is great, and when I'm having it right, security rules for a Firebase database, I know 90% of that. So I know the output I expect, so I use it as a faster type pretty much. I make sure that all the data it needs is there.

David:

Because you know what good looks like already.

Frank van Puffelen:

Yeah, exactly. It's like I could have done this myself. I don't have to do it myself, and that's still nicer. And that's sort of the distinction you need to learn to make. And I think with a lot of the marketing around AI is taking everyone's job. That whole messaging is so destructive for their own market where look, you have a tool and the tool is going to be better. Tomorrow's version of that tool is better than today's for the simple reason. Otherwise, why would you release version? And that's exciting, but somehow you're promising so much. A lot of smart folks are not looking to give the tool the light of day.

And that is sad for me because again, I want more people to build more apps, but I also want more people to get faster help in all kinds of other things.

David:

I totally agree with you. If you could separate the vision and like, Hey, what this could be one day, but we're not there yet, but in the meantime it can do this thing 5% better or something like that, and they got to increase their valuations and build a lot of hype and energy. It costs a lot of money to build all these data centres and buy all these GPUs. So kind of get it. But I totally agree with you, and I think it's funny, even those demos you're talking about in the keynote, if they just did something that was maybe not as complicated or I don't think people are expecting it to be this miraculous thing either. I mean just a little thing that helps me and is better and just does something better, but if I put energy and effort into it and it kind of makes something that's just kind of ho-hum or kind of not great, then it's not really going to solve my need.

But if it did a smaller thing really well and you could demonstrate that to me, then I think it helps people win. But I love the framing of it as a tool and I think getting the sense that this is just something that has a lot of knowledge, 40%, and it can help you along the way. And that distinction of like are you a beginner or you're an expert and you got to go into how you're using that tool with different set of lenses on. So given that you've contributed so much content to the training of these LLMS and these platforms are out there where you could ask questions, get answers. Now that content has been consumed and you expect us to go to the tool and ask a question, have it be answered. I mean, first of all, how do you feel about that being the source of all those answers, but also how do we continue to build answers for the next generation of questions?

Frank van Puffelen:

Yeah, it's a really good question. It's one that actually part of it keeps me awake at night. So one of the things I tried to do early on with LLMS was like, what are they trained on? And working at Google, of course, I was involved with the body of training material, but it was also very clear of tools that I was not involved with like ChatGPT, was trained on Stack Overflow answers. And a few months ago, I actually spent some time on like, Hey, can I prove this? I took one of my oldest answers that essentially I've seen people then copy paste into their own questions when they couldn't get it to work correctly or something. One of my proven answers with a track record, and I asked ChatGPT the same question, and I got my answer, right? It's like, "Ah, okay, so it's trained on that."

This is not to prove that they copied my data, right? That's not the point at all. My point is, "Good. The information is not lost." One of the things didn't notice there, by the way, Facebook, when I asked ChatGPT, he was like, Hey, did you copy my answer? And it said, "No, no, no. There's just only so many ways you can do this." Got a bit defensive there, which I enjoyed. But the other part there is that I had written this originally in Java, but then later in old JavaScript, because it's 10 years ago and it rewrote it to modern JavaScript. It's like, this is awesome. It had all my variable names in there, which is how I recognised that it was mine. It was like I used some not ideal variable names back then, and I could see them reappear, but then with much more modern codes, that sort of is great.

It's the right answer that might help train it on, but then apply to current needs of developers. It needs to be time scrapped, needs to be, not with callbacks, but with async awaits type things. That was really awesome to see. So I love that. That just leads to the fear indeed of with the decline of questions on Stack Overflow, and there's really hardly any questions coming in anymore. It's like, where do we create new training material? And I see that some developers are going to other platforms, so I see an influx in Reddit of these types of questions that honestly, they should ask on Stack Overflow because the helpers are still there [inaudible 00:51:49] on Stack Overflow. We're still trying to do that.

But yeah, I'm still looking for the better location. I write more blog posts than I did in the past, but I also know that the training, these are less likely to be used as important training material than answers on Stack Overflow, simply because they're disassociated from the 30 million eyeballs that I get on these, and that is rough. I really am wondering what the next tool is going to be. So if anyone has an idea, then reach out to me on socials or something, let me know. I'm really curious about where we can as a community create more of this knowledge base that Stack Overflow is.

David:

Yeah, well, I hope they figure it out because you've had such an impact on so many people over the era where that existed and obviously continue to make an impact going on into the future. So obviously we could talk all day. We might have to have you a second time or as many times as you'd like, really appreciate you sharing your story with us and for all the things that you've done and just the commitment to teaching and helping the developer community grow, and like you said, making the ability to make apps accessible to more people. Really thank you for that effort and for being a friend and someone to come on and impart your wisdom with us.

Frank van Puffelen:

Thank you, David. Thanks. So much for having me. I look forward to doing this again.

David:

Awesome. Sounds good.

Thank you for joining us on Build to Succeed, a Very Good Ventures podcast. We hope you enjoy exploring the experiences and insights of leaders that have built successful digital products. Please take a moment to leave us a review and don't forget to subscribe to get our latest episodes. Thanks again, and see you next time.

‍