Listen to audio narrated version!
Over 18 months from 2019-2020, I explored one single idea that spawned one of my biggest blogposts, got me invited to speak at top conferences across 3 countries, and helped me get a job at AWS. And it all started with a tweet.
- Step 1: Respond to Others!
- Step 2: Yes, And!
- Step 3: Livestream!
- Step 4: Blogpost!
- Step 5: Conference Lightning Talk!
- Step 6: Conference Livecode Talk!
- Step 7: Advanced Conference Talk!
- Step 8: Job Interview!
Side note: I know I'm still a small fry in the grand scheme of things, so please don't worry that I'm getting a big ego from this. I encourage you to follow the careers of folks like Bret Victor, Sarah Drasner, Dan Abramov and Anjana Vakil if you truly want to know what it takes to be an industry legend. Still, my story often encourages others to start from humble beginnings. If a simple guy like me can do so well, surely they can do better!
Step 1: Respond to Others!
I get a lot of my ideas from simply observing what excites people. This is key for unlocking a crucial source of content — things I take for granted, that excites others. It often surfaces areas of unconscious competence.
This was the context with which I read Jack Cross' tweet on Feb 26 2019: "Was reading through [React's source code]. and I think useState is implemented with useReducer!"
At the time, React Hooks were all of 4 months old, and were a hotly discussed topic in webdev circles. I had known about Jack's observation for a while, but never really thought it worth comment until Jack did. I also knew that many folks were tripping over the importance of JavaScript closures with the Hooks API design. I wanted to find a way to properly explain all this once and for all.
It got my gears going: I'm a believer that you only truly Know Your Tools when you can read through its source code, and can build it from scratch. I'd done the former, so I did the latter:
You will see that the code sample here relies on an imperative React.render API, which is nothing like the real ReactDom.render. At the time I was only focused on the mental model, so I didn't think about a more faithful clone.
Step 2: "Yes, And"!
(90 minutes after the original tweet)
I got quite a bit of instant feedback on that tweet, namely this suggestion from Dan on the React Core team: "You want to have a list of Hooks. Otherwise it’s boring because custom ones don’t work. Should be no more than extra 10 lines."
That was exactly the push I needed — not just confirming that I was going down the right path, but also a suggestion for what to do next, that jibed with my own instincts. So I followed up 90 minutes later with this extension:
This was finally simple enough to understand, yet complex enough to be useful, which finally made it take off with a bunch of feedback.
I think Twitter is best as an Ensemble rather than Committee, particularly with the "Yes, And" spirit of starting from where the other person leaves off. This is what Dan did with me, and I followed through.
It's important to note that I wasn't the first to observe the simplicity of Hooks. There was prior art and very popular blogposts all making the same observation. But I was the first to demonstrate it in 28 lines of code, which made it a lot more approachable because it fit in a single screenshot.
Side note: I often also get asked what to do if someone is just starting out on Twitter and doesn't have the following to get feedback like I did. I think they don't appreciate that I'd only been tweeting about webdev/React for 1 year at that point. I believe that the best way to solve the relationship cold start problem is to Pick Up What They Put Down.
Step 3: Livestream!
(Friday after the original tweet)
Joel Hooks of Egghead.io DM'ed me to do a livestream of this process that same Friday. I think I was in LA at the time and had to do it in on shitty courtyard wifi but it went well. Unfortunately I can't find a recording of the talk, but I recall that Eve Porcello was there, together with a few dozen other React folks!
This was the first time I had ever livecoded anything online, and it set the stage for what was to come...
Step 4: Blogpost!
(2 weeks after the original tweet)
The blogpost version went live on the Netlify blog, with title and grammatical edits from my coworkers. The response was great:
Fun fact: I was in Mexico on a dive trip with no access to internet at the time! So I never even got round to tweeting it out, but it didn't matter. By this point, the content had been 3x validated, so I was pretty confident the blogpost would do well regardless.
Step 5: Conference Lightning Talk!
(1 month after the original tweet)
Ben Dunphy of Reactathon invited me to present my blogpost as a lightning talk in April. Reactathon is the premier React conference in San Francisco - it would've been my 4th or 5th conference appearance ever at the time, so I was already starting to get used to the speaking "circuit". But this was my first time getting invited rather than applying through the regular competitive CFP process — so I was pretty stoked about that!
I only had ~10 minutes so I just threw some code up on slides. The reception was decent for the minimal work I put into it. The talk got me shouted out on the wildly popular Syntax.fm podcast from Wes Bos and Scott Tolinski, from whom I learned React, as well as one from Lee Byron, who designed the original React class API.
Step 6: Conference Livecode Talk!
(4 months after the original tweet)
I remember paying the ~$300 out of pocket for JSConf Asia tickets in Jan 2018, when I was just starting out. I had no idea that I would be paid to fly back to Singapore and speak there just a year later.
I proposed this talk without knowing if I could do it. I just knew from studying Kelsey Hightower's demos and André Staltz's advice that livecoding was a great way to further demystify this concept. I had been unable to do it at Reactathon. A livecoded talk was my "white whale".
I not only pulled it off, but also managed to add some dramatic flair rendering code to screen:
Fun fact: I only worked out key parts of this code the night before I was due to give the talk. After breaking through on the render loop and figuring out some kinks with CodeSandbox, I stayed up all night reworking and practicing my presentation, building in failsafes in case I screwed up, and added in the René Magritte flourish right at the end. I presented that talk on ~2 hours of sleep.
The reception exploded. Not only was the content 4x validated at this point, but I had worked out a compelling presentation style and left the viewer with a thought provoking question at the end.
Step 7: Advanced Conference Talk!
(8 months after the original tweet)
When you have a hit like that you naturally want to follow it up, and you naturally start getting more conference invites as well. So when the GitNation folks reached out for the React Advanced conference in London there was only one topic I wanted to do: explain Concurrent React the same way I had React Hooks.
(This is the revised version for ByteConf; the React Advanced one is here and I did a paid version for Egghead.io subscribers as well)
While React Hooks were a relatively simple mental model (I started this journey reducing it down to 26 lines of code), Concurrent React not only involved building in a proper time slicing scheduler and Fiber reconciler, but it also wasn't live yet (and still isn't fully shipped as of the time of writing 2 years later, although React Server Components is a huge step forward) so people weren't familiar with it.
Putting together this massive effort involved pulling in notes from 18 months of covering Concurrent React by myself, in particular studying prior art from Rodrigo Pombo in cloning the API from scratch. You can check out his talk here to contrast what he did vs me.
The reception was great but I neglected to tweak my talk for the venue. I had a livecoding talk, but it was a very long conference hall, which guaranteed that half the audience (about 1500 people) couldn't see a thing I wrote 🤦♂️. However I did meet up with Nader Dabit at that conference, which set things in motion...
Step 8: Job Interview!
(11 months after the original tweet)
Within 3 months of that conference I was at Amazon's offices in Seattle on my final interview day for an open spot on Nader's team. The developer advocate interview at Amazon requires you to prepare a talk on something you know well, and field questions on it by non-domain-expert engineers.
So I just presented my talk again, building "Concurrent React from Scratch" in front of 3 people who only barely knew React and weren't aware of my prior experience with this topic.
I got the offer the next day.
Why I Wrote This
I've recently been guiding a group of ~50 students as a mentor for Tiago Forte's Building A Second Brain course, and it's been remarkably helpful for solidifying my own takeaways and for helping others go down the same path I have ("When one teaches, two learn").
Week 4 was the lesson on Intermediate Packets, which Tiago has written about and covered on his podcast if you want to catch up on it. Intermediate Packets are often presented as a way to take a big goal and break it down into pieces. That's a great way to plan out a big project in a top-down fashion — however I think bottoms up is greatly underappreciated as a content strategy.
As you can tell from my story, things escalated pretty quickly from just a random tweet, to me being flown across the world to speak at conferences and helping me get a job at a FAANG company. But at no point did I plan to do any of that. I just focused on an interesting problem, made the next possible move available to me, and responded to feedback.
For each one of these hits I have, there are a thousand that go absolutely nowhere. Some tweets develop into blogposts, some blogposts develop into talks, and then they just fall flat. I only really have a true hit once a year, but it takes all the dead ends and exploration for me to find the real gems that resonate with others.
If I'd developed each idea with a top-down big project goal in mind, I'd fail to reach them 99.9% of the time. I think bottom-up content creation with exploration over expectations is a far more sustainable approach.
Again, I write not to brag, because I'm plenty aware that there are much better developers and speakers than I. But every time I tell this story, it inspires people to start on their own journey learning in public. I'm sure people with more talent and determination will be able to take this process far further than I have. I hope this post has shown you a little of the behind the scenes.
Reactions
- Matias Woloski, cofounder of Auth0, notes that this is a form of "Content Market Fit", similar to "Product Market Fit". Auth0's advocacy of JWT's started with a blogpost, then into conference speaking, and finally developing http://jwt.io/ as the industry reference.
- Netlify's Mathias Biilmann also went through a similar journey with the Why Static Site Generators Are The Next Big Thing blogpost developing into The New Front-end Stack. Javascript, APIs and Markup at SmashingConf and then https://jamstack.org/
- See also David Perell's Content Triangle
Top comments (0)