Podcast appearances and mentions of christopher chedeau

This week we talk to a legend in the dev tools space, Christopher Chedeau. Christopher is a software engineer at Meta (formerly Facebook) and has worked on some of the most popular open source projects in the world. He is the creator of Prettier, a code formatter that has saved millions of developer hours. He is also the co-creator of React Native, a framework for building native apps with React. Christopher has also worked on many other projects such as Excalidraw, Yoga, and and many others. https://blog.vjeux.com https://github.com/vjeux https://twitter.com/Vjeux Episode sponsored By Raycast (https://www.raycast.com/) Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership

Christopher Chedeau est le cocréateur de React Native. Développeur français à San Francisco, son parcours est inspirant, mais tout n'était pas gagné d'avance… Quel pouvait être le rêve de Christopher quand il était enfant, avant de réussir une brillante carrière dans une entreprise mondialement connue : Meta (anciennement Facebook) ? Et bien son papa (ingénieur […] L'article Christopher Chedeau, React Native et son succès chez Meta est apparu en premier sur Coder pour changer de vie.

Listen to the Sourcegraph podcast: https://about.sourcegraph.com/podcast/christopher-chedeau/ (~28mins in)Lessons learned: Hackathon is important for intrapreneurship Near Death moment requires leap of faith Solve People Problems with Technology, not just technology problems Transcript [00:00:00] swyx: I'm continuing my exploration of how technologies get adopted. And recently there was a really good interview of Christopher shadow by Beyang Liu on the source graph podcast. So I really had to feature it. this tells the story of the invention and adoption of react native internally within Facebook. And the context to this is. [00:00:21] Facebook had a problem with the iteration speed of mobile apps at Facebook, and they were much slower than web apps. So basically the context before this conversation is that mark Zuckerberg had actually set an engineering priority to fix the solution and the engineers have to figure it out. [00:00:36] Christopher Chedeau: One of those things that John had in mind, Can we embed JavaScript in a iOS app. And so at that point, we actually there was no API for this and they're going to do it, but like you found a way to cross compare something and he was able to do it. And you, you want it to be like, okay, can we run, react and power, like native iOS views out of react instead of like dibs and spans, you can like a UI label and a UI views. [00:01:03] And. And so this is like at Facebook there's hackathons. And so in the summer does a three day hackathon. And we basically like Ashwin Lynn that's where on my team, on the photos team. And Joanne, we hacked together off for three days working on this like raw using react to power, like native use. [00:01:25] And at the end of the three days, we had a demo where we are able to show his view and we had a primitive layout system. And. I have the texts it's on the right and the iOS, the rep on the left and basically moved the line like a before and after and a native, iOS, like button. And I bought to move the, like better from the left to the right. [00:01:49] And we were able to click on it. Now, the lights like actually like walks and we're able to like, do. Changing and saving would be like almost entirely. I think it was a hundred milliseconds, a refresh. So it was barely perspective perceptible and we presented to the like hackathon group, like all the, did some callbacks could go. [00:02:11] And what happened is the five project, like most interesting have an audience with Mark Zuckerberg. And so you went to present this hack to Mark Zuckerberg and there was a SRAP, the CTO of the company as well, like in this? Yes. Yeah. And wasn't for this. Yeah. And both of them were like, we're super excited. [00:02:32] And what happened the next week is we basically did like a wall tour of Facebook and we talked to all of the management chain, . And it was like a super, like a fun thing. But now the thing that happened then is okay, so we did this demo, there was like people liking it and everything, but now for like myself as an engineer, like I joined like Facebook, like less than a year ago. [00:02:54] And I moved like my, like myself, I married my wife. I like, this was like a huge like thing. We moved off way across the world. So now it was like a soul searching moment. Do I want to like bets, like this dream, like on a crazy idea that and I was like, like at that time I was like the answer was No. [00:03:18] And so what happened is like a Lena Nash Ashwin basically went and B up like a, they wanted to do an iOS photo up and they built it using what was react iOS at the time. And three months after they basically came back to us and said Hey look like we really want to build like the iOS photo app. [00:03:37] Yeah. And right now we're spending more time building this react iOS thing than actually building the products. And so we're going to restart the product like in a normal iOS. So we can actually walk on it. The project could die. All the project could live and I need to make a call. Do I want to invest in? [00:03:58] And so I did a lot of soul searching and I basically at that point I was like, okay, I think I need to do it. And so, Tom Occhino was the manager of a Joel at the time. And Joel Dan and myself okay, now we like basically creating a small team. And then she came in after this. And this is how like the program. [00:04:17] But this was like not an easy, like a decision to make. And this is like something, a lot of people don't realize it counting products and like they're super high risk Harry, well, for decks, but most of the projects actually fail. This is a startup. Like most of us, not the film and the fact that I'm like here talking to you, like all of the stars align and everything, like it's good work, but this was not a given at the time. [00:04:40] Beyang Liu: You took a risk and it paid off. And I think especially it was a big risk in Facebook at the time. Cause my understanding is that they had already tried to build an initial version of the mobile application using web technologies. That was like the first attempt. [00:04:54] And then it wasn't like performant enough for the user experience. Wasn't good. So they ended up rebuilding it in, native iOS and Android. So there must have been like probably some amount of institutional resistance. Right. . Have another go at a web based or web inspired technology, right? [00:05:11] Christopher Chedeau: Yeah. Yeah. This was like a very interesting time. And like one of the things that's also I don't know if it's true today, but like when I like joined Facebook and even at school, there was this notion of if you're doing web, you're not a real engineer. If you're doing like a channel or like network or native, like you're real engineer. [00:05:31] Yeah. And so there was this like super interesting notion where we are coming from a web background. And so when you have all of these preconceived notions, Whatever we'll doing is not going to be a real engineering. And we're like, scripted is, and let's do this. And this is like very interesting. [00:05:52] The other thing which has been super interesting is there's also a very big difference between the iOS community and general. Hmm. And so, the what's super interesting is iOS community is like apple, like plays a central role. And basically there's like this notion that like everything that apple does is the right way, and this is the way things should go. [00:06:16] And there's a very angry notion of this. And so now if you're basically come in, like we're doing something different when apple guideline, there's a lot of reasons. Yeah. And so this is in practice it has works well because like apple in practice, the software that they produce and like the libraries and everything, I actually really good in practice. [00:06:36] So that's reasonable. But it's been like one of the very interesting thing about trying to convince people the, on the other side for Android, which was super interesting is Android, like the state of the development at the time was like very fragmented. There's 20 different of Android and everything is hiking and like the quality of the framework and the fraud, was not as good. [00:06:57] And so basically like 400, like people were a lot more like welcoming to the idea, but the challenge there was. The actual devices were like, really, really was like for iOS, like the iPhone is actually like super powerful on Android. There was like really bad phones. And so now like a, the channel was like, oh, do you have the JavaScript runtime on top of it and everything. [00:07:20] So it was a lot more challenging to actually get it to work well. And so it was super interesting, like how, like one place was more about like the. The like people mindset and everything and the other, one's more about like the actual techno like technology called shysters and that's well, challenges for like working on this. [00:07:40] And one thing that we found is that in practice, like a lot of the people working on react native, I've been people like coming from a web. Yeah. And the thing is we have been hiring a lot, but it's still like how that via an iOS and Android engineers and women employee as more of them. [00:07:58] And so we've been able to like bootstrap and say, I found them there, our team using react native through like the. And all the channels were starting to hire like dedicated native engineers. They were able to like get funded through like web development. And so it's also like a, an interesting thing. [00:08:15] The staffing and the people working on this projects.  [00:08:18] Beyang Liu: Yeah, that's a neat I guess developer team growth hack is a using a technology that allows people from a much wider pool to, to come work on, on the product. I I'm curious, you mentioned all these challenges with getting started in both iOS and Android, partly psychological, partly technical. [00:08:37] What was the first project or first major project that the react native team targeted inside Facebook as a focal point.  [00:08:45] Christopher Chedeau: So the first one was Instagram. They had a list of all of the photos you've liked. Oh, your favorite regions. And this view like was super small and would have like being our entry point into getting Instagram. [00:08:59] And so one of the challenge with this is like the, the, the mission is like, the feature was not big enough to justify like the investment and adding like a whole like JavaScript run time and this kind of things. And so. We were not able to like, actually succeed there. And I, in interest respect, like I think you need to start to find like something small enough, but something like significant enough that they actually solves a real problem. [00:09:27] Fall the company. And I don't think we really judged like the right balance. And so this is four counts. The thing that actually worked out and like the first one was ads manager. And so we were building like a ads, like app for managing your ads on the phone. Yeah. One of the thing is like the team had a really hard time hiring native engineers to actually build this and this first time on the app. [00:09:53] And so this felt like the perfect opportunity for us to actually get like a team. And most of that same like ads is like the most complicated, like piece of a JavaScript software. And so, there was a lot of really good. From an engineer's like JavaScript expelled, like in the ads organization, they were able to bootstrap the asthma job product. [00:10:15] And we were able to walk with them. And so this was like the first big app that was shipped, using react native. And to this day, it's still using right there live and like it's been super successful.  [00:10:24] Beyang Liu: That's awesome. And, and how did it grow from there? I mean, these days, so  [00:10:28] Christopher Chedeau: one of the biggest thing you're using react native is actually marketplace. [00:10:33] And so this is a yeah, one of the big success stories. And one of the reason why they have been able to be successful as they've been able to iterate like super quickly and like figure out like what works, what doesn't work and like being able to yeah, to move faster on like with true native development.  [00:10:51] Beyang Liu: Yeah, that's awesome. [00:10:53] And marketplace, I think these days it's like one of the largest online marketplaces where like goods are bought and sold anywhere. I think I I've certainly bought like a ton of stuff on marketplace and have as well. So thanks for that. That's a, that was like more than 1 billion people using marketplace every month. [00:11:12] Wow. Pretty insane. That's insane. [00:11:14] swyx: So that is the react native story, which I don't expect to be very representative or applicable to a lot of other situations, but I think it's still notable and it still has a lot of impact and there's still some other lessons to learn from it. So the first lesson is that it's a case of entrepreneurship.  [00:11:30] It started because of a hackathon because mark Zuckerberg had some overall objectives, but didn't really prescribe this solutions. And I think hackathons and giving people space like a three-day hackathon is actually a pretty significant engineering investment, but giving people space to come up with solutions that they've always wanted to work on, I think gives you a lot of these breakthrough ideas that would just never have come up in a regular cycle or a sprint or whatever you call it.  [00:11:54] And the second point that I really learned about is deciding to bet on react native that react native had a near death experience because they tried it out on Facebook photo app, and it was just too unproductive and they could have just died if Christopher did not decide to invest more time in it. And I think you always need these.  [00:12:12] At critical moments, people to just decide that this investment is worth it, that this technology is worth it. Um, Before you get much traction because it's just not in a usable state. And finally, I think the reflection that I have is that react native solve the people problem. And solving people problems actually often solves the technology problem or beats the technology problem. Uh, Innocence that web engineers are much easier to hire than native engineers and web development cycles are much faster than native development cycles it may be inferior in all other respects but if you just win on those two things you win the technology

On the eve of the pandemic, Christopher Chedeau was procrastinating performance reviews at Facebook and decided to hack together a simple drawing app. That weekend project became Excalidraw, an open-source virtual whiteboard so popular that its users have basically demanded a startup form around it so that they can bring it to work. In this episode of the Sourcegraph Podcast, Christopher tells the backstory of Excalidraw's meteoric rise, as well as his story of joining Facebook and coming to America, and tales from the early days of React and how React Native was born.Show notes & transcript: https://about.sourcegraph.com/podcast/christopher-chedeau/Sourcegraph: about.sourcegraph.com

After this podcast recording, I wrote Technical Community Builder is the Hottest New Job in Tech which went into further detail on my thoughts on Community! Audio source: https://www.heavybit.com/library/podcasts/developer-love/ep-15-learning-in-public-with-shawn-swyx-wangSHOW NOTES Geoffrey Moore's Crossing the Chasm /r/ReactJS Taming the Meta Language by Cheng Lou Avis is No. 2. We Try Harder Metcalfe's Law Reed's Law Clubhouse CMX Udemy The Community Fund Working in Public by Nadia Eghbal Hacking Communities by Laís de Oliveira Prettier Transistor.fm Stripe TRANSCRIPTPatrick Woods: Awesome. Swyx, thanks so much for coming on the show today.I'm really excited to have this conversation.I'm sure lots of folks are aware of who you are and probably follow you on Twitter, but for those that don't, would you mind giving us a little bit of an overview about who you are and what you're working on?Shawn "Swyx" Wang: Sure. Thanks for having me on.Been enjoying the podcast, and this is my second Heavybit podcast alongside JAMstack radio.So I'm Shawn, I also go by Swyx, that's my English and Chinese initials.It's a complicated history, but I was at Netlify, passed through AWS and most recently just left AWS to join Temporal.And have been primarily active in the front-end/ serverless space.And I've been very interested in this whole idea of developer experience.I did not know to call it developer love until I came across Orbit.And I think Orbit's model is fascinating and really nails it.But to me, the way I've been breaking down developer experience is developer tooling and developer communities.So kind of straddling both.I was a moderator of r/ReactJS subreddit, going from about 40,000 members to over 200,000.Recently stepped down from that to help run the Svelte society, which is the community organization for the Svelte framework. And I think it's just a magical thing to be able to enable a community around a certain technical topic. Patrick: Yeah. Thanks for the overview.So you mentioned developer experience as a concept and a practice that you're very interested in.What do you think led to that point for you?Swyx: Honestly, it was Netlify branding their developer relations people as developer experience engineers, which I was pretty skeptical about, because if you are devrel, just say your devrel, don't try to put some unique spin on it.But then I think they really envisioned something bigger than traditional devrel, which was building our integrations and also working on community building, which is not like me talking to everyone, but also enabling others to talk to everyone else.And so I think many to many is a really noble goal.It's very challenging obviously, because you have to influence without any formal authority, but it's also a very appealing goal economically, because then you don't have to scale their number of employees linearly with your number of users, which I think makes a lot of sense.Patrick: So you mentioned developer experience for you is really comprised of tooling and communities.Can you talk a little bit about the relationship between those two pillars?Swyx: I don't know if I have a formal relationship in my head.The framework that I come from is actually from Cheng Lou, who used to be on the React Core team.I think he's on the Reason or ReScript core team now. And he gave a talk at Facebook's internal conference called Taming The Meta Language, and the argument of that--And it's a very good talk. I recommend people check it out.The argument on that talk was essentially that every programming language or every framework has a core and a periphery, and the more developed it gets, the core which is kind of like the code that runs, is a smaller and smaller part of it.And really the middle language starts to go around it, which involves tutorials, docs, workshops, community, jobs, third party libraries, yada yada.And so in his original slides, he had a long list of these things that are wrapping around a very popular framework, which for him was reacts, but you can extend this to basically anything.But for me, I think it essentially just breaks down to, okay, the code that is not core but makes all the developer experience much better, so that's the developer tooling, and then developer communities, which is all the people around the code, which isn't core to the code, but makes using that code a lot better.So it's just code and people.Patrick: Yeah. I love that.So as a project or a framework grows the core, maybe it becomes smaller as a percentage of the overall footprint with the periphery, the middle language increasing.What's that tipping point look like, do you think, when it switches from code to community being the bigger part?Swyx: Yeah. This is something you can tie in to Geoffrey Moore's idea of Crossing the Chasm.So for people who haven't heard about this, it's like a five stage adoption process going from 0% of the total population to 100% of the total population.And then it's a bell curve from 0% to a 100%.So the early stage is kind of the hobbyists, like super early adopter types.The only thing that they care about is this is cool.I can hack on this in the weekends, and this is technically better on some basis, right?Like in theory, I really want this thing to exist. I look at all the existing solutions out there and none of them fit me, because I have very specific needs.And they don't need a lot of documentation.They don't look for other people like, is this used in production by some big company that I recognize.They don't think about stuff like that. They're just like, does this fit a very specific need that I have?That's it. If it does, good. That's enough for them.But the majority of people don't work like that. Right?They do want to see documentation. They want to see a thriving job market.They want to see that like whatever, Netflix has used this in production.All that stuff that's not core to the code, but does provide some measure of faith that this is tested at scale, that this is reliable and dependable and a good technical bet. As you go from early adopters, you cross the chasm into the early majority and the late majority. The requirements of the early adopters versus the majority are very different. The earlier adopters require a lot less essentially handholding. I'm not trying to demean the people in the majority.They just have different needs for that specific domain.And the people in the majority are more conservative, probably as a good measure of technological conservatism.You don't bet early on everything because you're going to get burned.So I think it just makes sense to bet early on some things where it really, really counts, and then just be conservative, use boring technology on everything else.But it does make a lot of sense that the crossover is a very challenging thing.Because when you start a framework, when you start a programming language, you're just like one person or like a small team just hacking away, right?You just care about the code and making it run fast or more securely, or have special features that nothing else in the world has.That's great. And then suddenly a community grows around you and then they're asking for things like, "Can you make better docs? Can you integrate with my thing? This doesn't work well with my existing worlds."And you're like, "Okay, sure. I want you to be happy."But that takes you further and further away from just working on the thing itself.So I think as a project grows in importance and adoption by the majority of the community, you start to embrace different parts of the population with different needs.And I think that that's the crossover point. I don't have a number for you, but people typically peg it at--I don't know, 5% or 10% of the population where it really starts just crossing over already.Because there are a lot of people in the middle.Patrick: Thinking about your experience with the React subreddit, what were some of the learnings or observations you had as that community scaled through those different phases?Swyx: It's a challenging one because Reddit is a constraint format.It's essentially a link aggregator with a voting and some comments.So, JavaScript is the largest programming language and React is the largest framework within JavaScript.Arguably there's some other measures.But when you have such a large community like this in a constraint format where basically only one link or one question can be in the top position when you sort by up votes, then there's a matter of what target audience do we want to target?Because there are a lot more beginners than there are advanced people, but people come for engaging events, knowledgeable conversations.So there's always this tension between, there's a lot of beginners who don't know any better and we should be welcoming to them, of course.But at the same time, if we make it too beginner-focus, the events will go away, and it will lose its quality.So there's a very challenging tension.One of the ways in which we solve that is to basically contain the beginning of questions to a dedicated thread.And that's something that I did when I was starting out.Basically the promise you make is that you will answer every single question that goes in there, which is a step up from stack overflow, where you can ask a question and it just gets crickets.Patrick: All right.Swyx: And so that contains the beginner questions and allows other types of contents to come up, which can be more advanced.And you try to make the two extremes happy, even though you can never really do a fantastic job.So there are other ways, for example, you can forge the community and create as specifically beginner focused one.But then you get what you get, which is that there won't be that many experienced people frequenting that subreddit, therefore the answers may not be as good, or you just have a glut of people asking questions and nobody's around to answer them.Patrick: Yeah. In terms of tactics, were you the one answering the questions in the beginner thread or were there other moderators that jumped in or did the community help out?Swyx: I started doing that. So there were some months where it was like 500 pushes and answers, and the vast majority of them were me.Patrick: Wow.Swyx: And it's not so bad, once you find repeats, then you can just copy and paste.But I think when you're leading the community, you do have to lead by example, and then people who see what you're doing in the service of the community, start to jump in and help out.That's where I recruited a couple of my other fellow moderators, because I saw that they took the initiative and joined in with no expectation of any personal benefit.They're just serving the community.I think there is some personal benefit in the sense of, you get to answer all these questions and you strengthen your own knowledge, which is really good.And you also understand the pain points.So you can go write blog posts and articles and even libraries to solve those pain points.So having a very close ear to the ground for what people are facing helps you just be relevant to everyone else.So I think there's a lot of benefits for doing that.But yeah, it's actually a pretty good recruiting ground.Basically, if you want to be a leader of the community, just act like it and people will see what you're doing, and then they'll formally give you that position.Patrick: You mentioned that by being heavily involved with these beginner questions, things like that, it leads to inspiration for blog posts, tutorials code, things like that.We think a lot about the second order of effects of an active community.And one of those is content like that, where if you have a thriving community, one second order effect is you probably have ideas for blog posts, guides, tutorials, things like that.And I'm not sure everyone realizes the sort of power of that type of output.Swyx: Oh yeah. We have people who teach React for a living.They actually go through the Reddit to browse for people's pain points so that they can write articles. It's pretty effective.Patrick: Yeah. That's awesome. So you're working today with Svelte Society.Can you tell us a little bit about what you're working on there, and the nature of the community that's around that?Swyx: Yeah. So, Svelte Society started off as a meetup in New York, because I was friends with Rich Harris, who created Svelte.And I had basically ignored him for a full year because I was so deep into React, that I was just like, I don't need a new framework in my life.And I think we were both speaking at a conference and he gave a really convincing talk where I reached a point where I was just like, "Okay, I got to try this thing out."And of course I was impressed.Of course it solves major pain points that I had with React.And I just ignored him for a year, because I'm one of those not early adopter types.So there was a meetup that was going to happen in London, which is going to be this first Svelte meetup in the world.And I was like, "We can't have that. We're in New York. We have Rich Harris in New York. We need to meet up as well."So I just decided to tweet that. I wanted to launch a meetup. I had no speakers, no guest list, no venue. I just set a date, that was it. And then people got together and within a week we actually organized a met up with 50 people, someone from Microsoft stepped up and offered their location.And we did the very first Svelte meet up just scooping London, and eventually Stockholm also did one.So eventually the three of us got together when COVID hit.The three organizers from New York, London and Stockholm got together, and then we created Svelte Society as a global online community. We've done two conferences, we're about to have our third in April. And a few thousand developers, I think we're at 7,000 and something. And it's a small, tiny community, but it's actually a lot of fun growing something from scratch, rather than taking over something halfway and growing into something already huge. So I'm enjoying that difference in vibe. I think that developer communities where you are not the default, so everyone comes to you as the second framework or the second tooling, is a very nice position to be in because you get people who know what they're coming to you for.For example, when people choose React, they just choose React because they're told to do it, right?They don't actually know the difference between JavaScript and React, or they don't know anything else apart from React.And so some of their questions might be very off topic or just kind of not discerning.They don't actually know what they want.I kind of call this second framework syndrome, which is just actually like a positive.So I need a different word than syndrome.But essentially, once you've picked one tool in some domain, and you've gone onto the second tool, you're much more discerning and you're less likely to identify so strongly with one tool, because if you've left a tool before, you're never going to say like, "Okay, this is the solution for everything."Because you might leave the tool for something else again.Whereas I think people who are first time to a framework or to a tool might be too loyal to it and try to solve everything with it. And that's a recipe for pain.Patrick: It reminds me of the classic advertising campaign from Avis.They were number two in the market.And so this is like 1950s, 1960s mad men era, and their whole campaign was, "Hey, we're number two. So we'll try harder for your business."Swyx: Yeah. This is great. Acknowledge that you don't have the top spot, but there are things that you can still bring that people still really value.And if you just say that, I think people recognize it and respect that.I do a lot of marketing types in my line of work, and I don't like marketing that just denies reality.I think it's way better to just accept it head on, call it out.The other famous example is Domino's, right?They're just like, "Hey everyone, we know our pizza sucks. We revamped it. Come try us out." And it worked.Patrick: Big time. Yeah. Well this reminds me of a tweet you shared recently of talking about the advice, to talk about benefits versus features, but your view is that the opposite is true for developers.Swyx: For developers.Patrick: Yeah. Can you talk a little bit about features and benefits when it comes to communicating with developers?Swyx: Yeah.This is one they struggle with back and forth, and specifically the tweet is about me relearning it.So the advice in traditional marketing is to sell benefits over features, right?Sell people on the vision of what they will be with you rather than without you.Instead of, you're specific how you get there.And that's why, I guess when people sell perfume or clothes or whatever they show you someone in a fancy dress or some dude with a fancy watch on a yard or something.It's association and that's how you do marketing in a traditional sense.But I think developers have been lied to too much, where we just stopped believing in people in marketing.So if you tell me your library's blazing fast, I don't know what that means.So tell me why it's fast, show me why it's fast, don't just tell me that it's fast. Because, sure, that's a benefit.Obviously that's an improvement to my workflow.But if I don't know why it's fast, then I'm not going to accept it on faith, because I've been burned too much or I'm not going to be able to explain it to the rest of my team or my boss when I try to adopt it at work.You have to have a logical reason, because there's also going to be a trade-off right?There are some free lunches, but usually there's no free lunch.You have to be able to answer the question of like, "What am I giving up in order to get this benefit?"And usually, marketing you only talk about the benefits, and you don't talk about the sacrifices.And I think that the most concise way to do all of that is to tell you how it works.Show you under hood and give you the logical explanation for, okay, all these alternative solutions that you're used to, they all use this legacy format, and we use a different format that is just way optimized without those legacy assumptions.In exchange for all these benefits, it will not be compatible with some legacy features that you now no longer care about.And you're like, "Ah, okay, that is me and I'm sold."But if you skip all of that and just go like, "This will be faster." I can't get behind that.So I think that's my insight on developer marketing that we want to know how it works.And I think that's which is partially why open source is something that's so appealing as well. We are able to see the code.Patrick: Yeah. Do you think that the continuum from features to benefits, do you think where the messaging lands at the timeline maps to where a potential user is on the chasm?Maybe early adopters care more about how it works and late majority we're about?Swyx: Exactly.Patrick: Yeah.Swyx: Yeah. So I got some pushback on my tweet saying people don't understand how React works, and it's a black box to most people.And that's true, but because React has already crossed the chasm, it doesn't have to.So I definitely am focused more towards early adopters, because I guess I work on earlier stage companies.If you're IBM, nobody knows how Watson fricking-- What is Watson?I don't know, but it does Jeopardy.I don't talk to the type of developers that buy IBM.And no shade on them, it's just really, I think when you're dealing on cutting edge stuff you really have to open the hood.Patrick: Yeah. Agreed. Shifting gears a bit, you champion the idea of learning in public.And you described your writing on this topic as your most impactful essay.So I'm really curious, how did the concept of learning in public become so central for you and your work?Swyx: I think that it was a reflection of when you look back on your work for the past year, for me, it was like the past six months, and try to understand what parts of my work was the most impactful, and what parts of my work didn't matter at all.I realized that it was the stuff that I did in public.And sometimes got wrong in public that contributed most to my learning.And I think this idea, there's a name for it. I actually got from Kelsey Hightower, who is sort of Mr. Kubernetes now.But he's very much someone who learns in public.Something that he just learned, he'll share it because it's was valuable to him from three to six months ago.Therefore it will probably be valuable to a lot of other people. It may not be the most insightful thing in the world.He's not presenting himself as the expert in something, but that's not going to stop him from sharing something fundamental that he learned, which is useful.And if you do that, you'll not only learn faster, because you get feedback from other people.Both from people who know more than you, and also people who are with you in your journey.But also you get to demonstrate your interests, which is very good for your career. It's a two-way street.It turns your network from outbound network, you reach out whenever you need a job, to an inbound network, people understand what you're into and they reach out to you for stuff that you are interested in.And I think that's a fundamentally different way mode of operation that most developers are used to.And they don't even realize that this is possible.They're like, "Oh, you got to be internet famous to do this."And surely you can get internet famous by doing this.But to me, that's not the goal. The goal is to just have a record of what you learned.Because when we do interviews, for example, we try to have this really lossy compression algorithm.We compress all that we are, all that we can do and that we've done, into one piece of paper and hope that the other side has the right decompression algorithm to unpack that.And then we complain about how broken the hiring processes, because we stick to this completely useless thing.It's much better to have a, let's say like a site or a GitHub that just shows that I've been interested in this.I've been hacking on this for three years and here's all the things I've done. It's instantly verifiable.It's like a cryptographic proof of work. And you don't need some massive following for that.All you need to do is actually do good work.Patrick: What's a tangible example of learning in public?What does that look like in practice?Swyx: So one of my talks was about how React Hooks work under the hood, because Hooks were a major feature of React that were launched.And those launched in 2018, and a lot of people were talking about it and not trusting it, because it was a little bit magical.So I thought about this question and then I tried to make a small clone of it.And it was just a very simple, like 29 line proof of concept. And I tweeted it out. This is a career hack as well. Whenever you tweet about a company's products or a framework's features, probably the people who wrote that feature will see it. Especially if there's a company involved, they will have a Slack channel hooked up to their company's Twitter account. That's how it works, right? And so, Dan Abramov and the React core team actually saw it.And it was like almost there. There's some flaws.So he actually gave me suggestions to correct it, and I just went and did it.And then that actually got a lot of traction.So that actually led to a blog post, then actually led to a workshop that was conducted with egghead.io.And then eventually a conference talk at GS conf, that was my biggest talk to date.And all that just because I tweeted out a tiny thing that I was trying to work on myself.And I could not have got there without help, without feedback from other people.And the other thing is I would never have thought that this was something that I could do, like do a completely live coded presentation on stage without all this validation and support and help.And it's one of those things where you don't know what you have until people sometimes pull it out of you when you share it.It just wouldn't have happened if I didn't share it.Patrick: Have you seen this concept work for non-technical people as well?Swyx: I think so. So I used to be in finance and I still follow a lot of investing people in the investing sphere.So, Patrick O'Shaughnessy is, I guess, a well-known investor by now.His approach is very much in the learning public phrase as well.So he also uses that term. But he uses it to just talk about the industries that he invest in, right?He can be much more in-depth in, let's say, minerals or energy, but let's say if he wants to learn about tech or consumer retail or shipping, he can just invite a guest to go on his podcast and he'll talk about it.And that's a form of learning in public as well.You're putting a beacon out there and having real conversations.You're never presenting yourself as an expert, but you become an expert if you do it this enough.And the rate of learning is way faster than if you just did everything in private.So the argument is very much like you're not putting everything in public, but if you put it just a little bit, you actually get a lot of benefits, because there's such a great network effect to learning in public.Patrick: Yeah. It's interesting to think about the gradient of self editing that has to happen when you're deciding what to put in public versus what not to share.Swyx: Yeah. And some people, especially women, have to do more editing, just because they get attacked more.And that's really unfortunate, but it happens.And I think you have to have a thick skin, actually my preferred way of saying that you should have a thick skin is that you should divorce your identity from your work. When people criticize your work, they're not criticizing you, they're criticizing the work that was produced by some past version of you. And if you're growing at all, you should look back on your work like a year from now, and just say, that was totally horrible.So you should agree with the people who are criticizing you.And in fact, if you build a reputation of someone who takes criticism well, then they'll criticize you more and you'll learn more.And if you just don't take it personally, and as long as they don't make personal attacks at you, of course that's not acceptable, but if you don't take it personally, then yeah, you're totally fine. So the way I phrased it is that you can learn so much on the internet for the low, low price of your ego, and just get you out of the way. Are you here to be good or are you here to feel good?Patrick: That's a pretty fundamental distinction that not many people may draw.So you've mentioned before the idea of learning in public and the phrase you use is building a habit of critical learning exhaust, which I think is very poetic.What do you think the relationship is between learning in public and the communities you're a part of?How do those two aspects interplay for you, do you think?Swyx: So there's a selfish reason. And then there's a selfless reason.The selfless reason is that I think we need to make it easier for people to learn in public, to create receptive and welcoming communities that recognize that you're just trying to improve yourself just like everyone else is improving themselves.And sometimes we don't have a space for that. And when we don't have a space for that we just clam up and just not try.So if we just foster a community of people who are all improving and working on things, I think that's just a better net positive for the world and net positive for everyone in that community.The selfish reason for that is that there's a scaling law that scales beyond me.So the way I think about this is that, there are few scaling laws.Some people are very familiar with Metcalfe's law in tech, which is that, the value of a network scales according to a square of its number of nodes.And that's analogous to me having a very big "Rolodex" which is like, my friend's list is very long, then I can call upon these as experts or friends or mentors whenever I want.That's really good. But it could be better, which is what's better than Metcalfe's law?Metcalfe's law is great. But what's really explosive is Reed's law.So Reed's law is sort of an exponential growth of the number of nodes.Because each of the number of nodes can form subgroups independently of the central node, which is the reason why Facebook, when it grows, the value of Facebook grows not as number of the members, it also grows by the number of interest groups within Facebook, right?That's why Facebook groups is so powerful as a value added to Facebook, to the point where most people would just use Facebook today for Facebook groups.And Facebook just doesn't care. Doesn't have to know.And you can be in a thousand different groups and it doesn't matter.But they're all valuable to you. Okay. How does that tie back to the community?A community is a many to many ongoing sustaining relationship between all of them, and me being able to grow them.I grow at that accelerated pace faster than Metcalfe's law, because Metcalfe's law is limited by Dunbar's number like--Sorry, I'm pulling in so many concepts, but there's a limit to the number of people that I could possibly know.But if I enable each of them to talk to each other and collaborate with each other, then I benefit as well, partially because I help to be a central member of that community.But then also when I find them, they will be innovating without me there.And that's a benefit to me as well, whether I've realized it or not.Patrick: Yeah. The distinction between Reed's and Metcalfe's law is really quite fascinating.Swyx: That's community. It really is, Metcalfe's law scales, but it's so much effort to add each node, because you have this central dependency, right?Which is, let's say the company or the core team of a framework, but once you have a community, then they're just all interacting on their own basis.And you don't really have a say, which is a little bit worrying, because it's out of your control.It's adding value to your network, whether you've realized it or not.Patrick: So a lot of Orbit's customers and folks in our own community have this question where they're early on their journey.Many of their early community members are just users of their product--t he early adopters, we would call that, or the Orbit one.And they're starting to ask this question of, what's the tipping point when a community goes from mostly people talking to the company about the product or the project to talking to each other about the project, about ideas and their job and broader concepts.Can you talk a little bit about when you've seen that occur, and if there are any tools or tactics or frameworks that the project maintainers or the company founders can implement to accelerate that tipping point.Swyx: Yeah. I think I definitely am not the authority on this, because I haven't seen this occur too much.I've seen instances of it. And I just don't know if I have the authoritative story.If said like, this is the general theory of how to make networks, I think I'd be a millionaire.That's a very valuable information. But I'm actively researching this.So with all that said, I think that what can be very helpful is that you make the identities and the interest graphs of your members of your network discoverable to each other.So a lot of the times when you hire a community manager, their job is to know the community members very well, and they typically store it in their heads.But if you have a listing of them, where people can actually independently search and discover, then you really find that independent connections start taking shape.But you as someone who manages that community needs to make that happen.Because that's not going to happen in any organized fashion on its own.So one of the ways in which I do see it happening very effectively for a company or a framework is sort of an official partner designation.So you do have the ability to bless some people as the recognized experts.So at AWS, we have AWS Heroes, like we'll anoint like external parties as serverless heroes or data heroes or machine learning heroes.These will be recognized experts. I just saw that Webflow actually, and Vercel have Webflow experts or like a Vercel partners program, where these are sort of the key system integrators, I think they're called, or like agencies or whatever you call it, that are very keen on working with Webflow.So then they get a lot of benefit from associating themselves with you as experts, or just as long as they derive significant value from hiring or finding business off of you, then they're a very engaged community members, and they're very incentivized to contribute to the value of your community.And it's just like a reinforcing loop, because as you build that then more people know to come to your community to find these people.And because more people come to find these people then more people on the supply side sign up and it's like a demand and supply side marketplace type of thing. So I do think that a marketplace is like the ultimate business model. I am a huge fan of marketplaces, but it can be hard to start. And sometimes you have to bootstrap one side versus the other. But essentially what you're doing is a marketplace, where you set the rules, you make it easy for people to transact and you establish reputation systems, you establish trust, you establish like this conflict or dispute resolution mechanisms.These are all traditional forms of a marketplace, but you can actually bring all those lessons, all of it, to communities.Patrick: I love marketplace as a metaphor for community.Swyx: The other thing that you can do as well is to organize events.Because I think we as humans, we like-- Okay, most of the time we like async, we like to do things on our own.We like to build our own networks independently, but every few months we love special occasions to announce some things and to gather to celebrate something you, like a woodstock, or I don't know, basically a conference.But the definition of a conference is changing in the COVID world.And another thing that you can do is definitely organize events where people would just get together.And sometimes it can just be a small dinner, let's say we can all meet up again in person.You can just have a day when everyone just gets together and just talks, and you as a community organizer, that's a minimum viable market place, which is just like, "Hey everyone, we're all going to get to get together in this room at this time and day."Which is what I did for my meetup, right?There's no economic transaction, you're not taking a fee or anything, but you're just making it possible for people to find each other.That's a marketplace.Patrick: Thinking more broadly about communities in general.What are some trends that you've been seeing in the way communities are being built or platforms are using or methods you're seeing as we go into 2021, and what are some of the community building concepts that you're excited about?Swyx: Oh, I'm so into this. Yeah.To a point where I do have an ongoing research collection about dev communities and people who are innovating in community space.I always thought that things were sort of going online, things are going asynchronous, and then Clubhouse changed everything for me.I realized that people actually like real-time connection and the ability to ask questions and participate in chat, and sometimes video and anti-feature, which is another interesting concept, right?Because Zoom was the darling, and now Clubhouse is. A nd Clubhouse is like Zoom, but worse.So yeah. I think people are realizing that connection is real.Having events like a clear before and after is a real thing, which I think is a reversal of some of the trends that we were seeing.We were moving towards more async online chat-based communities.And I think now we're seeing some revival in live events and live ongoing discussions in spontaneity and imperfection.Beyond that, I'm not really sure I have-- Okay, so the other thing that's also happening is cohorts, right?Which Wes Kao and Gagan Biyani from Udemy are championing.Which is basically communities gated by when people join. So most communities they're just open at all times.So you just come on in whenever, and whenever someone says hi, they're just like, "Okay, it's another person it's not something special."But when you make something into a cohort, suddenly groups have identities like, Oh, I'm sort of class of spring 2019.That's Y Combinator, right? But that's also college, and that's also a cohort of communities.And those cohorts are prebuilt, it's an event.Everyone is new and everyone knows that there's a group that's going through the same experience as they are.But then there's also broader group with more experience than they are. And they can access that as well.I think cohorts are an interesting twist on how people run communities.None of this is new, right? But we're just taking lessons from maybe other domains and applying it to online communities that may not have been applied before.And I wish I could go back in time and tell myself from three years ago all this stuff, because I didn't know any of this, but now it's obvious.It's obvious to me because I watch all these people closely, maybe people who are listening, if it's not obvious to you sit up and listen, because this is real.This is very valuable. And this is happening at a very, very fast pace.Patrick: Where would you suggest people tune in or the resources or people that you follow that are particularly insightful when it comes to these topics?Swyx: Yeah. Wes Kao is pretty much leading the core based course league.Rosie Sherry, from Indie Hackers is definitely collating a lot of community news.There's also Greg Eisenberg, he runs a consultancy that starts communities for people.The only problem I have with him is that he thinks of himself very highly.So he rubs people the wrong way, I think. But he does have valuable insights, which is very frustrating.Sometimes arrogant people are worth it.Patrick: Yeah. I think it's complete opposite of someone like Rosie, who is such an intellectual heavy hitter, but also so humble.Swyx: Yeah. I got more resources for you.So by the way I collect all this in my circle community.So, codingcareer.circle.so is where I collect all this information.So there's Get Together, which is a book and podcast for people who form communities.There is CMX Hub, which is, David Spinks, who has been doing this awhile as well.There's a bunch of people in this community space.Oh, Lolita Taub is a VC who just launched the community fund.So they're specifically a venture capital firm that is focused on companies building communities and companies building tools for companies building communities there's a whole circle of that.Patrick: Yeah.Swyx: There's a lot of stuff. And then there's also a couple of books that people really like.So Nadia Eghbal, Working in Public has some sense of community building in her stadiums and whatever and village metaphors.And Laís de Oliveira, has a book on hacking communities, which I haven't read, but I've definitely singled that out for reading up.Anyway that's just my resource dump.And I'm keeping this list because I think it's a growing knowledge base of what it means to run a community, and what are all the different ideas that people are bringing to their communities.Patrick: Awesome. Thanks for sharing that.So zooming out a bit to a question that I ask pretty much every guest on the show, what do you think is the secret to building things developers love?Swyx: So in that tweet about development marketing, I actually also mentioned another concept, which is a wow moment, right?And I actually expanded upon that by saying a wow moment should be something that inspires you to talk to your friends, tell your friends about it.It makes your jaw literally dropped. And it makes you never want to go back to the old way of doing things again.It creates a clear before and after. There was you before seeing this demo or seeing this tool, and then there's you after. And it creates a gap, because it makes everything that you used to do before the old way, you didn't even use to call it the old way. It just became the old way once you saw this new thing. And I think developers love something that takes away some pain that they might feel at their core, but maybe sometimes they don't even know that they have it.So I'll give you one example, which is Prettier in the JavaScript ecosystem.Anyone could have built Prettier in any of JavaScript's 25 years of existence, but nobody did.Until it was some-- It's Christopher Chedeau, but someone just went like, "Hey, Go has this really nice formatting tool. What if we just had that in JavaScript? And what if it was just standard."And he built it, and now it is standard in the span of two to three years in JavaScript, which is massive.And people love Prettier for what it does. Which is pretty funny.The thing is you'll never make everyone happy.There's a very strong band of people in JavaScript who don't like Prettier for their own reasons.But you make a lot of people happy and they do say that they love Prettier.So I think that's one of those examples where, there was an old way, which is you manually formatted your code and you had code review stand up meetings, where you argued over the spacing.I've been in those meetings, okay?And then there's an after, with this tool, where you no longer spend any time on that, because you just have a standardized tool that just does all that for you.So I like that. And I think that's one example of making things that developers love.Patrick: Aside from beautiful code.I always ask people, what's one thing you're loving right now?Swyx: I'm loving Transistor.fm for hosting my podcasts.I do run a couple of small podcasts, nothing like yours.But it makes it very easy to host stuff and generates a website for you.And it just takes away all the pain for me that I don't want to do.So I will pick Transistor.I guess I also pick Stripe, because it's such an easy--I wrote a book and I run the entire fulfillment from beginning to end, and Stripe checkout was so such an easy thing to integrate that I happily paid them their 3% or whatever it is.Patrick: Yeah.Swyx: Not a very non-consensus pick. I have to pick Stripe. But I do have to give them credit.Patrick: Well, you've been super generous with your time today.We've covered a lot of really fascinating topics.If people want to learn more about you and what you're working on, where online would you send them to go do that?Swyx: Yeah. Thanks for having me. My Twitter is where I'm most active.So twitter.com/swyx. And you can find my blog at swyx.io to get all my talks and book and whatever else you want to find out about these ideas.Patrick: Awesome. Well, thanks so much for coming on the show.Swyx: Thanks for having me.

This is a repeat episode of the JavaScript Jabber 146. Here's the original link https://devchat.tv/js-jabber/146-jsj-react-with-christopher-chedeau-and-jordan-walke/ Sponsors Dev Heroes Accelerator Raygun | Click here to get started on your free 14-day trial

This is a repeat episode of the JavaScript Jabber 146. Here's the original link https://devchat.tv/js-jabber/146-jsj-react-with-christopher-chedeau-and-jordan-walke/ Sponsors Dev Heroes Accelerator Raygun | Click here to get started on your free 14-day trial

“When I started React Native, everyone I talked to was like you need the primitives to be platform specific, otherwise this is too crazy, everyone’s tried the cross-platform dream – it doesn’t work.” Continue reading… The post The Future of React with Christopher Chedeau appeared first on Software Engineering Daily.

React.js is a JavaScript library for building user interfaces. Facebook and Instagram maintain the open-source repository and use the technology to build front-end components. Questions include: What is a virtual DOM? How does React.js make development more modular? Why is DOM manipulation so expensive? What is Facebook’s development process of React like? What is Flux The post React.js with Sebastian Markbage and Christopher Chedeau appeared first on Software Engineering Daily.

The panelists talk to Christopher Chedeau and Jordan Walke about React.js Conf and React Native.

The panelists talk to Christopher Chedeau and Jordan Walke about React.js Conf and React Native.

The panelists talk to Christopher Chedeau and Jordan Walke about React.js Conf and React Native.