` tag and `` is more likely to exist in most sites (no judgment pls, i've heard enough semantic HTML preaching). That the top tag centers itself relative to nothing is unintuitive, but thats how browsers do.\r\n- `line-height: 1.75`: Spacing between the lines to help increase visual clarity. Always leave line height unitless because [reasons](https://twitter.com/JayGilmore/status/1449731397585879040).\r\n- `font-size: 1.5em`: I've noticed that recent design trends and screen sizes have tended toward bigger font sizes. Or maybe I'm getting old. Prefer `em` or `rem` over `px` if you want to let users scale it.\r\n\r\n[Tushar points out](https://dev.to/tusharsadhwani/comment/1j1a0) that you can use `:root` instead of `` to guarantee that there is some selector present, but its a touch too fancy for me and uses an extra character :)\r\n\r\n## Optional 100 more bytes\r\n\r\nIf you can spare a few extra bytes of CSS, I'd also recommend margins for headers, paragraphs, and lists, and softening body text:\r\n\r\n```css\r\nh1,h2,h3,h4,h5,h6 {\r\n margin: 3em 0 1em;\r\n}\r\n\r\np,ul,ol {\r\n margin-bottom: 2em;\r\n color: #1d1d1d;\r\n font-family: sans-serif;\r\n}\r\n```\r\n\r\n![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7eyghddgt0v5hu0i6f9n.png)\r\n\r\n## Applying Styles on Pages You Don't Control\r\n\r\n- You can auto apply these styles on to pages with https://github.com/ankit/stylebot. I can't vouch for their security as I only just started using it.\r\n- WaterCSS is a bookmarklet or extension or script with some nice presets: https://watercss.kognise.dev/\r\n- SakuraCSS is a bookmarklet that does the same https://oxal.org/projects/sakura/bookmark/","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/100-bytes-of-css-to-look-great-everywhere-19pd","devToReactions":319,"devToReadingTime":3,"devToPublishedAt":"2021-10-16T21:05:53.602Z","devToViewsCount":15609,"title":"100 Bytes of CSS to look great everywhere","published":true,"description":"Simple grab and go upgrade to the base user agent stylesheet to make for readable sites","tags":"css","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ar002arl80e64kfoxpz.png","slug":"css-100-bytes","canonical_url":"https://www.swyx.io/css-100-bytes"},"title":"100 Bytes of CSS to look great everywhere","description":"Simple grab and go upgrade to the base user agent stylesheet to make for readable sites ","category":"note","tags":["css"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ar002arl80e64kfoxpz.png","canonical":"https://www.swyx.io/css-100-bytes","slug":"css-100-bytes","date":"2021-10-16T21:05:53.602Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/168","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/168/comments","title":"100 Bytes of CSS to look great everywhere","created_at":"2022-01-17T22:55:07Z","updated_at":"2023-09-02T07:10:33Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/168/reactions","total_count":2,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":2,"eyes":0}}},{"title":"Connecting the dots in public on the Changelog","slug":"changelog-pod","tags":["LIP"],"venues":"Changelog","date":"2021-10-06T00:00:00.000Z","url":"https://changelog.com/podcast/467","description":"TToday we’re joined by Shawn “swyx” Wang, also known as just “swyx” — and we’re talking about his interesting path to becoming a software developer, what it means to “learn in public” and how he’s been able to leverage that process to not only level up his skills and knowlege, but to also rapidly advance his career.","category":"podcast"},{"title":"How to Market Yourself with Shawn “Swyx” Wang","slug":"uibreakfast-pod","tags":["Marketing"],"venues":"UIBreakfast","date":"2021-10-06T00:00:00.000Z","url":"https://uibreakfast.com/223-how-to-market-yourself-with-shawn-swyx-wang/","description":"Today we talk about marketing yourself, both as a personal brand and at work. Our guest is Shawn “Swyx” Wang, an engineering thought leader and author of “The Coding Career Handbook.” You’ll learn several components of defining your brand, tips on expressing that brand in public, collateral and strategies that will help you at work, and more.","category":"podcast"},{"type":"blog","content":"\r\n> See discussions on [Hacker News](https://news.ycombinator.com/item?id=28903982) and [InfoQ](https://www.infoq.com/news/2021/10/cloudflare-r2-egress-aws/). I also discussed this on the [AWS.FM](https://mixtape.swyx.io/episodes/weekend-drop-aws-cloudflare-and-techbro-therapy-on-aws-fm) podcast.\r\n\r\nCloudflare launched on September 27, 2010, and every year since, it has made it a point to celebrate \"[Birthday Week](https://blog.cloudflare.com/tag/birthday-week/)\" with a raft of launches. By far, the show-stopper this year was the announcement of [R2 Storage](https://blog.cloudflare.com/introducing-r2-object-storage/), an S3-compatible Object Storage service that directly takes aim at [AWS' \"Hotel California\" business model](https://blog.cloudflare.com/aws-egregious-egress/). This has been extremely well received, going by the response on [HN](https://news.ycombinator.com/item?id=28682237) and [Twitter](https://twitter.com/QuinnyPig/status/1443028078196711426). In its past 5 birthdays, Cloudflare has gone from world-class CDN to offering:\r\n\r\n- 2017: [serverless compute](https://workers.cloudflare.com/) (Workers)\r\n- 2018: [eventually consistent datastore](https://developers.cloudflare.com/workers/learning/how-kv-works) (KV)\r\n- 2019: [website hosting](https://blog.cloudflare.com/extending-the-workers-platform/) (Workers Sites)\r\n- 2020: [strongly consistent datastore](https://blog.cloudflare.com/introducing-workers-durable-objects) (Durable Objects)\r\n- 2021: [object storage](https://www.cloudflare.com/products/r2/) (R2)\r\n\r\nThis is an [impressive pace](https://blog.cloudflare.com/the-secret-to-cloudflare-pace-of-innovation/) and they are now declaring that they will be \"[the fourth major public cloud](https://www.protocol.com/enterprise/cloudflare-r2-storage-aws)\". When your market cap is $36 billion and your next biggest competitor is worth $1.6 *trillion* (~45x larger, albeit not pure-play), this is a bold statement. Many startups are trying by offering specialized [Cloud Distros](https://www.swyx.io/cloud-distros/), but all building with AWS as the presumptive winner of the \"first layer cloud\" rather than trying to compete.\r\n\r\nWhat's Cloudflare's strategy here?\r\n\r\n**My realization: The big 3 clouds are playing Chess, but *Cloudflare is playing Go*.**\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dojvxo0i0u5v7cmm1d4p.png)\r\n\r\n## Two Kinds of Disruption\r\n\r\nThe canonical thoughtleader of Disruption theory is the legendary HBS Professor Clayton Christensen, and a lot has been made of [Cloudflare's Disruption](https://stratechery.com/2021/cloudflares-disruption/) of AWS; in fact, Cloudflare cofounders Matthew Prince and Michelle Zatlyn were [students of him](https://harbus.org/2011/cloudflare/) at HBS. James Allworth, their Head of Innovation, studied and [co-authored a book](https://claytonchristensen.com/books/how-will-you-measure-your-life/) with him. Prince [namechecked the Innovator's Dilemma at Cloudflare's launch](https://youtu.be/XeKWeBw1R5A?t=646) in 2010, and in 2021 is still proudly showing off a [handwritten note from him](https://news.ycombinator.com/item?id=28708636); in short, you can be sure his lessons are never far from Cloudflare's minds.\r\n\r\nAs Ben Thompson noted in [his now-famous takedown of Christensen on the iPhone](https://stratechery.com/2013/clayton-christensen-got-wrong/), people often miss that he had *two* theories of disruption:\r\n\r\n- **New Market Disruption**: When incumbents ignore new technologies until it is too late.\r\n - Allworth recently wrote an instant-classic application of this on [Intel (x86/CISC) vs Apple Silicon (ARM/RISC)](https://jamesallworth.medium.com/intels-disruption-is-now-complete-d4fa771f0f2c)\r\n- **Low-End Disruption**: When vertically integrated premium incumbents get disrupted by \"cheap and good enough\" modular providers.\r\n\r\n> A third model of disruption comes from Kevin Kwok's [Atomic Concepts](https://kwokchain.com/2021/02/05/atomic-concepts/), but that is a closer fit for the [Cloud Distros](https://www.swyx.io/cloud-distros/) thesis than Cloudflare.\r\n> \r\n\r\nOn the first theory: Cloudflare has some excellent technologists — [John Graham-Cumming](https://en.wikipedia.org/wiki/John_Graham-Cumming), [Kenton Varda](https://www.linkedin.com/in/kenton-varda-5b96a2a4/) and [Rita Kozlov](https://ritakozlov.com/about/) come to mind — and it is doing some cool things with V8 isolates and dynamic routing, but it doesn't (in my mind) have a clear claim on the overall new technology angle, since AWS created the modern serverless paradigm, [open-sourced Firecracker](https://www.amazon.science/blog/how-awss-firecracker-virtual-machines-work), and [is using Lambda for half of all new applications](https://www.protocol.com/newsletters/protocol-enterprise/serverless-container-aws) (though Cloudflare is also [aggressively dogfooding Workers](https://blog.cloudflare.com/the-secret-to-cloudflare-pace-of-innovation/)).\r\n\r\nMost of the disruption discussion focuses on the second model of disruption, and it rings true. Cloudflare took a part of the cloud nobody valued, gave away an insanely good free offering, and quietly accumulated an [80% market share](https://w3techs.com/technologies/cross/proxy/content_delivery). Meanwhile, when people think of \"Tier 1\" AWS services, its Cloudflare equivalent, Amazon CloudFront, rarely gets any love, and the official AWS Twitter account [hasn't tweeted about it in almost a year](https://twitter.com/search?q=from%3Aawscloud%20cloudfront&src=typed_query&f=live). Cloudflare leveraged their foothold into selling premium security services, and now is expanding into other value added pieces by leaning into a fundamentally different (high fixed cost, near zero marginal cost) business model the larger incumbents structurally cannot follow.\r\n\r\nThis, at least, is how Ben Thompson framed it in [his writeup on Cloudflare's Disruption](https://stratechery.com/2021/cloudflares-disruption/):\r\n\r\n[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7258tf9irknumz5db2vg.png)](https://stratechery.com/2021/cloudflares-disruption/)\r\n\r\nBut this diagram is a little too neat. It imagines the two clouds as worlds apart. Yet R2 is explicitly designed as S3-compatible; in Prince's words, you can [set it to \"slurp\" mode](https://news.ycombinator.com/item?id=28703464) and you magically have a S3 interface with egress that is [six orders of magnitude cheaper](https://twitter.com/QuinnyPig/status/1443076111651401731?s=20). Similarly, the original Cloudflare service could always be used together with EC2, and Cloudflare Workers have different enough usecases and limitations from AWS Lambda and Lambda@Edge that you could conceivably have a stack using all of them. \r\n\r\nThis isn't Apple vs Android; premium and vertically integrated vs cheap and modular; incompatible ecosystems, and never the twain shall meet. \r\n\r\nThis is something else.\r\n\r\n## Cloudflare and the Rules of Go\r\n\r\nIn the classic game of Go, you [capture pieces](https://www.pandanet.co.jp/English/learning_go/learning_go_6.html) by surrounding your opponents, instead of directly replacing their spot.\r\n\r\n![Basic Go Capture gif](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7idppjskwr10z817xo42.gif)\r\n\r\n### Storage Capture\r\n\r\nYou could view Cloudflare's Bandwidth Alliance and R2 as an \"encircling\" move around AWS' previously secure market position with S3. By promising to be API compatible (including offering S3's eleven-nines durability guarantee and free infrequent access), Cloudflare has cut off nearly all of AWS' remaining \"liberties\", putting it in \"[atari](https://en.wikipedia.org/wiki/List_of_Go_terms#Atari)\". If Cloudflare's offering matures enough to be seen as a strict superset, it places the final stone, capturing the \"cloud storage\" territory. \r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o4kk6ucmg8mbqd0t0yzw.gif)\r\n\r\n### Product Strategy\r\n\r\nIn Chess, pieces have different values and capabilities. Bishops are worth 3 points and move diagonally, Rooks are worth 5 and move in straight lines, and so on. Pieces are best deployed in a sequence chain where higher value pieces support lower value ones.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/buwls1amzbahfv0q30d6.png)\r\n\r\nIn Go, each piece is indistinguishable from the other; it is the *network position* that counts, not any individual piece. Support doesn't matter so much as adjacent territory claimed; in the picture below, the four white pieces on the left do far less than the four black pieces on the right.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pwwiby0brxdq3d7mzt6r.png)\r\n\r\nCompare this to public statements about how Cloudflare works. [From Prince](https://news.ycombinator.com/item?id=28703194): \r\n\r\n> **Since every server in our network runs every service**, once we’re in for one thing means everything we do in the region gets better and less expensive to operate. This means, counter intuitively, as we add more locations to our network our costs generally go down, not up.\r\n> \r\n\r\nSo while AWS has [17 ways to run containers](https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/) and [7 ways to do async message processing](https://serverlessfirst.com/aws-async-message-services/), all overlapping and reinforcing and supporting each other, Cloudflare will tend toward introducing singular primitives, [stuff them in a box](https://blog.cloudflare.com/cloudflare-for-offices/#built-for-purpose), and try to ship those boxes to [as many places as will possibly take them](https://blog.cloudflare.com/cloudflare-for-offices/). If they could install Cloudflare on your mobile phone, they would (this gets them dangerously close to being a [real life Pied Piper](https://www.youtube.com/watch?v=5JM8bkJLLjM)).\r\n\r\n> Update: I have been informed that you can in fact [install Cloudflare on your mobile phone](https://blog.cloudflare.com/1111-warp-better-vpn/)...\r\n\r\n### Territory Wins\r\n\r\nIn Chess, you only win when you checkmate the King, which in effect has infinite point value, winner-take-all. \r\n\r\nIn Go, you win by amount of territory claimed, and it is near impossible for one side to end up with zero territory. Perhaps this is more true to real life.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q8ne0yo5vzoytu04qdkv.png)\r\n\r\nWhile AWS boasts an impressive [230+ points of presence](https://aws.amazon.com/about-aws/global-infrastructure/), Cloudflare has [interconnects with 10,000 networks](https://www.cloudflare.com/network/) including \"every major ISP, cloud provider, and enterprise\". These aren't the same thing, but it reflects the substantially different game that Cloudflare is playing. From the point of view of users, Cloudflare can be much easier to use and is much more of a painkiller than other big cloud services in their stack, despite perhaps having a single digit % of mindshare and wallet share. This puts Cloudflare within a stone's throw of Ben Thompson's other big claim to fame in Tech Strategy, [Aggregation Theory](https://stratechery.com/aggregation-theory/) (the Intro to Tech Strategy chapter in [my book](https://www.learninpublic.org/) is free if you want my take on it).\r\n\r\nStrategically, \"Territory over Positioning\" happens to be exactly the right call. In a zero-sum market that isn't growing, you want to jockey for position and take out enemies. In a positive-sum, infinitely expanding market like Cloud, you want to encircle them.\r\n\r\n### Watch for Sente\r\n\r\nTo [quote Wikipedia](https://en.wikipedia.org/wiki/List_of_Go_terms#Gote,_sente_and_tenuki), a move that overwhelmingly compels a player into a particular follow-up move is said to have \"sente\" (先手), or \"initiative\". In most games, the player who maintains \"sente\" most of the time will win.\r\n\r\nThere is a lot of speculation that AWS will have to respond somehow to Cloudflare's provocations:\r\n\r\n{% twitter 1444016487304364036 %}\r\n\r\nBut beyond a [standard PR response](https://www.infoworld.com/article/3634406/cloudflare-hopes-lack-of-outbound-data-fees-will-convert-aws-s3-users-to-its-r2-storage-service.html), I doubt AWS will respond to mere noise - S3 data egress revenues have to take a significant downturn before AWS will be compelled to act. But when it does, every future move of Cloudflare's will be taken increasingly seriously. Cloudflare acts and talks like it has \"sente\" now, but it isn't real until AWS (or the other big clouds for that matter) feel forced to specifically respond.\r\n\r\n## Conclusion: Establish, Envelop, Expand\r\n\r\nWhile the tech industry is used to come-from-below disruption, and the software industry is increasingly grasping class-for-the-masses atomic concepts, I believe Cloudflare is writing a new playbook that is the little-guy counterpart of the [embrace, extend, extinguish](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish) model used by Microsoft.\r\n\r\nBecause it involves API compatibility, this playbook is particularly relevant to developer tools, and is protected by [the Supreme Court ruling in Google v Oracle](https://twitter.com/swyx/status/1379091545102503937). If I were to summarize it in three words, looking over Cloudflare's history and [annual report](https://d18rn0p25nwr6d.cloudfront.net/CIK-0001477333/fa0c28c8-a883-45cd-aba8-0b9c3249cc14.pdf), I might call it:\r\n\r\n- **Establish**: Establish a foothold in something incumbents don't care enough about\r\n- **Envelop**: Reverse-proxy something that incumbents don't serve customers well on\r\n- **Expand**: cross-sell other premium products and services until they are more customers of you than they are customers of the incumbent.\r\n\r\nGiven Cloudflare's fundamentally less-centralized approach to growing its cloud, it is no surprise that it [announced its first Ethereum product](https://blog.cloudflare.com/announcing-web3-gateways/) this Birthday Week; although it remains to be seen if a Web2-native company can really drop enough of its assumptions to handle Web3 threats or opportunities. If we are truly in the \"early Internet\" days of Web3, only the paranoid might survive here. Fortunately, Prince seems to be a [vocal fan of Andy Grove](https://twitter.com/search?q=from%3Aeastdakota%20grove&src=typed_query&f=top) as well.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/eating-the-cloud-from-outside-in-1n2d","devToReactions":30,"devToReadingTime":8,"devToPublishedAt":"2021-10-04T02:23:15.016Z","devToViewsCount":776,"title":"Eating the Cloud from Outside In","published":true,"description":"AWS is playing Chess. Cloudflare is playing Go.","tags":"Cloud, AWS, Strategy","slug":"cloudflare-go","canonical_url":"https://www.swyx.io/cloudflare-go","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4zf8a4nppo2jppogrshg.png"},"title":"Eating the Cloud from Outside In","description":"AWS is playing Chess. Cloudflare is playing Go. ","category":"note","tags":["cloud","aws","strategy"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4zf8a4nppo2jppogrshg.png","canonical":"https://www.swyx.io/cloudflare-go","slug":"cloudflare-go","date":"2021-10-04T02:23:15.016Z","readingTime":"8 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/169","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/169/comments","title":"Eating the Cloud from Outside In","created_at":"2022-01-17T23:01:05Z","updated_at":"2024-08-05T06:21:18Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/169/reactions","total_count":3,"+1":3,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Learning in Public with SWYX on Thunder Nerds","slug":"thundernerds-pod","tags":["LIP"],"venues":"ThunderNerds","date":"2021-10-03T00:00:00.000Z","url":"https://www.listennotes.com/podcasts/thunder-nerds/287-learning-in-public-with-Y4yNEbFi8Kh/","tweet":"https://twitter.com/thundernerds/status/1444725115766415364?s=20","description":"Today, we're thrilled to have Shawn as a guest on our podcast to discuss the past, present, and future state of JavaScript as well as the world of developer ergonomics and the magical possibilities of effortless platform management.","category":"podcast"},{"title":"Scaling and Measuring Developer Relations (with Sai Senthilkumar of Redpoint)","slug":"measuring-devrel-talk","categories":["Devrel"],"description":"I was interviewed by Sai of Redpoint for about 150 founders and devrel folks based on these blogposts","instances":[{"venue":"Swyx Youtube","date":"2021-09-25","video":"https://www.youtube.com/watch?v=guK1XiLQbH8"}],"category":"talk","date":"2021-09-25T00:00:00.000Z"},{"title":"Third Age of JS on WorkingCode","slug":"workingcode-pod","tags":["JavaScript"],"venues":"WorkingCode","date":"2021-09-22T00:00:00.000Z","url":"https://www.bennadel.com/blog/4120-working-code-podcast-episode-041-the-third-age-of-javascript-with-shawn-swyx-wang.htm","tweet":"https://twitter.com/bennadel/status/1440657316441776135?s=21","description":"Today, we're thrilled to have Shawn as a guest on our podcast to discuss the past, present, and future state of JavaScript as well as the world of developer ergonomics and the magical possibilities of effortless platform management.","category":"podcast"},{"type":"blog","content":"\r\n> Given as a talk for Infoshare 2022 ([Slides](https://docs.google.com/presentation/d/1BPiRzSkybfcajtaPv0KpUi229J0Rrsh_1KbdTRiSOUA/edit#slide=id.g35ed75ccf_022)). Translations: [Russian](https://t.me/super_oleg_dev/27)\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uqbmd7yo8iwhmttuq0np.png)\r\n\r\n*[Edit this chart](https://excalidraw.com/#json=6042109563895808,4Powv_4gGx0kX9ZZmg6l7w)*\r\n\r\nWatching recent trends in client-server paradigms, from Apollo GraphQL to React Server Components to Rails Hotwire, I've had a revelation that helped me make sense of it all: They're all abstractions over REST!\r\n\r\nThere are two schools of thought:\r\n\r\n- **Smart Client**: State updates are rendered clientside first, then sent back to the server.\r\n - **You can roll your own**: Use a state management solution like **Redux** or **Svelte Stores** and handwrite every piece of the client-server coordination logic.\r\n - **You can use libraries that combine state and data fetching**: **Apollo Client**, **React Query**, [RxDB](https://github.com/pubkey/rxdb), [GunDB](https://gun.eco/), [WatermelonDB](https://nozbe.github.io/WatermelonDB/) and [Absurd-SQL](https://jlongster.com/future-sql-web) all do dual jobs of fetching data and storing related state. (you can see [parallel implementations here](https://github.com/pubkey/client-side-databases) if evaluating)\r\n - You can use frameworks that abstract it away for you: **Blitz.js** and **Next.js**\r\n - **Or you can take it off the shelf**: **Google's Firebase** and **AWS' Amplify/AppSync** are fully vendor provided and vertically integrated with backend resources like auth, database, and storage (arguably [MongoDB Realm](https://www.mongodb.com/realm) and Meteor's [minimongo](https://www.npmjs.com/package/minimongo) before it)\r\n- **Smart Server**: State updates are sent to the server first, which then sends rerenders to the client (whether in HTML chunks, serialized React components, or XML).\r\n - [Phoenix Liveview](https://fly.io/blog/how-we-got-to-liveview/)\r\n - [Rails Hotwire](https://github.com/hotwired/hotwire-rails)\r\n - [React Server Components](https://www.swyx.io/react-server-components-demo/)\r\n - [ASP.NET Web Forms](https://docs.microsoft.com/en-us/previous-versions/bb386448(v=vs.140)?redirectedfrom=MSDN)\r\n\r\nOf course the \"Smart Server\" paradigm isn't wholly new. It has a historical predecessor — let's call it the \"Traditional Server\" paradigm. The Wordpress, Django, Laravel type frameworks would fill out HTML templates and the browser's only job is to render them and send the next requests. We gradually left that behind for more persistent interactive experiences with client-side JS (nee AJAX). For a long time we were happy with just pinging REST endpoints from the client, ensuring a clean separation of concerns between frontend and backend. \r\n\r\nSo why are we tearing up the old client-server paradigm? And which side will win?\r\n\r\n## It's about User Experience\r\n\r\nIronically, the two sides have very different goals in UX and would probably argue that the other is less performant.\r\n\r\n- Smart clients enable offline-first apps and optimistic updates so your app can keep working without internet and *feels* instant because you are doing CRUD against a local cache of remote data (I wrote about this in [Optimistic, Offline-First Apps](https://www.swyx.io/svelte-amplify-datastore) and RxDB has a [good writeup here](https://rxdb.info/offline-first.html)).\r\n - This improves **perceived performance for apps**.\r\n - However their downside is tend to come with large JS bundles upfront: Firebase adds as much as 1mb to your bundle, Amplify got it down to 230kb after a lot of modularization effort, Realm stands at 42kb.\r\n- Smart servers directly cut JS weight by doing work serverside rather than clientside, yet seamlessly patching in updates *as though they were done clientside*. Facebook has reported as high as [29% bundle reduction](https://twitter.com/swyx/status/1341151070743982080).\r\n - This improves **first-load performance for sites** and reduces total JavaScript sent throughout the session.\r\n - However their downside is that every single user of yours is doing their rendering on *your* server, not their browser. **This is bound to be more resource intensive and inserts a full network roundtrip for every user interaction**. The problem is mitigated if you can autoscale compute AND storage at the edge (eg with serverless rendering on [Cloudflare Workers](https://twitter.com/threepointone/status/1376248810003955716) or [AWS Lambda](https://twitter.com/swyx/status/1341951585396506624)). There are also real security concerns that should get ironed out over time.\r\n\r\nThe \"winner\" here, if there is such, will depend on usecase - if you are writing a web app where any delay in response will be felt by users, then you want the smart client approach, but if you are writing an ecommerce site, then your need for speed will favor smart servers.\r\n\r\n## It's about Developer Experience\r\n\r\n- **Platform SDKs**. For the Frontend-Platform-as-a-Service vendors like Firebase and AWS Amplify, their clients are transparently just platform SDKs — since they have total knowledge of your backend, they can offer you a better DX on the frontend with idiomatic language SDKs.\r\n- **Reducing Boilerplate**. Instead of a 2 stage process of writing a backend handler/resolver and then the corresponding frontend API call/optimistic update, you can write the backend once and codegen a custom client, or offer what feels like direct database manipulation on the frontend (with authorization and syncing rules).\r\n - The Smart Server boilerplate reduction is *extreme*, since the syncing protocol eliminates all need to coordinate client-server interactions. [Quote from a LiveView user](https://news.ycombinator.com/item?id=28621830): \r\n\r\n > \"LiveView is absurd. It's the biggest change I've experienced in web development since Rails v1. I've been able to build rich, interactive, games without a single line of Javascript. It takes complicated server / api / front-end build projects and results in literally 1/10th the amount of code for the same result.\"\r\n- **Offline.** Both Firebase Firestore and Amplify AppSync also support offline persistence. Since they know your database schema, it's easy to offer a local replica and conflict resolution. There are vendor agnostic alternatives like [RxDB](https://github.com/pubkey/rxdb) or [Redux Offline](https://github.com/redux-offline/redux-offline) that take more glue work.\r\n - Being Offline-first requires you to have a local replica of your data, which means that doing CRUD against your local replica can be much simpler (see below).\r\n- **Reducing Boilerplate for Optimistic Updates**.\r\n - When you do normal optimistic updates, you have to do 4 things:\r\n 1. send update to server, \r\n 2. optimistically update local state, \r\n 3. complete the optimistic update on server success,\r\n 4. undo the optimistic update on server fail\r\n - With a local database replica, you do 1 thing: write your update to the local DB and wait for it to sync up. The local DB should expose the status of the update (which you can reflect in UI) as well as let you centrally handle failures.\r\n- **People**. This is an organizational, rather than a technological, argument. How many times have your frontend developers been \"blocked by backend\" on something and now have to wait 2-3 sprints for someone else to deliver something they need? It is hugely disruptive to workflow. Give the developer full stack access to whatever they need to ship features, whether it is serverless functions, database access or something else. Smart Clients/Servers can solve *people* problems as much as UX problems.\r\n - This is why I am a big champion of shifting the industry divide from \"frontend vs backend\" to \"[product vs platform](https://twitter.com/swyx/status/1097334440169107456?s=20)\". Chris Coyier's term for this is [The All-Powerful Frontend Developer](https://css-tricks.com/the-all-powerful-front-end-developer/).\r\n - GraphQL is also secretly a \"people technology\" because it decouples frontend data requirements from a finite set of backend endpoints.\r\n\r\nBoth smart clients and smart servers greatly improve the DX on all these fronts.\r\n\r\n## It's about Protocols\r\n\r\nBetter protocols lead to improved UX (eliminating user-facing errors and offering faster updates) and DX (shifting errors left) and they're so relevant to the \"why are you avoiding REST\" debate that I split them out to their own category. Technically of course, whatever protocol you use may be a layer atop of REST - if you have a separate layer (like [CRDTs](https://github.com/jlongster/crdt-example-app)) that handles syncing/conflict resolution, then that is the protocol you are really using.\r\n\r\nA lot of these comments will feature GraphQL, because it is the non-REST protocol I have the most familiarity with; but please feel free to tell me where other protocols may fit in or differ.\r\n\r\n- **Type Safety**: GraphQL validates every request at runtime. [trpc](https://trpc.io/docs/rpc) does it at compile time.\r\n - Increased type annotation offers better codegen of client SDKs that you would otherwise have to hand-write. This is a much more established norm in gRPC than GraphQL and I'm not sure why.\r\n- **Bandwidth**: Sending less data (or data in a format that improves UX) over the wire\r\n - GraphQL helps solve the [overfetching](https://stackoverflow.com/questions/44564905/what-is-over-fetching-or-under-fetching) problem. In practice, I think the importance of this is overhyped unless you are Facebook or Airbnb. However the usefulness of [persisted queries](https://www.swyx.io/why-graphql-variables/) for solving *upload* bandwidth problems is underrated.\r\n - Hotwire sends [literal HTML Over The wire](https://hotwired.dev/)\r\n - React Server Components sends [serialized component data](https://www.youtube.com/watch?v=VA3TFymZlW4) over the wire; more compact because it can assume React, and smoothly coordinated with on-screen loading states\r\n- **Real-time**: offering \"live\" and \"collaborative\" experiences on the web\r\n - This is doable with periodic polling and long-polling, but more native protocols like UDP, WebRTC and WebSockets are probably a better solution\r\n - [Replicache](https://replicache.dev/) (used for [Next.js Live](https://nextjs.org/live)) and [Croquet](https://www.croquet.io/) look interesting here\r\n - UDP itself seems like a foundation that is ripe for much more protocol innovation; even [HTTP/3](https://www.stackscale.com/blog/http3/) will be built atop it\r\n\r\nThere remain some areas for growth that I don't think are adequately answered yet:\r\n\r\n- **Performance**: One nightmare of every backend developer is unwittingly letting a given user kick off an expensive query that could choke up system resources. Complexity budgets are not a solved problem in GraphQL. It's a touchy subject, but new protocols can at least open up a more interesting dance between performance and flexibility.\r\n- **Security**: allowing frontend developers direct database access requires much more guard rails around security. Vendors with integrated auth solutions can help somewhat, but the evangelists for a new protocol need to be as loud about their security requirements as they are the developer experience upsides.\r\n\r\n## Not Everyone is Anti-REST\r\n\r\nYes of course my title is a little clickbaity; REST is perfectly fine for the vast majority of webdevs. There are even people pushing boundaries within the REST paradigm. \r\n\r\n- [Remix](https://remix.run/), the soon-to-be-launched React metaframework from the creators of React Router, embraces native browser standards so you get progressive enhancement \"for free\", for example requiring that you [POST from a HTML form](https://remix.run/features) (they have clarified that [anything but GET is fine](https://twitter.com/remix_run/status/1439976471796203520?s=20), and they are pro-HTTP, and neutral REST)\r\n- [Supabase](https://supabase.io/) (where I am an investor) is a \"smart client\" solution that works equally well on the server, which invests heavily in the [open source PostgREST project](https://postgrest.org/en/v8.0/).\r\n\r\n---\r\n\r\n## Followups\r\n\r\n### Transitional Apps\r\n\r\nRich Harris recently gave a keynote at Jamstack conf that framed his take on this issue ([TLDR here](https://twitter.com/Rich_Harris/status/1446601175197880325)):\r\n\r\n{% youtube 860d8usGC0o %}\r\n\r\n### Reader Feedback\r\n\r\n- Jonathan W: \"The framing of the issue got my brain percolating a bit. The entire situation feels very similar to the first time a developer recognizes object-relational impedance mismatch—all the subtle differences that start to crop up as you layer an Application Framework on top of an ORM on top of an RDBMS on top of your business domain (you know, that kind of important topic). Each layer of abstraction is acceptable by itself, but the effects compound at each level and over time.\"\r\n- [@thxdr](https://twitter.com/thdxr): Other format efforts worth exploring: [JSONAPI](https://jsonapi.org/) is a JSON REST spec, and the [Relay spec](https://relay.dev/docs/guides/graphql-server-specification/) is essentially a GraphQL superset spec","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/why-do-webdevs-keep-trying-to-kill-rest-j2j","devToReactions":274,"devToReadingTime":8,"devToPublishedAt":"2021-09-20T14:46:38.648Z","devToViewsCount":13999,"title":"Why do Webdevs keep trying to kill REST?","subtitle":"The epic client-server battle of our time","published":true,"description":"How I broke out of the tiresome REST vs GraphQL debate - by realizing that the real battle is between Smart Clients and Smart Servers!","tags":"React, GraphQL, REST, Supabase","slug":"client-server-battle","canonical_url":"https://www.swyx.io/client-server-battle","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uqbmd7yo8iwhmttuq0np.png","disclaimer":"This post requires passing familiarity with all the technologies mentioned - there are too many to introduce individually, so please google them or ask me for a primer separately (I'm serious, if you can't find a good \"What is X?\" blogpost for something please ask)."},"title":"Why do Webdevs keep trying to kill REST?","subtitle":"The epic client-server battle of our time","description":"How I broke out of the tiresome REST vs GraphQL debate - by realizing that the real battle is between Smart Clients and Smart Servers! ","category":"note","tags":["react","graphql","rest","supabase"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uqbmd7yo8iwhmttuq0np.png","canonical":"https://www.swyx.io/client-server-battle","slug":"client-server-battle","date":"2021-09-20T14:46:38.648Z","readingTime":"9 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/170","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/170/comments","title":"Why do Webdevs keep trying to kill REST? ","created_at":"2022-01-17T23:01:07Z","updated_at":"2022-10-07T12:43:31Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/170/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"React and the Meta of the Web with Sunil Pai","slug":"sunil-pai-pod","categories":["React"],"description":"A wideranging podcast with Sunil covering the future of React, the Third Age of JavaScript, and the Meta of online discourse.","instances":[{"venue":"Swyx Youtube","date":"2021-09-20","video":"https://www.youtube.com/watch?v=H3h1WICelqs"}],"category":"talk","date":"2021-09-20T00:00:00.000Z"},{"type":"blog","content":"\nI was on the other side of the world when it happened.\n\nMy memory is curiously spotty about this major event I lived through. I remember exactly what I was doing at the time; yet I remember almost nothing else after.\n\nSingapore is ~12 hours ahead of New York, so I was just finishing up my night class at home, walking out to our living room TV telegraphing that the world had forever changed. I remember thinking how it was a horrific accident, and then seeing footage of the second plane and realizing it was no accident. I remember the third plane crashing into Pentagon. Then the fourth. Drip-fed to us minute by minute through our local TV news, by scared reporters who barely knew any more than we did.\n\nI don't know how I went to sleep that night. I remember looking at my baby sister, playing in her pen. Totally oblivious that the world she was born into had changed forever. (I would get that feeling again 2 years later, as [SARS](https://en.wikipedia.org/wiki/2002%E2%80%932004_SARS_outbreak) threatened to lock down Singapore in the first coronavirus outbreak of our lifetimes.)\n\nI didn't have any American friends at the time so it never got personal. But we watched with horror and confusion as the stories trickled out; [the Falling Man](https://en.wikipedia.org/wiki/The_Falling_Man), [the Flight 93 phone calls](https://www.nps.gov/flni/learn/historyculture/phone-calls-from-flight-93.htm), [the firefighters](https://en.wikipedia.org/wiki/Raising_the_Flag_at_Ground_Zero). I have no memory of how my parents or teachers dealt with it or moved on from it. I was myself unaware of how the military response moved from Afghanistan to Iraq and the intense debate prior and the quagmire after.\n\nAs a country with a 22% Muslim population, surrounded by other majority Muslim countries, tensions definitely were tight. First, copycat terrorists had to be preempted. Second, relationships needed to be rebuilt between faiths. [We would spend the next 1-7 years doing this.](https://www.straitstimes.com/singapore/politics/timeline-20-years-of-securing-singapore-following-911-attacks)\n\nTravel didn't happen for me until about 4 years later when I went on my first international trip for a choir competition. By then almost all the security measures you have today were in place, including the [shoe requirement](https://en.wikipedia.org/wiki/2001_shoe_bomb_attempt) (which now seems to have faded), although they had yet to [ban water](https://www.mentalfloss.com/article/565368/tsa-airport-liquids-rule-water-bottles-explained), and the X Ray machines weren't as fancy. For sure the days of [Rachel casually walking up to a flight](https://www.youtube.com/watch?v=g1q4w4wq8Cw) 30 minutes before departure were gone.\n\nLater when I learned more about geopolitics we would debate [The End of History](https://en.wikipedia.org/wiki/The_End_of_History_and_the_Last_Man) vs [The Clash of Civilizations](https://en.wikipedia.org/wiki/Clash_of_Civilizations) at school and I recall my classmates having very strong opinions without having really read either book. It's still not clear to me that any of that was at all useful or relevant. I remember reading dire essays about the disruptive threat of nonstate actors, yet, [as Noah Smith notes](https://noahpinion.substack.com/p/the-911-era-is-over-good), state power won, once citizens gave up their privacy.\n\nI wish I had journaled more back then. I wish I had told myself how it felt living through what I knew to be a special time. I wish I had close Muslim friends to process it with. And I wish I appreciated the difference between sudden tragedy and chronic, endemic disasters.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/september-11th-from-singapore-1a6l","devToReactions":7,"devToReadingTime":3,"devToPublishedAt":"2021-09-11T22:26:53.242Z","devToViewsCount":177,"title":"September 11th from Singapore","published":true,"description":"just some memories 20 years after 9/11.","tags":"Reflections","slug":"sept-11-from-singapore","canonical_url":"https://www.swyx.io/sept-11-from-singapore"},"title":"September 11th from Singapore","description":"just some memories 20 years after 9/11. ","category":"note","tags":["reflections"],"canonical":"https://www.swyx.io/sept-11-from-singapore","slug":"sept-11-from-singapore","date":"2021-09-11T22:26:53.242Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/171","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/171/comments","title":"September 11th from Singapore","created_at":"2022-01-17T23:01:09Z","updated_at":"2022-06-18T17:48:55Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/171/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Temporal on DevtoolsFM","slug":"devtoolsfm-pod","tags":["Temporal"],"venues":"DevTools","date":"2021-09-10T00:00:00.000Z","url":"https://devtools.fm/episode/13","description":"Join us as we chat with Shawn Wang who's Head of Developer Experience at Temporal and a staunch advocate of learning in public.","category":"podcast"},{"title":"Temporal - React for the Backend","slug":"temporal-react","categories":["Temporal"],"description":"swyx doing the podcast tour talking about everything Temporal!","instances":[{"venue":"DevtoolsFM","date":"2021-09-10","url":"https://devtools.fm/episode/13","video":"https://www.youtube.com/watch?v=yNOkWFGejUs"},{"venue":"ReactDayNY","date":"2021-10-07","video":"https://www.youtube.com/watch?v=Cxaf8E00GMM"},{"venue":"Temporal","date":"2021-10-07","video":"https://www.youtube.com/watch?v=umsYzbDtj18"},{"venue":"CascadiaJS","date":"2021-10-16","video":"https://www.youtube.com/watch?v=WRYozSljSpw"}],"category":"talk","date":"2021-09-10T00:00:00.000Z"},{"type":"blog","content":"\nWhat if I told you there was a simple strategy that can help you slow-cook a $300,000 a year side project and kickstart your indie hacker career, on a few hours a week?\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eoqzqrmmx3riez0ly7gi.png)\n\nIf you didn't care about money, how about >100k Twitter follows over 2 years?\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tlsvvck7t6wl74v3dq50.png)\n\nOr email subscribers?\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nenqwuk4glkok456gc3f.png)\n\n## Build a swipe file\n\nA \"swipe file\" is a collection of examples to copy for inspiration. The above screenshots are all real life examples from [ReallyGoodEmails](https://really-good-emails.notion.site/Really-Good-Emails-CEO-Hunt-60b87550816149719e166e15d22b9094) and [MarketingExamples](https://www.indieldn.com/post/how-harry-dry-grew-marketing-examples-to-40k-newsletter-subscribers), both (extraordinarily well executed) swipe files.\n\nI think it is one of the most underrated ways for [Part Time Creators](https://www.swyx.io/part-time-creator-manifesto/) to build a newsletter, build a brand, and get good at their craft, without reputation, expertise, or large upfront expenditure in time or money.\n\nHere is a Swipe File Swipe File for creators getting started.\n\n## The Strategy\n\n1. Start a Swipe File\n2. Collect examples\n3. Offer newsletter signup\n4. Offer login + faving\n5. Build a Community\n6. Hit the Media Circuit\n7. Make Generators\n8. Monetize\n 1. Sell Sponsor ads\n 2. Do a live workshop\n 3. Write a book\n 4. Build a course\n\nI add some more details below but that's the essence of the progression.\n\nI recorded everything below as a 14 minute video if that's your thing.\n\n{% youtube 2r7fSeMCcK8 %}\n\n## A Simple Directory\n\nGood swipe files focus in on a niche but important problem, that nobody specializes in. Here is [a site that only features og:image inspiration](https://www.ogimage.gallery/):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v6299vhagfkz9k1fq2vd.png)\n\nIt is pretty simple; the design comes from others, but the categorization comes from you. Clicking on each just sends you to the site it came from; no commentary or analysis needed. \n\n## In-App Flows\n\nSwipe files are usually static snapshots of public marketing design and copywriting, but there's no reason why you can't document the logged-in experience as well. Here's [DesignVault](https://designvault.io/app/clubhouse/):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hzbrowvearqmspetpz8k.png)\n\n## Add Commentary\n\nSwipe files lend themselves to marketing and design, because by their very nature they are visual and public. Here is [swipefile.com](https://swipefile.com/), with just a couple paragraphs of commentary on each example:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2nmnfl3k05grws3x7szn.png)\n\n## **Use a Tool**\n\nThe work gets a lot simpler and faster when you use a tool that is designed for capturing swipe files. Here's [Klart](https://klart.io/): \n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/44tsvlvhkgbcw3g1t1wt.png)\n\n## Build up Teardowns\n\nCorey Haines' [SwipeFiles.com](http://swipefiles.com) (note the plural, different from SwipeFile.com) adds step by step commentary with generalizable lessons ([scroll through this to understand](https://www.swipefiles.com/teardowns/baremetrics-recover-landing-page)):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zy6okzdsn5ygbae3b154.png)\n\n## Compelling How Tos\n\nSwitch the focus from a random assortment of \"What I like about X\" to a more directed \"How X does IMPORTANT_THING_EVERYONE_WANTS\". Title game is everything. Can you generate the \"instant click impulse?\"\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6jjooukovhklowhannwd.png)\n\n## Offer a Newsletter\n\nYes, people hate popups. Yes, they work. Yes, you can blanket it with social proof, like Harry Dry does on [MarketingExamples.com](https://marketingexamples.com/).\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iooeq2s17haf3c8k93af.png)\n\n## Build an Auth & Storage layer\n\nSince you have people's emails, you might as well give them a way to log in. As your examples pile up, people are going to want to save them to their collections, and you will want to use their faves to indicate popularity. See **[ReallyGoodEmails](https://reallygoodemails.com/)**.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e1ijsjsplr2ssofeo78f.png)\n\n## Build a Community\n\nSince people log in and heart stuff, it'd be nice if they could chat. [Circle is the best platform for that](https://jayclouse.com/how-to-build-an-online-community/). Here's the one I maintain for Learning in Public: [https://codingcareer.circle.so/c/learn-in-public](https://codingcareer.circle.so/c/learn-in-public)\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4kk7hsqbjb95z5tz7a1d.png)\n\n## Borrow a Platform\n\nWow, look at you! Email newsletter, Auth, Storage, Community... you're starting to need some serious software now around your swipe file, and you STILL need to figure out your social media distribution. You don't HAVE to have a separate platform — I often use my own Twitter as a flexible social Swipe File, and [Little Big Details](https://littlebigdetails.com/) is a Swipe File hosted on Tumblr with distribution, storage, and social features built in.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z90evhfpic26cnh5v860.png)\n\nJust keep in mind that you're *borrowing* that platform; if you didn't build it, it's not yours, and can be taken away at any time.\n\n## Make Generators and Prompts\n\nIf you CAN code though, you can level up your swipe file by letting people play mad libs with it (aka templatize your swipe file). Here's [What To Tweet](https://whattotweet.com/#) from [Josh Spector](https://joshspector.com/what-to-tweet/):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0p0qfrkstnh32h3sddo0.png)\n\nOr [the Blog Post Idea Generator](https://copywritingcourse.com/blog-post-idea-generator/):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3waei0hyg9pxvuw0ci49.png)\n\nAnd if you get really, really lucky, you can turn these [templates into a 7 figure business](https://headlime.com/blog/headlime-and-conversionai-join-forces-in-artificial-copywriting).\n\n## Hit the Media Circuit\n\nWith some initial success, it's time to hit the media circuit to get the attention up for the work you've already done. [Conferences](https://www.youtube.com/watch?v=vAE1Ssc56Nc), [Podcasts](https://www.listennotes.com/search/?q=marketing%20examples%20harry%20dry&sort_by_date=0&scope=episode&offset=0&language=Any%20language&len_min=0), Contributed articles.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4oxrtexujye3f8p2646d.png)\n\n## Time to Monetize\n\nSponsored Ads:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mcp701x0bzwy6saebxfs.png)\n\nRob Hope [turned One Page Love into a book](https://www.swyx.io/rob_hope_hot_tips/):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lxr7k0g7ijbyj60qtif8.png)\n\nAnd a [workshop](https://onepagelove.com/workshop):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ccrjgui1slyce6nbnocq.png)\n\nOr a recurring membership or SaaS, as [ReallyGoodEmail](https://really-good-emails.notion.site/Really-Good-Emails-CEO-Hunt-60b87550816149719e166e15d22b9094) have done:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5fvu1efknm63zc0se96q.png)\n\n## But I Don't Do Marketing Or Design\n\nDon't be so literal about what a swipe file is — pay attention to the *spirit* of the thing. [Mental Models](https://hn.algolia.com/?q=mental+models) are swipe files of perspectives to analyze given situations. A [tweet thread of frameworks](https://twitter.com/shreyas/status/1399042778613485578) is a swipe file of playbooks. [My Cheatsheets](https://github.com/typescript-cheatsheets/react) are swipe files of code, as is [useHooks](https://usehooks.com/):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tz98f00820zl1cno34ke.png)\n\nAll enormously useful, passively compounding sources of personal leverage for your creator journey.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-swipe-files-strategy-for-part-time-creators-45bd","devToReactions":16,"devToReadingTime":5,"devToPublishedAt":"2021-09-03T20:59:46.090Z","devToViewsCount":277,"title":"The Swipe Files Strategy for Part Time Creators","published":true,"description":"Swipe Files are underrated, passively compounding sources of personal leverage for your creator journey.","tags":"creators","slug":"swipe-files-strategy","canonical_url":"https://www.swyx.io/swipe-files-strategy","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eoqzqrmmx3riez0ly7gi.png"},"title":"The Swipe Files Strategy for Part Time Creators","description":"Swipe Files are underrated, passively compounding sources of personal leverage for your creator journey. ","category":"note","tags":["creators"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eoqzqrmmx3riez0ly7gi.png","canonical":"https://www.swyx.io/swipe-files-strategy","slug":"swipe-files-strategy","date":"2021-09-03T20:59:46.090Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/172","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/172/comments","title":"The Swipe Files Strategy for Part Time Creators","created_at":"2022-01-17T23:01:11Z","updated_at":"2023-01-04T17:59:04Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/172/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nGit moves at a surprisingly fast pace - as of Aug 2021, the current version of Git (`git --version`) is 2.33.\n\nI don't normally know or care what my Git version is, but over the past year this changed. The Git team must be doing something right, because I've noticed a few things trickle down to my relatively light usage:\n\n\n## `init.defaultBranch`\n\nThe default branch in Git is named `master`. As of Git 2.28, you can now configure it to anything else. Of course, [this is merely symbolic](https://mooseyanon.medium.com/github-f-ck-your-name-change-de599033bbbe) but is an appreciated signal.\n\n```bash\ngit config --global init.defaultBranch main\n```\n\nThis setting will work for new repos. For existing repos, and git aliases that work nicely with BOTH `master` and `main`, you can see my [Cheatsheet for moving from Master to Main](https://dev.to/swyx/move-primary-git-branch-from-master-to-main-m7c).\n\n## `git sparse-checkout`\n\nYou probably know about `git clone -–depth 1 [remote-url]` for repos where you don't want to download the full history. Git 2.25 introduced an additional command for giant repos, where even the current version is too big. So sparse checkout is like `git clone --depth 1` but for files:\n\n```bash\ngit clone --no-checkout https://github.com/my/big-repo\ncd big-repo/\n# only files at the root\ngit sparse-checkout init --cone \n# only files in specific directories (recursive)\ngit sparse-checkout set ...\n\n# do it\ngit checkout main\n```\n\n[More on the GitHub blog](https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/).\n\n## `git restore`\n\nI needed this one today. Basically if you screw up a file and need to bring it back from Git, you can use the new `git restore` command in v2.23:\n\n```bash\ngit restore path/to/file # discard current changes\ngit restore --staged path/to/file # unstage staged file\ngit restore --source [hash] path/to/file ## restore from specific commit hash\n```\n\n> ⚠️ Be careful - once you run this command you cannot get back the changes you discard.\n\nYes, there are confusingly similar commands between `checkout`, `restore`, `reset`, and even `switch`. [This StackOverflow answer](https://stackoverflow.com/a/58003889/1106414) clarifies pretty authoritatively:\n\n- `git-revert` is about making a new commit that reverts the changes made by other commits.\n- `git-restore` is about restoring files in the working tree from either the index or another commit.\nThis command does not update your branch.\nThe command can also be used to restore files in the index from another commit.\n- `git-reset` is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history.\ngit reset can also be used to restore the index, overlapping with git restore.\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/3-reasons-to-upgrade-git-2bj3","devToReactions":127,"devToReadingTime":2,"devToPublishedAt":"2021-08-30T22:29:07.922Z","devToViewsCount":7073,"title":"3 Reasons to Upgrade Git For The First Time Ever","published":true,"description":"Relatively new Git features that actually have me excited","tags":"Git, Tips","slug":"upgrade-git","canonical_url":"https://www.swyx.io/upgrade-git"},"title":"3 Reasons to Upgrade Git For The First Time Ever","description":"Relatively new Git features that actually have me excited ","category":"note","tags":["git","tips"],"canonical":"https://www.swyx.io/upgrade-git","slug":"upgrade-git","date":"2021-08-30T22:29:07.922Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/173","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/173/comments","title":"3 Reasons to Upgrade Git For The First Time Ever","created_at":"2022-01-17T23:01:13Z","updated_at":"2022-06-18T17:48:56Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/173/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> *See also the excellent discussions from [Chris Coyier](https://css-tricks.com/the-self-provisioning-runtime/), and Jeremy Daly's Serverless Chats on [Serverless Cloud](https://www.serverlesschats.com/117) (towards the end) and [then with me as a guest](https://www.serverlesschats.com/124/) and again on [the Best Of roundup](https://www.serverlesschats.com/138/)! It is also briefly mentioned in Jeremy’s [State of Serverless keynote](https://youtu.be/8E09kzyKk2g)\r\n>\r\n> I also relate this to [Temporal](https://www.swyx.io/why-temporal/) about 30mins into [the Purrfect.dev podcast](https://codingcat.dev/podcast/2-21-linking-your-microservices-with-workflows)*\r\n\r\n**If the Platonic ideal of Developer Experience is a world where you \"[Just Write Business Logic](https://twitter.com/swyx/status/1428740355994767369)\", the logical endgame is a language+infrastructure combination that figures out everything else.**\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/waips441uk8o9stb91ok.png)\r\n\r\nTwo paraphrases as assertions:\r\n\r\n- People who are really serious about developer experience should make their own language or runtime. ([quote](https://www.brainyquote.com/quotes/alan_kay_375550))\r\n- Developer Experience advances by extending the number of important problems our code handles without thinking of them. ([quote](https://en.wikiquote.org/wiki/Alfred_North_Whitehead#:~:text=Civilization%20advances%20by%20extending%20the,be%20made%20at%20decisive%20moments.))\r\n\r\nI feel a strong intuition of what the future of programming languages holds for practical (non-academic) developers, but lack the formal background to fully specify it. I'll write down the parts of the elephant I feel, and hope that the rest is so obvious that you, dear reader, shout and scream at me to fill in the blanks of my ignorance. *Please get in touch!!! My ignorance could fill a (blank) book and I need to know who to follow and what to read.*\r\n\r\n**My central assertion**: Advancements in two fields — programming languages and cloud infrastructure — will converge in a single paradigm: where all resources required by a program will be **automatically** provisioned, and optimized, *by the environment that runs it*.\r\n\r\n## Developer Experience in Languages\r\n\r\n*I am going to grossly oversimplify in order to make a point, which will infuriate some of you. I apologize in advance. It bothers me too but I did it anyway to strip out noise. If you have better examples to offer, please get in touch!*\r\n\r\nOne of Java's key advantages over C++ was its automatic garbage collection, whereas one of Go's key advantages over Java is its native CSP model. At a 50,000 ft view you can see languages as advancing by the number of hard problems that are elegantly solved by convention or language feature.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tuhhzfjn1fshlbuyyhxa.png)\r\n\r\nI've drawn the above chart as though Go is the perfect end state of things, but I want you to know that that is more due to my own lack of knowledge about what else could be abstracted. [Please improve it if you can](https://excalidraw.com/#json=5072020500905984,BgzMaD3_h6g46pLzHpPBcg) and I'll update and credit you. Adrian Colyer also has [this work of art](https://blog.acolyer.org/2019/01/25/programming-paradigms-for-dummies-what-every-programmer-should-know/) which should satisfy the more rigorously inclined:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qo0cn6cme96kmgyn7q5p.png)\r\n\r\nIn my oversimplistic interpretation, programming language advancement (and improvement in developer experience) could be viewed as the identification of programming chores that can be cleanly extracted into some shared codebase/convention with almost no loss in power.\r\n\r\n**If we can clearly define a new chore, we can make it a language feature.**\r\n\r\nA \"language paradigm\" doesn't have to be a standalone, full fledged new-parser-lexer-required programming language to do this job. Every framework, from React to Rails, parasitically imposes its own grammar and rules atop a host language, and good API design is indistinguishable from language design. *(I gave a talk on [React-as-Language](https://www.youtube.com/watch?v=Dz4q_bNDqfo) last year if you are interested in more on this.)*\r\n\r\nHowever, language development to date has mostly proceeded agnostic to infrastructure concerns, at the exact same time when infrastructure engineers are embracing languages to solve their problems.\r\n\r\n## Developer Experience in Infrastructure\r\n\r\nWhat we lost when we [broke up the monolith](https://www.notion.so/ff8a4f6757286444fa20b43f6b98b205) to move to the cloud was the assumption that everything our program needed would be in the box our program ran in. Suddenly we needed to provision storage, databases, VMs, containers, clusters, message queues, identity providers, gateways, and more and more and more vendor logos.\r\n\r\n[![https://pbs.twimg.com/media/E7-aTZlVgAMWjo5?format=jpg&name=4096x4096](https://pbs.twimg.com/media/E7-aTZlVgAMWjo5?format=jpg&name=4096x4096)](https://twitter.com/swyx/status/1423025792783568899)\r\n\r\nManaging all this by hand was impossible, so we moved toward declarative infrastructure, variously called Programmable Infrastructure or Infrastructure as Code:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pr1vy6bl5wdvonqgxqpg.png)\r\n\r\nThis works until you are knee deep in 30 minute debug loops pushing thousands of lines of YAML to see if *this* time it'll work, and start wishing for mature software engineering tooling like testing, code reuse, and linting/completions. At least that's how I see AWS CDK:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ist7stz9u9k9kdaslkzr.png)\r\n\r\nThe serverless movement started off with simple stateless functions like AWS Lambda, but with the advent of container based solutions like [AWS Fargate](https://aws.amazon.com/fargate/) and [Google Cloud Run](https://cloud.google.com/run), \"serverless\" has now come to mean autoscaling. This was another \"chore\" that is now increasingly part of every DevOps toolkit:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rs7tvd6o5kp9wx05maaz.png)\r\n\r\n([Edit this chart](https://excalidraw.com/#json=5169064850751488,0NoC4TlNlKx1UWvwlH9ZaA))\r\n\r\nBut, just like with languages, **there are new chores to be found**. The original intent of the DevOps movement was getting Devs to do their own Ops, but it feels like the outcome was mostly Ops people doing more Dev to keep up with the Joneses. If DevOps was successful enough, or if platforms were good enough at their jobs, Ops work should disappear.\r\n\r\n## Eliminating the DevOps divide\r\n\r\nWith a cutting edge stack today, you can fully describe your AWS Infrastructure in TypeScript, and write your application code in TypeScript... but yet these are separately executed and run things, with gobs of glue code between them (both explicit, in the form of connection strings, resource identifiers and client secrets, and implicit, in the form of SDKs).\r\n\r\n[Check out this example](https://github.com/dabit3/next.js-cdk-amplify-workshop) (from my former team at AWS! no diss intended at all). Here's just a glimpse of the Infra setup code: \r\n\r\n```tsx\r\n// // Infra code\r\n// lib/next-backend-stack.ts\r\nimport * as cdk from '@aws-cdk/core'\r\nimport * as cognito from '@aws-cdk/aws-cognito'\r\nimport * as appsync from '@aws-cdk/aws-appsync'\r\nimport * as ddb from '@aws-cdk/aws-dynamodb'\r\nimport * as lambda from '@aws-cdk/aws-lambda'\r\n\r\n// lib/next-backend-stack.ts\r\nconst api = new appsync.GraphqlApi(this, 'cdk-blog-app', {\r\n name: \"cdk-blog-app\",\r\n logConfig: {\r\n fieldLogLevel: appsync.FieldLogLevel.ALL,\r\n },\r\n schema: appsync.Schema.fromAsset('./graphql/schema.graphql'),\r\n authorizationConfig: {\r\n defaultAuthorization: {\r\n authorizationType: appsync.AuthorizationType.API_KEY,\r\n apiKeyConfig: {\r\n expires: cdk.Expiration.after(cdk.Duration.days(365))\r\n }\r\n },\r\n additionalAuthorizationModes: [{\r\n authorizationType: appsync.AuthorizationType.USER_POOL,\r\n userPoolConfig: {\r\n userPool,\r\n }\r\n }]\r\n },\r\n})\r\n// Create the function\r\nconst postLambda = new lambda.Function(this, 'AppSyncPostHandler', {\r\n runtime: lambda.Runtime.NODEJS_14_X,\r\n handler: 'main.handler',\r\n code: lambda.Code.fromAsset('lambda-fns'),\r\n memorySize: 1024\r\n})\r\n\r\n// Set the new Lambda function as a data source for the AppSync API\r\nconst lambdaDs = api.addLambdaDataSource('lambdaDatasource', postLambda)\r\n```\r\n\r\nAnd a glimpse at the app code:\r\n\r\n```tsx\r\n\r\nconst AWS = require('aws-sdk')\r\nconst docClient = new AWS.DynamoDB.DocumentClient()\r\n\r\nasync function getPostById(postId: string) {\r\n const params = {\r\n TableName: process.env.POST_TABLE,\r\n Key: { id: postId }\r\n }\r\n try {\r\n const { Item } = await docClient.get(params).promise()\r\n return Item\r\n } catch (err) {\r\n console.log('DynamoDB error: ', err)\r\n }\r\n}\r\n\r\nexport default getPostById\r\n```\r\n\r\nThat's still an awful lot of code between your app and its platform.\r\n\r\nWhat will it take to \"just write business logic\" and have the platform figure out the rest?\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/waips441uk8o9stb91ok.png)\r\n\r\n([Edit this chart](https://excalidraw.com/#json=6410328472551424,HnpqZm5ZufRY-hepDwr6Jg))\r\n\r\nOn a very trivial basis, we already have this. Where Heroku used to require buildpacks, most PaaS platforms now have heuristics that determine the project type for build and environment setup, automatically adapting for when you have a `Gemfile`, `requirements.txt`, `.nvmrc`, or `docker-compose.yml`. Platforms like Netlify and Vercel are going deeper than language runtimes, [detecting frameworks](https://www.netlify.com/blog/2019/04/24/zero-config-yet-technology-agnostic-how-netlify-dev-detectors-work/) and static site generators, but they are still mostly focused on build dependencies.\r\n\r\nSelf-provisioning can go further than just smarter build automation:\r\n\r\n- Imagine if you could provision a DynamoDB table by just requiring `@begin/data` in your app code (similar but not exactly like [Begin Data](https://docs.begin.com/en/data/begin-data)!)\r\n- Vercel and [Netlify](https://docs.netlify.com/configure-builds/common-configurations/next-js/) set up serverless functions based on Next.js routes and specially designated folders.\r\n- [Netlify Forms](https://docs.netlify.com/forms/setup/) scan your generated HTML and provisions any form endpoints and storage needed (see my [old Gatsby demo here](https://github.com/sw-yx/gatsby-netlify-form-example-v2) to see it in action or [my recent one with Svelte](https://www.swyx.io/sveltekit-netlify-forms/))\r\n- [Pulumi](https://www.pulumi.com/blog/building-your-first-serverless-app-using-only-javascript/) isn't automatic but combines app and provisioning logic in a very neatly concise way that would basically function as though the provisioning and app logic were actually one.\r\n- [Serverless Cloud](https://www.serverless.com/cloud) is working on **\"Infrastructure from Code\"** - Contact [Jeremy Daly](https://twitter.com/jeremy_daly) and [Doug Moscrop](https://twitter.com/dougmoscrop).\r\n {% youtube 1TKedWps7nU %}\r\n- [Aldo Bucchi is working on Lambdragon](https://dev.to/aldonline/comment/1hln8): \"Standing on the shoulders of giants (Pulumi’s closure serialization approach, Temporal/Cadence’s long running processes, Graal's multi-runtime JIT engine) and borrowing from academia when necessary for things like async transactional boundaries and type checking of heterogeneous codebases, we've spent he last two years solving all of these problems from the ground up so we can deliver a true \"universal, automatically inferred runtime\".\"\r\n- (Stealth startup) is building endpoints from statically analyzing JavaScript.\r\n- [Wasp-lang](https://github.com/wasp-lang/wasp) is a (very) new startup trying to combine React routing and the Prisma schema together in a DSL.\r\n- [Encore.dev](https://encore.dev/) by [Andre Eriksson](https://twitter.com/_eandre) - \"Call APIs as functions\" and \"Automatically managed PostgreSQL databases\"\r\n- [Cloud Compiler](https://cloudcompiler.run/) maybe... still super early\r\n- https://functionless.org/ \"Integrates with the AWS CDK, translates TypeScript application code to cloud resources and domain specific languages, and infers optimal IAM policies from business logic.\"\r\n- Chiselstrike: https://blog.chiselstrike.com/chiseling-in-the-open-7490d71e637c and https://www.nvp.com/blog/chiselstrike-simplifies-backend-builds-for-web-developers/\r\n\r\nAll this only scratches the surface of what is possible when you merge language and infrastructure. If you go down [the list of Jobs to Be Done of a Cloud](https://gist.github.com/sw-yx/ff8a4f6757286444fa20b43f6b98b205#reconstituting-the-monolith) you can see all of these can be automatically provisioned as part of the language.\r\n\r\n## Temporal.io\r\n\r\nPart of [my original Temporal pitch](https://www.swyx.io/why-temporal/) made reference to the fact that you could dynamically create retries, timeouts, task queues and timers in your application code, and Temporal would take care of it for you.\r\n\r\nFor the first time ever: **self provisioning asynchrony**.\r\n\r\n```tsx\r\n// retries and timeouts handled declaratively\r\nexport async function main(): Promise {\r\n const child = Context.child('wf name', {\r\n taskQueue: 'test',\r\n workflowExecutionTimeout: '10ms',\r\n retryPolicy: { maximumAttempts: 1 },\r\n });\r\n await child.execute();\r\n}\r\n\r\n// task queue dynamically provisioned\r\nconst workflow = workflowClient.stub('my-workflow', {\r\n taskQueue: 'my-task-queue',\r\n});\r\nconst result = await workflow.execute();\r\n\r\n// durable timer used inline with code\r\nlet hasUserResponded = false\r\nawait Promise.race([\r\n\tasync () => waitForUser().then(() => hasUserResponded = true),\r\n\tsleep(7 * DAYS) // durably set timer for 1 week!\r\n]);\r\nif (!hasUserResponded) // ... remind user or something\r\n```\r\n\r\nWhen you can freely and reliably move code into async blocks without the hassle of extra provisioning, the cost of building out new business logic features becomes dramatically cheaper. This is a subtle point, so I'm going to give you an example ([told by Joel Spolsky, featured on my mixtape](https://swyx.transistor.fm/episodes/elegant-software-joel-spolsky)) (3 min watch):\r\n\r\n{% youtube -QqIyICyXbU %}\r\n\r\nTL;DR - When Jeff Bezos wanted to turn the Amazon buying experience into a one click purchase, the engineers struggled to make it one click - their minds were set around the synchronous request-response, shopping-cart and order-confirmation model. The big unlock to One Click Purchases was accepting purchases right away, and **setting a timer** for them to change their mind. A lot of user experiences are improved by turning synchronous things asynchronous, and racing human interaction against timers, but previously the barrier to do this would be very high because of extra infrastructure involved. \r\n\r\n**Self-provisioning is key to lowering the barriers to experimentation and feature development**.\r\n\r\nBecause Temporal Server already contains the infrastructure to handle tasks and timers, Temporal *users* can essentially offload that problem to a central \"Platform\" or \"Infrastructure\" team. Still, as of today this cannot be considered fully self-provisioning, because Temporal still relies on manual monitoring and scaling (this is the central problem that Temporal Cloud solves).\r\n\r\nBesides, reliable async primitives are great, but far from the totality of infrastructure that a modern app requires. **I want ONE paradigm that auto-provisions ALL of it** based on the code I write**.**\r\n\r\n## Runtime, not Language?\r\n\r\nDoes it *have* to be a new language? This is what Paul Biggar is working on with [Darklang](https://docs.darklang.com/datastores/), where Datastores are colocated with HTTP routing and Cron and Functions:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7dmpkra9yjktktoyye98.png)\r\n\r\nYou not only *can't* code against a database that doesn't exist, you can't even code against *traffic* that doesn't exist, ensuring your code is always valid (within Dark's universe).\r\n\r\nEven if Dark is too strict for you (as it is for most), you could imagine taking advantage of a strongly typed, purposefully designed language that can be statically analyzed for all its infrastructural dependencies, which then translates to the necessary resource languages of the big clouds.\r\n\r\n> [Jolie Lang](https://www.jolie-lang.org/) is another effort I've come across here, though not so much self-provisioning as it is *infrastructure agnostic*, which I'm not really convinced solves anyone's problems but check it out and tell me if you think otherwise.\r\n\r\nMy sense is it doesn't *have* to be a new language. Imposing special rules on execution and syntax, and taking over the compiler or runtime — we even call our engineers [Language Runtime Engineers](https://startup.jobs/language-runtime-engineer-python-temporal-technologies-inc-3236482) — may be enough. \r\n\r\nRuntime optimizations are also a *huge* opportunity for dynamic (not static + upfront) self-provisioning: after all, what is serverless but a self-provisioning runtime based on traffic?\r\n\r\n## Conclusion\r\n\r\nPeople are wondering [if there is still anything left to innovate in programming languages](http://tagide.com/blog/academia/research-in-programming-languages/), but I write because I am almost certain that there is. But before we get there, the right move is probably a self provisioning *runtime* where we can prototype all these ideas - at the intersection of language and infrastructure.\r\n\r\n## Further Reading\r\n\r\n- https://erikbern.com/2021/04/19/software-infrastructure-2.0-a-wishlist.html\r\n- Nitric has been directly inspired by this post: https://nitric.io/blog/self-provisioning-runtime\r\n- Also check in with [Jeremy Daly](https://twitter.com/jeremy_daly) formerly of the Serverless Cloud team to see what he is cooking up","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-self-provisioning-runtime-3g6d","devToReactions":21,"devToReadingTime":10,"devToPublishedAt":"2021-08-30T01:02:48.949Z","devToViewsCount":1187,"title":"The Self Provisioning Runtime","published":true,"description":"Improvements in DX in both programming languages and cloud infrastructure will eventually converge in a single paradigm, where you truly \"just write business logic\" and the platform mostly figures out the rest.","tags":"DX, ideas","slug":"self-provisioning-runtime","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y3pfp9ohds23tfhehm6p.png","canonical_url":"https://www.swyx.io/self-provisioning-runtime"},"title":"The Self Provisioning Runtime","description":"Improvements in DX in both programming languages and cloud infrastructure will eventually converge in a single paradigm, where you truly \"just write business logic\" and the platform mostly figures out the rest. ","category":"note","tags":["dx","ideas"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y3pfp9ohds23tfhehm6p.png","canonical":"https://www.swyx.io/self-provisioning-runtime","slug":"self-provisioning-runtime","date":"2021-08-30T01:02:48.949Z","readingTime":"10 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/174","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/174/comments","title":"The Self Provisioning Runtime","created_at":"2022-01-17T23:01:15Z","updated_at":"2023-06-21T20:07:40Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/174/reactions","total_count":3,"+1":0,"-1":0,"laugh":0,"hooray":2,"confused":0,"heart":0,"rocket":0,"eyes":1}}},{"title":"7 Lessons to Outlive React","slug":"outlive-react","categories":["React"],"description":"There was a time before React, and there will be life after. If you tie yourself too closely to any technology, you might trap yourself and miss the next wave. Let's zoom out from the state management library du jour — what timeless lessons can we learn from React? In the talk I'll discuss lessons I've learned from studying React that I will take with me for the rest of my career.","instances":[{"venue":"React Summit","date":"2021-08-28","video":"https://www.youtube.com/watch?v=yLgq-Foc1EE"},{"venue":"ItalianCoders","date":"2021-12-10","video":"https://www.youtube.com/watch?v=b1FXpOExLQw"}],"category":"talk","date":"2021-08-28T00:00:00.000Z"},{"type":"blog","content":"\r\n*A [recent episode of SEDaily](https://softwareengineeringdaily.com/2021/08/17/octane-io-pay-as-you-go-pricing-with-akash-khanolkar/) discussed Usage Based Billing but remained fairly superficial. I went down this rabbit hole a few months ago and came out uninspired — here are my thoughts on it.*\r\n\r\n## Oct 2022 Update\r\n\r\n[Anhtho](https://twitter.com/byAnhtho) from Lago sent along her thoughts on why Stripe Billing isn't enough for usage-based billing: https://www.getlago.com/blog/is-stripe-using-stripe and also shared this piece on [separating entitlements from billing plans](https://arnon.dk/why-you-should-separate-your-billing-from-entitlement/).\r\n\r\n## Feb 2022 Update\r\n\r\n[Metronome has now emerged from stealth](https://blog.metronome.com/posts/2022/02/launch-iterate-and-scale/) with a healthy Series A:\r\n\r\n{% tweet 1488587468135813120 %}\r\n\r\nhttps://www.getlago.com/ is another new player.\r\n\r\n## Sept 2021 Update\r\n\r\nI had a great chat with Puneet and Lior from Amberflo who are actual experts in this area:\r\n\r\n{% youtube zelDLiG4SLE %}\r\n\r\nAkash from Octane was also [on PodRocket](https://podrocket.logrocket.com/octane).\r\n\r\n## My Story\r\n\r\nI remember the time when Netlify went from subscription-based billing to usage-based. We [used to have 4 tiers](https://web.archive.org/web/20181029150905/https://www.netlify.com/pricing/): Free (1 user), $45/mo (5 users + Password protection), $290/mo (10 users + RBAC), \"Call us\" (SLAs, special CDN, etc). We moved to the seat+usage based model [you see today](https://web.archive.org/web/20210823072328/https://www.netlify.com/pricing): $0/19/99 per user plans + clear limits for 8 features from Functions to Build Minutes.\r\n\r\nIt was possibly the most painful, yet high-revenue-impact work that an engineer could do. Over the course of >12 months we painstakingly instrumented every single part of the platform to not just work, but charge real money for the work we were doing. First [we started metering bandwidth](https://www.netlify.com/blog/2019/02/26/netlify-and-bandwidth/), the most obvious usage to charge for a web hosting company. Then, [new charges for build minutes](https://www.reddit.com/r/webdev/comments/dc7lx0/netlify_starts_charging_for_build_minutes/), quietly rolled out via email. Then over a year later, the journey ended with [usage charges for everything else](https://www.netlify.com/blog/2020/07/21/netlify-expands-pricing-options-more-value-for-developers-and-enterprise-teams/). (This happens to exactly match the main components of cloud businesses: [Networking, Compute, and Storage](https://twitter.com/swyx/status/1417136897894326277))\r\n\r\nTo be clear, as a DX Engineer I wasn't personally involved, so you are reading an observer's account of the problem, but I remember thinking at the time that this was a huge pain point. It took one of our most senior/capable engineers leading this project and we desperately wanted a \"Billing Engineer\" to lead this but it didn't seem a particularly attractive job to engineers. It wasn't particularly rocket sciency code, there were a lot of fiddly details to get right, and if we screwed up something we'd have particularly embarrassing consequences:\r\n\r\n{% tweet 1418567795021950982 %}\r\n\r\nBut it was also clear to me that this was important work — you can't get any \"closer to the money\" (a concept I discuss in [my Career Strategy chapter](https://www.learninpublic.org/toc)) than literally *working with money* on billing. Everyone says the single biggest lever on your business is pricing. If your billing code directly helped change the pricing model which resulted in 2x'ing revenue overnight and 100x it long term, isn't that a big deal??\r\n\r\n## Pros and Cons\r\n\r\nThe move to usage based billing proved a good move for Netlify and was surely a factor in raising our Series C.\r\n\r\n- There are a [litany](https://www.getoctane.io/blog/fair-saas-billing) of [blogposts](https://a16z.com/2021/03/11/bottom-up-pricing-packaging-let-the-user-journey-be-your-guide/#section--25) and [lists](https://openviewpartners.com/blog/usage-based-pricing-resources/) and [VC quotes](https://www.bvp.com/atlas/state-of-the-cloud-2021#Usage-based-pricing) on the benefits of usage based billing that I won't repeat here: aligning your pricing to the value you deliver, automatic \"upsells\" (accounts increase their value to you with no renegotiation), better attribution. The serverless movement is surprisingly aligned with the move to usage based pricing - instead of renting out a $5 a month box, you are now paying per function invocation.\r\n- There are downsides that aren't talked about as much — users now run build-vs-buy decisions every time they code, users fear \"denial of wallet\" attacks (since most platforms conveniently forget any spend limit features), and I now have to spend an hour in Excel just to figure out what moving any given site to Netlify will cost.\r\n\r\n## The Usage Based Billing Landscape\r\n\r\nSo when I heard [David Ulevitch mention that all SaaS companies were facing the same usage based pricing problems](https://twitter.com/swyx/status/1373430435074609153) we had faced, I got very excited. Whenever you have a boring-but-important feature you potentially have a great horizontal business on your hands. I asked for a list of who was working in this space and got a dozen DMs from people working in this space:\r\n\r\n- [Twisp](https://www.twisp.com/) (not public)\r\n- [Octane](https://www.getoctane.io/)\r\n- [Plangraph](https://www.plangraph.io/) (not public)\r\n- [MonetizeNow](https://www.monetizenow.io/) (semi-private)\r\n- [Metronome](https://getmetronome.com/) (not public)\r\n- [Chargify](https://www.chargify.com/)\r\n- [ChargeBee](https://www.chargebee.com/)\r\n- [Amberflo](https://amberflo.io/)\r\n- [RevOps](https://www.revops.io/) (historically for sales agreements, but just expanded to [usage](https://www.revops.io/usage/))\r\n- Unnamed Stripe alum\r\n- Oct 2022 update: Paigo https://news.ycombinator.com/item?id=33333584\r\n\r\nThere's loads more getting into the game — Just a simple search of \"Usage Based Billing\" yields more names like Recurly, Cheddar, Paddle, SubscriptionFlow, and Zoho. \r\n\r\n## It's more than just Billing\r\n\r\nStripe itself of course does [Metered Billing](https://stripe.com/docs/billing/subscriptions/metered-billing), and I got a confused DM from a couple of Stripe folks asking why that wasn't enough. \r\n\r\n- I don't have enough experience to REALLY know here but I would guess that most complex enough usecases require a whole data pipeline before actually making the Stripe call - aggregating the usage data, throttling extremely high frequency data, making it auditable, and applying discounts and discontinuities to the pricing or consumption function.\r\n- In order to give product/sales maximum control over pricing, you should be able to decouple pricing decisions from code as much as possible, allowing things like A/B testing of pricing and retroactive/hypothetical simulations of pricing results, all done without developer help as much as possible\r\n- Open question: if we were to implement hard limits or a credit system, should the billing system tie in to authorization? Would it slow authz down unacceptably or post unacceptable risks to uptime?\r\n- Open question: should the billing system tie in to the observability/metrics stack? it seems like there is a huge amount of overlap, but also having all your eggs in one source of truth seems like a very big risk to take if something happens to it.\r\n\r\n## Why I was scared off\r\n\r\nI was debating incubating, angel investing, or even personally working on this space myself, just based on how painful and how beneficial this journey was at Netlify. Ultimately I was scared off by the competition, and my inability to articulate some deep insight that Stripe or someone else might not eventually just build. I also was tempered in my TAM expectations when I saw that Zuora is still only at a $2b valuation.\r\n\r\nUltimately I think Usage Based Billing is a feature, not a product.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/why-isn-t-usage-based-billing-a-bigger-category-m8b","devToReactions":7,"devToReadingTime":5,"devToPublishedAt":"2021-08-23T08:28:32.312Z","devToViewsCount":562,"title":"Why Isn't Usage Based Billing A Bigger Category?","published":true,"description":"Usage billing is the new hotness for SaaS, and I have personally seen the pain it caused, but I was ultimately scared off from investing in it.","tags":"Reflections, Pricing","slug":"why-usage-billing","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kcy7senuwbb42gd7yjhw.png","canonical_url":"https://www.swyx.io/why-usage-billing"},"title":"Why Isn't Usage Based Billing A Bigger Category?","description":"Usage billing is the new hotness for SaaS, and I have personally seen the pain it caused, but I was ultimately scared off from investing in it. ","category":"note","tags":["reflections","pricing"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kcy7senuwbb42gd7yjhw.png","canonical":"https://www.swyx.io/why-usage-billing","slug":"why-usage-billing","date":"2021-08-23T08:28:32.312Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/175","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/175/comments","title":"Why Isn't Usage Based Billing A Bigger Category?","created_at":"2022-01-17T23:01:17Z","updated_at":"2022-12-30T10:22:54Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/175/reactions","total_count":1,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":1,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> \"Games are won by players who focus on the playing field –- not by those whose eyes are glued to the scoreboard.\" - Warren Buffett\r\n\r\n*Special thanks to [Matt Asay](https://www.techrepublic.com/article/tips-for-getting-developer-relations-right-at-your-company/), [Chris Aniszczyk](https://www.linkedin.com/posts/caniszczyk_measuring-developer-relations-activity-6903770012482375680-6lbc?utm_source=linkedin_share&utm_medium=member_desktop_web), [Gwen Shapira](https://twitter.com/gwenshap/status/1474316991645245441?s=20&t=SIdaZc_pY52gghJ8Mci1ew), the [Software Defined Talk crew](https://twitter.com/SoftwareDefTalk/status/1499755896456548353?s=20&t=SIdaZc_pY52gghJ8Mci1ew), and [many others](https://twitter.com/search?q=https%3A%2F%2Fwww.swyx.io%2Fmeasuring-devrel&src=typed_query) for their discussion of this post!*\r\n\r\n![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t6b2x3y2oe6v1o7eu053.png)\r\n\r\nA few years ago the key theme of one of the DevRelCons was \"metrics\". People breathlessly tweeted about how this was **the most important topic in DevRel**, to general agreement. The 2 day schedule was packed with 48 speakers with impressive titles stack ranked by follower count. Hundreds of DevRels flew in to hear DevRels thoughtlead DevRel. Drinks were drunk, hands were shook, empty promises made. Then they went home.\r\n\r\n**Nothing changed.** Today in 2021 people continue to talk about how hard it is to measure DevRel. The full videos of talks to this highly anticipated paid event worth hundreds of dollars per ticket were released on YouTube, with a total view count of 601 (not a typo). The organizers did an incredible job garnering 18 sponsors, all duly ignored. My company was one of them, spending thousands on a Gold slot for which we got 4 tickets, presumably to learn DevRel best practices and hire great talent. ***We sent none.***\r\n\r\nI did cherry pick an egregious anecdote, but it helps illustrate the typical state of DevRel accountability today. Lots of sizzle, questionable steak. **Loudly performing \"DevRel\", yet indistinguishable from \"[Con](https://dev.to/swyx/my-life-as-a-con-man-6b8)\"**. Yet despite lack of visibility, companies continue to invest! Because we *do* know that through all the noise and gladhanding, *some* value does get created and it *is* unique to all the other user acquisition channels available.\r\n\r\nI of course don't have the perfect answer. But I've lived it for a while and wanted to write down my evolving thoughts for others who are going down this same path. Instead of solutions, I'll offer structure. Instead of answering your questions, I hope to offer you better ones. \r\n\r\n*Note: I write for new DevRels as well as people running DevRel programs. This is a \"201\" blogpost rather than a \"101\" — I'm aiming to cover what introductory blogposts don't say. I will also have inconsistent capitalization and voice because I am condensing a massive amount of thoughts and trust you are smart enough to figure it out. Sometimes \"DevRel\" is one person (who actually holds the title \"Developer Advocate\" or \"DX Engineer\"), sometimes \"Devrel\" is an industry. If this upsets you, please read something else.*\r\n\r\n## Bottom Line Up Front\r\n\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yrvcdbq2vg48z492aber.png)\r\n\r\nStop looking: **Your North Star metric is \"monthly active developers\"**. If growth is accelerating, good. If growth is constant, fine. If growth is 0% or worse then whatever you are doing isn't working.\r\n\r\n- Every other company measuring devrel eventually settles on this, so just cut right to the chase. You could try \"monthly active clusters\" but you'll want each cluster's usage to grow as well so you end up indexing on \"developers\" anyway.\r\n- However MAD *is* multi-causal and a lagging indicator so you need leading indicators which you have more direct control over.\r\n\r\n## What kind of DevRel are you?\r\n\r\n![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ijj8os3spy3q2zggzlg2.png)\r\n\r\n**Unhappiness arises when there is an expectations mismatch between what the company wants out of DevRel and what each DevRel is naturally good at.** People have natural affinities — you are more likely to do well with community if you already organize meetups, you are more likely to be great at content if you are a regular on the speaker circuit, you are more likely to understand how to plug user gaps with product feedback if you already built one, etc. Don't judge a fish by its ability to climb trees.\r\n\r\nThere are three emerging sub-specialities of developer relations: **community**-focused, **content**-focused, and **product**-focused. How you are measured depends on what your strengths are and what your company *actually* thinks devrel is. We'll explore each in turn, but first some context:\r\n\r\n- A lot of companies will proclaim that their approach to developer *relations* is different from developer *evangelism* because it is a \"two way street\", meaning **you put product in front of people but also bring people's opinions back into product**.\r\n - The reality is often the ratio of this two way street traffic is 99% outbound and 1% inbound, because the product/engineering orgs haven't set aside any bandwidth for \"shadow PM-ing\" from devrel and all of devrel's metrics are outbound focused. Totally understandable, but could be better.\r\n- If you are in \"devrel\" but you walk like marketing, talk like marketing, and are measured like marketing, you are in marketing. **In fact, you are very expensive affiliate marketing**.\r\n - If you measure devrel by views, the established industry metric is \"cost per mille\" aka cost per thousand people reached. Indicative numbers: a typical developer content creator's CPM is $5, a normal devrel's CPM is $50-$100. In other words **you are paying 10-20x more to make content \"in-house\"** than just paying a \"professional\" to make something about you (often of higher quality, to a bigger audience).\r\n - Dev content agencies like [Draft](https://draft.dev/about) and [Ironhorse](https://ironhorse.io/developer-marketing/) exist but are an awkward half solution where they don't bring audience and don't have a deep relationship with your product.\r\n- So for a company devrel investment to make sense, **you have to provide some other form of value than raw anonymous reach**. This can be: depth, breadth, consistency, access, insight, community, email list building, etc.\r\n - Devrel specifically coexists as a separate discipline from marketing because developers hate marketing fluff and bottom-up + open source sales is so important for devtool adoption.\r\n - Career marketers have trouble relating to developers because so much of the conventional wisdom is inverted - you have to [sell features, not benefits](https://twitter.com/swyx/status/1361279902889086980), and be ready to dive into just-enough-technical-detail over using vague superlatives. However, marketers can still be very useful selling to other parts of the org.\r\n\r\n## Bad Metrics\r\n\r\nI've been asked to measure all these in my work: GitHub stars on my demos (yuck), traffic attributed to my Google Analytics UTM tag (yuck yuck), number of badges I could scan at a conference (yuck yuck yuck). All well intentioned but ultimately not meaningful, because they value quantity over quality, breadth over depth, free-and-superficial over paid-and-indicating-serious-interest. \r\n\r\n- Sometimes these are justified as \"something is better than nothing\", but once in place, metrics have a strange hold on the imagination: I've seriously had a CTO carelessly reject my genuine idea out of hand because \"it doesn't help OKRs\", the same OKRs we previously agreed should not describe all that we do.\r\n\r\nI agree with Amir Shevat that we should \"[do the right things over the easy to measure things](https://www.swyx.io/a16z_devrel_amir_shevat/#qa-with-amir-and-mikeal-rogers)\":\r\n\r\n- People are too flippant about using NPS. NPS is easily gamed and rating product on a 1-10 scale is meaningless to developers who know how this works. Try [the Sean Ellis question](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit#anchoring-around-a-metric-a-leading-indicator-for-productmarket-fit) instead: “How would you feel if you could no longer [use the product/be part of the community/read this content]?” and use it as a way to **segment/understand your audience** rather than being satisfied just keeping the NPS number forever high.\r\n- You are hereby banned from suggesting to A/B test anything if you do not have the traffic or the infrastructure to easily implement an A/B test like 90% of devtools startups. **A tight user feedback loop beats anonymous data.** You find out much more just showing a preview to users 1:1 or in small groups than keeping them at arms length.\r\n- [Will Klein suggests](https://twitter.com/willklein_/status/1420139597112037379?s=20) \"How quickly new releases are adopted\" for OSS devrel. This sounds good until you realize that **upgrade adoption is just a proxy for active usage** and the curves pretty much all look like this and **no matter what you do**, you can only budge them a few %:\r\n\r\n ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dhfgj2fs5t3kua9pjjcp.png)\r\n\r\n## Community-focused Developer Advocacy\r\n\r\nPeople are waking up to the lasting power of community and now [Technical Community Builder is the Hottest New Job in Tech](https://dev.to/dx/technical-community-builder-is-the-hottest-new-job-in-tech-8cl).\r\n\r\nCommunity metrics that I like (pick 1-3): \r\n\r\n- Number of active members in Slack/Discord\r\n- Number of weekly new topics in Discourse/StackOverflow/GitHub Discussions\r\n- Number of user contributions (whether it is PRs, questions, answers, blogposts, meetup talks, etc)\r\n- Number of [Orbit level 1](https://github.com/orbit-love/orbit-model) users\r\n- Number of events and number of attendees\r\n- Number of engaged \"superusers\"\r\n\r\nThings to look out for:\r\n\r\n- Beware the optics of regularly **asking your users to do free work for you**, and measuring yourself by metrics that are at best only loosely correlated with your community building work.\r\n - For example, most company \"communities\" are really just support forums, and increased support load is not always good nor does it have anything to do with your stewardship of it. Also beware of using devrel in place of a proper support team.\r\n - You need to give people a cause to rally around other than getting help. Having **great content is often the \"minimal viable community\"**.\r\n - A \"big tent\" serves your community over the company — invite your competitors to your event or conference, present together or let them do friendly trash talk, whatever makes your community an actual place where people get together to learn about your topic is good for you. This is especially effective when attempting [Category Creation](https://codingcareer.circle.so/c/devtools/category-creation-netlify-slack-datastax#comment_wrapper_2653625).\r\n- \"True\" community metrics are extremely hard to measure. For example, one definition of a good community is that people expect their association with your project/product to outlast their current employment. **The natural frequency for measuring this spans years** but no metrics system is this patient.\r\n- **Events** are underrated for fostering company community. To [paraphrase Marshall McLuhan](https://en.wikipedia.org/wiki/Understanding_Media), forums and chats are \"cold\", events are \"hot\" (EDIT: I wrote more on this idea in [Community Heat](https://www.swyx.io/community-heat)). From company office hours, to social hours, to full-on conferences and hackathons, to user-organized meetups. Measure attendance and frequency of these events. I am dead serious about this — we had a Principal DevRel whose primary job was to help organize our 3 conferences (together with Marketing) and their associated community. If he did nothing else but that, he would already have been worth his weight in gold to us.\r\n - Live hackathons are appropriate if you have good docs, short time to value, fast iteration times (<1min to change and redeploy) and people can get to a tangible wow moment *that wins them the hackathon* (particularly in a multi-vendor hackathon). So you should develop a sense of what kinds of things win hackathons — anything realtime (because a live demo can include the audience), anything phone based (everyone has a phone), anything AI based (people like seeing machines act like people), anything visual design. Remote/async hackathons may be a better option if your product has a longer time to value. Work with [Major League Hacking](https://mlh.io/), [DevTo](https://dev.to/t/hackathon), or [FreeCodeCamp](https://www.freecodecamp.org/news/tag/hackathons/), or collab/sponsor with YouTubers in your niche.\r\n- Having an engaged and growing superuser community, e.g. AWS Heroes, Java Champions, GitHub Stars and Stripe Community Experts, can help reward your most ardent advocates with access and status. **A small group of highly engaged fans can make a community feel more alive than a large group of passive users.**\r\n- If your core product is open source, how much community involvement do you really want? [Runa Capital has a definition of Active Contributors](https://medium.com/runacapital/open-source-analysis-and-os-databases-1eb1fe840719), and the big dogs go up to 200 regular contributors a year. This is a *lot* of external community to manage - is this something your engineering/product team is equipped/prepared/willing to handle?\r\n- Bonus Community questions:\r\n - Does devrel or marketing handle the swag program? Do you [tie it to open source like Gatsby](https://store.gatsbyjs.org/)? Do you build your swag/CRM with your product as a demo or is that Not-Invented-Here syndrome?\r\n - How can you measure community-generated content and community-organized meetups? Devrel scales by how it *enables users* to tell (even brag to) each other about their usage. You can borrow ideas from non-devtool \"user community\" efforts like [Notion](https://gettogether.fm/episodes/notion).\r\n - How do you bring your community closer in touch with your engineers? Kelsey Hightower ran [empathy sessions](https://www.businessinsider.com/google-cloud-kelsey-hightower-customer-empathy-sessions-2021-8) where the Kubernetes team were just expected to use Kubernetes and failed. Obviously these interactions are valuable but how do you measure?\r\n - How can you help your users **hire each other**? At Temporal we set up a [careers page for our users](https://temporal.io/careers#external-jobs). Unfortunately most of these attempts will be too sporadic to seriously measure.\r\n\r\n## Content-focused Developer Advocacy\r\n\r\nContent is the bread and butter of DevRel. If you have no idea where to start I recommend producing at least 1 piece of content on your company a week and just experimenting until you find your groove. Rewriting your blog once a year is fun, but not everyone has put in the reps to learn to regularly produce interesting content.\r\n\r\nContent metrics that I like (in rough order): \r\n\r\n- Number of Newsletter subscribers\r\n- Number of YouTube subscribers\r\n- Number of Twitter follows\r\n- Number of Workshop completions\r\n- Number of Conference/meetup appearances\r\n- [SEO Domain Authority](https://moz.com/learn/seo/domain-authority)\r\n\r\nNuances to consider:\r\n\r\n- As a content creator you have the choice between [TOFU, MOFU, and BOFU content](https://swyx.transistor.fm/episodes/tofu-mofu-and-bofu-content):\r\n - Top of Funnel - never heard of you (Awareness)\r\n - Middle of Funnel - comparing you to others and learning basic features/concepts (Evaluation)\r\n - Bottom of Funnel - deciding to buy and put you into production (Conversion)\r\n - If you only measure website traffic then you naturally incentivize DevRel to create clickbait TOFU that doesn't have to convert at all and alienate your biggest fans.\r\n- Most companies create and measure the blogposts as their main metric and the newsletter is the afterthought. If you are building a company you should see this is ass backwards. Newsletter signup (incentivized by great company blogposts and updates) keeps you honest. Most marketers and professional creators view **1 email subscriber to be worth between 100-1000 social media followers**. Even though many developers don't like giving their email and you'll need other ways to reach them, you are not exempt from universal rules of media.\r\n- In fact, the more seriously you view yourself as \"**building a media-company-within-a-company**\" rather than \"doing some content marketing\", the better you will do.\r\n - This is how seriously a16z treats its media effort: its third GP was [Margit Wennmachers](https://en.wikipedia.org/wiki/Margit_Wennmachers), a PR/Comms exec, and just started [Future.com](http://future.com) with Sonal Chokshi to create its own alternative to tech journalists.\r\n - You also don't have to build this on your own — [HubSpot bought The Hustle](https://techcrunch.com/2021/02/04/hubspot-acquires-media-startup-the-hustle/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAAGOLdJAZwMKTEwvtahBFLftY0UHRa4em-NlWREigwDiYW3cpNo-lqtWCsANBwgHpSc21kuUaKzib5xOBc8wvwwQf4byzrmU-sZDzDuPOglJPCoiJQda8j6I4HIwS4zVBNstuyd7xQ4EbvpRyWdOgjYYFwvfINtXQefmyrPOgn3Dx) for exactly this reason.\r\n - When you mash Alex Rampell's \"[The battle between every startup and incumbent comes down to whether the startup gets distribution before the incumbent gets innovation](https://a16z.com/2015/11/05/distribution-v-innovation/)\" with Justin Kan's \"[second time founders are obsessed with distribution](https://twitter.com/justinkan/status/1059989657218248704?lang=en)\", it just makes business sense to take distribution as seriously as product.\r\n- Keep in mind **the [half life of your content](https://epipheo.com/learn/what-is-the-lifespan-of-social-media-posts/)** — how long until a piece of content gets half of the views it will ever get in its lifetime. Twitter's half-life is hours, YouTube's half-life is months, blog is years. Create accordingly.\r\n - You can test things on more ephemeral media before developing them further on more permanent media.\r\n - Most managers think they are helping by establishing content calendars. I have never seen a DevRel operation stick to these beyond month 1. Turns out it is much easier to say you will do things than to actually do things. Ultimately you will create content because you are inspired to, not because some calendar said so. Keep a list of topics that you want to cover and reguarly pick them off based on subjective interest vs user need. Exception for YouTube - the recommendation algorithm does reward weekly output. See [Dan Luu on best practices for engineering blogs](https://danluu.com/corp-eng-blogs/).\r\n- **Community sizing**: There are between 5-10 million developers on YouTube (my estimate). There are between 1-2 million developers on Twitter (my estimate). There are about [6 million developers on Hacker News](https://twitter.com/swyx/status/1422043347011600386?s=20). Each have their own pet topics and sub communities. Consider/gauge/prioritize accordingly.\r\n- **Default to Consistency**: If you are new to professional content creator life, best way to get started is just [**default to consistency**](https://www.swyx.io/quality-vs-consistency/). That said, [10x content](https://sparktoro.com/blog/resources/10x-content-by-rand-fishkin/) has incredible half-life when you have the right idea.\r\n- **Workshops** are extremely underrated forms of content for achieving depth. Instead of 5,000 people watching your 5 minute video and then disappearing forever, you could have 50 people go through your 3-5 hour workshop and put it in production at work. \r\n - Record it and put it online - you're not going to get huge views on a 3-5 hour video that is so company specific, but for the people who prefer fastforwarding thru video or desperately need to solve some problem, it is hugely appreciated.\r\n - Most workshops can also be converted into self guided text based versions: see AWS Workshops like [Amplify](https://amplify-photo-sharing.workshop.aws/), [ECS](https://ecsworkshop.com/), and [EKS](https://www.eksworkshop.com/), Google [Colabs](https://colab.research.google.com/github/firebase/quickstart-python/blob/master/machine-learning/Firebase_ML_API_Tutorial.ipynb), GitHub [Learning Labs](https://lab.github.com/githubtraining/github-actions:-hello-world).\r\n- **Conference** appearances are probably overrated by most companies, by the simple fact that most developers don't go to conferences. Companies have historically overspent on devrel travel budgets if you just take into account attendee reach. However, millions of developers do watch good conference videos after the fact. You can abstractly view conference expenses as production costs for social proof and a really good YouTube video (on a channel you don't own). It's well worth producing 1-2 great conference talks a year at high profile events, and sometimes to get there, you need to practice and iterate at 5-10 smaller venues, but anything beyond that probably has diminished returns compared to anything else you could be doing.\r\n- **Meetups** are a different matter: high touch, low intensity. Being able to give the same elevator pitch over and over again at different meetups can be great for capturing the attention of a small set of developers. Use their questions and feedback to improve your elevator pitch ([2 word](https://www.swyx.io/two-words/), 1 sentence, 2 minute, 7 minute, 25 minute, 55 minute versions) as an infinite game. Raw # of meetup appearances is probably a good enough metric here.\r\n- [I agree with Steph Smith](https://twitter.com/swyx/status/1408896221456986114) that **most companies focus too much on social channels**, with the twist that most developers discover solutions more by hearing about them from friends and thoughtleaders than by searching for them. Auth0 and Digital Ocean famously prioritized an SEO based approach, however your devtool/brand should be general enough for this to work.\r\n- Bonus \"Content\" things to consider:\r\n - who owns example repos and code samples and keeps them up to date?\r\n - are you creating content because your docs aren't clear enough? are you creating docs because your product isn't intuitive? All content ultimately has a half-life — sometimes you have to go downstream to fix root cause instead of measuring someone on how well they apply bandaids.\r\n - how can you encourage real-engineer-content and user-generated content? Devrel scales by how it *enables others* to create content, not just by having a sole monopoly on content.\r\n\r\n## Product-focused Developer Advocacy\r\n\r\nProduct metrics that I like: \r\n\r\n- Number of launch day users, and positive launch day mentions\r\n- Number of prioritized user issues from DevRel\r\n- Number of monthly users of integrations/tooling\r\n- [the Sean Ellis question](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit#anchoring-around-a-metric-a-leading-indicator-for-productmarket-fit) (over NPS) for integrations/tooling managed by devrel\r\n- [Gustaf Alstromer's PMF measure](https://youtu.be/T9ikpoF2GH0?t=958): Value metric, and % retention at ideal recurring frequency\r\n- Something that measures [Developer Exceptions](https://www.swyx.io/developer-exception/), I haven't worked it out yet\r\n\r\nDevrels can provide tremendous value in the lead up to any product launch by beta testing (either personally or with users), or creating eyecatching/inspiring demos, blogposts, and videos for launch day/annual conference. \r\n\r\n- Sometimes the best product feedback can be negative: \"Hey, you need to postpone this launch, you aren't ready.\" Negative feedback is better coming from within than without, but the company culture needs to be receptive to criticism.\r\n- If you habitually shoot the messenger, however mistaken they are, don't be surprised that you stop receiving bad news.\r\n- Yes, people really do hire DevRels, tell them to give product feedback, and then ignore that feedback. This is the *norm*.\r\n\r\nDevrel are also often responsible for maintaining non-core integrations and helper tooling.\r\n\r\n- Examples: Netlify has an entire [Integrations Engineering](https://www.netlify.com/blog/2021/01/06/developer-experience-at-netlify/) team. Currently it just works on Next.js integrations, but it could also own, for example, the VS Code extension. In the past I helped build out [Netlify Dev](https://news.ycombinator.com/item?id=19615546) and [react-netlify-identity](https://github.com/netlify-labs/react-netlify-identity) as part of this function. [Sourcegraph's Integrations](https://docs.sourcegraph.com/integration) are not core product, but help adoption under their [7 stage SDLC framework](https://beyang.org/time-to-build-dev-tools.html). Popular quick start tooling like [Docker Compose](https://github.com/temporalio/docker-compose) and [Helm Charts](https://github.com/temporalio/helm-charts) also fall under this function.\r\n- A more involved version of this bleeds into \"Solutions Engineering\" where you help out with customer-specific custom demos and integration work. For large enough customers and small enough startups this is fine, but the bulk of the DevRel effort should focus on work that scales.\r\n\r\nMost devrels spend most of their time advocating TO developers than FOR them. The user-to-product feedback loop is the most underdeveloped element of developer advocacy right now basically because it is unclear who owns this function between Devrel and PM. \r\n\r\n- It can be like grooming a \"top 3 user asks\" list like [Amir Shevat did at Slack and Twitch](https://www.swyx.io/a16z_devrel_amir_shevat/#tldr)\r\n- or it can be building prototypes and \"hacky MVPs\" to validate ideas that you then hand off to engineering\r\n- or it can be collecting data on what messaging resonates with developers based on how they explain it to others\r\n- all of which is really hard to measure\r\n\r\n## Conclusion\r\n\r\nUltimately I hope for more intellectual honesty within the industry that acknowledges the complex tradeoffs:\r\n\r\n- between the need for communicating value and quantifying progress vs the dehumanizing effect of metrics on what is ultimately an extremely human endeavor\r\n- between lagging metrics that are more meaningful but where you have less control, and leading metrics where you have more control but little accountability, and the primary link between leading and lagging is \"merely\" anecdotal and qualitative but ultimately your job\r\n- where content is a personal, creative process which needs a culture that accepts risk taking and failure, hot streaks and lulls, where consistency, quality, and scope are valued differently by different segments of your audience, and too many backseat drivers guarantees death of personality and ownership.\r\n\r\nI'll leave you with one anecdote: When I first hear about a technology I keep it on a mental backburner simply to see if it sticks around and makes progress. I typically end up only trying out a technology at least one year after first hearing about it and seeing consistent progress. It's not just me; many CTOs and VP Engs recommend a **multiyear adoption path** especially for core tech. Traditional marketing advice says people have to hear about you at least 7 times before they decide to buy; for developer tools, Matt Biilmann from Netlify says it's more like 14.\r\n\r\nTry fitting *that* into your quarterly OKR review cycles.\r\n\r\n> If you are interested in more DevRel thoughts, podcasts, and books, check [the DX Circle guide](https://codingcareer.circle.so/c/dev-communities/developer-relations-wip-guide?) for more!\r\n\r\n## Addendum\r\n\r\n- https://bitergia.com/ Software Development Analytics for understanding, reporting, and decision making process regarding community health, project sustainability, development efficiency, talent retention & acquisition, content creation, developer audience analysis, and more.\r\n- https://dots.community/ Scale your community while keeping it personal. Automate routine tasks, and understand member behaviors on Slack, Discord, and more!\r\n- https://www.commonroom.io/ Common Room gives you a unified view of what’s happening across platforms — Twitter, Slack, GitHub, Discourse, Discord, Intercom, Meetup, and more.\r\n- https://orbit.love/ Grow and measure your community across any platform with Orbit, mission control for your community.\r\n- Tessa Mero has more KPIs to choose from based on her devrel group at Cloudinary and in Seattle: https://dev.to/tessamero/measuring-success-and-kpis-in-developer-relations-community-contributed-outline-1383","frontmatter":{"source":"devto","devToUrl":"https://dev.to/dx/measuring-developer-relations-ie8","devToReactions":70,"devToReadingTime":16,"devToPublishedAt":"2021-08-16T01:06:41.751Z","devToViewsCount":1449,"title":"Measuring Developer Relations","published":true,"description":"DevRel is hot but nobody knows how to measure it. That's because we don't agree on what effective DevRel *is*, and we don't agree on the tradeoffs of lagging vs leading metrics for a creative, unattributable, intimately human endeavor.","category":"essay","tags":"DX, devrel, content","slug":"measuring-devrel","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t6b2x3y2oe6v1o7eu053.png"},"title":"Measuring Developer Relations","description":"DevRel is hot but nobody knows how to measure it. That's because we don't agree on what effective DevRel *is*, and we don't agree on the tradeoffs of lagging vs leading metrics for a creative, unattributable, intimately human endeavor. ","category":"essay","tags":["dx","devrel","content"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t6b2x3y2oe6v1o7eu053.png","slug":"measuring-devrel","date":"2021-08-16T01:06:41.751Z","readingTime":"18 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/176","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/176/comments","title":"Measuring Developer Relations","created_at":"2022-01-17T23:01:19Z","updated_at":"2022-03-15T05:50:24Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/176/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nImagine a job where you make $600k a year investing other people's money (no downside) into amazing founders, try to be helpful, and make as much as $20 million over 10 years. Pretty sweet right? \n\nThose numbers aren't hypothetical; that's exactly [what Brianne Kimmel does with her WorkLife Fund](https://podcasts.apple.com/us/podcast/206-with-brianne-kimmel-how-venture-capitalists-make-money/id1469759170?i=1000530964156) (to be fair she has top tier results, with >200x returns in 2 years on Hopin and Pipe alone). It's a pretty sweet life and is governed by the Matthew effect inherent in the *capital* part of *venture capital*: initial success leads to better dealflow leads to more funds and more success.\n\nI accidentally have a decent profile for a VC career. I have an economics degree from Wharton and spent my first 6 years working in every part of finance from central banking to investment banking to hedge funds ([long story here](https://www.freecodecamp.org/news/shawn-wang-podcast-interview/)). I also code and am well recognized in (mostly JS) devtools circles. I was [with Netlify](https://www.swyx.io/farewell-netlify/) (a16z backed) from Series B to C and am now at Temporal (Sequoia backed). I have a better-than-average network across my blog, newsletter, Twitter, podcast, including many founders, a dozen GPs, and I think I've shook hands with at least 3 billionaires. As an indie creator I've watched with green-tinged eyes as [Ryan Hoover](https://www.weekend.fund/), [Li Jin](https://www.atelierventures.co/), [Tyler Tringas](https://tylertringas.com/a-new-default-funding-for-tech-companies/), [Sahil Lavingia](https://techcrunch.com/2020/08/05/gumroad-founder-sahil-lavingia-launches-new-seed-fund-in-collaboration-with-angellist/), [Paige Doherty](https://twitter.com/paigefinnn/status/1350955353291317250), [Packy McCormick](https://www.notboring.co/p/introducing-not-boring-capital) and others launched funds that tie in perfectly with their brands. (Evan Armstrong came up with a witty term for writer-VC's: [Content Capitalists](https://every.to/napkin-math/the-rise-of-the-content-capitalist))\n\nI'm nowhere near as accomplished as any of them but pursuing their *path* was at least available to me given my network and trajectory. Instead I've turned away and chosen the more traditional path of salaried startup employee, with less freedom and more discomfort. I get asked why every now and then so I figure I better jot down my post-hoc rationalizations:\n\n- **I don't want to be a meta-creator**: [Meta-Creators have a ceiling](https://www.swyx.io/meta-creator-ceiling/) to substance - they burn bright but are overwhelmingly talkers rather than doers.\n- **There is too much money chasing too few operators**: This is a time of ridiculously easy money, with GameStop still worth $11b and Dogecoin worth $26b, Devtools startups raising unicorn rounds at 260x ARR, and Roam raising a $200m seed. Interest in private company funding is at generational highs, while new company formation is just coming off generational lows. Investors say getting great dealflow is their biggest problem, but post-PMF founders themselves report that hiring experienced senior executives is *their* biggest problem.\n- **This will be much easier after I have \"made it\"**: \"I'll be ready someday\" is a terrible reason to not do things — a college friend of mine is already a GP at Greylock without ever having been a founder or early stage exec. But I also see *heaps* of bright eyed bushy tailed \"partners\" who haven't done a notable thing in their lives and I know that nobody gives them the time of day. Just being at a good firm is no longer enough — your shortform bio (founded X, led X at Y, coined X) has to get to the level where people get you on the cap table just to have your name on the funding announcement. [Power is moving to the person](https://www.notboring.co/p/power-to-the-person). As [Ashley Mayer put it](https://twitter.com/ashleymayer/status/1378090154078957571?s=20), the influencers are trying to become VCs at the exact same time as the VCs are trying to become influencers.\n\nBut the biggest reason of all: **I'm on the hunt for bigger problems**. When you are [a frog in a well](https://en.wikibooks.org/wiki/Chinese_Stories/The_frog_of_the_well), all you see when you look up is a tiny circle of sky. My imagination is constrained by my experience, and despite my already diverse background across countries, industries, and cultures, I feel like I haven't pushed myself into hard enough problems.\n\n- When you are a regular employee at a stable company working on defined career paths, everything looks \"solved\" and your main job is to learn how things are \"done\". But founding and investing in startups is not just the art of identifying what big things are broken (everyone can complain about how everything is broken), but also whether the technology and market are ready for the right people to lead everyone to the promised land.\n- When you take the \"solve your own problems\" approach you most like come up with B2C ideas, which are pretty universally regarded to be much harder than B2B (B2C has lower ARPU, higher churn, higher support cost, higher UX/design bar, but do have high growth potential). On my own, the best idea I've had is \"[Superhuman for Twitter](https://twitter.com/search?q=from%3Aswyx%20twitter%20client&src=typed_query)\". At Temporal, I've had two theses — [X University as a Service](https://twitter.com/swyx/status/1319028647349555200), [the Enterprise House of Brands](https://twitter.com/swyx/status/1338956681695227904) — that off the bat have much better revenue potential and lower product/platform risk.\n\nAs an \"operator\" I'm focusing on specializing in Developer Experience, which economically speaking is helping Developer Tools companies \"cross the chasm\". I also practice this on a light burn basis with [Svelte Society](https://twitter.com/SvelteSociety), which in its second year alone memed Svelte to the [top of the StackOverflow frameworks survey](https://twitter.com/SvelteSociety/status/1422372693827985409?s=20).\n\nI'm not resting on my laurels though. I started angel investing last year and have made 6 investments so far, 2 of which already have markups. I'll share more detailed investment theses for each soon, but I think my goal is to deploy ~$50k/yr as an angel as a way to dip my toe into startup investing, mindful that valuations are sky high right now. If I get an early hit, then that's an accelerant to an eventual VC career. \n\nI could also start a syndicate or rolling fund. Even now the maximum I've allowed myself to go is starting a devtools-angels [list](https://github.com/sw-yx/devtools-angels/) and [Discord](https://discord.gg/7xkkV6CF) (where we are currently at 400 members!!) but the principle is the same — I'm not ready to be a fulltime investor, so I refuse to take formal steps, but I'm happy to lay the groundwork and have the option someday.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/why-i-m-not-a-vc-yet-2md8","devToReactions":34,"devToReadingTime":5,"devToPublishedAt":"2021-08-08T06:26:46.379Z","devToViewsCount":2115,"title":"Why I'm not a VC (yet)","published":true,"description":"There is too much money chasing too few operators.","tags":"Reflections, Money, VC","slug":"not-vc-yet","canonical_url":"https://www.swyx.io/not-vc-yet"},"title":"Why I'm not a VC (yet)","description":"There is too much money chasing too few operators. ","category":"note","tags":["reflections","money","vc"],"canonical":"https://www.swyx.io/not-vc-yet","slug":"not-vc-yet","date":"2021-08-08T06:26:46.379Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/177","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/177/comments","title":"Why I'm not a VC (yet)","created_at":"2022-01-17T23:01:21Z","updated_at":"2022-06-18T17:48:56Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/177/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> You can hear me read this [on my mixtape here](https://swyx.transistor.fm/episodes/the-genius-of-apples-name-brent-schlender).\r\n\r\nI recently started [the audiobook version of Brent Schlender's Becoming Steve Jobs](https://amzn.to/3BsnXH3) and this passage on Apple's name made me stop in my tracks:\r\n\r\n> There are different tales about the origin of the name, but it was a brilliant decision. Years later, Lee Clow, Steve’s longtime collaborator on Apple’s distinctive brand of advertising, told me, “I honestly believe that his intuition was that they were going to **change people’s lives by giving them technology they didn’t know they needed, that would be different from anything they knew.** So they needed something friendly and approachable and likable. He took a page out of Sony’s book, because Sony was originally called Tokyo Telecommunications Engineering Corporation, and [cofounder] Akio Morita said they needed something much more approachable.”\r\n>\r\n>Indeed, adopting the name Apple foreshadows the expansiveness and originality Steve would bring to the creation of these new machines. It’s suggestive of so much: the Garden of Eden, and the humanity — both good and bad — resulting from Eve’s bite of the fruit from the Tree of Knowledge; Johnny Appleseed, the great sower of plentitude from American myth; the Beatles and their own record label, a connection that would lead to litigation years later; Isaac Newton, the plummeting apple, and the spark of an idea; American as apple pie; the legend of William Tell, who saved his own life and that of his son by using his crossbow to pierce an apple perched on the son’s head; wholesomeness, fecundity, and, of course, the natural world. \r\n>\r\n> **Apple is not a word for geeks**, unlike Asus, Compaq, Control Data, Data General, DEC, IBM, Sperry Rand, Texas Instruments, or Wipro, to mention some less felicitously named computer companies. It hints at a company that would bring, as it eventually did, humanism and creativity to the science and engineering of computers. As Clow suggests, settling on Apple was a great, intuitive decision. Steve was innately comfortable trusting his gut; it’s a characteristic of the best entrepreneurs, a necessity for anyone who wants to make a living developing things no one has ever quite imagined before.\r\n\r\nI don't know how many times I've looked at names like Asus, IBM, Wipro, and Texas Instruments and never reflected on how they are clearly less friendly than \"Apple\". It's obvious in retrospect — the best kind of obvious.\r\n\r\nLongtime readers here will know I have opinions on [How to Name Things](https://www.swyx.io/how-to-name-things/) - mostly in code. It's easy to have strong opinions about stuff only developers see since user validation is just asking people like yourself. It's much harder to name something consumer facing. Here are some useful rules I gleaned from Apple:\r\n\r\n- Two syllables max\r\n- Familiar English word - literal 5 year olds can spell and pronounce it right\r\n- Starts with A - useful for alphabetical sort. [Amazon did this too](http://blog.idonethis.com/startup-name/)\r\n- Name leads to easy logo/swag/branding ideas\r\n- Evoke aspirational qualities - knowledge, health, nature\r\n\r\nI've vacillated somewhat on whether or not to use an English word for a name. My current company, [Temporal](http://temporal.io/), is an English word, and by sheer misfortune it exactly coincided with [the Temporal JavaScript proposal](https://github.com/tc39/proposal-temporal). Given that we aim to [release a JS SDK soon](https://github.com/temporalio/sdk-node), this is regrettable potential confusion in every customer conversation. Whereas if you just make up a word, like \"Netlify\", or \"Serverless\", you not only ensure that you never clash with anyone, you also shoot right to the top in SEO results. Then again, people can just append \"Apple Computer\" or \"Apple Macintosh\" and do fine.\r\n\r\nWhatever you do, the worst outcome of naming something an English word is [if it leads people to assume it does something different than you intend](https://twitter.com/zachleat/status/1387103114604470272?s=20). It can help to do a sanity check by asking people to guess what your thing does without context.\r\n\r\n## Related Reads\r\n\r\n- [How to Name Things](https://www.swyx.io/how-to-name-things/)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-genius-of-apple-s-name-2643","devToReactions":13,"devToReadingTime":3,"devToPublishedAt":"2021-07-22T02:11:17.479Z","devToViewsCount":761,"title":"The Genius of Apple's Name","published":true,"description":"An excerpt from Becoming Steve Jobs that made me stop in my tracks.","tags":"apple, naming, tech","slug":"apples-name","canonical_url":"https://www.swyx.io/apples-name","cover_image":"https://data1.ibtimes.co.in/en/full/567663/becoming-steve-jobs.jpg?h=450&l=50&t=40"},"title":"The Genius of Apple's Name","description":"An excerpt from Becoming Steve Jobs that made me stop in my tracks. ","category":"note","tags":["apple","naming","tech"],"image":"https://data1.ibtimes.co.in/en/full/567663/becoming-steve-jobs.jpg?h=450&l=50&t=40","canonical":"https://www.swyx.io/apples-name","slug":"apples-name","date":"2021-07-22T02:11:17.479Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/178","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/178/comments","title":"The Genius of Apple's Name","created_at":"2022-01-17T23:01:23Z","updated_at":"2022-02-03T10:44:10Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/178/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> - You can [listen to the audio narrated version here](https://swyx.transistor.fm/episodes/weekend-drop-temporal-the-iphone-of-system-design).\r\n> - I elaborated on these in:\r\n> - [CascadiaJS](https://www.youtube.com/watch?v=WRYozSljSpw) (9 min lightning talk)\r\n> - [React NYC](https://youtu.be/Cxaf8E00GMM) (30min talk)\r\n> - [The MongoDB Podcast](https://mongodb.libsyn.com/ep-93-swyx-learn-in-public-and-temporal) (33min podcast)\r\n> - [The SourceGraph Podcast](https://about.sourcegraph.com/podcast/swyx/) (1h15min podcast)\r\n> - [Complete Intro to Temporal](https://www.youtube.com/watch?v=CeHSmv8oF_4&feature=emb_title) (2h workshop - first 10mins has the \"Why Temporal\")\r\n> - [The Purrfect.Dev Podcast](https://codingcat.dev/podcast/2-21-linking-your-microservices-with-workflows)\r\n\r\nI'm excited to finally share why I've joined [Temporal.io](http://temporal.io) as Head of Developer Experience. It's taken me months to precisely pin down why I have been obsessed with Workflows in general and Temporal in particular. \r\n\r\nIt boils down to 3 core opinions: Orchestration, Event Sourcing, and Workflows-as-Code.\r\n\r\n*Target audience: product-focused developers who have some understanding of system design, but limited distributed systems experience and no familiarity with workflow engines. My only goal is to outline Temporal's core design goals and to imply that, if you share these goals, then you will eventually build something like Temporal, as [Mitchell Hashimoto put it](https://temporal.io/#final-quote). I will not explain how it works, how to get started, or even really what Temporal is — that comes later.*\r\n\r\n## 30 Second Pitch\r\n\r\nThe most valuable, mission-critical workloads in any software company are long-running and tie together multiple services. \r\n\r\n- **Because this work relies on unreliable networks and systems**:\r\n - You want to standardize timeouts and retries.\r\n - You want offer \"reliability on rails\" to every team.\r\n- **Because this work is so important**:\r\n - You must never drop any work.\r\n - You must log all progress.\r\n- **Because this work is complex**:\r\n - You want to easily model dynamic asynchronous logic...\r\n - ...and reuse, test, version and migrate it.\r\n\r\n**Finally, you want all this to scale**. The same programming model going from small usecases to millions of users without re-platforming. Temporal is the best way to do all this — by writing idiomatic code known as **\"workflows\"**.\r\n\r\n## Requirement 1: Orchestration\r\n\r\nSuppose you are executing some business logic that needs to go through System A, then System B, and then System C. Easy enough right?\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vbkxrbfs1qroe2xdxr6u.png)\r\n\r\nBut:\r\n\r\n- System B has rate limiting, so sometimes it fails right away and you're just expected to try again some time later.\r\n- System C goes down a lot — and when it does, it doesn't actively report a failure. Your program is perfectly happy to wait an infinite amount of time and never retry C.\r\n\r\nYou could deal with B by just looping until you get a successful response, but that ties up compute. Probably the better way is to persist the incomplete task in a database and set a cron job to periodically retry the call.\r\n\r\nDealing with C is similar, but with a twist. You still need B's code to retry the API call, but you also need another (shorter lived, independent) scheduler to place a reasonable timeout on C's execution time since it doesn't report failures when it goes down.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rckh4r82ipdl4pgbnt7d.png)\r\n\r\nWiring together queues, timers, databases, and serverless functions just to do retries (just retries!) is a real architecture [recommended by AWS](https://aws.amazon.com/blogs/compute/using-amazon-sqs-dead-letter-queues-to-replay-messages/):\r\n\r\n[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sudt9rwhnz96y9lizpbm.png)](https://aws.amazon.com/blogs/compute/using-amazon-sqs-dead-letter-queues-to-replay-messages/)\r\n\r\nBut imagine doing this *per system*. Pretty soon your architecture looks [like this](https://theburningmonk.com/2017/04/aws-lambda-3-pro-tips-for-working-with-kinesis-streams/):\r\n\r\n[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yg4aawm4h6bo0t1wg8mk.png)](https://theburningmonk.com/2017/04/aws-lambda-3-pro-tips-for-working-with-kinesis-streams/)\r\n\r\nDo this often enough and you soon realize that [writing timeouts and retries are really standard production-grade requirements](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) when crossing any system boundary, whether you are calling an external API or just a different service owned by your own team. \r\n\r\nInstead of writing custom code for timeout and retries for every single service every time, is there a better way? Sure, we could centralize it!\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4k8vcafyzeiusfwj6m5d.png)\r\n\r\nWe have just rediscovered the need for **orchestration over choreography**. There are various names for the combined A-B-C system orchestration we are doing — depending who you ask, this is either called a Job Runner, Pipeline, or Workflow.\r\n\r\nHonestly, what interests me (more than the deduplication of code) is **the deduplication of infrastructure**. The maintainer of each system **no longer has to provision** the additional infrastructure needed for this stateful, potentially long-running work. This drastically simplifies maintenance — you can shrink your systems down to as small as a single serverless function — and makes it easier to spin up new ones, with the retry and timeout standards you now expect from every production-grade service. Workflow orchestrators are \"reliability on rails\".\r\n\r\nBut there's a risk of course — you've just added a centralized dependency to every part of your distributed system. *What if it ALSO goes down?*\r\n\r\n## Requirement 2: Event Sourcing\r\n\r\nThe work that your code does is mission critical. What does that really mean?\r\n\r\n- **We cannot drop anything.** All requests to start work must either result in error or success - no \"it was supposed to be running but got lost somewhere\" mismatch in expectations.\r\n- **During execution, we must be able to resume from any downtime**. If any part of the system goes down, we must be able to pick up where we left off.\r\n- **We need the entire history** of *what* happened *when*, for legal compliance, in case something went wrong, or if we want to analyze metadata across runs.\r\n\r\nThere are two ways to track all this state. The usual way starts with a simple task queue, and then adds logging:\r\n\r\n```jsx\r\n(async function workLoop() {\r\n\tconst nextTask = taskQueue.pop()\r\n\tawait logEvent('starting task:', nextTask.ID)\r\n\ttry {\r\n\t\tawait doWork(nextTask) // this could fail!\r\n\tcatch (err) {\r\n\t\tawait logEvent('reverting task:', nextTask.ID, err)\r\n\t\ttaskQueue.push(nextTask)\r\n\t}\r\n\tawait logEvent('completed task:', nextTask.ID)\r\n\tsetTimeout(workLoop, 0)\r\n})()\r\n```\r\n\r\nBut logs-as-afterthought has a bunch of problems.\r\n\r\n- The logging is not tightly paired with the queue updates. If it is possible for one to succeed but the other to fail, you either have unreliable logs or dropped work — unacceptable for mission critical work. This could also happen if the central work loop itself goes down while tasks are executing.\r\n- At the local level, you can fix this with batch transactions. Between systems, you can create two-phase commits. But this is a messy business and further bloats your business code with a ton of boilerplate — IF (a big if) you have the discipline to instrument every single state change in your code.\r\n\r\nThe alternative to logs-as-afterthought is logs-as-truth: If it wasn't logged, it didn't happen. This is also known as **Event Sourcing**. We can always reconstruct current state from an ever-growing list of `eventHistory`:\r\n\r\n```jsx\r\n(function workLoop() {\r\n\tconst nextTask = reconcile(eventHistory, workStateMachine)\r\n\tdoWorkAndLogHistory(nextTask, eventHistory) // transactional\r\n\tsetTimeout(workLoop, 0)\r\n})()\r\n```\r\n\r\nThe next task is strictly determined by comparing the event history to a state machine (provided by the application developer). Work is either done and committed to history, or not at all.\r\n\r\nI've handwaved away a lot of heavy lifting done by `reconcile` and `doWorkAndLogHistory`. But this solves a lot of problems: \r\n\r\n- Our logs are **always reliable**, since that is the *only* way we determine what to do next.\r\n- We use **transactional guarantees** to ensure that work is either done and tracked, or not at all. There is no \"limbo\" state — at the worst case, we'd rather retry already-done work with idempotency keys than drop work.\r\n- Since there is no implicit state in the work loop, it can be **restarted easily** on any downtime (or scaled horizontally for high load).\r\n- Finally, with standardized logs in our event history, we can share **observability and debugging tooling** between users.\r\n\r\n*You can also make an analogy to the difference between \"filename version control\" and git — Using event histories as your source of truth is comparable to a git repo that reflects all git commits to date.*\r\n\r\nBut there's one last problem to deal with - how exactly should the developer specify the full state machine?\r\n\r\n## Requirement 3: Workflows-as-Code\r\n\r\nThe prototypical workflow state machine is a JSON or YAML file listing a sequence of steps. But this abuses configuration formats for expressing code. it doesn't take long before you start adding features like conditional branching, loops, and variables, until you have an underspecified Turing complete \"domain specific language\" hiding out in your JSON/YAML schema. \r\n\r\n```jsx\r\n[\r\n {\r\n \"first_step\": {\r\n \"call\": \"http.get\",\r\n \"args\": {\r\n \"url\": \"https://www.example.com/callA\"\r\n },\r\n \"result\": \"first_result\"\r\n }\r\n },\r\n {\r\n \"where_to_jump\": {\r\n \"switch\": [\r\n {\r\n \"condition\": \"${first_result.body.SomeField < 10}\",\r\n \"next\": \"small\"\r\n },\r\n {\r\n \"condition\": \"${first_result.body.SomeField < 100}\",\r\n \"next\": \"medium\"\r\n }\r\n ],\r\n \"next\": \"large\"\r\n }\r\n },\r\n {\r\n \"small\": {\r\n \"call\": \"http.get\",\r\n \"args\": {\r\n \"url\": \"https://www.example.com/SmallFunc\"\r\n },\r\n \"next\": \"end\"\r\n }\r\n },\r\n {\r\n \"medium\": {\r\n \"call\": \"http.get\",\r\n \"args\": {\r\n \"url\": \"https://www.example.com/MediumFunc\"\r\n },\r\n \"next\": \"end\"\r\n }\r\n },\r\n {\r\n \"large\": {\r\n \"call\": \"http.get\",\r\n \"args\": {\r\n \"url\": \"https://www.example.com/LargeFunc\"\r\n },\r\n \"next\": \"end\"\r\n }\r\n }\r\n]\r\n```\r\n\r\nThis example happens to be from [Google](https://github.com/GoogleCloudPlatform/workflows-samples/blob/main/src/step_conditional_jump.workflows.json), but you can compare similar config-driven syntaxes from [Argo](https://github.com/serverlessworkflow/specification/blob/57ed379acdf066c7dd87644b1ec2254f1f350ba6/comparisons/comparison-argo.md), [Amazon](https://states-language.net/spec.html), and [Airflow](https://airflow.apache.org/docs/apache-airflow/stable/tutorial.html#example-pipeline-definition). The bottom line is you ultimately find yourself hand-writing the Abstract Syntax Tree of something you can read much better in code anyway:\r\n\r\n```jsx\r\nasync function dataPipeline() {\r\n\tconst { body: SomeField } = await httpGet(\"https://www.example.com/callA\")\r\n\tif (SomeField < 10) {\r\n\t\tawait httpGet(\"https://www.example.com/SmallFunc\")\r\n\t} else if (SomeField < 100) {\r\n\t\tawait httpGet(\"https://www.example.com/MediumFunc\")\r\n\t} else {\r\n\t\tawait httpGet(\"https://www.example.com/BigFunc\")\r\n\t}\r\n}\r\n```\r\n\r\nThe benefit of using general purpose programming languages to define workflows — Workflows-as-Code — is that you get to **the full set of tooling** that is already available to you as a developer: from IDE autocomplete to linting to syntax highlighting to version control to ecosystem libraries and test frameworks. But perhaps the biggest benefit of all is the reduced need for context switching from your application language to the workflow language. (So much so that you could copy over code and get reliability guarantees with only minor modifications.)\r\n\r\nThis config-vs-code debate arises in multiple domains: You may have encountered this problem in AWS provisioning (CloudFormation vs CDK/Pulumi) or CI/CD (debugging giant YAML files for your builds). Since you can always write code to interpret any declarative JSON/YAML DSL, the code layer offers a superset of capabilities.\r\n\r\n## The Challenge of DIY Solutions\r\n\r\nSo for our mission critical, long-running work, we've identified three requirements:\r\n\r\n1. We want an **orchestration** engine between services.\r\n2. We want to use **event sourcing** to track and resume system state.\r\n3. We want to write all this **with code** rather than config languages.\r\n\r\nRespectively, these solve the pain points of reliability boilerplate, implementing observability/recovery, and modeling arbitrary business logic.\r\n\r\nIf you were to build this on your own: \r\n\r\n- You can find an orchestration engine off the shelf, though few have a strong open source backing.\r\n- You'd likely start with a logs-as-afterthought system, and accumulating inconsistencies over time until they are critical enough to warrant a rewrite to a homegrown event sourcing framework with stronger guarantees.\r\n- As you generalize your system for more use cases, you might start off using a JSON/YAML config language, because that is easy to parse. If it were entrenched and large enough, you might create an \"as Code\" layer just as AWS did with AWS CDK, causing an impedance mismatch until you rip out the underlying declarative layer.\r\n\r\nFinally, you'd have to make your system scale for many users (horizontal scaling + load balancing + queueing + routing) and many developers (workload isolation + authentication + authorization + testing + code reuse).\r\n\r\n## Temporal as the \"iPhone solution\"\r\n\r\nWhen [Steve Jobs introduced the iPhone](https://www.youtube.com/watch?v=MnrJzXM7a6o) in 2007, he introduced it as \"a widescreen iPod with touch controls, a revolutionary mobile phone, and a breakthrough internet communications device\", before stunning the audience: \"These are *not* three separate devices. This is **ONE** device.\"\r\n\r\n{% youtube MnrJzXM7a6o %}\r\n\r\nThis is the potential of Temporal. Temporal has opinions on how to make each piece best-in-class, but the tight integration creates a programming paradigm that is ultimately greater than the sum of its parts:\r\n\r\n- You can build a UI that natively understands workflows as potentially infinitely long running business logic, exposing retry status, event history, and code input/outputs.\r\n- You can build workflow migration tooling that verifies that old-but-still-running workflows have been fully accounted for when migrating to new code.\r\n- You can add pluggable persistence so that you are agnostic to what databases or even what cloud you use, helping you be cloud-agnostic.\r\n- You can run polyglot teams — each team can work in their ideal language, and only care about serializable inputs/outputs when calling each other, since event history is language-agnostic.\r\n- There are more possibilities I can't talk about yet.\r\n\r\n## The Business Case for Temporal\r\n\r\nA fun anecdote about how I got the job: through blogging.\r\n\r\nWhile exploring the serverless ecosystem at Netlify and AWS, I always had the nagging feeling that it was incomplete and that the most valuable work was always \"left as an exercise to the reader\". The feeling crystallized when I rewatched DHH's 2005 Ruby on Rails demo and realized that there was no way the serverless ecosystem could match up to it. We broke up the monolith to scale it, but there were just too many pieces missing.\r\n\r\nI started analyzing cloud computing from a \"Jobs to Be Done\" framework and wrote two throwaway blogposts called [Cloud Operating Systems and Reconstituting the Monolith](https://gist.github.com/sw-yx/ff8a4f6757286444fa20b43f6b98b205). My ignorant posting led to [an extended comment from a total internet stranger](https://twitter.com/swyx/status/1226747097208295424) telling me all the ways I was wrong. [Lenny Pruss](https://twitter.com/lennypruss?lang=en), who was ALSO reading my blogpost, saw this comment, and got Ryland to join Temporal as Head of Product, and he then turned around and pitched (literally pitched) me to join.\r\n\r\nOne blogpost, two jobs. [Learn in Public](https://www.swyx.io/LIP) continues to amaze me by the [luck it creates](https://www.swyx.io/create-luck).\r\n\r\nStill, why would I quit a comfy, well-paying job at Amazon to work harder for less money at a startup like this?\r\n\r\n- **Extraordinary people**. At its core, betting on any startup is betting on the people. The two cofounders of Temporal have been working on variants of this problem for over a decade each at AWS, Microsoft, and Uber. They have attracted an extremely high caliber team around them, with centuries of distributed systems experience. I report to the Head of Product, who is one of the fastest scaling executives Sequoia has ever seen.\r\n- **Extraordinary adoption**. Because it reinvents service orchestration, Temporal (and its predecessor Cadence) is very horizontal by nature. [Descript uses it](https://docs.temporal.io/blog/descript-case-study) for audio transcription, [Snap uses it](https://eng.snap.com/build_a_reliable_system_in_a_microservices_world_at_snap) for ads reporting, [Hashicorp uses it](https://temporal.io/#final-quote) for infrastructure provisioning, [Stripe uses it](https://stripe.com/jobs/listing/infrastructure-engineer-developer-productivity-workflow-engine/2964407) for the workflow engine behind Stripe Capital and Billing, [Coinbase uses it](https://docs.temporal.io/blog/reliable-crypto-transactions-at-coinbase/) for cryptocurrency transactions, [Box uses it](https://docs.temporal.io/blog/Temporal-a-central-brain-for-Box) for file transfer, [Datadog uses it](https://www.youtube.com/watch?v=eWFpl-nzGsY) for CI/CD, [DoorDash uses it](https://doordash.engineering/2020/08/14/workflows-cadence-event-driven-processing/) for delivery creation, [Checkr uses it](https://docs.temporal.io/blog/how-temporal-simplified-checkr-workflows/) for background checks. Within each company, growth is viral; once one team sees successful adoption, dozens more follow suit within a year, all through word of mouth.\r\n ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p51uo0krl90sx03s83sp.png)\r\n- **Extraordinary results**. After migrating, Temporal users report production issues falling from once-a-week to near-zero. Accidental double-spends have been discovered and fixed, saving millions in cold hard cash. Teams report being able to move faster, thanks to testing, code reuse, and standardized reliability. While the value of this is hard to quantify, it is big enough that users organically tell their friends and [list Temporal in their job openings](https://temporal.io/careers#external-jobs).\r\n- **Huge potential market growth**. The main thing you bet on when it comes to Temporal is that its primary competition really is homegrown workflow systems, not other engines like Airflow, AWS Step Functions, and Camunda BPMN. In other words, even though Temporal should gain market share, **the real story is market growth**, driven by the growing microservices movement and developer education around best-in-class orchestration. At AWS and Netlify, I always felt like there was a missing capability in building serverless-first apps — duct-taping functions and cronjobs and databases to do async work — and it all fell into place the moment I saw Temporal. I'm betting that there are many, many people like me, and that I can help Temporal reach them.\r\n- **High potential value capture**. Apart from market share and market growth, any open source project has the additional challenge of value capture, since users can self-host at any time. I mostly subscribe to David Ulevitch's take that [open source SaaS is basically outsourcing ops](https://mobile.twitter.com/swyx/status/1373425786351284228). I haven't talked about [Temporal's underlying architecture](https://docs.temporal.io/blog/workflow-engine-principles) but it has quite a few moving parts and takes a lot of skill and system understanding to operate. For reasons I won't get into, Temporal scales best on Cassandra and that alone is enough to make most want to pay someone else to handle it.\r\n- **Great expansion opportunities**. Temporal is by nature the most direct source of truth on the most valuable, mission critical workflows of any company that adopts it. It can therefore develop the most mission critical dashboard and control panel. Any source of truth also becomes a natural aggregation point for integrations, leaving open the possibility of an internal or third party service marketplace. With the Signals and Queries features, Temporal easily gets data in and out of running workflows, making it an ideal foundation for the sort of human-in-the-loop work for [the API Economy](https://www.swyx.io/api-economy/). Imagine toggling just one line of code to A/B test vendors and APIs, or have Temporal learn while a domain expert manually executes decision processes and take over when it has seen enough. As a \"high-code\" specialist in reliable workflows, it could be a neutral arms dealer in the \"low-code\" gold rush, or choose to get into that game itself. If you want to get really wild, the secure distributed execution model of Workflow workers could be facilitated by an [ERC-20 token](https://www.investopedia.com/news/what-erc20-and-what-does-it-mean-ethereum/). (*to be clear... everything listed here is personal speculation and not the company roadmap)*\r\n\r\nThere is much work to do, though. Temporal Cloud needs a lot of automation and scaling before it becomes generally available. Temporal's UI is in the process of a full rewrite. Temporal's docs need a lot more work to fully explain such a complex system with many use cases. Temporal still doesn't have a production-ready Node.js or Python SDK. And much, much, more to do before Temporal's developer experience becomes accessible to the majority of developers.\r\n\r\n## Conclusion: Temporal's Strategy Turn\r\n\r\nI've probably exhausted your patience at this point but at least I hope you see that I genuinely think the potential is humongous. *And yet* I'm still understating it.\r\n\r\nTemporal today is pitched as \"reliability on rails\" or as a \"workflow-as-code microservices orchestration engine\" in the same way that the initial pitch of iPhone led with \"a widescreen iPod with touch controls\". We do that because it's familiar to things you already know — queues, databases, cronjobs, job runners, data and provisioning pipelines. \r\n\r\nBut now all my iPhone audio comes from Spotify and Overcast, I barely use the phone functionality, and I'm using the mobile Internet the rest of the time. The equivalent decade-long potential of Temporal is as ambitious as defining an \"8th layer\" to the [OSI 7 Layer](https://www.swyx.io/osi-layers-coding-careers/) model and reinventing asynchronous programming the way iPhone reinvented smartphones.\r\n\r\nLong time readers will recognize this as a \"[Strategy Turn](https://www.swyx.io/strategy-turns/)\" — the fact that it will happen is a matter of when, not if.\r\n\r\nIf what I've laid out excites you, take a look at [our open positions](https://temporal.io/careers) (or write in your own!), and [join the mailing list](https://docs.temporal.io/docs/concepts/introduction#mc_embed_signup_scroll)!\r\n\r\n## Further Reading\r\n\r\n{% youtube WRYozSljSpw %}\r\n\r\n- Orchestration\r\n - [Yan Cui's guide to Orchestration vs Choreography](https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/)\r\n - [InfoQ: Coupling Microservices](https://www.infoq.com/podcasts/design-time-coupling-microservices/) - a non-Temporal focused discussion of Orchestration\r\n - [A Netflix Guide to Microservices](https://www.youtube.com/watch?v=CZ3wIuvmHeM)\r\n- Event Sourcing\r\n - Martin Fowler on [Event Sourcing](https://martinfowler.com/eaaDev/EventSourcing.html)\r\n - Kickstarter's guide to [Event Sourcing](https://kickstarter.engineering/event-sourcing-made-simple-4a2625113224?gi=e356daabcb81)\r\n- Code over Config\r\n - [ACloudGuru's guide to Terraform, CloudFormation, and AWS CDK](https://acloudguru.com/blog/engineering/cloudformation-terraform-or-cdk-guide-to-iac-on-aws)\r\n - [Serverless Workflow's comparison of Workflow specification formats](https://github.com/serverlessworkflow/specification/tree/main/comparisons)\r\n- Temporal\r\n - [Dealing with failure](https://docs.temporal.io/blog/dealing-with-failure/) - when to use Workflows\r\n - [The macro problem with microservices](https://stackoverflow.blog/2020/11/23/the-macro-problem-with-microservices/) - Temporal in context of microservices\r\n - [Designing A Workflow Engine from First Principles](https://docs.temporal.io/blog/workflow-engine-principles/) - Temporal Architecture Principles\r\n - [Writing your first workflow](https://www.youtube.com/watch?v=taKrIWt6KMY&feature=youtu.be) - 20min code video\r\n - [Case studies](https://docs.temporal.io/blog/tags/case-study) and [External Resources](https://docs.temporal.io/docs/external-resources/) from our users","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/temporal-the-iphone-of-system-design-4a78","devToReactions":19,"devToReadingTime":15,"devToPublishedAt":"2021-07-19T07:46:12.503Z","devToViewsCount":295,"title":"Temporal - the iPhone of System Design","published":true,"description":"Temporal ties Orchestration, Event Sourcing, and Workflows-as-Code in one distributed system and it is eating the world.","tags":"Temporal, Work, Reflections","slug":"why-temporal","canonical_url":"https://www.swyx.io/why-temporal","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f4gjemgd6pr1494mmu9g.png"},"title":"Temporal - the iPhone of System Design","description":"Temporal ties Orchestration, Event Sourcing, and Workflows-as-Code in one distributed system and it is eating the world. ","category":"note","tags":["temporal","work","reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f4gjemgd6pr1494mmu9g.png","canonical":"https://www.swyx.io/why-temporal","slug":"why-temporal","date":"2021-07-19T07:46:12.503Z","readingTime":"16 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/179","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/179/comments","title":"Temporal - the iPhone of System Design","created_at":"2022-01-17T23:01:25Z","updated_at":"2022-06-25T20:48:33Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/179/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Svelte on PodRocket","slug":"podrocket-2","tags":["Svelte"],"venues":"Podrocket","date":"2021-07-16T00:00:00.000Z","url":"https://podrocket.logrocket.com/svelte","description":"Curious about all of the hype around Svelte? Swyx joins us on this episode of PodRocket to talk about Svelte and all of the work he has been doing at Svelte Society.","category":"podcast"},{"type":"blog","content":"\r\n> Note: my [2024 setup is here now](https://www.swyx.io/new-mac-setup)\r\n\r\nI set up a new Mac for work today. Here's everything I use on a Mac for fullstack web development.\r\n\r\nUnlike [Mina Markham](https://github.com/minamarkham/formation), I choose not to automate my setup because I only do it about once a year and I want the ability to make conscious changes each time.\r\n\r\n> I previously tracked my new mac setup in [an old version of this page from 2018-2020](https://dev.to/swyx/my-new-mac-setup-4ibi).\r\n\r\n\r\n## 1hr Video Walkthrough\r\n\r\n{% youtube qwflfsgU0eg %}\r\n\r\n---\r\n## OS/Browser Settings\r\n\r\n- **Browser**: Download Chrome, set to default.\r\n- **Log in to**: (this helps with logins for the other services below)\r\n - Twitter\r\n - Github (more setup instructions below)\r\n - Gmail\r\n- **System Settings**:\r\n - Disable Spotlight search for all miscellaneous crap except apps and system preferences\r\n - including [stupid Developer option](https://www.howtogeek.com/231829/how-to-disable-developer-search-results-in-spotlight-on-a-mac/) (make sure to add [Xcode.app](http://xcode.app) to /Applications not /user/swyx/Applications)\r\n - Disable Ask Siri\r\n - Set to [Big cursor](https://www.lifewire.com/make-mac-mouse-pointer-bigger-2260808) for accessibility during presentation\r\n - [some reports of memory leaks](https://www.techrepublic.com/article/macos-monterey-has-a-serious-memory-leak-problem-and-the-cause-has-been-found/) when doing this\r\n - Fix trackpad direction: Trackpad -> Scroll & Zoom - Natural off\r\n - Disable dictionary lookup: Trackpad -> Point & Click -> Look up & data detectors off\r\n - (if using windows keyboard) [remap alt and cmd keys](https://superuser.com/questions/158561/how-can-i-remap-windows-and-alt-keys-in-os-x) for ergonomics\r\n- **Finder settings**:\r\n - Preferences → show filename extensions\r\n - Enable showing dotfiles (just hold Cmd + Shift + . (dot) in a Finder window)\r\n - [Show path bar](https://www.tekrevue.com/tip/show-path-finder-title-bar/) in footer for easier navigation\r\n - Prune the excessive sidebar bookmarks\r\n - create \"Work\" folder and pin it\r\n- **Keyboard**:\r\n - [remap command+Q to literally anything else](https://apple.stackexchange.com/questions/78948/how-to-disable-command-q-for-quit) - to prevent accidental close-all\r\n - Shortcuts: copy picture of selected area to clipboard -> Cmd+E\r\n- **MacOS Dock:**\r\n - Remove everything from the Dock except: Finder, System Preferences and Trash\r\n - Turn Dock Auto Hiding on\r\n - turn this on for MacOS Menu bar as well\r\n- **Chrome extensions**: (tied to Chrome account)\r\n - Paywall blocker [https://github.com/iamadamdev/bypass-paywalls-chrome/](https://github.com/iamadamdev/bypass-paywalls-chrome/)\r\n - See Tweets about any page [https://github.com/sw-yx/Twitter-Links-beta](https://github.com/sw-yx/Twitter-Links-beta?organization=sw-yx&organization=sw-yx) ([my blogpost here](https://www.swyx.io/twitter-metacommentary/))\r\n - [Morpheon Dark theme](https://chrome.google.com/webstore/detail/morpheon-dark/mafbdhjdkjnoafhfelkjpchpaepjknad?hl=en)\r\n - [Lastpass](https://chrome.google.com/webstore/detail/lastpass-free-password-ma/hdokiejnpimakedhajhdlcegeplioahd?hl=en-US)\r\n - [Display Anchors](https://chrome.google.com/webstore/detail/display-anchors/poahndpaaanbpbeafbkploiobpiiieko/related?hl=en)\r\n - [React Devtools](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en)\r\n - [Refined Github](https://github.com/sindresorhus/refined-github)\r\n - [Code Copy](https://chrome.google.com/webstore/detail/codecopy/fkbfebkcoelajmhanocgppanfoojcdmg?hl=en)\r\n - [Video Speed Controller](https://chrome.google.com/webstore/detail/video-speed-controller/nffaoalbilbmmfgbnbgppjihopabppdk?hl=en) ← VERY HIGHLY RECOMMENDED\r\n - [Palettab](https://palettab.com/)\r\n - [Privacy Badger](https://chrome.google.com/webstore/detail/privacy-badger/pkehgijcmpdhfbdbbnkijodmdjhbjlgp?hl=en-US)\r\n - [RescueTime](https://chrome.google.com/webstore/detail/rescuetime-for-chrome-and/bdakmnplckeopfghnlpocafcepegjeap?hl=en-US)\r\n - [uBlock Origin](https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en)\r\n - [Octolinker](https://chrome.google.com/webstore/detail/octolinker/jlmafbaeoofdegohdhinkhilhclaklkp?hl=en)\r\n - [async render toolbox](https://github.com/sw-yx/async-render-toolbox) (i made this)\r\n\r\n## Setup Terminal\r\n\r\n- Copy my dotfiles (vimrc, zshrc, .gitignore_global): [https://gist.github.com/sw-yx/7fa1009e460ecb818d5e6d9ca4616a05](https://gist.github.com/sw-yx/7fa1009e460ecb818d5e6d9ca4616a05)\r\n- Install [ZSH](https://ohmyz.sh/) (first usage of `git` will prompt you to install git - takes 15 minutes)\r\n - `git config --global init.defaultBranch main`\r\n - `git config --global user.name \"swyx\"`\r\n - `git config --global user.email shawnthe1@gmail.com`\r\n - Font - [Inconsolata for Powerline](https://github.com/powerline/fonts/blob/master/Inconsolata/Inconsolata%20for%20Powerline.otf)\r\n - [autosuggestions](https://github.com/zsh-users/zsh-autosuggestions)\r\n - [syntax highlighting](https://github.com/zsh-users/zsh-syntax-highlighting)\r\n - may need to [chmod stuff](https://stackoverflow.com/questions/13762280/zsh-compinit-insecure-directories) or warnings show at start of every session\r\n\r\n ```\r\n $ sudo chmod -R 755 /usr/local/share/zsh\r\n $ sudo chown -R root:staff /usr/local/share/zsh\r\n\r\n ```\r\n\r\n- [Hyper Terminal](https://hyper.is/)\r\n - settings: [shell: '/bin/zsh'](https://gist.github.com/robertcoopercode/276d7cf66e9b0eea48c117fff1762a17#file-hyper-js-L60)\r\n - settings: `fontFamily: '\"Inconsolata for Powerline\", Menlo, \"DejaVu Sans Mono\", Consolas, \"Lucida Console\", monospace',`\r\n - [Fig](https://fig.io/) - context-aware autocomplete for terminal. Waitlisted now, but you can skip the waitlist [here](https://fig.io/invite?code=swyx) (i get nothing from this)\r\n - More CLI tools recommended by Brendan Faik (founder of Fig) - `bat`, `exa`, `ripgrep`, and other [Rust CLI alternatives](https://zaiste.net/posts/shell-commands-rust/). Also [zsh abbreviations](https://github.com/momo-lab/zsh-abbrev-alias)\r\n - [More CLI tools from Earthly](https://earthly.dev/blog/command-line-tools/) - [HN here](https://news.ycombinator.com/item?id=27992073)\r\n - `broot` - a better `tree` \r\n - `funky` - simple shell functions\r\n - `fzf` - fuzzy finder\r\n - `mcfly` - guesses commands based on your history\r\n - `zoxide` - a better `cd`\r\n - `gitupdate` - use file names to create a more meaningful commit message\r\n\r\n## Set up apps/environments\r\n\r\n- Install [Homebrew](https://brew.sh/) - `/bin/bash -c \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\"`\r\n\r\n i have a bunch more stuff in `brew list` but i'm not sure what i use actively. You can mass install these: `brew install $(cat packages.txt)`\r\n\r\n ```\r\n bat gdbm libuv python@3.9\r\n brotli gh libyaml readline\r\n c-ares go mpdecimal ruby\r\n deno gradle notunes sqlite\r\n diff-so-fancy icu4c node xz\r\n fnm jemalloc openjdk yarn\r\n fzf libev openssl@1.1 z\r\n ```\r\n- new: added brew install `--cask notunes`, replaced `nghttp2` above\r\n- `brew update` on m1's have turned out to be super annoying. [this](https://stackoverflow.com/questions/64963370/error-cannot-install-in-homebrew-on-arm-processor-in-intel-default-prefix-usr) helped me: `arch -x86_64 brew install YOUR_PACKAGE`\r\n- `brew install bat`\r\n- [Github CLI](https://github.com/cli/cli): `brew install github/gh/gh`\r\n - you need to login to git - if you have 2fa enabled, you cant use your normal github password. try pushing to a repo and enter in a [Personal Access Token](https://stackoverflow.com/a/34919582) for password.\r\n - then run `gh auth login`\r\n - [add GitHub SSH key](https://docs.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) (not optional)\r\n- `brew install fzf` - fuzzy finder - usage example is [here](https://twitter.com/swyx/status/1048009961723318272)\r\n- `brew install node`\r\n - [Node.js/NPM](https://nodejs.org/en/download/)\r\n - `npm login`\r\n - `npm config set loglevel`\r\n - `sudo npm install netlify-cli -g`\r\n - `npm i -g sign-bunny fortune-node parrotsay`\r\n - `npm install -g undollar` for removing $\r\n - `sudo npm install -g trash-cli`\r\n- `brew install yarn --ignore-dependencies` - [yarn](https://yarnpkg.com/en/docs/install#mac-stable) note\r\n- you may need to [work around Mac OS Sierra](https://stackoverflow.com/questions/43780207/installing-node-with-brew-fails-on-mac-os-sierra)\r\n- `brew install z` - [REALLY GOOD TRY IT](https://brewinstall.org/install-z-on-mac-with-brew/)\r\n- Misc\r\n - `pip3 install --user powerline-status`\r\n - go to a neutral folder and `git clone && cd fonts && ./install.sh`\r\n - [fnm](https://github.com/Schniz/fnm) faster alternative to [nvm](https://github.com/creationix/nvm): `curl -fsSL | bash` or `brew install fnm`\r\n - **[Anaconda](https://www.anaconda.com/download/#macos) Python distro** - be careful they tend to [modify your bash prompt without asking](https://askubuntu.com/questions/1026383/why-does-base-appear-in-front-of-my-terminal-prompt\\)\r\n - [Docker Desktop](https://hub.docker.com/editions/community/docker-ce-desktop-mac/)\r\n - `brew install` [ffmpeg](https://ffmpeg.org/download.html) and then\r\n - https://github.com/tombonez/noTunes\r\n - download [Audacity](https://www.audacityteam.org/download/mac/) - and [install ffmpeg](https://manual.audacityteam.org/man/installing_ffmpeg_for_mac.html)\r\n - `brew install java` - you could download [Java Development Kit](https://www.oracle.com/java/technologies/javase/javase-jdk8-downloads.html) from Oracle but fuck them for putting it behind signup wall\r\n - `brew install go` you may need to `export PATH=$PATH:/usr/local/go/bin`\r\n - `brew install diff-so-fancy` - then set `git config --global core.pager \"diff-so-fancy | less --tabs=4 -RFX\"` - makes for much nicer git diff\r\n - You can also diff with this bash function `dif() { git diff --color --no-index \"$1\" \"$2\" | diff-so-fancy; }` or with VSCode `code --diff file1.js file2.js`.\r\n - You can also try [https://github.com/dandavison/delta](https://github.com/dandavison/delta)\r\n\r\n## Setup Apps\r\n\r\n- Emojis: [https://matthewpalmer.net/rocket/](https://matthewpalmer.net/rocket/)\r\n- Password Manager: I use 1password for company and lastpass for personal\r\n- Window Manager: [https://www.spectacleapp.com/](https://www.spectacleapp.com/) launch at login\r\n- Clipboard Manager: [https://clipy-app.com/](https://clipy-app.com/) or https://yippy.mattdavo.com/ (untested)\r\n- Loom: [https://www.loom.com/desktop](https://www.loom.com/desktop)\r\n- Zoom: [https://zoom.us/download](https://zoom.us/download)\r\n- Screenshots: [https://cleanshot.com/](https://cleanshot.com/) (previously used [https://zapier.com/zappy](https://zapier.com/zappy)). [Browser extension - Lightshot](https://chrome.google.com/webstore/detail/lightshot-screenshot-tool/mbniclmhobmnbdlbpiphghaielnnpgdp)\r\n- Caffeine (Keep Mac awake for talks): [https://intelliscapesolutions.com/apps/caffeine](https://intelliscapesolutions.com/apps/caffeine)\r\n - used to be [http://lightheadsw.com/caffeine/](http://lightheadsw.com/caffeine/)\r\n - maintained version: [Amphetamine](https://roaringapps.com/app/amphetamine) (thanks Matt Mischuk!)\r\n- [NoTunes](https://github.com/tombonez/noTunes) - disable itunes/apple music\r\n- Video capture: [https://getkap.co/](https://getkap.co/)\r\n- Dual Screen: [https://www.duetdisplay.com/](https://www.duetdisplay.com/)\r\n- Gifs: [Licecap](https://www.cockos.com/licecap/)\r\n- [Slack](https://slack.com/downloads/osx) or [Discord](https://discord.com/)\r\n- OBS: [https://obsproject.com/](https://obsproject.com/)\r\n- Transcribing: [https://www.descript.com/download/mac](https://www.descript.com/download/mac)\r\n- SkyFonts: [https://www.fonts.com/web-fonts/google](https://www.fonts.com/web-fonts/google)\r\n- Microsoft Todo: [https://apps.apple.com/app/apple-store/id1274495053?mt=8](https://apps.apple.com/app/apple-store/id1274495053?mt=8)\r\n- Stretchly: [https://hovancik.net/stretchly/](https://hovancik.net/stretchly/)\r\n- Disk Space: [Disk Inventory X](http://www.derlien.com/) - you can clean node modules with [this bash command](https://twitter.com/swyx/status/1064672618450579457?s=20) or as a [cronjob](https://gist.github.com/zephraph/9169b9de4568b858f4b0e45fc41218b7)\r\n- Replay: [download](https://replay.io/welcome) - https://www.notion.so/Replay-Docs-56758667f53a4d51b7c6fc7a641adb02\r\n- SimpleNote: [https://apps.apple.com/us/app/simplenote/id692867256?ls=1&mt=12](https://apps.apple.com/us/app/simplenote/id692867256?ls=1&mt=12)\r\n- [Superhuman for Mac](http://superhuman.com/mac) and [https://mail.superhuman.com](https://mail.superhuman.com/) \r\n- Notion: [https://www.notion.so/desktop](https://www.notion.so/desktop)\r\n - [https://chrome.google.com/webstore/detail/notion-web-clipper/knheggckgoiihginacbkhaalnibhilkk?hl=en](https://chrome.google.com/webstore/detail/notion-web-clipper/knheggckgoiihginacbkhaalnibhilkk?hl=en)\r\n- App Search/Utils: [https://www.alfredapp.com/](https://www.alfredapp.com/)\r\n - set to Alfred Dark\r\n - [airdrop to iphone/ipad](https://github.com/swmoon203/CrossShare/blob/master/Alfred%20Workflow/Cross%20Share%20Airdrop.alfredworkflow)\r\n - [Cupcake Ipsum](http://www.packal.org/workflow/cupcake-ipsum)\r\n- Editor: Download [VS Code](https://code.visualstudio.com/download) (I used to use Insiders but the popups are super annoying). use Settings Sync to sync across machines\r\n - have to set up powerline fonts \"Meslo LG M for Powerline\" ([download](https://github.com/powerline/fonts/blob/master/Meslo%20Slashed/Meslo%20LG%20M%20Regular%20for%20Powerline.ttf))\r\n - auto-close-tag v0.5.6\r\n - auto-rename-tag v0.0.15\r\n - Bookmarks v9.1.0\r\n - code-settings-sync v3.1.2\r\n - debugger-for-chrome v4.10.2\r\n - es7-react-js-snippets v1.8.7\r\n - graphql-for-vscode v1.12.1\r\n - mdx v0.1.0\r\n - prettier-vscode v1.6.1\r\n - python v2018.9.2\r\n - python v0.2.3\r\n - rainbow-brackets v0.0.6 - this is now deprecated, use the native [`\"editor.bracketPairColorization.enabled\": true`](https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization)\r\n - shades-of-purple v3.17.0\r\n - vscode-graphql v0.1.5\r\n - vscode-import-cost v2.9.0\r\n - vscode-styled-components v0.0.23\r\n - vscode-wakatime v1.2.3\r\n - [TabNine](https://www.tabnine.com/) AI completions\r\n - [GitHub Copilot](https://marketplace.visualstudio.com/items?itemName=GitHub.copilot)\r\n - to try: [File Utils](https://marketplace.visualstudio.com/items?itemName=sleistner.vscode-fileutils) - recommended by [Stolinski](https://twitter.com/stolinski/status/1417247358430109697)\r\n - Here's the full list you can run from command line\r\n\r\n```jsx\r\ncode --install-extension 2gua.rainbow-brackets\r\ncode --install-extension ahmadawais.shades-of-purple\r\ncode --install-extension austenc.tailwind-docs\r\ncode --install-extension bradlc.vscode-tailwindcss\r\ncode --install-extension cpylua.language-postcss\r\ncode --install-extension dbaeumer.vscode-eslint\r\ncode --install-extension dsznajder.es7-react-js-snippets\r\ncode --install-extension esbenp.prettier-vscode\r\ncode --install-extension formulahendry.auto-close-tag\r\ncode --install-extension formulahendry.auto-rename-tag\r\ncode --install-extension GabrielNordeborn.vscode-graphiql-explorer\r\ncode --install-extension GitHub.copilot\r\ncode --install-extension golang.go\r\ncode --install-extension heybourn.headwind\r\ncode --install-extension jpoissonnier.vscode-styled-components\r\ncode --install-extension kgscott.retreon\r\ncode --install-extension kumar-harsh.graphql-for-vscode\r\ncode --install-extension luyizhi.vscode-graphql\r\ncode --install-extension ms-python.python\r\ncode --install-extension ms-python.vscode-pylance\r\ncode --install-extension ms-toolsai.jupyter\r\ncode --install-extension msjsdiag.debugger-for-chrome\r\ncode --install-extension NickScialli.svelte-dark\r\ncode --install-extension octref.vetur\r\ncode --install-extension oderwat.indent-rainbow\r\ncode --install-extension sdras.night-owl\r\ncode --install-extension silvenon.mdx\r\ncode --install-extension svelte.svelte-vscode\r\ncode --install-extension TabNine.tabnine-vscode\r\ncode --install-extension ThreadHeap.serverless-ide-vscode\r\ncode --install-extension tht13.python\r\ncode --install-extension WakaTime.vscode-wakatime\r\ncode --install-extension Wattenberger.footsteps\r\ncode --install-extension wix.vscode-import-cost\r\n```\r\n\r\n---\r\n\r\n## Other good \"new laptop setup\" lists:\r\n\r\n- [Tania Rascia's setup](https://www.taniarascia.com/setting-up-a-brand-new-mac-for-development/?ck_subscriber_id=591519942)\r\n- [Nick Nisi's dotfiles](https://github.com/nicknisi/dotfiles)\r\n- [Mathias Bynens macos defaults](https://github.com/mathiasbynens/dotfiles/blob/master/.macos)\r\n- [Jamon's MacOS maintenance tips](https://twitter.com/jamonholmgren/status/1175077165848653824)\r\n- [James Martinez](https://twitter.com/jamescmartinez/status/1528506724835008514?s=21&t=fLywP84bqTwwVbJG8Lr-BA)\r\n- Vendasta: https://github.com/vendasta/setup-new-computer-script\r\n- You can [automate dotfiles/homebrew setup with Sheldon Hull's tool](https://www.sheldonhull.com/docs/shell/#installing-brew-packages)\r\n- Physical equipment setups from prominent people: https://setups.co/\r\n- please send me yours!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/my-2021-new-mac-setup-1b1","devToReactions":129,"devToReadingTime":9,"devToPublishedAt":"2021-07-05T21:57:11.469Z","devToViewsCount":4117,"title":"My 2021 New Mac Setup","published":true,"description":"I set up a new Mac for work today. Here's everything I use on a Mac for fullstack web development.","tags":"mac, tech","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/86ug0c6q3akqvp5c9e1b.png","slug":"new-mac-setup-2021","canonical_url":"https://www.swyx.io/new-mac-setup-2021/"},"title":"My 2021 New Mac Setup","description":"I set up a new Mac for work today. Here's everything I use on a Mac for fullstack web development. ","category":"note","tags":["mac","tech"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/86ug0c6q3akqvp5c9e1b.png","canonical":"https://www.swyx.io/new-mac-setup-2021/","slug":"new-mac-setup-2021","date":"2021-07-05T21:57:11.469Z","readingTime":"9 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/180","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/180/comments","title":"My 2021 New Mac Setup","created_at":"2022-01-17T23:01:28Z","updated_at":"2024-12-30T09:47:58Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/180/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nAnyone who's created or consumed content long enough will eventually find a fork in the road, both equally well traveled by: Should we post continuous updates or do a big launch? Blog Updates or [Digital Garden](https://maggieappleton.com/garden-history)? \"[Today I Learned](https://github.com/jbranchaud/til)\" or [10x Evergreen Skyscrapers](https://sparktoro.com/blog/resources/10x-content-by-rand-fishkin/)? Do people want the journey or the destination?\r\n\r\nI think we should do both. I've come to regard learning — the accumulation of knowledge — as *simultaneously* a discrete *and* a continuous process. \r\n\r\nIf the tools we use don't respect this duality, information is lost — either writing involves too much effort, or reading requires too much context. This has implications both for people who want to learn better, as well as content creators who want to transfer knowledge better.\r\n\r\n## Discrete vs Continuous Learning\r\n\r\n**Books, courses, and wikis** are prime examples of **discrete** learning. \r\n\r\n- The ideal wiki article is a complete introduction, history, and overview of a particular topic. Its value comes from being a reliable aggregate source of truth. The structure and sequencing of knowledge presented is often as valuable as the content itself. As **evergreen** content, effort spent on both creating and consuming it has a high return, because it is designed from the outset to have lasting relevance.\r\n- However, long books, courses, and wikis are a lot of content to consume all at once and may never be finished. The scope may be so large that it is hard to keep up to date, particularly when the *structure* itself needs to change with the times.\r\n\r\n**Twitter, Discord, and Email Newsletters** offer modes of **continuous** learning.\r\n\r\n- The focus is on new content, and lack of structure allows maximum flexibility. Information is also bitesize and thus very consumable. Because of the realtime/live nature and randomness of quality, there is inbuilt variable reward which keeps us as addicted as BF Skinner's pigeons.\r\n- However, the lack of historical context can leave beginners out of the loop, and even experts can fall prey to [base rate neglect](https://thedecisionlab.com/biases/base-rate-fallacy/). News also has limited long term expected value due to the Lindy Effect, and therefore have a much lower signal to noise ratio. Finally, since major developments tend to spread out over time, there is often no one canonical link that you can send people to get up to speed — you \"just had to be there\".\r\n\r\nI've only mentioned examples familiar to individual learners, but this duality also exists at a company level. Do you put all your company knowledge in Notion/Sharepoint (discrete) or Slack (continuous)? Do your docs offer a complete learning path (discrete) or do people also have to read your blog and support forums (continuous)?\r\n\r\n## Particle/Wave Duality\r\n\r\nI've already given away the analogy in the title, but this situation reminds me of the dual-slit experiment of quantum mechanics. Here's a quick one minute explainer:\r\n\r\n{% youtube Q_h4IoPJXZw %}\r\n\r\nPerhaps you're most familiar with this in the double split experiment:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2jncajmthzjihsfmmst3.png)\r\n\r\nI'm no expert myself but the version that works best for the analogy I'm going for sums it up like this:\r\n\r\n- As the light/electron beam is in transit, it acts like a wave.\r\n- As the light/electron beam is \"observed\"/hits the screen, it acts like a particle.\r\n\r\nThis all has very nice parallels to the process of learning. Sometimes we are picking up knowledge in a continuous stream, sometimes we just want a big quantum of knowledge all at once. The best forms of learning combine the two modes:\r\n\r\n- If you learn in a continuous stream, it is useful to recap everything you learned in a post-mortem or retrospective. If you've gained a few years of experience, it's helpful to write down [Things You Believe](https://www.notion.so/5bb2d99e50fdbbd15dd9622837d14e2b) or write up the guide you wish you'd had.\r\n- If you learned in a discrete block, it is useful to continue that education with continuous [spaced repetition](https://ncase.me/remember/) or involvement in an alumni community (many professions from finance to airline pilots even require this as \"Continuing Education\"!)\r\n\r\n## The Particle/Wave Duality Theory of Knowledge\r\n\r\nThe Particle/Wave Duality Theory of Knowledge defines learning — the accumulation of knowledge — as *simultaneously* a discrete *and* a continuous process. There's no point picking a side. We learn best with both, so if you are a content creator or knowledge worker, you need a way to record both. \r\n\r\nIf knowledge tools don't respect this duality, users will be forced to do the work of duplicating knowledge, or lose it forever.\r\n\r\n## Paying the Duality Cost\r\n\r\nI'll motivate this with a personal example. I run [the Coding Career Community](https://www.learninpublic.org/) in *two* places - [Circle.so](http://circle.so) for my async knowledge base (discrete), and Discord for my live chat (continuous). Of course, both are more continuous places of engagement compared to the book they are focused on, which is the most discrete item of all in my hierarchy (discrete-ness is a spectrum!)\r\n\r\nPeople might think me crazy for splitting my efforts in running *two* communities, instead of one. But I get active users in both and they rarely overlap: \r\n\r\n- My Circle members are nominally bigger, but far less active and conversations can drag out over days. The primary means of engagement is by the weekly Thursday recap newsletter that gets automatically sent out.\r\n- My Discord members are fewer, but more active and respond quickly to new posts. The primary means of engagement is in-app notifications, banking on the network effect of my members already being active in other Discords.\r\n\r\nYou can analyze this split in every dimension and still come up 50-50. Think about the new user experience, a critical moment for every community. \r\n\r\n- A Discord user can say hi and immediately get the dopamine hit of a hi back. But they're not going to scroll up and read through the best hits of the community (pinning isn't very effective), so what they see is just completely randomly whatever is the topic of conversation that day.\r\n- A Circle user doesn't even have to say hi, but can get immense value from the top/pinned post and become a fan right then. So I can pour in all my effort to make that top notch.\r\n\r\nThere's no clear cut right answer. Some users will prefer one extreme, some the other, and yet more will just want both. Yet I need to keep both up to date. What I do right now is peak do-things-that-don't-scale: I post continuous updates to Discord, and then once a week I sum up the best of what I find and [manually cross-post it to Circle](https://codingcareer.circle.so/c/learn-in-public). Sometimes I find the occasional quality post on Circle, so I send it back to Discord (for sharing with the Discord natives), and to Twitter (for marketing).\r\n\r\nSo I'm paying the expensive cost of Particle/Wave Duality, because my tools currently don't recognize it. I could make a bot to do the two way sync between Discord and Circle, but what I'd really like is for this to just be built in in some way. \r\n\r\n## Database Solutions\r\n\r\nIf you are developer-literate, I also think there are a couple alternative analogies you can use to solve this dual need:\r\n\r\n- [**Change Data Capture**](https://en.wikipedia.org/wiki/Change_data_capture) (discrete → continuous): When you update a row in a database, there can be inbuilt functionality to send a notification of what changed (eg [DynamoDB with Kinesis Data Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html)). So people can read up a discrete state of information, then subscribe to the diffs. This is exactly how I use Notion at work, where I rely on email updates of diffs since it is impossible for me to stay on top of all the changes my coworkers are making by checking through each document individually.\r\n- **[Materialized Views](https://en.wikipedia.org/wiki/Materialized_view) (**continuous → discrete**)**: As you add, modify, or delete data, a separate \"materialized view\" auto updates and can always be referenced as the source of truth on all the changes that have happened to date. This is how Kanban boards and issue trackers work, by presenting a top down view of the status of work items moving through the engineering process.\r\n\r\nWhat would Change Data Capture and Materialized Views look like for knowledge management tools, say a Second Brain, or a Blog?\r\n\r\n## Applying Theory to Creation\r\n\r\nUltimately I think a lot about this in terms of the context of writing and other forms of content creation. As much as I've been talking about the preferred content consumption angle, the stakes are even higher for content creation:\r\n\r\n- Discrete knowledge items like books and courses are most useful to learners because they present a comprehensive overview. However if it is such a big lift, it may never get done and you may be doing your learners a disservice by not contributing your voice.\r\n - By the way, many people also treat blogposts like discrete items, taking months to draft it and to have it peer-reviewed like an academic journal. This is usually unsustainable and the blogging grinds to a halt, killed by its own process.\r\n- Continuous knowledge items like tweets and chat conversations are far more digestible and easier to create. However, small low effort items out of context aren't all that valuable in themselves, and struggle to stand out and get traction compared to [10x Content](https://sparktoro.com/blog/resources/10x-content-by-rand-fishkin/) that sells itself.\r\n\r\nUltimately I think you should try to do both. Prototype by making continuous knowledge items, but be aware that most people will never see your work there. So periodically you need to do \"treasure collection\" - go back through your continuous streams, and pick out the most promising threads to turn into bigger, discrete pieces. I wrote about one such journey of mine in [Bottom Up Idea Exploration](https://www.swyx.io/bottom-up-ideas/).\r\n\r\n## Just in Time vs Just in Case\r\n\r\nThose of you familiar with the literature of learning may find a parallel to JIT vs JIC modes of learning. You can loosely map JIT learning to discrete knowledge (have a book or wiki to look it up when you need it, but not before) and JIC learning to continuous knowledge (plug yourself in to a stream of knowledge and let serendipity guide you). \r\n\r\nBut the mapping isn't 1:1. You can use a book as JIC learning if you resolve to read it cover to cover, or JIT as a reference. You can use a Discord chat as JIT access to a knowledgeable community, or JIC as a passive observer.\r\n\r\nIt is very popular to deride JIC because that is something we are trained to do in school and it can prevent us from actually doing anything productive with that knowledge. That is definitely true and most people should try to be more JIT purely because they naturally skew JIC. However that isn't to say that JIC has no place in learning - having a good mental map of everything is actually important to knowing what you don't know.\r\n\r\n## Question from a Reader\r\n\r\n\"*Our team currently has years of docs in a Google docs like system. Main problem with new hires is that they haven't yet accepted that the docs are poorly maintained, or there are 6 docs for the same process written by different people and not deleted or updated. It's madness. How would you go about this process?*\"\r\n\r\nAh, the outdated knowledge base problem. We continually swing back and forth between wanting a discrete source of truth, but then time passes and continuous updates do not get registered. Technology hasn't (yet) solved this — although graph database tooling like [Roam Research](https://roamresearch.com/) or [Obsidian](https://obsidian.md/) can automatically propagate continuous updates to discrete materialized views, it is still a poor susbstitute for properly curated and updated structure. \r\n\r\nUltimately I view the knowledge base problem as a human problem - you have to commit to maintaining your sources of truth, but don't make it so huge as to be unmaintainable and unreadable. Don't be so rigid about your process that you treat people talking to each other to figure out problems as a bug. Identify what you care about and make it a priority to enforce that, but recognize that enforcement isn't free and pick your battles.\r\n\r\n*Major thanks to [David Golden](https://xdg.me/), [MJ Meyer](https://twitter.com/_mjmeyer?lang=en), and [Calvin Torra](https://calvintorra.com/) for providing feedback on drafts!*\r\n\r\n## Further reading\r\n\r\n- **Sonal Chokshi**, editor in chief at a16z, talked about the idea of stock and flow concept in media at the end of [her Indie Hackers podcast episode](her Indie Hackers podcast episode).\r\n- Oct 2022 Edit: a B2B version of this exists, with an extension for \"systems of intelligence\"\r\n\r\n{% twitter https://twitter.com/swyx/status/1586576013231722496 %}","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-particle-wave-duality-theory-of-knowledge-41g6","devToReactions":15,"devToReadingTime":8,"devToPublishedAt":"2021-06-25T20:29:35.045Z","devToViewsCount":151,"title":"The Particle/Wave Duality Theory of Knowledge","published":true,"description":"Learning is *BOTH* a discrete and a continuous process. If the tools we use don't respect this duality, information is lost — either writing involves too much effort, or reading requires too much context.","tags":"Learning, Epistemology, Reflections","slug":"particle-wave-duality","canonical_url":"https://www.swyx.io/particle-wave-duality","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eyde1r0bt3isr7kj6te2.png"},"title":"The Particle/Wave Duality Theory of Knowledge","description":"Learning is *BOTH* a discrete and a continuous process. If the tools we use don't respect this duality, information is lost — either writing involves too much effort, or reading requires too much context. ","category":"note","tags":["learning","epistemology","reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eyde1r0bt3isr7kj6te2.png","canonical":"https://www.swyx.io/particle-wave-duality","slug":"particle-wave-duality","date":"2021-06-25T20:29:35.045Z","readingTime":"10 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/181","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/181/comments","title":"The Particle/Wave Duality Theory of Knowledge","created_at":"2022-01-17T23:01:30Z","updated_at":"2022-10-30T04:33:42Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/181/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nOne benefit of moving business logic to Temporal is how Temporal implements retries and timeouts for Activities in a standardized way. This has the effect of adding a reliability layer atop unreliable Activities and Workers, in a durable and scalable fashion. However, understanding the terminology can be a bit intimidating at first glance. \n\nThis post (together with the embedded talk) aims to give you a solid mental model on what each Activity timeout does and when to use it.\n\n> Note: You can also set [Workflow timeouts](https://docs.temporal.io/docs/concepts/workflows#timeout-settings) and [retry policies](https://docs.temporal.io/docs/concepts/activities#retries) you can set. This post deals only with *Activity* timeouts.\n\n## Talk version: whiteboard session\n\nYou can watch this 18 minute talk where our CEO Maxim Fateev explains the 4 Types of Activity timeouts you see in Temporal.\n\n{% youtube JK7WLK3ZSu8 %}\n\nThe rest of this post summarizes the main points covered in this whiteboard session, for those who prefer a written version.\n\n## Written version: TL;DR\n\n![image](https://user-images.githubusercontent.com/6764957/122424123-0ab1e300-cfc1-11eb-82c5-cf8856a87242.png)\n\nTemporal has four timeouts — two that are commonly used, and two that are useful only in specific cases:\n\n- Schedule-To-Close: Limits the maximum execution time including retries.\n- Start-To-Close: Limits the maximum execution time of a single execution. **We recommend ALWAYS setting this!**\n- Heartbeat: Limits the maximum time between Heartbeats. *For long running Activities*, enables a quicker response when s Heartbeat fails to be recorded.\n- Schedule-To-Start: Limits the maximum time that an Activity Task can sit in a Task Queue. Mainly to identify whether a Worker is down or for Task routing. **This is rarely needed!**\n\nYou can find the precise APIs in the reference documentation for each SDK: [Java](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/activity/ActivityOptions.Builder.html) and [Go](https://pkg.go.dev/go.temporal.io/sdk@v1.7.0/internal#ActivityOptions).\n\n## Lifecycle of an Activity\n\nTo really understand how timeouts work, we should understand the typical lifecycle of an Activity as it journeys through the various parts of the system.\n\n### Step 1 - Workflow Worker\n\nAn activity `SimpleActivity` is first invoked inside a Workflow Worker on Task Queue `sampleTaskQueue`. The precise method of invocation differs by SDK, and timeouts are also specified up front as part of Activity options:\n\n\n```go\nao := workflow.ActivityOptions{\n TaskQueue: \"sampleTaskQueue\",\n ScheduleToCloseTimeout: time.Second * 500,\n // ScheduleToStartTimeout: time.Second * 60, // usually not needed! see below\n StartToCloseTimeout: time.Second * 60,\n HeartbeatTimeout: time.Second * 10,\n WaitForCancellation: false,\n}\nctx = workflow.WithActivityOptions(ctx, ao)\n\nvar result string\nerr := workflow.ExecuteActivity(ctx, SimpleActivity, value).Get(ctx, &result)\nif err != nil {\n return err\n}\n```\n\nBehind the scenes, the SDK transforms this into a `ScheduleActivity` Command, which is sent to the Temporal Server. \nThis Command includes various metadata, including the activity type (`SimpleActivity`), activity task queue (`sampleTaskQueue`), and activity ID. A `RetryPolicy` was not specified, so Temporal uses [the default Retry Policy](https://docs.temporal.io/docs/concepts/workflows#retry-policy).\n\n### Step 2 - Temporal Server\n\nReceiving the Command, Temporal Server adds an Activity Task to the `Bar` Activity Task Queue.\nThere is an atomic guarantee that these both happen together, to prevent race conditions. \nWe explained why this is important and how Temporal accomplishes this in [Designing A Workflow Engine](https://docs.temporal.io/blog/workflow-engine-principles/).\n\n> The Activity Execution is now in a `SCHEDULED` state.\n\n### Step 3 - Activity Worker \n\nAn Activity Worker that has been polling the `Bar` Activity Task Queue picks up the Activity Task and begins execution.\n\n> The Activity Execution is now in a `STARTED` state.\n\n### Step 4 - Temporal Server\n\nOnce the Activity Execution finishes successfully, the Activity Worker sends a `CompleteActivityTask` message (together with the result of the Activity Execution) to Temporal Server, which now gives control back to the Workflow Worker to continue to the next line of code and repeat the process.\n\n> The Activity Execution is now in a `CLOSED` state.\n\nWe have just described the \"Happy Path\" of an Activity Execution.\nHowever, what happens when an Activity Worker crashes midway through an execution?\n\n## Start-To-Close Timeout\n\nWe use the Start-To-Close timeout to control the maximum amount of time **a single Activity Execution** can take. We recommend **always** setting this timeout.\n\n![image](https://user-images.githubusercontent.com/6764957/122290108-fff64000-cf25-11eb-92b3-0533e41c3fee.png)\n\nThe classic example for why the Start-To-Close timeout is relevant, is when an Activity Task has been picked up from the Activity Task Queue (`STARTED` state) but the Worker crashes after that (so the Activity Execution never reaches `CLOSED` state). \n\n- Without a timeout configured, Temporal would never proactively timeout this Activity Execution to initiate a retry. The Activity Execution becomes \"stuck\" and the end user would experience an indefinite delay of their Workflow Execution with no feedback.\n- With the timeout configured, Temporal registers an `ActivityTaskTimedOut` event internally which triggers the Server to attempt a retry based on the Activity Execution's `RetryPolicy:`\n - The Server adds the Activity Task to the Activity Task Queue again.\n - The Server increments the attempt count in the Workflow Execution's mutable state.\n - The Activity Task is picked up again by an Activity Worker.\n - In the Temporal Server, the Start-To-Close timer is reset and will fire again if this second attempt fails.\n\nThe tricky part of setting Start-To-Close is that it needs to be set longer than the maximum *possible* Activity Execution, since you want to avoid premature timeouts for Activity Executions that genuinely take that long. \nPractically, if an Activity Execution can take anywhere from 5 minutes to 5 hours, you need to set Start-To-Close to be longer than 5 hours.\nIf you have a long running Activity Execution like that, then we suggest using Heartbeat timeouts.\n\n## Schedule-To-Close Timeout\n\nThe Schedule-To-Close Timeout is used to control the overall maximum amount of time allowed for an Activity Execution, including all retries.\nThis timeout only makes sense if the Activity Execution has a `RetryPolicy` with `MaximumAttempts > 1`.\n\n![image](https://user-images.githubusercontent.com/6764957/122290183-0dabc580-cf26-11eb-913d-3dc74d5eb55f.png)\n\nIf you let it, Temporal will retry a failing Activity Execution for up to 10 years! (with exponential backoff up to a defined maximum interval)\nMost Temporal developers will want to fine-tune retries to balance the user experience against the unreliability of the Activity Execution.\n\nWhile you can control intervals between retries and maximum number of retries in the `RetryPolicy`, the Schedule-To-Close Timeout is the best way to control retries based on the overall *time that has elapsed*.\nWe recommend using the Schedule-To-Close Timeout to limit retries rather than tweaking the number of Maximum Attempts, because that more closely matches the desired user experience in the majority of cases.\n\n## Heartbeat Timeout\n\nFor long running Activity Executions, we recommend recording Heartbeats to create more frequent ping-backs from the Activity Worker to the Temporal Server. \nThen, set a Heartbeat Timeout to fail the Activity Execution when the Temporal doesn't receive a Heartbeat from your Activity Execution at the expected frequency.\n\n![image](https://user-images.githubusercontent.com/6764957/122424268-287f4800-cfc1-11eb-8417-f52743347afc.png)\n\nHeartbeats must be recorded from Activity Definitions (Activity code) using SDK APIs:\n\n\n```go\nprogress := 0\nfor hasWork {\n // Send heartbeat message to the server.\n activity.RecordHeartbeat(ctx, progress)\n // Do some work.\n ...\n progress++\n}\n```\n\nSetting a Heartbeat Timeout enables you to retry Activity Executions more quickly (e.g. the next minute after a Heartbeat is missed) than the Start-To-Close Timeout, which must be set to as long as the longest possible Activity Execution (e.g. five hours later when we are sure the Activity Execution should have been completed).\n\nThere are some minor nuances to Heartbeats that may be of interest:\n\n- You can freely record Heartbeats as often as you want (e.g. once a minute, or every time a loop iterates).\nThe SDKs throttle the Heartbeats that get sent back to the Server anyway.\n- If a Heartbeat Timeout isn't set and the Activity Execution tries to record a Heartbeat, nothing will be recorded since that information will never be used.\n\n## Schedule-To-Start Timeout\n\nThe Schedule-To-Start Timeout sets a limit on the amount of time that an Activity Task can sit in a Task Queue.\nWe recommend that most users monitor the `temporal_activity_schedule_to_start_latency` metric and set alerts for that as a [production scaling](https://docs.temporal.io/docs/server/production-deployment/#faq-autoscaling-workers-based-on-task-queue-load) metric, rather than setting an explicit timeout for it.\n\n![image](https://user-images.githubusercontent.com/6764957/122290279-287e3a00-cf26-11eb-8dd6-3133016a0bd9.png)\n\nAs a queue timeout, `ScheduleToStart` is unique in that it **doesn't result in a retry** — all a retry would do is pop the activity right back on to the same queue!\n\nThe Schedule-To-Start Timeout is most useful when you have a concrete plan to reroute an Activity Task to a different Task Queue, if a given Task Queue is not draining at an expected rate.\nYou can also reschedule a whole set of other Activity Executions or do other compensation logic based on this timeout.\nThis is a powerful feature for building ultra-reliable systems, however most users will not need this since you can horizontally scale the number of Workers easily.\n\nGenerally, issues with Schedule-To-Start are better addressed by scaling Activity Workers accordingly, rather than by adding timeouts.\n\n## Putting it all together - a recruiting example\n\nWe've recently found the terminology of timeouts useful even internally for our recruiting and realized that this could be a relatable analogy for most people.\n\nAs [we are hiring heavily at Temporal](https://temporal.io/careers), there is a lot of interview scheduling going on intermixed with our regular day jobs. You could model the end-to-end hiring process for a candidate as a single \"Workflow\" with multiple \"Activities\": sourcing, interviewing, making a decision, and then the offer process. \n\nSpecifically for the \"Activity\" of interviewing we've encountered some pain points:\n\n- Some interviews were scheduled for 90 minutes, which we found to be way too long\n- Some interviews had no-shows for any number of reasons ranging from miscommunication to Life™ getting in the way, and we were unclear on when to call an end to the interview and try to reschedule\n- Sometimes a process would just drag out for weeks and weeks, leaving other candidates waiting.\n\nTo resolve this, we could think about setting some timeout policies (for clarity, none of these are real numbers):\n\n- A Start-To-Close Timeout of 45 minutes so we don't spend too much time per interview.\n- A Heartbeat Timeout of 10 minutes to see if we should cancel on no-shows.\n- A Schedule-To-Close Timeout of 4 weeks to limit the length of time we spend accommodating other people's schedules vs our own.\n\n![image](https://user-images.githubusercontent.com/6764957/122290324-359b2900-cf26-11eb-93a6-5027fc98593b.png)\n\nShould we set a Schedule-To-Start timeout? You could imagine candidates sitting a queue waiting to be interviewed, with not enough interviewer \"Workers\" to process them. A timeout here wouldn't help much, because there's no other queue to put them on. Better to set up monitoring and alerting on Schedule-To-Start latency, and scale up workers accordingly as needed (autoscaling is [currently not possible](https://docs.temporal.io/docs/server/production-deployment/#faq-autoscaling-workers-based-on-task-queue-load)).\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/temporalio/the-4-types-of-activity-timeouts-in-temporal-1p69","devToReactions":14,"devToReadingTime":7,"devToPublishedAt":"2021-06-22T20:57:31.229Z","devToViewsCount":245,"title":"The 4 Types of Activity timeouts in Temporal","published":true,"description":"This post (together with the embedded talk) aims to give you a solid mental model on what each Activity timeout in Temporal does and when to use it.","tags":"Temporal, Architecture, Golang","slug":"temporal-activity-timeouts","canonical_url":"https://docs.temporal.io/blog/activity-timeouts","cover_image":"https://user-images.githubusercontent.com/6764957/122424123-0ab1e300-cfc1-11eb-82c5-cf8856a87242.png"},"title":"The 4 Types of Activity timeouts in Temporal","description":"This post (together with the embedded talk) aims to give you a solid mental model on what each Activity timeout in Temporal does and when to use it. ","category":"note","tags":["temporal","architecture","golang"],"image":"https://user-images.githubusercontent.com/6764957/122424123-0ab1e300-cfc1-11eb-82c5-cf8856a87242.png","canonical":"https://docs.temporal.io/blog/activity-timeouts","slug":"temporal-activity-timeouts","date":"2021-06-22T20:57:31.229Z","readingTime":"8 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/182","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/182/comments","title":"The 4 Types of Activity timeouts in Temporal","created_at":"2022-01-17T23:01:32Z","updated_at":"2022-06-18T17:48:57Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/182/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n{% youtube kYfNvmF0Bqw %}\n\n> “When you grow up you tend to get told that the world is the way it is and your life is just to live your life inside the world. Try not to bash into the walls too much. Try to have a nice family life, have fun, save a little money. That's a very limited life. Life can be much broader once you discover one simple fact: **Everything around you that you call life was made up by people that were no smarter than you.** And you can change it, you can influence it… Once you learn that, you'll never be the same again.”\n>\n> — Steve Jobs\n\nThe common reminder, \"*Memento mori*\", is often interpreted as a call to withdraw our ambitions and not take pride in our achievements.\n\nI worry that this makes us too fatalistic, nihilistic, and self centered. \"Nothing I do matters, so why should I bother?\"\n\n*Memento mori* is no guide to life. Fortunately, I've found it has an opposite: \n\n**Memento vivere**. *Remember that you must LIVE*.\n\nThe way things are is often how we think the way things will always be. But nothing could be further from the truth:\n\n- The iPhone was introduced in 2007, 14 years ago.\n- The World Wide Web was invented in 1990, 31 years ago.\n- The Personal Computer revolution started in 1977, 44 years ago.\n- Richard Nixon took the US off the gold standard in 1971, meaning the current international financial system is only 50 years old.\n- Color TV first aired in 1951, 70 years ago.\n- Nuclear bombs were developed in 1945, 76 years ago.\n- Automatic washing machines rolled out in the 1930s.\n- Home radios and refrigerators were first introduced in the 1920's.\n- Henry Ford first sold the Model T automobile in 1908.\n- Thomas Edison started the Edison Electric Illuminating Company in 1882.\n- Alexander Graham Bell made the first telephone call in 1876.\n\nWhat are we doing today that will find its place on a list like this, 100 years from now?\n\n{% tweet 1394098022523490305 %}","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/memento-vivere-5eak","devToReactions":13,"devToReadingTime":2,"devToPublishedAt":"2021-06-19T21:47:04.595Z","devToViewsCount":238,"title":"Memento Vivere","published":true,"description":"Remember what life can do.","tags":"Reflections","slug":"memento-vitae","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bws2vd0uoev528u8kkyi.png","canonical_url":"https://www.swyx.io/memento-vitae"},"title":"Memento Vivere","description":"Remember what life can do. ","category":"note","tags":["reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bws2vd0uoev528u8kkyi.png","canonical":"https://www.swyx.io/memento-vitae","slug":"memento-vitae","date":"2021-06-19T21:47:04.595Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/183","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/183/comments","title":"Memento Vivere","created_at":"2022-01-17T23:01:34Z","updated_at":"2022-06-18T17:48:57Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/183/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"The Coding Career Handbook with Educative","slug":"coding-career-educative","categories":["Careers"],"description":"Shawn talks about his work with the LearnInPublic movement and his own contributions to the Educative platform.","instances":[{"venue":"Educative","date":"2021-06-14","tweet":"https://twitter.com/leepngo/status/1404408306215628801?s=21","video":"https://www.youtube.com/watch?v=9maORXuCBHk"}],"category":"talk","date":"2021-06-14T00:00:00.000Z"},{"type":"blog","content":"\nMost people who come across the IaaS vs PaaS debate conclude that the early PaaSes were \"just too early\". That was my own premise in [Cloud Distros](https://www.swyx.io/cloud-distros/) (*start there if you are new to IaaS vs PaaS, then head to [my take on AWS](https://www.swyx.io/hello-aws/#muck)*) — and it was a little too convenient. \n\nTechnology progresses in a series of [back-and-forth switchbacks](https://twitter.com/swyx/status/1260022224351723521), not a monotonic straight line. In the year since I wrote that essay I've learned that the real story is a lot more nuanced than simple \"timing\".\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kly0pr01qek5sc175e2p.png)\n\n## Learning 1: PaaS was the \"Old\" way\n\nHere is Amazon CTO Werner Vogels, on [choosing to offer \"tools instead of platforms\"](https://cacm.acm.org/magazines/2021/3/250706-a-second-conversation-with-werner-vogels/fulltext):\n\n> It was slightly controversial, because most technology companies at the time were delivering everything and the kitchen sink, and it would come with a very thick book and 10 different partners that would tell you how to use the technology. We went down a path, one that Jeff [Bezos] described years before, as **building tools instead of platforms**. A platform was **the old-style way** that large software platform companies would use in serving their technology.\n> \n> If you would go from Win32 to .NET, it was clear that the vendor would tell you exactly how to do it, and it would come with everything and the kitchen sink — not small building blocks but rather, \"This is how you should build software.\"\n>\n> A little before we started S3, we began to realize that what we were doing might radically change the way that software was being built and services were being used. But we had no idea how that would evolve, so it was more important to build small, nimble tools that customers could build on (or we could build on ourselves) instead of having everything and the kitchen sink ready at that particular moment. **It was not necessarily a timing issue**; it was much more that we were convinced that whatever we would be adding to the interfaces of S3, to the functionality of S3, should be driven by our customers—and how the next generation of customers would start building their systems.\n\nIaaS was a conscious choice by AWS - it wasn't simply that we hadn't developed the underlying technology to build good PaaSes. AWS had the core insight that whatever would be successful in the cloud era would be materially different than with desktops (where Microsoft's platform approach with Windows ruled).\n\nEven this insight wasn't immediately obviously correct. AWS' first launch, SQS, was [in 2006](https://en.wikipedia.org/wiki/Amazon_Web_Services#Founding_(2000%E2%80%932005)). [Balaji Srinivasan notes](https://twitter.com/balajis/status/1368230680367300612): \"It wasn’t until Instagram in 2012 that everyone took AWS seriously as a way to build a billion dollar company.\" \n\n## Learning 2: We have failed at building IaaS before\n\nBalaji [also noted](https://twitter.com/balajis/status/1368228398229680134): \n\n> \"Many people had scar tissue from trying to do IAAS a few years too early, before the Xen hypervisor. It’s an extremely capital intensive business and Bezos nailed the timing.\" \n\nHe includes this passage from Ben Horowitz's recap of [the Loudcloud/Opsware years](https://a16z.com/2010/03/17/the-case-for-the-fat-startup/):\n\n> During this period, Loudcloud/Opsware had **over 20 direct competitors**. Almost all the competitors from the Loudcloud era went bankrupt, including MFN/SiteSmith, Exodus, LogicTier, Williams Communication, Global Crossing, WorldCom/Digex and Storage Networks. Those that survived got bought with **valuations of less than $100 million** (e.g., Totality) or still have very low valuations (e.g., Navisite).\n\nSo if the late 2000's were \"too early\" for PaaS, you could also have made the case that the early 2000's were \"too early\" for IaaS. Betting on IaaS the way AWS did, at the time that it did, was not at all obvious.\n\n## Learning 3: Single Layer PaaS was too restrictive\n\nHeroku was by no means a failure, but it certainly disappointed relative to its IaaS contemporaries, which today take in tens of billions a year.\n\nJason Warner, GitHub CTO and Heroku's former VP of Engineering, [observed this about Heroku](https://www.infoworld.com/article/3614210/the-decline-of-heroku.html):\n\n> It should never have been a PaaS; it should have been a **multilayered cake of PaaS** with various escape hatches to build out with Kubernetes or go multicloud, but that wasn’t what was to be.\n\nToday, most IaaSes have \"worked backward\" and innovated forward - much as AWS originally offered S3 and EC2 and CloudFront and VPC, it now offers DynamoDB and Aurora and Elasticsearch and Lightsail and Elastic Beanstalk and Lambda and a couple hundred more ways to consume the underlying storage, compute, and networking services. Same for GCP and Azure.\n\nThe IaaSes, being lower level by nature, were in a better place to build up the multilayered cake, than the PaaSes were able to break themselves up.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/why-iaas-beat-paas-4np7","devToReactions":9,"devToReadingTime":4,"devToPublishedAt":"2021-06-13T18:34:19.181Z","devToViewsCount":370,"title":"Why IaaS beat PaaS","subtitle":"From the people who were *there*","published":true,"description":"The conclusions are far more nuanced when you ask the people involved at the time.","tags":"Cloud, AWS, Azure","slug":"why-iaas-beat-paas","canonical_url":"https://www.swyx.io/why-iaas-beat-paas","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kly0pr01qek5sc175e2p.png"},"title":"Why IaaS beat PaaS","subtitle":"From the people who were *there*","description":"The conclusions are far more nuanced when you ask the people involved at the time. ","category":"note","tags":["cloud","aws","azure"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kly0pr01qek5sc175e2p.png","canonical":"https://www.swyx.io/why-iaas-beat-paas","slug":"why-iaas-beat-paas","date":"2021-06-13T18:34:19.181Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/184","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/184/comments","title":"Why IaaS beat PaaS","created_at":"2022-01-17T23:01:36Z","updated_at":"2022-06-18T17:48:57Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/184/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n*Listen to [audio narrated version!](https://swyx.transistor.fm/episodes/second-brain-4-intermediate-packets-bottom-up-idea-exploration)*\n\nOver 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.\n\n- [Step 1: Respond to Others!](#stage-1-respond-to-others)\n- [Step 2: Yes, And!](#step-2-yes-and)\n- [Step 3: Livestream!](#step-3-livestream)\n- [Step 4: Blogpost!](#step-4-blogpost)\n- [Step 5: Conference Lightning Talk!](#step-5-conference-lightning-talk)\n- [Step 6: Conference Livecode Talk!](#step-6-conference-livecode-talk)\n- [Step 7: Advanced Conference Talk!](#step-7-advanced-conference-talk)\n- [Step 8: Job Interview!](#step-8-job-interview)\n\n> **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](http://worrydream.com/#!/Bio), [Sarah Drasner](https://sarahdrasnerdesign.com/speaking), [Dan Abramov](https://overreacted.io/my-decade-in-review/) and [Anjana Vakil](https://www.youtube.com/results?search_query=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!\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ooajl9yok4rffbgc2hvb.png)\n\n## Step 1: Respond to Others!\n\nI 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*](https://en.wikipedia.org/wiki/Four_stages_of_competence).\n\nThis was the context with which I read Jack Cross' [tweet](https://twitter.com/crosscompile/status/1100127023106805767?s=20) on Feb 26 2019: \"*Was reading through [React's source code]. and I think `useState` is implemented with `useReducer`!*\" \n\nAt 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](https://twitter.com/markdalgleish/status/1095025468367990784) with the Hooks API design. I wanted to find a way to properly explain all this once and for all.\n\nIt got my gears going: I'm a believer that you only truly [Know Your Tools](https://www.swyx.io/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:\n\n{% twitter 1100809424963219456 %}\n\nYou 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.\n\n## Step 2: \"Yes, And\"!\n\n(*90 minutes after the original tweet)*\n\nI got quite a bit of instant feedback on that tweet, namely [this suggestion](https://twitter.com/dan_abramov/status/1100813228525916161) 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.\"*\n\nThat 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:\n\n{% twitter 1100833207451185152 %}\n\nThis was finally simple enough to understand, yet complex enough to be useful, which [finally made it take off](https://twitter.com/swyx/status/1100833207451185152/retweets/with_comments) with a bunch of feedback.\n\nI think Twitter is best as an [Ensemble rather than Committee](https://www.swyx.io/ensembles-vs-committees/), particularly with the \"[Yes, And](https://en.wikipedia.org/wiki/Yes,_and...)\" spirit of starting from where the other person leaves off. This is what Dan did with me, and I followed through.\n\nIt's important to note that I wasn't the first to observe the simplicity of Hooks. There was prior art and [very popular blogposts](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e) 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.\n\n> 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](https://www.swyx.io/puwtpd/).\n\n## Step 3: Livestream!\n\n(*Friday after the original tweet)*\n\nJoel Hooks of Egghead.io DM'ed me to do [a livestream of this process](https://twitter.com/swyx/status/1100839318518521856) that same Friday. I think I was [in LA at the time](https://mobile.twitter.com/swyx/status/1101555809140453376) 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](https://mobile.twitter.com/eveporcello) was there, together with a few dozen other React folks!\n\nThis was the first time I had *ever* livecoded anything online, and it set the stage for what was to come...\n\n## Step 4: Blogpost!\n\n(*2 weeks after the original tweet*)\n\n[The blogpost version](https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-react-hooks-really-work/) went live on the Netlify blog, with title and grammatical edits from my coworkers. [The response](https://mobile.twitter.com/search?q=https%3A%2F%2Fwww.netlify.com%2Fblog%2F2019%2F03%2F11%2Fdeep-dive-how-do-react-hooks-really-work%2F&src=typed_query) was great:\n\n{% twitter 1116607569055715328 %}\n\nFun fact: I was in Mexico on a [dive trip](https://mobile.twitter.com/swyx/status/1103385015159648256) 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.\n\n## Step 5: Conference Lightning Talk!\n\n*(1 month after the original tweet)*\n\n[Ben Dunphy](https://mobile.twitter.com/benghamine) of [Reactathon](https://www.reactathon.com/) 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](https://www.swyx.io/cfp-advice/) — so I was pretty stoked about that!\n\n{% youtube VugRXf8Gg4o %}\n\nI only had ~10 minutes so I just threw some code up on slides. The reception was [decent](https://twitter.com/httpJunkie/status/1112711415507222528?s=20) for the minimal work I put into it. The talk got me [shouted out](https://twitter.com/swyx/status/1117824535548579840) on the wildly popular [Syntax.fm](http://syntax.fm) podcast from Wes Bos and Scott Tolinski, from whom I learned React, as well as one from [Lee Byron](https://twitter.com/leeb/status/1112183983129784321?s=20), who [designed the original React class API](https://reactjs.org/blog/2016/09/28/our-first-50000-stars.html#api-churn).\n\n## Step 6: Conference Livecode Talk!\n\n*(4 months after the original tweet)*\n\nI remember paying the ~$300 out of pocket for JSConf Asia tickets in [Jan 2018](https://twitter.com/swyx/status/956340811603390465), when I was just starting out. I had no idea that I would be *paid* to fly back to Singapore and [speak there](https://twitter.com/swyx/status/1090886781828968448) just a year later.\n\nI proposed this talk without knowing if I could do it. I just knew from studying [Kelsey Hightower's demos](https://www.youtube.com/watch?v=U6SfRPwTKqo) and [André Staltz's advice](https://staltz.com/your-ide-as-a-presentation-tool.html) 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\".\n\nI not only [pulled it off](https://www.swyx.io/hooks/), but also managed to add some dramatic flair rendering code to screen:\n\n{% youtube KJP1E-Y-xyo %}\n\n*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](https://en.wikipedia.org/wiki/Ren%C3%A9_Magritte) flourish right at the end. I presented that talk on ~2 hours of sleep.\n\n[The reception](https://twitter.com/search?q=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DKJP1E-Y-xyo&src=typed_query) *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.\n\n## Step 7: Advanced Conference Talk!\n\n(*8 months after the original tweet)*\n\nWhen 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](https://reactadvanced.com/) conference in London there was only one topic I wanted to do: **explain Concurrent React** the same way I had React Hooks.\n\n{% youtube fKlt5GFQnVc %}\n\n*(This is the revised version for ByteConf; [the React Advanced one is here](https://www.youtube.com/watch?v=dFO4m7Y-yhs) and I did a paid version for [Egghead.io subscribers as well](https://egghead.io/lessons/react-concurrent-react-from-scratch))*\n\nWhile 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](https://dev.to/swyx/an-annotated-guide-to-the-react-server-components-demo-2a83/) is a huge step forward) so people weren't familiar with it.\n\nPutting together this massive effort involved pulling in notes from [18 months of covering Concurrent React](https://github.com/sw-yx/concurrent-react-notes) by myself, in particular studying [prior art from Rodrigo Pombo](https://github.com/pomber/didact) in cloning the API from scratch. You can [check out his talk here](https://www.youtube.com/watch?v=8Kc2REHdwnQ) to contrast what he did vs me.\n\n[The reception](https://twitter.com/search?q=-from%3Aswyx%20%40swyx%20reactadvanced%20until%3A2019-11-01%20since%3A2019-10-24&src=typed_query) 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](https://twitter.com/swyx/status/1187740301831659522) at that conference, which set things in motion...\n\n## Step 8: Job Interview!\n\n*(11 months after the original tweet)*\n\nWithin 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.\n\nSo 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. \n\nI got the offer the next day.\n\n## Why I Wrote This\n\nI've recently been guiding a group of ~50 students as a mentor for [Tiago Forte's Building A Second Brain](https://www.swyx.io/tiago-forte-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\"). \n\nWeek 4 was the lesson on Intermediate Packets, which Tiago has [written about](https://medium.com/praxis-blog/bending-the-curves-of-productivity-25edb268672f) and [covered on his podcast](https://www.listennotes.com/podcasts/the-building-a/intermediate-packets-TO04J8Q5XZI/) 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.\n\nAs 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.\n\n**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. \n\nIf 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.\n\nAgain, 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](https://swyx.io/LIP). 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.\n\n## Reactions\n\n- Matias Woloski, cofounder of Auth0, [notes that](https://twitter.com/woloski/status/1404105211543801864?s=20) 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.\n- Netlify's Mathias Biilmann also went through a similar journey with the [Why Static Site Generators Are The Next Big Thing](https://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/) blogpost developing into [The New Front-end Stack. Javascript, APIs and Markup](https://vimeo.com/163522126) at SmashingConf and then https://jamstack.org/\n- See also David Perell's [Content Triangle](https://perell.com/essay/the-ultimate-guide-to-writing-online/)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/bottom-up-idea-exploration-375f","devToReactions":33,"devToReadingTime":10,"devToPublishedAt":"2021-06-06T16:42:16.265Z","devToViewsCount":538,"title":"Bottom-Up Idea Exploration","published":true,"description":"My own content creation philosophy, explored through my own personal story with React","tags":"Reflections, LearnInPublic, React","slug":"bottom-up-ideas","canonical_url":"https://www.swyx.io/bottom-up-ideas","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ooajl9yok4rffbgc2hvb.png"},"title":"Bottom-Up Idea Exploration","description":"My own content creation philosophy, explored through my own personal story with React ","category":"note","tags":["reflections","learninpublic","react"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ooajl9yok4rffbgc2hvb.png","canonical":"https://www.swyx.io/bottom-up-ideas","slug":"bottom-up-ideas","date":"2021-06-06T16:42:16.265Z","readingTime":"9 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/185","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/185/comments","title":"Bottom-Up Idea Exploration","created_at":"2022-01-17T23:01:38Z","updated_at":"2022-06-18T17:48:58Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/185/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n\n> Listen to [the audio version of this essay here](https://swyx.transistor.fm/episodes/the-power-of-personal-podcasting-swyx)!\n\nWhat kind of egotistical asshole runs a solo podcast?!\n\nLoads. Naval Ravikant [has one](https://nav.al/). Peter Thiel [has one](https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy8zMGVhZDM1Yy9wb2RjYXN0L3Jzcw==). James Beshara [has one](https://belowthelinepod.com/). Scott Hanselman's has been [running for 15 years](https://www.hanselminutes.com/archives). Lex Fridman and Joe Rogan became global celebrities just broadcasting 3 hour long conversations with anyone they wish. (Yeah it seems to be all dudes... let me know if you have other examples)\n\nAnd, as of this year.... me.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t873icsvyz33o5bm73sv.png)\n\n## The Personal Podcast\n\nThe defining characteristic of a Personal Podcast to me is that it is primarily driven by the interests of one person exploring their intellectual curiosity under their own name. \n\nThat's it. No co-host banter. No company sponsor, or singular theme, trying to establish thought leadership (ruling out [Tiago's](https://fortelabs.co/blog/basbpodcast/) or [Corey's](https://www.swipefiles.com/everything-is-marketing)) to try to sell you something. Purely [learning in public](https://www.swyx.io/learn-in-public/).\n\nI've increasingly come to like the idea, so on January 15th I started what I've come to call my own \"[mixtape](http://swyx.transistor.fm/)\". \n\nMy format is simple: Short audio clips from others on weekdays, long form content from me on weekends. Inspired by [Ryan Holiday](https://dailystoic.com/), [NFX](https://podcast.nfx.com/episodes), [The Daily](https://www.nytimes.com/column/the-daily) and [Techmeme](https://art19.com/shows/techmeme-ridehome). It's been slowly growing to a small listenership, mostly because I have no idea how the hell to market a podcast. This will be my 100th episode, and I think I have fuel in the tank for 100 more. \n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9zqbpdbxaxff794lx2g8.png)\n\nI thought I should offer some reflections on the occasion of my first 100 episodes. As [@visakanv is fond of saying](http://www.visakanv.com/blog/100-2/), \"do 100 thing\" is a key bar towards experimenting and building competence in something. \n\nI'm not *great* at this yet. But I'm better than I was before. And at the end of the day, isn't that all we can ask for ourselves?\n\n## Personal Podcast Superpowers\n\n1. **Infinite Game**: the benefit of a personal podcast not being tied to a company or professional topic is that your name is the one thing that is going to last with you for the rest of your life. \n - I'll grant that it's possible, ideal even, to have your name tied to one topic for the rest of your life, like [Rob Walling](https://www.startupsfortherestofus.com/), but it is very rare.\n - The personal focus limits your reach, but ensures longevity. Having a personal podcast trains you to play Infinite Games by **playing a game you cannot win**, since the only goal is to keep going.\n - Personal podcasting is a great low stakes way to practice being a [Part Time Creator](https://www.swyx.io/part-time-creator-manifesto/), as a means to lock down the time management and productivity tactics to run your own media operation.\n2. **Hot Medium**: Audio is a much \"hotter\" medium than text, as [Alex Danco has pointed out](https://alexdanco.com/2019/10/17/the-audio-revolution/). \n 1. It affords a lot more room for expression: in the same time it takes for someone to read your work, you can convey and evoke vocal emotion, include audio snippets, and even play music to your listeners (Music is the [highest TAM](https://en.wikipedia.org/wiki/Total_addressable_market) market, period). Voice creates a visceral connection straight into your eardrums, and the rise of truly wireless earbuds like Airpods have only increased this power.\n 2. Even it's constraints are nice: most of us spend all day staring at computer screens, so an audio-only format can be welcome respite during exercise and commutes.\n 3. The power of audio is why, despite being extremely widely read already, both [Ben Thompson](https://stratechery.com/2020/the-daily-update-podcast/) and [Packy McCormick](https://www.listennotes.com/podcasts/not-boring-packy-mccormick-trq3Lf8VpJe/) invest time to read out audio versions of their essays every week.\n3. **Independence**: Podcasting is one of the few truly decentralized mediums (although Spotify is doing its best to ruin it). If you can host MP3 files:\n 1. You cannot be deplatformed whether by [errant algorithm](https://www.swyx.io/proving-our-humanity/) or arbitrary decision.\n 2. You can run a podcast that will likely outlast any podcasting platform.\n4. **Completionism**: For a huge % of the population, podcasts are the only RSS feed where they regularly have 100% completion rate. \n 1. Not everyone will subscribe to your personal podcast, but those who do are *far* more likely to consume your content than even newsletter subscribers (where a 50% open rate is considered excellent)\n5. **Superfans**: You give an extra opportunity for people who want \"more where that came from\" to do just that.\n 1. This includes stripping out audio of the video interviews and talks you do, which can be helpful even just for discovery (in other words, even if the visual component is important, it can help your fans learn about content they want to watch)\n 2. You can guard against bitrot and increase discovery by rehosting your own appearances on other podcasts (like [my YouTube interviews](https://swyx.transistor.fm/episodes/weekend-drop-grifters-and-content-creation-traps) or my [Second Brain Workshops](https://swyx.transistor.fm/episodes/basb-week-1-the-capture-habit)) on your own feed (instead of requiring your superfans to go find your appearances through an index on your site or just following you closely on social)\n6. **Scheduling and Creative Control**: You don't rely on anyone else and don't need anyone's permission to change formats, take a break, or decide on content mix\n 1. I started my own podcast because of 3 consecutive weeks of scheduling difficulties with [my podcast cohost Randall](http://careerchats.transistor.fm/). To be clear, they were all my fault, but just the inflexibility of having to work with someone else's schedule (for a non-work project) proved very difficult to sustain.\n 2. I can throw in [music](https://swyx.transistor.fm/episodes/talkbox-byron-chambers-lorenz-rhode-scary-pockets) or [personal essays](https://swyx.transistor.fm/episodes/35-principles-for-35-years) or [angel investment chats](https://swyx.transistor.fm/episodes/weekend-drop-e2e-keyserver-startup-with-ashoat-tevosyan) or anything else I feel like anytime I want, as long as I think it'd make for something I myself would want to listen to in future.\n\nAs a side benefit, podcasting counts as excellent speaking practice - If you know you have a problem with your ums and ah's, there's nothing better to feel the pain than [spending hours editing them out](https://twitter.com/swyx/status/1378422268838076416) to motivate you to fix that.\n\n## Bring Back Mixtapes\n\nI think of my mixtape as a new format that I don't see anywhere else. Of course, mixtapes themselves are [as old as recorded audio](https://en.wikipedia.org/wiki/Mixtape), but they died off in the age of professional podcasting. \n\n- **Giving Value.** My formula of short weekday + long weekend is a blend of [Corey Quinn's AWS podcast](https://www.lastweekinaws.com/podcast/) and Peter Thiel's \"[recycled talks](https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy8zMGVhZDM1Yy9wb2RjYXN0L3Jzcw==)\". I think this is the right blend of \"[jab jab jab, right hook](https://www.garyvaynerchuk.com/the-one-thing-i-didnt-clarify-enough-in-jab-jab-jab-right-hook/)\": Giving value on a regular basis, and only infrequently asking for something self serving (my listener's time to listen to my voice drone on).\n- **Curation.** The weekday episodes clip extensively from other podcasts I listen to. I often get asked about IP rights of doing this, since it is so rarely done — I am mostly relying on [fair use](https://en.wikipedia.org/wiki/Fair_use) law and asking for forgiveness rather than permission. For what it's worth, every time I've publicly tweeted about an episode clip [like with Lynn Jurich](https://twitter.com/swyx/status/1382836263011581955) or [Shaan Puri](https://twitter.com/swyx/status/1372968161620811782), it's received retweets and even thanks from the people involved in the podcast. As for my listeners, I hope it helps them discover podcasts they haven't heard before, and zoom in to the specific timestamp that I deem most valuable.\n- **Brevity.** The shortcast format is another innovation - most weekday episodes are edited to under 10 minutes as much as possible. This is part creative constraint, part keen calculation: Everyone else puts out 30, 60, 120, and 180 minute episodes, so I stand out when I drop something that ends in 3 minutes and delivers that single hit you think about for months. It feels like a much smaller ask for hopefully great value.\n\n## Downsides\n\nI've had my own struggles with the high frequency format as well.\n\n- **Audio Editing**: I've gotten a lot better at putting episodes together with Audacity and Descript, but it is still a massive time sink and often takes 2-5x longer to produce than the final output.\n- **Discoverability:** Audio just doesn't show up for SEO. This can be mediated by smart titling and including transcripts, but it will just never rank as highly as a standalone blogpost. But perhaps more concerning for ROI on my time, my efforts will never scale through algorithmic recommendations. I have to put in extra effort mentioning it on Twitter or email, and it mostly doesn't do very well due to the platform incongruity.\n- **Analytics:** While I can track downloads, I don't *actually* know if anyone is even listening on the other side. So I do rely on people giving me positive encouragement via email, Discord, or Twitter like [this](https://twitter.com/nickytonline/status/1392844338925871109?s=20) or [this](https://twitter.com/ronvoluted/status/1395540202412597251?s=20) or [this](https://twitter.com/APKoponen/status/1359508767625392131?s=20).\n- **Depth**: Depressingly, most people don't read the descriptions of podcasts. I love giving further details for people to go down the same path I did, but people can't click on a link in my spoken word.\n- **Commentary**: People respond to podcasts even less than they read the descriptions, because the medium itself doesn't have an inbuilt feedback layer. I could include my email or a feedback form in every episode, but even then the response rate is super low. And it is many-to-one, rather than many-to-many, where feedback is encouraged because people can see that *other people* are giving feedback, and that I am responsive to it.\n\nFor these reasons, I am thinking about branching out or tweaking the format yet again, to involve YouTube. YouTube has a lot of these downsides mitigated, and the audio can still be stripped out and republished as an audio podcast. However, one downside is amplified: the need to edit **video** over audio, with correspondingly higher wait times and longer publish cycle.\n\n## Shameless Plug\n\n[Subscribe to my mixtape](http://swyx.transistor.fm/) already to experience it yourself, and let me know if you're inspired to start your own!\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-power-of-personal-podcasting-kkm","devToReactions":27,"devToReadingTime":7,"devToPublishedAt":"2021-05-28T02:09:23.639Z","devToViewsCount":587,"title":"The Power of Personal Podcasting","published":true,"description":"Celebrating following 100 episodes of my mixtape, and reflecting on why this works","tags":"Creators, Podcasts, Reflections","slug":"personal-podcasting","canonical_url":"https://www.swyx.io/personal-podcasting","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t873icsvyz33o5bm73sv.png"},"title":"The Power of Personal Podcasting","description":"Celebrating following 100 episodes of my mixtape, and reflecting on why this works ","category":"note","tags":["creators","podcasts","reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t873icsvyz33o5bm73sv.png","canonical":"https://www.swyx.io/personal-podcasting","slug":"personal-podcasting","date":"2021-05-28T02:09:23.639Z","readingTime":"8 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/186","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/186/comments","title":"The Power of Personal Podcasting","created_at":"2022-01-17T23:01:40Z","updated_at":"2022-06-18T17:48:58Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/186/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nIt's official: With the new [Payment Links](https://stripe.com/en-sg/payments/payment-links) feature, Stripe has entered the No Code market.\n\n{% youtube bLNFJNoL9e8 %}\n\n## Why It's a Big Deal\n\nYou can think of the process of getting money from your customers to yourself in 3 stages:\n\n- Running a Server for backend logic and secrets\n- Building a Frontend UI for customers to enter in their payment details and complete their purchase\n- Creating a [`PaymentIntent`](https://stripe.com/docs/payments/payment-intents#:~:text=Each%20PaymentIntent%20typically%20correlates%20with,collect%2C%20and%20the%20desired%20currency.) to track a single customer session from end to end. These must be created uniquely for each transaction.\n\nEach of these stages are immensely technical. \nStripe's recent product releases have progressively eliminated each one of these stages, opening Stripe up to the 99.6% of humanity that doesn't code!\n\n## Towards Stripe Checkout\n\nStripe's roots are famously developer centric. The default approach was to only offer a serverside SDK, and let you [wire everything else up yourself](https://stripe.com/docs/payments/integration-builder).\n\nThis gives you maximum control, but it can mean a lot of code to write and maintain. You not only have to code up an attractive, reassuring UI for people to enter their credit card details (though [Stripe Elements](https://stripe.com/en-sg/payments/elements) makes that easier), you also have to continually run a server just to take even a small one-off payment. If your server goes down , or you screw up some JavaScript, there goes your money!\n\nSo along comes [Stripe Checkout](https://stripe.com/en-sg/payments/elements), where Stripe hosts your UI:\n\n![https://res.cloudinary.com/practicaldev/image/fetch/s--EMzAeaWh--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://b.stripecdn.com/docs/assets/overview.6a4ea4b380bea93a5be8a820f3eb7c35.gif](https://res.cloudinary.com/practicaldev/image/fetch/s--EMzAeaWh--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://b.stripecdn.com/docs/assets/overview.6a4ea4b380bea93a5be8a820f3eb7c35.gif)\n\nWonderful! You not only don't have to code the UI or host it, Stripe is continually improving the checkout page on your behalf. It is even hosting it **on their domain**, and most people will trust a Stripe domain over your own when entering in their credit card details.\n\nBut.\n\nLook upon [the Stripe Checkout docs](https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=checkout#create-a-checkout-session) and realize that the `PaymentIntent` section is not handled at all - you STILL have to write some code and run at least a serverless function to get this thing working!\n\nI know this all too well because I spent a day learning and debugging this when I was [launching my self published book](https://dev.to/swyx/lessons-and-regrets-from-my-25000-launch-3aaa).\n\n## Stripe Payment Links\n\nSince everyone was writing little serverless functions to coordinate all the `PaymentIntent` creation and offer a nice URL for all this, the natural next step is for Stripe to do it for you instead!\n\nYou can think of [Stripe Payment Links](https://stripe.com/en-sg/payments/payment-links) as a thin layer atop of Stripe Checkout:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ald99mra5o9qjjt1xui5.png)\n\nNow the interface between your user and your business is just a simple URL - the web's firstborn API. \n\nGetting started with it could not be easier.\n\nAssuming you have some [products and prices already set up](https://stripe.com/docs/billing/prices-guide) in Stripe, head to your Stripe Dashboard and look for \"Payment links\" under the Products section. [Here is a direct link](https://dashboard.stripe.com/payment-links).\n\nFrom here you can create a New link for each product, in seconds.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j91nd0eohyyrpika39dw.png)\n\nThe final Payment link will just look like this: https://buy.stripe.com/4gwcQB0I9dVpeIw5km (yes, that's a real Payment link URL!). You can now use it inside of low and no code setups like HTML, Wordpress, or WebFlow.\n\nBut perhaps the biggest 🤯 of all is that **you don't even need a website to take the money over the Internet anymore**. You can now drop that link over a Discord or Slack app, or even place it as your \"link in bio\". \n\nThat's the beauty of the URL - it's accepted everywhere. As all the best payment solutions should be.\n\n## Comparisons\n\nNow that Stripe is handling all three stages of the ecommerce process for the first time, it is inevitable to start comparing it to other vendors that have done the same since forever. Before Stripe, you could easily have spun up a Shopify or Gumroad site and taken payments that way. Is Stripe now going for their lunch?\n\nI don't have any inside info on this, but my intuition is: No. People hire Gumroad and Shopify to do very different jobs. \n\nFor example, Gumroad: \n\n- acts as a [Merchant of Record](https://www.digitalocean.com/blog/starter-apps-for-any-indie-business/#:~:text=Gumroad%20had%20the%20features%20Adam,him%20of%20those%20burdens%20too.) (to drastically simplify tax collection and compliance)\n- provides social proof (in the form of customer reviews)\n- platform traffic and revenue via [its Discover marketplace](https://gumroad.com/discover)\n- fulfilment (aka if you are selling digital content, it hosts your files for your customers to download)\n\nIn exchange for all that, it takes [6.5% of your sales](https://sacra.com/research/gumroad-android-creator-economy/). Stripe Payment Links are available for no extra charge on Stripe's standard [integrated pricing](https://stripe.com/en-sg/pricing).","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/stripe-goes-no-code-stripe-payment-links-explained-4im","devToReactions":23,"devToReadingTime":4,"devToPublishedAt":"2021-05-26T02:17:37.126Z","devToViewsCount":615,"title":"Stripe Goes No-Code — Stripe Payment Links Explained","published":true,"description":"Stripe has entered the No Code market in a big way! I take a crack at explaining what it's doing and why.","tags":"Tech, Stripe, Creators","slug":"stripe-payment-links","canonical_url":"https://www.swyx.io/stripe-payment-links","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yp9fv1grnc9upw94yu9e.png","disclosure":"I was given a preview of this feature, as a Stripe Community Expert. No financial sponsorship took place."},"title":"Stripe Goes No-Code — Stripe Payment Links Explained","description":"Stripe has entered the No Code market in a big way! I take a crack at explaining what it's doing and why. ","category":"note","tags":["tech","stripe","creators"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yp9fv1grnc9upw94yu9e.png","canonical":"https://www.swyx.io/stripe-payment-links","slug":"stripe-payment-links","date":"2021-05-26T02:17:37.126Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/187","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/187/comments","title":"Stripe Goes No-Code — Stripe Payment Links Explained","created_at":"2022-01-17T23:01:42Z","updated_at":"2022-06-18T17:48:58Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/187/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n> \"Civilization advances by extending the number of important operations which we can perform without thinking about them.\" — Alfred North Whitehead\n\nI've just implemented Prettier + ESLint on my React codebase [at work](https://github.com/temporalio/documentation/pull/451/commits/cae25e5ee08ef6ba840596679b7d37e79585ce4b) and figured I'd better share my notes in case others need to figure this out.\n\nMy setup includes:\n\n- See lint violations inline in VSCode\n- Prettify after PR merge with GitHub actions\n- Prettify before git commit (some folks dislike this)\n- Ability to manually run checks locally\n\nEven if you use TypeScript, you'll want BOTH Prettier and ESLint in your codebase. Prettier [doesn't always do what you mean](https://twitter.com/swyx/status/1191452690930376705) and ESLint checks things that Prettier doesn't. For historical reasons, this codebase doesn't use TypeScript, don't @ me, my love for [TypeScript is well documented](https://react-typescript-cheatsheet.netlify.app/).\n\n## Step 1: Dependencies\n\n```bash\nyarn add -D eslint eslint-plugin-react husky lint-staged prettier\n\n# or npm i -D eslint eslint-plugin-react husky lint-staged prettier\n```\n\nas of time of writing these are the versions I am working with:\n\n```json\n{\n \"devDependencies\": {\n \"eslint\": \"^7.27.0\",\n \"eslint-plugin-react\": \"^7.23.2\",\n \"husky\": \"^6.0.0\",\n \"lint-staged\": \"^11.0.0\",\n \"prettier\": \"^2.3.0\"\n }\n}\n```\n\nNote that this setup requires more work if you [using Husky v6 with Yarn 2](https://typicode.github.io/husky/#/?id=manual).\n\n\n## Step 2: Scripts\n\nadd stuff to package.json...\n\n```json\n{\n \"scripts\": { \n \"format\": \"prettier --write .\",\n \"prepare\": \"husky install\"\n },\n \"lint-staged\": {\n \"**/*\": \"prettier --write --ignore-unknown\"\n },\n}\n```\n\nYou can now run `npm run format` to prettify your existing codebase as a oneoff.\n\nIn case you were wondering:\n\n- [Husky](https://typicode.github.io/husky/#/) adds a git commit hook so that...\n- [`Lint-staged`](https://github.com/okonet/lint-staged) only runs Prettier on new stuff that you stage in git\n\n## Step 3: Prettier Settings\n\nCommence bikeshedding! Use the [Prettier Playground](https://prettier.io/playground/#N4Igxg9gdgLgprEAuEAzArlMMCW0AEAEnADYkQDqEATiQCYAUwA5tXHLlM-gLz4A6IABalyggDT5W7eHV74A5IKq06ghZIDOOEghjzUAQxKa4k6AFkI6UwHkAbnGriAvgEp8wflG-58OVAYAQmkOHC43YDYYdGoofCh0MhcAbm9fPz8Aeiz8ABVbABFbJHxC6AV9Gzh8akMoOggAW394tganDN19RJa+C0MYIQA6VHIafAYBoeG6huaGDwAqfABGAFEAagB2N2GYCABlGGpw5kXZuAAHEkMwOAYs-n5h57pNrJxmSUFBN3T4rUOLF4gAeOg4ez4MC3TSaAByhiacB4CmIZEoNHoCnwuBguh4wAABgBNaz4QxsfD2HDaA7UBLoJoAIyc+AAJMBGS0XESXPhLNY7I5qITBdUHE4XAA+AGZfCgzQnaDMaVc0KcZjDTQkHD3Bj4AAMklW+D2BwAqlcrk4AMKGUyLfCbKRsMJcbW6-Wrc0QAAyEAA7naHQ8PC5QVkldQVbLAX4WG7NcMEHRNBQcEMGBI-vgAPwCECF-ClRVXer4JUATwJwGAkHI1FKSn40irChcMokhcjmnLUGl+BcGT8oLgTTj-Bg6qTcDkw58MEj47j8q5DG0ulg-3jmQLgleIBHmVKgiCggXx8jEPs0rSPigLhA4hAECuuGgmmQoEpMcDAAVKQQL8UGMQNDCrL8X2ZOowAAaw4Q5yzAM5kCMEwzBAcdWToOg5z9epmHQQxmDgAAxGgmkGTVkBAQx0AOZ9hBgJoSAoIRMzgPs7jgQ5gMzSFMyrWiwDhJjwlMagYH-OpmCotDjFMF8ACtNAADwAIVghCYEOJE4D9cI4AUjCVPUw4zl0ABFdAIHgEylJActqEk2jmUMVkSCYq5TlgDM6CGZAAA5jScmNTAoOorlonyuKcRwmIAR1s+AZLfEC6M0ABaKB2DwugmLYZKcDYGSSPkpB0Mc0wmhwBzMO0LhrJS4ykBOdBMJgDz-MCpAACYXxOQwdDOW1mgqrDNAAViY6o8g8kCqsw+wOoASQ6WBDjAU53wAQQaY4a1apbOyAA) to decide on what settings your team wants.\n\nPut this in `.prettierrc.json`\n\n```json\n{\n \"arrowParens\": \"always\",\n \"bracketSpacing\": false,\n \"embeddedLanguageFormatting\": \"auto\",\n \"htmlWhitespaceSensitivity\": \"css\",\n \"insertPragma\": false,\n \"jsxBracketSameLine\": false,\n \"jsxSingleQuote\": false,\n \"printWidth\": 80,\n \"proseWrap\": \"preserve\",\n \"quoteProps\": \"as-needed\",\n \"requirePragma\": false,\n \"semi\": true,\n \"singleQuote\": false,\n \"tabWidth\": 2,\n \"trailingComma\": \"es5\",\n \"useTabs\": false,\n } \n```\n\nStep 4: ESLint\n\nYou know you gotta...\n\n```js\nmodule.exports = {\n \"env\": {\n \"browser\": true,\n \"es2021\": true,\n \"node\": true\n },\n \"extends\": [\n \"eslint:recommended\",\n \"plugin:react/recommended\"\n ],\n \"parserOptions\": {\n \"ecmaFeatures\": {\n \"jsx\": true\n },\n \"ecmaVersion\": 12,\n \"sourceType\": \"module\"\n },\n \"plugins\": [\n \"react\"\n ],\n \"rules\": {\n \"react/prop-types\": [0, {}], // this is dumb, why is this still recommended\n \"react/no-unescaped-entities\": [0, {}],\n \"no-unused-vars\": [1, {}],\n }\n};\n```\n\n> Recommended: also enable the [ESLint VSCode plugin](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) to see the eslint feedback in your editor!!!\n\nStep 5: Automate\n\nWe'll just add a nifty little GitHub Action in `.github/workflows/autoformat.yml`:\n\n```yaml\nname: Continuous Integration\n\n# This action works with pull requests and pushes\non:\n pull_request:\n push:\n branches:\n - master\n\njobs:\n prettier:\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout\n uses: actions/checkout@v2\n with:\n # Make sure the actual branch is checked out when running on pull requests\n ref: ${{ github.head_ref }}\n\n - name: Prettify code\n uses: creyD/prettier_action@v3.3\n with:\n # This part is also where you can pass other options, for example:\n prettier_options: --write **/*.{js,md}\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n```\n\nThat's it!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/how-to-add-prettier-and-eslint-automation-to-a-react-codebase-2gk1","devToReactions":261,"devToReadingTime":3,"devToPublishedAt":"2021-05-25T22:32:58.247Z","devToViewsCount":4930,"title":"How To Add Prettier and ESLint Automation to a React Codebase","published":true,"description":"Automated code quality with GitHub Actions, Husky, Lint-staged, Prettier, and ESLint","tags":"React, JavaScript, Webdev","slug":"prettier-eslint-react","canonical_url":"https://www.swyx.io/prettier-eslint-react","cover_image":"https://miro.medium.com/max/1400/1*N9n5F63ne3HimpJ10d1HEw.jpeg","disclosure":"I just did this as of May 2021 so your mileage may vary"},"title":"How To Add Prettier and ESLint Automation to a React Codebase","description":"Automated code quality with GitHub Actions, Husky, Lint-staged, Prettier, and ESLint ","category":"note","tags":["react","javascript","webdev"],"image":"https://miro.medium.com/max/1400/1*N9n5F63ne3HimpJ10d1HEw.jpeg","canonical":"https://www.swyx.io/prettier-eslint-react","slug":"prettier-eslint-react","date":"2021-05-25T22:32:58.247Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/188","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/188/comments","title":"How To Add Prettier and ESLint Automation to a React Codebase","created_at":"2022-01-17T23:01:44Z","updated_at":"2022-06-18T17:48:59Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/188/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"How to make your own luck on the Scrimba podcast","slug":"scrimba-pod-luck","tags":["Luck"],"venues":"Scrimba","date":"2021-05-25T00:00:00.000Z","url":"https://scrimba.com/podcast/swyx-coding-career-handbook/","description":"Shawn (Swyx) Wang joins us to discuss his book, The Coding Career Handbook 📖!","category":"podcast"},{"title":"Swyx on DevJourney with Tim Bourgignon","slug":"devjourney-pod","tags":["LIP"],"venues":"DevJourney","date":"2021-05-25T00:00:00.000Z","url":"https://devjourney.info/Guests/152-ShawnWang.html","description":"Shawn took us along on his transition from his very well-paid trading job to his career as a developer. We talked about re-using your skills, boot camps, the power of networks, LearnInPublic, motivation, and much more.","category":"podcast"},{"type":"blog","content":"\r\n*This post originated as [an AMA on IndieHackers](https://www.indiehackers.com/post/made-121-326-since-launching-my-book-last-july-63-of-it-after-launch-month-ama-about-long-tail-infoproducts-41b55f5670)*\r\n\r\nI [launched the Coding Career Handbook almost a year ago](https://www.indiehackers.com/product/cracking-the-coding-career) and since then have been focusing on long tail revenue, while keeping my day job as a [Part Time Creator](https://www.swyx.io/part-time-creator-manifesto/).\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ophhz5kfehva2xubp6mw.png)\r\n\r\nSince launch ([day](https://dev.to/swyx/lessons-and-regrets-from-my-25000-launch-3aaa), [month](https://dev.to/swyx/5-q-a-s-on-writing-and-selling-my-first-book-18d1), [cheatsheet](https://github.com/sw-yx/launch-cheatsheet)) I've been consistently hitting around $1-2k a week in infoproduct revenue, with a high price point ($59 for just the book, $249 for book+community+behind the scenes), and no sales apart from Black Friday.\r\n\r\n\r\n![image](https://user-images.githubusercontent.com/6764957/119191126-d4ac3c80-bab0-11eb-815d-1481c8616aec.png)\r\n\r\n## 5 Tips for Long Tails\r\n\r\nOff the top of my head these things helped extend the tail:\r\n\r\n- **Run a Twitter**. This is definitely extra work and I'm not sure how much sales it helps to drive, but having a [dedicated book twitter](https://twitter.com/Coding_Career) helps me stay current in people's minds without making my main account too spammy. Being tagged on feedback is great for social proof.\r\n- **Run a podcast**. Randall and I [ran a podcast](https://careerchats.transistor.fm/) that helped extend the reach of content we already worked on.\r\n- **Run a paid community**. My [middle tier](https://www.learninpublic.org/#community) is a high signal/low noise Discord + Circle community focused on tech careers and part time creation. Monthly calls and meetups and daily chats helps drive word of mouth.\r\n- **Blog**. 1/4 of my book was [prior blogposts that did well](https://swyx.io/LIP), so appending a shoutout to the top of the post helps drive traffic for people who want to read more.\r\n- **Do podcasts and talks**. I do at least a talk a month and it turns out podcasters like [inviting book authors to chat](https://shoptalkshow.com/432/) - the caveat here is that I've had zero luck cold pitching, [the talks/podcasts I did](https://www.learninpublic.org/) were all already warm/inbound.\r\n\r\nI spent about 600 hours writing the book. \r\n\r\nI think creators should spend equal time marketing as they do creating. \r\n\r\nSo I probably still have a ways to go, not inclusive of a planned v2 of the book this year.\r\n\r\nLet me know what other questions you have!\r\n\r\n## Reader Q&A\r\n\r\n**Emma**: How do you identify your niche and gauge their interest?\r\n\r\n> blog a lot and see what works 🤷‍♂️\r\n>\r\n> a set of good posts = the mvp of a book\r\n\r\n**Akcium**: Do you have a newsletter?\r\n\r\n> I have [a personal newsletter](https://www.swyx.io/subscribe), but decided not to do a separate book newsletter. \r\n>\r\n> I probably lost a lot of potential sales that way (bc its a way to extend the relationship if people are noncommittal), but it felt like extra work that I wouldn't enjoy. I'm more of a twitter native.\r\n\r\n**Akcium**: Would it be reasonable to make a separate twitter for a ...book?\r\n\r\n> I don't actually think *most* people should make a separate twitter. \r\n>\r\n> I only do it so as to shard my content because it is important that my main twitter not become too self promotional. \r\n>\r\n> If you are just starting out building an audience, just build one, not two.\r\n\r\n**unemployability**: How did you finally settle on those price points?\r\n\r\n> hey! yeah so pricing is a weird one - I approached it as a shock therapy exercise since I didn't need the money. You know how @patio11 and @csallen are always telling people to raise prices? i took that as far as I thought I could for a book:\r\n> \r\n> - Started with presale of $19 and then randomly promised that my presale price was 50% off launch...\r\n> - That means my launch price was $39... and i wanted to make the launch look like a good deal so I said it was 30% off the final price... \r\n> - That made the final book $59 and I had to put in the work to make sure it was worth that...\r\n> - Then I followed @jhooks' advice to do 1x 2x 5x three tier pricing.\r\n> - Wanted to make the middle tier a nobrainer so I put the community at $40 which is super cheap compared to the book\r\n> - then threw all the value add I could think of into the 5x. goal here was to try to sell a 3-figure thing to internet strangers for the first time... job accomplished.\r\n> \r\n> Higher prices can always be discounted in future... much harder to raise them. I also have something worth more to offer, when for example, i do a talk at a conference and they want to raffle off something.\r\n\r\n**Rob Fitzpatrick** (author of the Mom Test): Happy to see you mention spending a significant amount of time on the creation. So many people in this space seem obsessed with churning stuff out more quickly, whereas I always feel that it's more important to spend whatever time is required to make the end result most valuable.\r\n\r\n> Yes! That's what rubs me the wrong way about Daniel's \"pump it out in 2 weeks\" thing. It's of course great to make your first dollar on the internet, but no customer wants to hear how *little* you worked for their dollar.\r\n\r\n**Bhumi**: What is your main distribution channel for the long-tails post \"launch\" month growth? Is it mainly Twitter? Does your community help with the ongoing growth?\r\n\r\n> I listed a few channels above, and word of mouth from community (special shoutout to Tre Tuna from Amazon/Hack Reactor!!) has definitely helped. But I don't check my stats so I don't know what the main contributor was. \r\n>\r\n> I generally subscribe to the idea that people have to hear about you at least 3-4 times before they decide to buy your stuff so thats why I don't really bother.\r\n>\r\n> Just put out as much as I can given the time limits that i have, and let the cards fall where they may.\r\n\r\n**TypeofGraphic**: What advice would you give around starting and growing a community?\r\n\r\n> 1. show up every day\r\n> 2. propose relevant topics\r\n> 3. respond promptly when someone engages\r\n> 4. do it for a year\r\n\r\n**TypeofGraphic**: If you did it again - another book, another topic maybe. What would you do differently?\r\n\r\n> If i did it again, i'd make a short book - like, 100 pages, price it at $9, art design the heck out of it because everyone judges a book by its cover and illustrations. I made the mistake of aiming for the high end when I did my pricing and product and perhaps could have done better just going for reach first.\r\n>\r\n> When you do a book, you can either go for money or go for reach. I naively went for money. Better play is to make first book for reach, so that everyone is HUGELY IMPRESSED, then second book for money.\r\n\r\n**manast**: Just one question, how did you grow your Coding_Career twitter? did you have a large audience already in your regular twitter that you managed to engage in your new twitter account, or how did you do it?\r\n\r\n> i think i had about 15 or 16k followers when i launched that twitter, its middle sized? idk.\r\n>\r\n> for Coding_Career i think just tweeting focused threads like [this one](https://twitter.com/Coding_Career/status/1395415855303852033 ). I have more dev twitter advice in the book. :)\r\n\r\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/5-tips-for-long-tail-infoproduct-sales-40ad","devToReactions":11,"devToReadingTime":5,"devToPublishedAt":"2021-05-22T21:56:06.252Z","devToViewsCount":287,"title":"$120k in Infoproduct Sales - How to Extend the Long Tail","published":true,"tags":"Creators, Reflections","slug":"long-tail-infoproduct","canonical_url":"https://www.swyx.io/long-tail-infoproduct","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ophhz5kfehva2xubp6mw.png"},"title":"$120k in Infoproduct Sales - How to Extend the Long Tail","description":"*This post originated as an AMA on IndieHackers (https://www.indiehackers.com/post/made-121-326-since-launching-my-book-last-july-63-of-it-after-launch-month-ama-about-long-tail-infoproducts-41b55f5670)* ","category":"note","tags":["creators","reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ophhz5kfehva2xubp6mw.png","canonical":"https://www.swyx.io/long-tail-infoproduct","slug":"long-tail-infoproduct","date":"2021-05-22T21:56:06.252Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/281","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/281/comments","title":"$120k in Infoproduct Sales - How to Extend the Long Tail","created_at":"2022-01-18T00:09:38Z","updated_at":"2022-06-18T17:45:00Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/281/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n*This post was originally published on [FreeCodeCamp](https://www.freecodecamp.org/news/how-to-optimize-for-change-software-development/).*\n\nImagine you worked at Magic Money Corp, which runs on just three lines of JavaScript:\n\n```jsx\nlet input = { step1: 'collect underpants' }\ndoStuff(input) \nprofit(input) // $$$!!!\n```\n\nNow imagine something's wrong with the left phalange and we need to take `doStuff` down for maintenance. What happens if you temporarily comment out the second line?\n\nOh no! `profit()` is erroring all over the place. You've broken our magic money machine! To solve this, you would now have to read through the entire source code of `doStuff` to understand what it does and replace critical code for `profit` to function. \n\nMaybe it's better to just leave `doStuff` there... we don't *need* a functioning phalange right?\n\n**When we are afraid of making changes to our code, it starts to ossify and bloat.**\n\nNow let's imagine if we had built Magic Money Corp on immutable data structures instead (or used a functional language):\n\n```jsx\nlet input = ImmutableMap({ step1: 'collect underpants' })\ndoStuff(input)\nprofit(input) // $$$!!!\n```\n\nIt *looks* the same, but now I can remove `doStuff`, and have no fear of breaking Magic Money Corp! \n\nI've been obsessed with Dan Abramov's concept of [Optimizing for Change](https://overreacted.io/optimized-for-change/) since he wrote about it two years ago. It clearly articulates a core design principle of React (the rest are [here](https://reactjs.org/docs/design-principles.html) and [here](https://github.com/reactjs/react-basic)). For me, it is one of [the 7 lessons that will outlive React](https://twitter.com/swyx/status/1383516418205835264) that I now try to apply everywhere else.\n\nThe main question it doesn't answer: *how* exactly do you optimize for change?\n\n## TL;DR\n\n- Plan for Common Changes\n- Use Simple Values\n- Minimize Edit Distance\n- Catch Errors Early\n\n## Why Optimize for Change\n\nFirst, an obligatory explanation of this idea:\n\n- **Hard-to-delete code drives out easy-to-delete code over time**\n- Many layers of bandaids over hard-to-delete code causes technical mummification\n- Therefore we must try to optimize for change from the earliest design\n\nThe inspiration for this came from \"Easy-to-replace systems tend to get replaced with hard-to-replace systems\" ([*Malte Ubl*](https://twitter.com/cramforce/status/1139925981051801600)) and \"Write code that is easy to delete, not easy to extend\" ([*tef*](https://programmingisterrible.com/post/139222674273/how-to-write-disposable-code-in-large-systems))**.** Economics fans will recognize this as [an application](https://twitter.com/swyx/status/1286624921532080129) of [Gresham's Law](https://en.wikipedia.org/wiki/Gresham%27s_law). The idea is the same — a form of anti-entropy where *inflexibility* increases, instead of disorder.\n\nIt's not that we don't *know* when our systems are hard-to-replace. It is that the most expedient response is usually to slap on a workaround and keep going. After one too many bandaids, our codebase mummifies. This is the consequence of not allowing room for *change* in our original designs, a related (but distinct) idea to \"technical debt\" (which has its [own](https://redmonk.com/rstephens/2017/08/08/technical-debt/) [problems](https://twitter.com/jessitron/status/1123310331957145601)).\n\nThe reason we must allow for changes is that [requirements volatility is a core problem of software engineering](https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/). We devs often fantasize that our lives would be a lot easier if product specs were, well, fully *specified* upfront. But that's the [spherical frictionless cow](https://en.wikipedia.org/wiki/Spherical_cow) of programming. In reality, the only constant is change. We should carefully design our abstractions and APIs acknowledging this fact.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n1078j8opalnrzuu8p4u.png)\n\n## Plan for Common Changes\n\nOnce you're bought in to the need to optimize for change, it is easy to go overboard and be overcome by analysis paralysis. *How* do you design for *anything* when EVERYTHING could change?!\n\nWe could overdo it by, for example, putting abstract facades on every interface or turning every function asynchronous. It’s clear that doubling the size of your codebase in exchange for no difference in feature set is not desirable either.\n\nA reasonable way to draw the line is to design for small, common tweaks, and not worry about big, infrequent migrations. Hillel Wayne calls these [requirement perturbations](https://twitter.com/hillelogram/status/1189024161127190528) — small, typical feature requests should not throw your whole design out of whack. \n\nFor the probabilistically inclined, the best we can do is make sure our design adapts well to 1-3 \"standard deviation\" changes. Bigger changes than that are rare (by definition), and justify a more invasive rewrite when they happen.\n\nThis way, we also avoid optimizing for change that may never come, which can be a significant source of software bloat and complexity.\n\n*Common changes can be accumulated with experience - the humorous example of this is [Zawinski's Law](http://www.catb.org/jargon/html/Z/Zawinskis-Law.html), but there are many far less extreme changes that are entirely routine and can be anticipated, whether by [Preemptive Pluralization](https://www.swyx.io/preemptive-pluralization/) or [Business Strategy](https://www.swyx.io/dev-guide-to-tech-strategy/).*\n\n## Use Simple Values\n\nOnce we have constrained the scope of our ambitions, I like to dive straight into thinking about API design. The end goal is clear. In order to make code easy to change: \n\n- it has to first be easy to ***delete...***\n- which then makes it easier to ***cut and paste***...\n- which makes it easier to create and break apart ***abstractions***...\n- and so on, until you cover all routine maintenance tasks, including logging, debugging, testing and performance optimization.\n\nRich Hickey is well known for preaching the [Value of Values](https://www.infoq.com/presentations/Value-Values/) and [Simplicity](https://www.infoq.com/presentations/Simple-Made-Easy/). It is worth deeply understanding the implications of this approach for API design. Where you might pass class instances or objects with dynamic references, you could instead pass simple, immutable values. This eliminates a whole class of potential bugs (and unlocks logging, serialization and other goodies). \n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/olrtcg8p9ress0j3klob.png)\n\nOut of these requirements for simple uncomplected values, you can derive from first principles a surprising number of \"best\" practices — [immutable programming](https://www.youtube.com/watch?v=bFuRvcAEiHg), constraining state with a [functional core, imperative shell](https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell), [parse don't validate](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/), and [managing function color](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/). The pursuit of simplicity isn't a cost-free proposition, but a variety of techniques from [structural sharing](https://twitter.com/jordwalke/status/959018527091904512) to static analysis can help.\n\nInstead of memorizing a table of good/bad examples, the better approach is to understand that these are all instances of the same general rule: **Complexity arises from coupling.** \n\n## Minimize Edit Distance\n\nI mentally picture the braids from *Simple Made Easy* now, whenever I think about complexity.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gj20hvtks9erpk2y4wzp.png)\n\nWhen you have multiple strings next to each other, you can braid them and knot them up. This is complexity — complexity is difficult to unwind. It is only when you have just one string that it becomes impossible to braid. \n\nMore to the point, we should try to reduce our reliance on *order* as much as possible:\n\n- Execution order — If I delete something on line 2, how easily can the developer tell if something in line 3 will blow up? How many changes do I need to make to fix it?\n- Resolution order — If concurrent processes resolve out of order, how easily can I correct for or guarantee against race conditions?\n- Filesystem order — If I move some code from one place to another, how many other files need to be edited to reflect this?\n- Argument order — If I swap the position of some arguments, whether in a function call or a class constructor or a YAML config file, does the program implode?\n- *this is an ad hoc list; there are probably some big ones I'm missing here, please let me know*\n\nYou can even quantify this complexity with a notion of \"[edit distance](https://en.wikipedia.org/wiki/Edit_distance)\":\n\n- If I use multi-arity functions, then I cannot easily add or remove or rearrange parameters without then updating *all* the callsites, or adding default params I don't actually want. Single arity functions/languages with named params require only essential updates and no more. (This isn't without tradeoffs of course — more discussion [here](https://twitter.com/swyx/status/1198632709834326021))\n- Turning a stateless component stateful with React (pre-Hooks) used to require edits/additions of 7 lines of code. With React Hooks, it just takes 1.\n- Asynchrony and Data Dependency tend to propagate in a codebase. If one requirement changed and something at the bottom needed to be async (e.g. it needs one data fetch), I used to have to switch between at least 3 files and folders, and add reducers and actions and selectors with Redux to coordinate this. Better to decomplect parent-child relationships — a design goal prominent in [React Suspense](https://twitter.com/acdlite/status/969747179731533824), [Relay Compiler](https://twitter.com/swyx/status/1193112002413117440) and [GraphQL's dataloader](https://sophiebits.com/2020/01/01/fast-maintainable-db-patterns.html).\n\nYou could even imagine a complexity measure similar to the CSS specificity formula - a complexity of `C(1,0,0,0)` would be harder to change than `C(0,2,3,4)`. So optimizing for change would mean reducing the \"edit distance\" complexity profile of common operations.\n\nI haven't exactly worked out what the formula is yet, but we can *feel* it when a codebase is hard to change. Development progresses slower as a result. But that's just the visible effect — because it isn't *fun* to experiment in the codebase, **novel ideas are never found**. The invisible cost of missed innovation is directly related to how easy it is to try stuff out or change your mind.\n\n**To make code easy to change, make it impossible to \"braid\" your code.**\n\n## Catch Errors Early\n\nAs much as we can try to contain the [accidental](https://medium.com/background-thread/accidental-and-essential-complexity-programming-word-of-the-day-b4db4d2600d4) complexity of our code by API design and code style, we can never completely eliminate it except for the most trivial programs. For the remaining essential complexity, we have to keep our feedback loops as short as possible.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ft6xbdkm4mpzitumho5i.png)\n\nIBM coined the term \"[Shift Left](https://devops.com/shift-left-can-you-be-left-out/)\" after finding that [the earlier you catch errors, the cheaper they are to fix](https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC). If you arrange the software development lifecycle from left (design) to right (production), the idea is that if you shift your errors \"left\" then you'd save actual money by catching errors earlier (For more on this, see my discussion and sources in [Language Servers are the New Frameworks](https://dev.to/dx/language-servers-are-the-new-frameworks-1lbm)).\n\nIn concrete terms this might translate to:\n\n- unit tests that pinpoint what broke in your code when you refactor\n- types that [codify the contracts](https://css-tricks.com/types-or-tests-why-not-both/) between data and functions\n- continuous deploys that take [less than 15 minutes](https://stackoverflow.blog/2021/01/19/fulfilling-the-promise-of-ci-cd/) (you probably have easy wins to make in [frontend](https://twitter.com/housecor/status/1213093680501993472?s=20) or [backend](https://charity.wtf/2020/12/31/why-are-my-tests-so-slow-a-list-of-likely-suspects-anti-patterns-and-unresolved-personal-trauma/))\n- [local development servers](https://twitter.com/swyx/status/1115632067885375491) that emulate your cloud environment\n- \"live\" values either provided by [language servers](https://dev.to/dx/language-servers-are-the-new-frameworks-1lbm) or [editor plugins](https://quokkajs.com/) or [replay recording](https://replay.io/)\n\nThe causality may be ***bidirectional***. If you make it easier to change things, you will be able to make changes more frequently. It could work the other way too — because you expect to make frequent changes, you are more incentivized to make things easy to change. An extreme example of this involves not just code, but community - the longer a library (or language) stays on version 1, the harder the difficulty of switching to version 2, whereas ecosystems that regularly publish breaking versions (in exchange for clear improvements) seem to avoid stasis by sheer exposure.\n\n## A caution against *too much* change\n\nAny good idea turns bad when taken to the extreme. If you change things *too much* you might be favoring *velocity over stability* — and stability is very much a feature that your users and code consumers rely on. [Hyrum's law](https://www.hyrumslaw.com/) guarantees that with sufficient users and time, even your *bugs* will be relied on, and people will get upset if you fix them.\n\nThat said, overall, I find Optimizing for Change a net win in my programming, product, and system design decisions and am happy that I've boiled it down to four principles: Plan for Common Changes, Use Simple Values, Minimize Edit Distance, and Catch Errors Early!\n\n## Related reads\n\n- [Pre-emptive Pluralization is Probably Not Evil](https://www.swyx.io/preemptive-pluralization/)\n- [7 Lessons to Outlive React](https://twyx.ck.page/posts/swyx-io-7-lessons-to-outlive-react)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/how-to-optimize-for-change-a2n","devToReactions":42,"devToReadingTime":9,"devToPublishedAt":"2021-05-20T00:16:31.290Z","devToViewsCount":2230,"title":"How To Optimize for Change","published":true,"description":"Lessons from React, GraphQL, and Rich Hickey on how to design software that doesn't implode the first time requirements change.","tags":"Learnings, APIDesign, Tech","slug":"optimize-for-change","canonical_url":"https://www.freecodecamp.org/news/how-to-optimize-for-change-software-development/","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n1078j8opalnrzuu8p4u.png"},"title":"How To Optimize for Change","description":"Lessons from React, GraphQL, and Rich Hickey on how to design software that doesn't implode the first time requirements change. ","category":"note","tags":["learnings","apidesign","tech"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n1078j8opalnrzuu8p4u.png","canonical":"https://www.freecodecamp.org/news/how-to-optimize-for-change-software-development/","slug":"optimize-for-change","date":"2021-05-20T00:16:31.290Z","readingTime":"9 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/282","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/282/comments","title":"How To Optimize for Change","created_at":"2022-01-18T00:09:40Z","updated_at":"2022-06-18T17:47:43Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/282/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n*Listen to [audio version](https://swyx.transistor.fm/episodes/why-creator-clones-fail)*\n\n## TL;DR\n\nIncumbents fail to clone creator startups because:\n\n- You need big creators to adopt them... \n- ...but your **algorithm punishes change**\n- You can't support it on all clients...\n- ...and you can't make a new client for it\n- Clones need original content...\n- ...but clones are expendable\n\n## Context\n\nThere's a lot of cloning going on in the creator economy. Twitter cloning Clubhouse, Facebook cloning Clubhouse, YouTube cloning Patreon, YouTube cloning TikTok, Instagram cloning SnapChat, on and on. Every time a new clone is announced, naysayers love proclaiming the imminent doom of the challenger.\n\nThey are sometimes right. But usually wrong. \n\nI'd love to explore why.\n\nI love collecting examples of **the Innovator's Dilemma**, which was [coined by Clayton Christensen](https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma). The Innovator's Dilemma demonstrates how successful, outstanding companies can **do everything right**, and *still* lose their market leadership, or even fail as new unexpected competitors rise and take over the market. \n\nPart of this thesis is when the incumbent company despite better distribution, resources, people, whatever... is **constitutionally unable** to clone the small startup. \n\nThis is known as **counter positioning**, as popularized by Hamilton Helmer in [the 7 Powers](https://www.sachinrekhi.com/7-powers-hamilton-helmer). And you can hear it 30 minutes into this MKBHD podcast talking about the failure of YouTube Shorts:\n\n{% youtube Jl2ciIU4Qm4 %}\n\n## You need big creators to adopt them... but your algorithm punishes change\n\n> Marques: \"The TikTok algorithm is something special. It just surfaces things you want to see. It's really good. So they have that to compete again.\"\n> \n> Andrew: \"People might wonder why we made a podcast video channel and a podcast clips channel... the theory behind it is that if you have long form content and you have shorter clips, the watched overall watch time on the channel is going to be all over the place.\n>\n> Because if you have. 30 minutes of watch time on the long one and six minutes of watch time on the short one, it gets confused and has a hard time serving those videos. Yeah. So that's why we separate them.\n>\n> Now bring it back to YouTube Shorts. Imagine being a channel like us, that creates generally 10 to 15 minute videos. Now putting a bunch of 60 second clips on where the watch time is 60 seconds. How is that going to affect our 15 minute video?\"\n\nThe MKBHD channel still doesn't use the YouTube Premiere feature (despite it requiring no change in format). \n\nWhy? Because when they tested it, their premiered video \"literally had the worst rating out of our last 10 videos, with like half the views of number 9. It was pretty bad.\"\n\nIt turns out that Premiere views don't count towards overall video ranking. **YouTube screwed up** and creators found that out to their cost. \n\nYou only need to be algo-burned a couple times before you just decide to *never* deviate from the success formula.\n\nSo what if you make a separate channel?\n\n> Andrew: \"I would consider that a fail for YouTube's marketing in the sense that they're hoping big creators bring this to their main audience, but the minute you switch it to another audience, you're going to lose a giant portion of your subscribers\"\n\n## You need big creators to adopt them... but they have different formats\n\n\nAndrew: \"Not to mention that they're vertical, which we would never, ever, ever put on the channel.... [Most people] use YouTube on desktop, because it was originally built on desktop.\n\nIt became mobile. And even when you're using mobile, you're almost almost turning to landscape, whereas. Tick-tock works well because it's only supposed to be on a phone... YouTube is not quite that. It's becoming good at it, but it's still always has its heart and soul in the desktop version of it. And that's why this feature just feels a little. Off.\"\n\n## You can't support it on all clients... and you can't make a new client for it\n\nEstablished apps have a number of clients across web, mobile, and tablet, whereas startups can often just focus on one thing. Twitter Spaces, Twitter's Clubhouse clone, is still not available on iPad or web, despite being on iPhone and Android.\n\n> Andrew: \"I tried to look at Shorts on my desktop and I literally couldn't.\"\n>\n> Marques: \"Oh, you won't find that on the desktop, but you will find that on your phone, which is where they're competing with TikTok\"\n\nSo what if we just made a different standalone clone to tackle it head on?\n\n> Marques: \"I think if they wanted to feel less 'off', they would have made it a separate app, like a YouTube shorts app. So then you go vertical with just that work bad. Cause nobody's opening that app.\"\n\n## Clones need original content... but clones are expendable\n\nThis is particularly true when dealing with any significant format change - going from async to live, long from to short form, or landscape to portrait. And it's likely that startups break through *because* they figured out how to make a new format work.\n\n> MKBHD: \"YouTube knows that it needs YouTube shorts creators instead of just people uploading to Tik Tok, and then copying that file and also putting it on shorts.\"\n>\n> Andrew: \"That's literally all Reels is. All of Reels has the TikTok watermark and the name on it. People are just using Reels to find more people to go follow on TikTok.\"\n\nSo you want to encourage creators to invest in your clone in order to make it successful... but what if you yourself don't have unlimited patience or budget to invest in it?\n\nThis may be a [particuarly Google](https://killedbygoogle.com/) problem, but the truth is that no clone at any incumbent is strategically important. People aren't going to fight tooth and nail for survival because their \"survival\" is *never* really at risk.\n\nWhatever the reason — once you have a perception that you *could* shut down the clone, it becomes a self-fulfilling prophecy.\n\nMKBHD: \n\n> \"The hesitation by a lot of YouTubers to dive into Shorts is really interesting. I think a lot of the longer-term creators like me have a bit of an aversion to YouTube releasing new untested unproven features because... they could possibly get killed in six months and you will have just poured a bunch of resources and pivoted your channel down a path that ends up being a dead end.\"","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/why-creator-clones-fail-5c90","devToReactions":11,"devToReadingTime":5,"devToPublishedAt":"2021-05-18T02:39:42.867Z","devToViewsCount":316,"title":"Why Creator Clones Fail","published":true,"description":"The Innovator's Dilemma according to MKBHD, applied to YouTube's attempt to clone TikTok","tags":"Strategy, Creators, YouTube","slug":"clones-fail","canonical_url":"https://www.swyx.io/clones-fail"},"title":"Why Creator Clones Fail","description":"The Innovator's Dilemma according to MKBHD, applied to YouTube's attempt to clone TikTok ","category":"note","tags":["strategy","creators","youtube"],"canonical":"https://www.swyx.io/clones-fail","slug":"clones-fail","date":"2021-05-18T02:39:42.867Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/283","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/283/comments","title":"Why Creator Clones Fail","created_at":"2022-01-18T00:09:42Z","updated_at":"2022-06-18T17:47:43Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/283/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n[Link to PDF version](https://www.temporal.io/case-studies/Revolutionizing_Audio_with_Descript_and_Temporal.pdf)\n\n_This case study is based on an interview with Nicolas Gere-lamaysouette, engineer on Descript's audio transcription service. And - yes - we used Descript to transcribe the Descript interview!_\n\n## Problem\n\nDescript offers a revolutionary editing experience enabling users to modify spoken language in audio and video as if it’s written in a Google Doc. The foundation of Descript is transcription, which is achieved using a blend of proprietary AI algorithms. Synthetically generating a speaker's voice, deleting filler words and producing shareable assets are all made possible by Descript's proprietary transcription process.\n\nNo transcription, no Descript. Therefore, this service needs to be fast and reliable. Regardless of whether you are transcribing a 5 minute clip or a 3 hour Clubhouse conversation.\n\nWhen a user hits “transcribe”, Descript fires off an asynchronous, multistage and parallelized process that involves re-encoding audio, chunk-splitting, external API calls, merging results that may potentially arrive out of order, and verifying their alignment.\n\nUntil recently, this complex multistage task was handled via a patchwork of handwritten scripts and queues built with Node.js, RabbitMQ, and PostgreSQL. Since application state was distributed across various queues and databases, it was hard to test end to end logic. This quickly resulted in Descript encountering production issues that were nearly impossible to debug. There were lots of production incidents, and when they happened it was extremely hard to understand which part of the pipeline was stuck.\n\n> \"We had one incident every week just on the transcription workflow because it was too complicated to maintain... You can test each worker separately, but it was impossible to test the logic for every new feature end to end, so **we were afraid of doing any changes in that code path**.\"\n\n\n## To code or not to code\n\nThis homegrown system was sufficient to get going, but as Descript scaled up, they quickly realized that they wanted an orchestration engine built for this job. The most important features they needed were **testing, debugging, monitoring, and scalability**.\n\nThe team evaluated a number of workflow orchestration tools, including [Argo Workflows](https://argoproj.github.io/projects/argo/). However they soon realized that they strongly preferred the \"Workflow-as-Code\" approach of Temporal. Descript wanted to write, test, deploy and version control workflows with the exact same languages and tools used in the rest of their stack. This ability to model complex dependencies and error handling as idiomatic Go code was a better fit than simple JSON/YAML DSL's, particularly for local debugging and production monitoring. They also had scalability and latency concerns with Argo, because it was designed for CI/CD workloads so that each activity requires starting up a Kubernetes pod. Descript's data pipeline needs would involve spinning up thousands of pods, making that a nonstarter.\n\n> \"It was a game changing revelation - **Temporal gave us the ability to test our workflows with unit tests**, basically just writing code instead of writing JSON or YAML, which are completely untestable.\"\n\n## Migrating to Temporal\n\nThe migration process was relatively simple. Transcription is a self contained service that doesn't rely on Descript's core databases. So the process was to create a new workflow and begin progressively migrating workloads over using feature flags. The end results of the pipeline were checked via a single table, making it easy to effectively port over by effectively switching from handwritten queues to Temporal task queues.\n\nEven though the migration was prototyped with a self hosted cluster of Temporal (using our [Kubernetes helm chart](https://github.com/temporalio/helm-charts)), they decided to sign up for Temporal Cloud as an early design partner. As a small startup, they didn't want to manage Temporal themselves.\n\"We migrated progressively using feature flags, and verified performance as we went, but we had confidence in the Temporal team so we didn't stress about load testing.\"\n\n## Looking Back\n\nTemporal has helped Descript solve fundamental reliability issues with its core transcription loop. The frequency of production incidents has declined from once-a-week to virtually zero. Nicolas attributes this success to the ability to test everything with unit tests as well as normal end-to-end testing on a staging environment.\n\nTesting is important, but Temporal opened up more opportunities since migration:\n\n- **Orchestration of multiple Workflows**: you can flexibly **reuse a workflow** once it is written, allowing the transcription workflow to be easily composed with other APIs. This helped Descript develop a major transcription correction feature much more quickly than with the previous architecture.\n- **Specialized Compute for Machine Learning**: Some parts of the transcription process use Python components that generate CUDA instructions - these must be run on workers with GPUs, and then reliably merged back into a general data processing workflow. Temporal's ability to route activities to multiple [Task Queues](https://docs.temporal.io/docs/concepts/task-queues/) made this straightforward.\n- **Session Routing for Stateful Execution**: You can finetune the execution of sequential activities on the same worker, using [Go SDK Sessions](https://docs.temporal.io/docs/go/sessions/), which Descript will need (but doesn't yet use).\n\nAn unexpected advantage that Descript is enjoying is better observability of workflows, which **helps improve customer service** even when Descript is not at fault.\n\n> \"When a customer reports an issue, it's very easy for us to just put the Workflow ID into the Temporal Web UI to see what is going on... I can see a summary of workflow status and access the full event history for audit needs. \"\n\n\n## What's Next?\n\nNow that Descript has had production experience running with Temporal Cloud, more opportunities are presenting themselves in a diverse array of use cases, including:\n\n- billing and subscription management\n- other CPU intensive backend workloads\n- the ([fan favorite](https://twitter.com/swyx/status/1370415731372826628)) Identify Speaker feature\n\nOther teams at Descript are waiting for our NodeJS client to explore migrating other forms of workloads.\n\n> \"Everyone in the company can see more and more use cases where Temporal would be useful.\"\n\n\n## Working with Temporal\n\n\nDescript has found Temporal’s Slack very helpful. It can be difficult to adopt a core infrastructure technology like Temporal without help from the community and Temporal's core developers. It has also helped make the case internally to see other well regarded engineering teams ask similar questions and adopt alongside Descript.\n\n> \"The Temporal Community is great, the company is so helpful! Temporal is a complex piece of software and there are a lot of corner cases, so it is nice that the people who create Temporal are easy to reach to help us with our issues.\"\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/temporalio/revolutionizing-audio-with-descript-and-temporal-3dkp","devToReactions":5,"devToReadingTime":5,"devToPublishedAt":"2021-05-17T18:36:38.545Z","devToViewsCount":94,"title":"Revolutionizing Audio with Descript and Temporal","published":true,"description":"A case study I published for my work at Temporal","tags":"Temporal, golang, podcasts, machinelearning","slug":"temporal-descript-case-study","canonical_url":"https://docs.temporal.io/blog/descript-case-study","cover_image":"https://user-images.githubusercontent.com/6764957/116481376-a1adc900-a8b5-11eb-8ae6-326a0fe90b1c.png","disclosure":"This is a piece I published at Temporal - https://docs.temporal.io/blog/descript-case-study"},"title":"Revolutionizing Audio with Descript and Temporal","description":"A case study I published for my work at Temporal ","category":"note","tags":["temporal","golang","podcasts","machinelearning"],"image":"https://user-images.githubusercontent.com/6764957/116481376-a1adc900-a8b5-11eb-8ae6-326a0fe90b1c.png","canonical":"https://docs.temporal.io/blog/descript-case-study","slug":"temporal-descript-case-study","date":"2021-05-17T18:36:38.545Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/284","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/284/comments","title":"Revolutionizing Audio with Descript and Temporal","created_at":"2022-01-18T00:09:44Z","updated_at":"2022-06-18T17:47:43Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/284/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nToday I want to talk about a meme. This meme takes many forms, but it's latest iteration is the Midwit meme:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q52ca85320lzxly8xli0.png)\n\nYou could abstractly view this as a clever blend of the [Haha Go Brrr](https://knowyourmeme.com/memes/money-printer-go-brrr) meme with [Horseshoe theory](https://en.wikipedia.org/wiki/Horseshoe_theory), but that'd be an incredibly \"100 IQ\" way to overanalyze a meme. At the end of the day, it is just an incredibly flexible meme that has somehow outgrown its edgy, racist roots to be applied everywhere from finance to linguistics to biology.\n\nIt can be distilled to the simple observation that total beginners and total experts can often share a love of simplicity, in a way that absolutely *infuriates* the [book smart](https://twitter.com/swyx/status/1388584008494239750) intermediates.\n\nYou feel it when a self described \"15 IQ\" electrician [makes $3.4 million](https://twitter.com/AK_Bull_Worm/status/1391957751933267969) on knockoff dog themed cryptocurrency, in perfect sympatico with the [150 IQ Elon Musk](https://twitter.com/elonmusk/status/1391523807148527620).\n\nI felt it when Jan Hatzius, the longtime Chief Economist at Goldman Sachs, talks up his \"[above-consensus GDP growth projections](https://www.goldmansachs.com/insights/podcasts/episodes/01-08-2021-jan-hatzius.html)\" like it means a damn, whereas degenerate gamblers and PhD quants alike just remind each other to \"buy low, sell high\".\n\nI get the same feeling when senior software engineers stop at \"[it depends](https://twitter.com/swyx/status/1202202923385536513?s=20)\" and pat themselves on the back for a job well done. A generation earlier you could find the same middle-of-the-curve engineers worshipping \"Uncle Bob\" (the jury is out on the \"IQ\" of the median remnant Clean Coder). Now the same midwit engineers (of which I am one) wage toxic tribal wars over frameworks, while Pieter Levels [makes >$1m a year with a single PHP file](https://twitter.com/levelsio/status/1381709793769979906) and [just learned git](https://twitter.com/levelsio/status/1327451757975375874).\n\nYou could keep going:\n\n- Piet Mondrian's journey from learning to draw in primary school to imitating [the impressionist masters at age 27](https://www.piet-mondrian.org/view-of-winterswijk-1899.jsp) to the famous [Mondrian squares at age 58](https://en.wikipedia.org/wiki/File:Piet_Mondriaan,_1930_-_Mondrian_Composition_II_in_Red,_Blue,_and_Yellow.jpg) he could have drawn as a primary schooler\n- The Silicon Valley nerds drinking Soylent and wearing $400 health rings, compared to total meatheads and ultrafit athletes who simply \"Eat Less Move More\"\n- The Fortune Cookie Twitter accounts that can tweet shit like \"[Pain is a fact. Suffering is a choice](https://twitter.com/naval/status/1389064024378122241).\" and get 100x the engagement of tryhard social media managers who spend hours strategizing over the biweekly tweetstorm with coerced retweets from coworkers.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qxsvr40em2vy284f9kuq.jpg)\n\nAfter you see enough of these, you have to wonder:\n\nCan we just skip the complexity? From simple on this side of the curve, straight to simple on the other side? Bypass the complex phase like an [Einstein-Rosen bridge](https://phys.org/news/2015-12-wormholes.html)? Aren't they just the same thing?\n\nMy answer, after a lot of admittedly 100 IQ introspection, is: No. \n\nYou don’t get to [80/20 hack](https://www.swyx.io/8020/) your way to enlightenment by imitating it.\n\nYou've probably heard this story before: \n\n> - A businessman finds a fisherman, who is living an idyllic, peaceful life by the sea. \n> - He laughs and tells the fisherman how to get rich instead. \n> - The fisherman asks him what he will do after he gets rich. \n> - He replies that he would retire to an idyllic, peaceful life by the sea.\n\nThere's supposed to be a deep life lesson in there, but it's always felt insincere to me. \n\nTo me it is better to have reached the heights of a career, or suffered an epic defeat, even if I do end up in the same place as everyone else in the end.\n\nTo me simplicity is made more beautiful when understood through a long personal struggle with complexity. When I can dance with it, having turned a mighty nemesis into an old friend, and teach others to do the same.\n\nBetter to have loved *and* lost, than never to have loved at all.\n\nAfter all, we share the same destination. The ultimate horseshoe is biblical in nature: dust shall inevitably return to dust. What is life, then, but our unique, 100 IQ, wandering journey through vicissitudes? \n\n> *“I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.” - Oliver Wendell Holmes Jr.*\n\n> Thanks to [David Golden](http://xdg.me/) for reviewing an early draft of this — his take: \n>\n> - \"My (possibly mid-curve) view is that left-curve people love simplicity, but their success with simplicity is luck driven, which is infuriating, driving mid-curve people to try to systematize away from luck.\n> - Whereas right curve have either learned to succeed with simplicity without luck, or have learned that luck is what matters so don't overcomplicate. ¯\\_(ツ)_/¯\n> - And thus your point about the journey is that you can't get to systematic success with simplicity without the mid-curve experience.\"","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/don-t-rush-to-simplicity-on-the-other-side-of-complexity-105n","devToReactions":31,"devToReadingTime":4,"devToPublishedAt":"2021-05-15T13:23:31.682Z","devToViewsCount":874,"title":"Don't Rush to Simplicity","published":true,"description":"Expertise in a subject often goes in a bell curve of simple → complex → simple. Can we skip the complexity?","tags":"Reflections, Complexity, Memes","slug":"simplicity-rush","canonical_url":"https://www.swyx.io/simplicity-rush","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q52ca85320lzxly8xli0.png"},"title":"Don't Rush to Simplicity","description":"Expertise in a subject often goes in a bell curve of simple → complex → simple. Can we skip the complexity? ","category":"note","tags":["reflections","complexity","memes"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q52ca85320lzxly8xli0.png","canonical":"https://www.swyx.io/simplicity-rush","slug":"simplicity-rush","date":"2021-05-15T13:23:31.682Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/285","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/285/comments","title":"Don't Rush to Simplicity","created_at":"2022-01-18T00:09:46Z","updated_at":"2022-05-28T13:54:55Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/285/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nA while ago, Paul Graham [made](https://twitter.com/paulg/status/1314948607662010374) a big call:\n\n> \"I'm going to risk calling it. The feeling of deja vu is too strong. Stripe is the next Google.\"\n\nAt the time, Stripe had last raised at a [$36 billion valuation](https://www.cnbc.com/2020/04/16/stripe-raises-600-million-funding-round-at-36-billion-valuation.html) - a year later, it's now valued at [$95 billion](https://www.cnbc.com/2021/03/14/stripe-valued-at-95-billion-in-600-million-funding-round.html). \n\nThis would be a lifetime peak valuation for most exited startups (Uber changed transportation and Airbnb changed hotels, and both are currently worth $80b), so what Paul was really doing here is making an active prediction that the ceiling for Stripe is *much higher*. Google is valued at $1500 billion at time of writing — and Paul thinks they will \"probably\" be bigger (\"[There is more money in money than search](https://twitter.com/paulg/status/1314951673203359756?s=20)\").\n\nIt isn't a given by any means (though Paul has had a [decent streak in calls](https://twitter.com/paulg/status/1391865950769659907) lately). Stripe does face competition in established payment processors, as well as Adyen, though momentum [appears weak](https://twitter.com/GergelyOrosz/status/1352188920025522177). You could handicap its odds of being \"the next Google\" at, say, a fairly conservative 50%.\n\nThat means **the expected return of betting on Stripe for the next decade is ~10x** (it's more like 8x, but who's counting). You don't get this fat a pitch in this league.\n\nSo given that you have a [definite optimist](https://www.anthonyjcampbell.com/blog/optimism) approach to the future, what do you do with this information?\n\nI think about this question a lot. The simple first order answer, of course, is to join Stripe. Most engineers will be millionaires 10x-ing on option grants.\n\nBut that may not even be the best use of time for you. Stripe aims to be a [platform of platforms](https://stratechery.com/2020/stripe-platform-of-platforms/). The [Mullenweg-Gates Line](https://twitter.com/swyx/status/1360729115372920832) notes that effective platforms capture only about 5% of the total value they create. There's approximately $14 trillion ((EV of 800b - Current Valuation 100b)/5%) in value of platform to be built atop Stripe.\n\nStripe currently lists 10 products on its home page, from the classic Payments and Billing to the newer Atlas and Climate. The vast majority of developers have only a narrow view of Stripe's world. I would explore ways to explore and exploit the capabilities opened up by Stripe's newer products — in particular the recently launched [Capital](https://stripe.com/capital) and [Treasury](https://stripe.com/treasury) services.\n\nYou could also become a domain expert in *optimizing for Stripe*. Platforms tend to reward this behavior greatly. There is no Stripe podcast. No Stripe newsletter. No \"Stripe Enterprise Optimization\" cottage industry. The room for the \"[Danny Sullivan](https://en.wikipedia.org/wiki/Danny_Sullivan_(technologist)) of Stripe\" exists.\n\nThere's also the challenger status - figure out what Stripe is philosophically prevented from doing, and [counter-position](https://jppandith.substack.com/p/33-counter-positioning-3rd-of-the) in that exact thing. [DuckDuckGo is growing >50% a year](https://duckduckgo.com/traffic) being the credible anti-Google. The obvious angle here is that Stripe is very traditional-economy oriented (with [attendant frustrations](https://news.ycombinator.com/item?id=24291790)): what is the decentralized, permissionless, equivalent of Stripe? The reason I don't love this as much is it feels like too much of a \"bank shot\", but surely there's a few billion of value in here for the patient and ideologically committed.\n\nWhat else?","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/what-if-stripe-was-the-next-google-g9d","devToReactions":20,"devToReadingTime":3,"devToPublishedAt":"2021-05-14T14:54:25.087Z","devToViewsCount":781,"title":"What if Stripe is the next Google?","published":true,"description":"Working out a thought exercise by Paul Graham.","tags":"Reflections","slug":"stripe-next-google","canonical_url":"https://www.swyx.io/stripe-next-google","disclosure":"These are just off the cuff thoughts; I may return to flesh these out over a period of years."},"title":"What if Stripe is the next Google?","description":"Working out a thought exercise by Paul Graham. ","category":"note","tags":["reflections"],"canonical":"https://www.swyx.io/stripe-next-google","slug":"stripe-next-google","date":"2021-05-14T14:54:25.087Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/286","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/286/comments","title":"What if Stripe is the next Google?","created_at":"2022-01-18T00:09:48Z","updated_at":"2022-06-18T17:47:44Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/286/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"How to Market Yourself (without Being a Celebrity)","slug":"market-yourself-pod","tags":["LIP"],"venues":"DataTalksClub","date":"2021-05-14T00:00:00.000Z","url":"https://datatalks.club/podcast/s03e07-market-yourself.html","description":"Discussing personal branding and developer marketing with LearnInPublic.","category":"podcast"},{"title":"How to Market Yourself (without Being a Celebrity)","slug":"market-yourself","categories":["Marketing"],"description":"Discussing personal branding and developer marketing with LearnInPublic.","instances":[{"venue":"DataTalksClub","date":"2021-05-14","tweet":"https://twitter.com/Al_Grigor/status/1393219745088946178?s=20","url":"https://datatalks.club/podcast/s03e07-market-yourself.html","video":"https://www.youtube.com/watch?v=tkBCPqWKCL8"},{"venue":"ReactEurope","date":"2020-04-20","url":"https://portal.gitnation.org/contents/shawn-swyx-wangs-career-tips-knowing-how-to-market-yourself-authentically-is-not-scammy","video":"https://www.youtube.com/watch?v=bcca0VCJe9Q&list=PLCC436JpVnK31LZG2cNINhlEQ1KTm39BR&index=15"}],"category":"talk","date":"2021-05-14T00:00:00.000Z"},{"title":"E2E Encryption Keyservers with Ashoat Tevosyan","slug":"comm-with-ashoat","categories":["Tech"],"description":"A recording of one of the most interesting angel investing conversations I've had this year.","instances":[{"venue":"Swyx YouTube","date":"2021-05-09","video":"https://www.youtube.com/watch?v=lWCOruAWpW4"}],"category":"talk","date":"2021-05-09T00:00:00.000Z"},{"type":"blog","content":"\nThe [Pareto Principle](https://en.wikipedia.org/wiki/Pareto_principle) is making you lazy.\n\nLet me be more precise: The [Pareto distribution](https://en.wikipedia.org/wiki/Pareto_distribution) is a useful model of power law effects in real life. But people are using it poorly, primarily as an *excuse* to be lazy.\n\nThis thought was triggered by [Shaan Puri's newsletter](https://www.shaanpuri.com/) featuring [Steph Smith](https://stephsmith.io/) this week (both of whom I greatly respect, this is a jumping off point, not a dunk):\n\n{% twitter 1386071726279127041 %}\n\nYou hear 80/20 rules [a lot](https://twitter.com/search?q=80%2F20%20filter%3Afollows&src=typed_query) in [premium mediocre](https://www.ribbonfarm.com/2017/08/17/the-premium-mediocre-life-of-maya-millennial/) circles. If you want to signal that you are smarter than the average 80/20 bear, you might refer to the \"[high order bit](https://twitter.com/search?q=%22high%20order%20bit%22&src=typed_query)\" instead. Same shit, different status signal.\n\nThe spirit of the idea is sound. It's great for 280 character tweets and 5 minute soundbites. But idk if it's good for people who finish things. At best, I don't think it's sufficient for execution. At worst, it's just intellectually dishonest.\n\nLook at reactions like [this](https://twitter.com/jasonleowsg/status/1386209784626434050?s=20): \n\n> \"Love this [80/20] framing! Great way to remove the fluff and get to the core\".\n\nI'm sorry but the remaining 80% is not \"the fluff\":\n\n- People forget that *the devil is in the details*. The first 20% everyone knows to say on Twitter. The remaining 80% is the ugly, nasty, hacky, unglamorous shit nobody talks about unless you've got time to sweat the details (*unless you've already moved on to the next 80/20?*). \n - The more popular the 80/20 meme becomes, the less competition you will have as someone who knows how to take things to the finish line.\n- People forget that causal attribution is subject to [narrative fallacy](https://fs.blog/2016/04/narrative-fallacy/). Ask a successful person what their 80/20 was and they'll confidently tell you in hindsight. The truth is at the time they had 4 other bets also going on that just didn't work out. \n - The popular saying in medical school is that \"[50% of what you learn will be wrong — we just don't know which 50%](https://blogs.bmj.com/pmj/2014/05/30/50-of-what-you-are-taught-is-wrong/)\". And that is in goddamn *medical science* with double blind randomized clinical trials. We don't have 1% of that rigor in popular anecdata which you base your 80/20 inferences on.\n- People forget that distributions aren't always Pareto. When you assert that \"an 80/20\" exists, you are asserting useful [dimensionality reduction](https://en.wikipedia.org/wiki/Dimensionality_reduction). Sometimes complex, or even linear, things just do not have an \"80/20\". \n - The [FAA's Parachute Rigger Handbook](https://www.faa.gov/regulations_policies/handbooks_manuals/aviation/media/prh_change1.pdf) has 350 pages of densely packed advice. Please **do not try to 80/20 your parachute packing**.\n\nI'm reminded of that classic movie Click, where Adam Sandler finds a magic remote that lets him \"80/20 his life\":\n\n{% youtube 5fjha1FnlBU %}\n\nDon't spend your life spraying 20% effort all over the place, hoping for 80% results, only to look back and wonder why you never hit 100% on anything.\n\n> Edit: The always excellent David Golden wrote a [wonderful response to this piece](https://xdg.me/80-20/) highlighting the cases where 80/20 is actually very justified, and I agree!\n\n> This topic is loosely related to Epistemology, which I've [written about briefly](https://www.swyx.io/first-principles-approach/#epistemology).","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/80-20-is-the-new-half-ass-3kg","devToReactions":20,"devToReadingTime":3,"devToPublishedAt":"2021-04-28T19:00:42.842Z","devToViewsCount":643,"title":"80/20 is the new Half-Ass","published":true,"description":"Don't spend your life spraying 20% effort all over the place, hoping for 80% results, only to look back and wonder why you never hit 100% on anything.","tags":"Reflections, Advice","slug":8020,"canonical_url":"https://www.swyx.io/8020","cover_image":"https://media.tenor.com/images/57667e0083dca419064604482f597126/tenor.png","disclosure":"This is just a quick rant. I'm mainly trying to remind people of the value of execution and the small details, not dunking on anyone in particular."},"title":"80/20 is the new Half-Ass","description":"Don't spend your life spraying 20% effort all over the place, hoping for 80% results, only to look back and wonder why you never hit 100% on anything. ","category":"note","tags":["reflections","advice"],"image":"https://media.tenor.com/images/57667e0083dca419064604482f597126/tenor.png","canonical":"https://www.swyx.io/8020","slug":"8020","date":"2021-04-28T19:00:42.842Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/287","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/287/comments","title":"80/20 is the new Half-Ass","created_at":"2022-01-18T00:09:50Z","updated_at":"2022-06-18T17:47:44Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/287/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nThis is a direct answer to [this SvelteKit issue](https://github.com/sveltejs/kit/issues/942). I see a lot of JS developers struggle with using Netlify Forms, so I want to help.\r\n\r\n## 9 Min Video Walkthru\r\n\r\nThis is the video version of the instructions below.\r\n\r\n{% youtube cj3f2Xth5Mk %}\r\n\r\n## Context\r\n\r\nNetlify Forms were designed primarily for traditional static site generators like Hugo and Jekyll, using HTML crawling to initialize forms. The idea is like this:\r\n\r\n- Your static site is a folder of `.html` files\r\n- Netlify crawls all of them looking for `

` tags (or ``, because some projects like Create React App or Gatsby helpfully delete unrecognized attributes for you, what fun)\r\n- For each detected tag, it sets up a dedicated \"form\" which is pretty much an append-only schemaless document store of all submissions.\r\n- These are received via a special endpoint set up at the domain root (`/`) looking for `POST` requests with `\"Content-Type\": \"application/x-www-form-urlencoded\"` (or with `multipart` for file uploads)\r\n- **Crucially: If no forms are detected, this feature doesn't work**.\r\n\r\nMany JS framework users struggle to use them because:\r\n\r\n- the form needs to exist in HTML at build time but JS frameworks render them at runtime. \r\n- SvelteKit introduces another wrinkle in that you have to decide whether to prerender the form. \r\n- JS framework users also often want to use AJAX to offer a better UX. So again you have to do things slightly differently than with pure HTML forms. \r\n\r\n### Optional Features You May Want\r\n\r\nWhat I cover here is just the simplest solution to help people solve the immediate pain point. You can also:\r\n\r\n- leave your \"helper form\" hidden at build time and render the real form clientside\r\n- upload files with Netlify Forms (underrated)\r\n- do progressive enhancement of behavior from HTML to JS. \r\n- For spam prevention, there is support for [honeypot and recaptcha](https://docs.netlify.com/forms/spam-filters/). See [demo apps](https://github.com/sw-yx/gatsby-netlify-form-example-v2) for setup instructions.\r\n- You can also [trigger Netlify functions](https://docs.netlify.com/functions/trigger-on-events/) on successful submissions to do arbitrary logic (like notify you on Slack or create an account)\r\n\r\nI'll come back and add that to this blogpost if I ever get the time. Pls [yell at me](https://twitter.com/swyx/status/1386447885936390147) to indicate interest or i wont do it.\r\n\r\n## SvelteKit Setup Instructions\r\n\r\n### Project Init\r\n\r\nGo through the standard SvelteKit setup:\r\n\r\n```bash\r\nnpm init svelte@next myapp \r\ncd myapp\r\nnpm i\r\n```\r\n\r\nYou can set up GitHub/Netlify either thru CLI or UI - I found some [bugs](https://github.com/netlify/cli/issues/2229) with Netlify CLI when I tried this but it might be fixed by the time you read this:\r\n\r\n```bash\r\n# optional: set up git/github/netlify deploy via CLI\r\ngit init && git add . && git commit -m \"hi\"\r\ngh repo create # have the github cli installed\r\nntl init # netlify cli\r\n```\r\n\r\nor you can just use the UIs for each service\r\n\r\n### Add SvelteKit Netlify Adapter\r\n\r\n```bash\r\nnpm i -D @sveltejs/adapter-netlify@next \r\n```\r\n\r\nthen add it to `svelte.config.cjs`:\r\n\r\n```js\r\nconst adapter = require('@sveltejs/adapter-netlify');\r\nmodule.exports = {\r\n\tkit: {\r\n\t\tadapter: adapter(), // currently the adapter does not take any options\r\n\t\ttarget: '#svelte',\r\n\t\tprerender: {\r\n\t\t\tcrawl: true,\r\n\t\t\tenabled: true,\r\n\t\t\tforce: true,\r\n\t\t\tpages: ['*'],\r\n\t\t},\r\n\t}\r\n};\r\n```\r\n\r\nthen add a `netlify.toml` file at project root:\r\n\r\n```\r\n[build]\r\n command = \"npm run build\"\r\n publish = \"build/\"\r\n functions = \"functions/\"\r\n```\r\n\r\nYou can see these instructions in [my netlify adapter docs](https://github.com/sveltejs/kit/pull/1217).\r\n\r\n### Add the Prerendered Form\r\n\r\nHead to `/src/routes/index.svelte` and add the form accordingly.\r\n\r\n```html\r\n\r\n\r\n\r\n

Welcome to SvelteKit

\r\n

Visit kit.svelte.dev to read the documentation

\r\n\r\n\r\n \r\n \r\n

\r\n Your Name: \r\n

\r\n

\r\n Your Email: \r\n

\r\n

\r\n Message: </label>\r\n </p>\r\n <p>\r\n <button type=\"submit\">Send</button>\r\n </p>\r\n</form>\r\n```\r\n\r\n### Deploy\r\n\r\nNow you should be able to push to GitHub and have it build and render the form successfully.\r\n\r\nExamples:\r\n\r\n- https://github.com/sw-yx/sveltekitnetlifyforms\r\n- https://sveltekitnetlifyforms.netlify.app/\r\n\r\n## Screenshots\r\n\r\n![image](https://user-images.githubusercontent.com/6764957/116011598-83975d00-a658-11eb-8f1e-9140698fd22c.png)\r\n\r\n\r\n![image](https://user-images.githubusercontent.com/6764957/116011546-27343d80-a658-11eb-9a3e-862cbe61ea08.png)\r\n\r\n\r\n![image](https://user-images.githubusercontent.com/6764957/116011560-3dda9480-a658-11eb-8954-fd8cf7160ae2.png)\r\n\r\n\r\n![image](https://user-images.githubusercontent.com/6764957/116011573-564aaf00-a658-11eb-8f94-56c5ec824014.png)\r\n\r\n\r\n## Graveyard: AJAX Example\r\n\r\n> Warning: this is untested code - I ran out of time but dumping it here anyway in case it helps someone\r\n\r\nIf you want an AJAX experience for your form here is some untested code I was working on that may help you get going:\r\n\r\n```html\r\n<script context=\"module\">\r\n export const prerender = true;\r\n</script>\r\n\r\n<script>\r\n let isSubmitting = false;\r\n\r\n const handleSubmit = (e) => {\r\n let myForm = document.getElementById(\"test\");\r\n let formData = new FormData(myForm);\r\n isSubmitting = true;\r\n return fetch(\"/\", {\r\n method: \"POST\",\r\n headers: { \"Content-Type\": \"application/x-www-form-urlencoded\" },\r\n body: new URLSearchParams(formData).toString(),\r\n })\r\n .then(() => {\r\n console.log(\"Form successfully submitted\");\r\n isSubmitting = false;\r\n myForm.reset();\r\n })\r\n .catch((error) => {\r\n alert(error);\r\n isSubmitting = false;\r\n });\r\n };\r\n</script>\r\n\r\n<h1>Welcome to SvelteKit</h1>\r\n<p>\r\n Visit <a href=\"https://kit.svelte.dev\">kit.svelte.dev</a> to read the documentation\r\n</p>\r\n\r\n<form\r\n id=\"test\"\r\n name=\"test\"\r\n on:submit|preventDefault={handleSubmit}\r\n netlify\r\n netlify-honeypot=\"bot-field\"\r\n>\r\n <input type=\"hidden\" name=\"form-name\" value=\"test\" />\r\n <input type=\"text\" name=\"bot-field\" style=\"opacity: 0\" />\r\n <p>\r\n <label>Your Name: <input type=\"text\" name=\"name\" /></label>\r\n </p>\r\n <p>\r\n <label>Your Email: <input type=\"email\" name=\"email\" /></label>\r\n </p>\r\n <p>\r\n <label>Message: <textarea name=\"message\" /></label>\r\n </p>\r\n <p>\r\n {#if isSubmitting}\r\n <div>Submitting</div>\r\n {:else}\r\n <button type=\"submit\">Send</button>\r\n {/if}\r\n </p>\r\n</form>\r\n```\r\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/how-to-use-sveltekit-with-netlify-forms-5gmj","devToReactions":35,"devToReadingTime":4,"devToPublishedAt":"2021-04-25T22:28:24.272Z","devToViewsCount":1362,"title":"How to use SvelteKit with Netlify Forms","published":true,"description":"a simple tutorial","category":"tutorial","tags":"Svelte, Netlify","slug":"sveltekit-netlify-forms","cover_image":"https://user-images.githubusercontent.com/6764957/116011560-3dda9480-a658-11eb-8954-fd8cf7160ae2.png","canonical_url":"https://www.swyx.io/sveltekit-netlify-forms"},"title":"How to use SvelteKit with Netlify Forms","description":"a simple tutorial ","category":"tutorial","tags":["svelte","netlify"],"image":"https://user-images.githubusercontent.com/6764957/116011560-3dda9480-a658-11eb-8954-fd8cf7160ae2.png","canonical":"https://www.swyx.io/sveltekit-netlify-forms","slug":"sveltekit-netlify-forms","date":"2021-04-25T22:28:24.272Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/288","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/288/comments","title":"How to use SvelteKit with Netlify Forms","created_at":"2022-01-18T00:09:51Z","updated_at":"2024-03-31T02:34:14Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/288/reactions","total_count":6,"+1":1,"-1":0,"laugh":0,"hooray":2,"confused":0,"heart":3,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n\r\nI turn 35 today. Here are 35 principles I have accumulated and try to live by (you can [listen to the narrated version here](https://swyx.transistor.fm/episodes/35-principles-for-35-years)):\r\n\r\n1. **Life is too Short for Short Term Games**. We only have so many years for long term games to compound. \r\n \r\n{% twitter 1281424520100737025 %}\r\n\r\n2. **Writing is Stupendously High Leverage.** \r\n - It helps to organize my thoughts and learning (aka [Building My Second Brain](https://twitter.com/swyx/status/1245281982797373441?lang=en)). I win even if nobody reads me.\r\n - It enables me to share great ideas even while I sleep (as a [Friendcatcher](https://twitter.com/swyx/status/1224538408132993026?lang=en)). I am constantly shocked at the caliber of people that read my work and DM me their thoughts. There is absolutely no other way I would be on their radar.\r\n - Blogging helped me [sell $4k worth of an empty PDF](https://www.swyx.io/coding-career-launch/) on the day I decided to write my book because people trusted me. \r\n - It's led to multiple job opportunities from great companies (e.g. [Netlify](https://www.swyx.io/farewell-netlify/), [AWS](https://www.swyx.io/hello-aws/), [Temporal](https://gist.github.com/sw-yx/ff8a4f6757286444fa20b43f6b98b205#reconstituting-the-monolith)) that I would have otherwise struggled to be hired at.\r\n3. **Learn in Public**. Most of you know me for this one... ([read up if you're new round here, welcome!](https://www.swyx.io/learn-in-public/))\r\n4. **Good Enough is Better than Best**. In a world of infinite abundance, you can lose yourself constantly chasing the hottest new thing. [Satisfice rather than Maximize.](https://twitter.com/swyx/status/1221129594146840577) \r\n5. **Less is More**. Minimalism wins: [Subtracting is harder than Adding](https://twitter.com/patrickc/status/1380556517208825856). Quantity reduces perceived quality. Depth and whitespace stand out. (yes I realize the irony of this principle in a list of 35)\r\n6. **Create Clarity.** Simple Explanations of What, Why, and How are extremely underrated and extremely useful. This is also a core skill of all leaders. \r\n \r\n {% twitter 1382726094214758400 %}\r\n7. **Optimize for Change**. Optimizing for anything else tends to make systems **MORE** fragile, not less. If you learn only one [lesson from React and GraphQL](https://twitter.com/swyx/status/1383516418205835264), learn [How to Optimize for Change](https://www.swyx.io/optimize-for-change)\r\n8. **Seek First To Understand, Then To Be Understood.** Don't get defensive about your point of view or perception of reality - understand theirs first. Either you will learn something new or you'll understand how to better get your point across. [Hold multiple perspectives in your head](https://www.swyx.io/learn-in-private/#go-meta) and be able to summarize the best arguments of all major parties in a way that *THEY* agree with.\r\n9. **Praise in Public, Criticize in Private**. \r\n - As satisfying as it might be to dump on someone publicly, I need to remember how it makes them feel. \r\n - Everything is *not* awesome, and I despise fake positivity. But I can either help or make them feel bad about it and the former is more effective than the latter.\r\n - Exception for companies and people that are actively harming or misleading the vulnerable.\r\n10. **Build an Empathy Check Habit**. I can't take back an impulsive response that hurts someone. When I can't check with trusted friends, [I need to think before I tweet.](https://mobile.twitter.com/swyx/status/1344687793851699200)\r\n11. **People remember how you made them feel, before what you said**. [A good story has more power than a good argument.](https://twitter.com/swyx/status/1385352144195252224)\r\n12. **Treat Others How They Want To Be Treated**. The Golden Rule is -sadly- not good enough when your privilege is higher or expectations are lower than others'. Time for [The Platinum Rule](https://www.swyx.io/platinum-rule/).\r\n13. **Complete Truths are Not Welcome.** \r\n - Most people are more interested in...\r\n - being entertained\r\n - sharing outrage\r\n - feeling good about themselves\r\n - defending their reputation\r\n - ...than debating truth or improving themselves. \r\n - Trying to change them is ineffectual.\r\n - Let them be, and seek out like minds.\r\n14. **Organize IRL Events**. You can do a lot to create excitement and connection in a community simply by organizing dinners and meetups and conferences. [Svelte Society](https://twitter.com/svelteSociety/) started on a whim [exactly like this](https://twitter.com/swyx/status/1179261731304022017). Now there are thousands of members drawn to the Svelte community that wouldn't have before.\r\n15. **Don't offer unsolicited help.** Make Sure Help Is Wanted Before Offering It. Men - be especially wary about this when women are talking about their problems. Sometimes they just need support, not solutions. (But sometimes it really IS [about The Nail](https://twitter.com/swyx/status/1385353980021075968)...)\r\n16. **Ask For Help More**. People are happy to help and like you more when they have helped you. Don't worry about showing weakness; you are getting something far more valuable in return. [Use a Help Timeout](https://twitter.com/swyx/status/1378020519774019587).\r\n17. **Log Your Wins**. e.g. when you ship something big or small, or when someone says nice things about you. They can help when you are feeling emotionally down, or when writing a [brag document](https://jvns.ca/blog/brag-documents/). Help others celebrate their wins too. P.S. a **brag slack channel** can serve as an OLTP store of personal wins.\r\n18. **Don't End The Week With Nothing.** The reason you don't see any of my work prior to 2017 is because I thought it was sufficient to just work hard at my finance job. Now all of my intellectual output from my 20's - some of the best research and writing I have ever done - is locked up in some mailbox somewhere. Never again.\r\n \r\n {% twitter 1371227946136993792 %}\r\n19. **Pick Up What They Put Down.** Guarantee feedback by giving feedback. [https://www.swyx.io/puwtpd](https://www.swyx.io/puwtpd)\r\n20. **Speak Succinctly**. Stop speaking in trailing sentences and double-barreled questions. Set the general direction and shut up. If they're off-track, interject. This is preferable to preempting all conversation paths to show how smart you are.\r\n21. **Optimize for Retention, not Consumption**. We are the sum total of still-relevant knowledge we still remember, not the total of the volume of content we consume.\r\n22. **Illustrate Your Point**. Adding code samples or drawing 2x2's and system diagrams makes your idea much more effective. A picture *IS* worth a thousand words! [Even this shitty example](https://twitter.com/swyx/status/1249793388037025797) works, you can do better than me.\r\n23. **Separate Your Identity from Your Work.** You can learn a lot on the Internet for [the low, low price of $YOUR_EGO](https://kentcdodds.com/chats-with-kent-podcast/seasons/01/episodes/you-can-learn-a-lot-for-the-low-price-of-your-ego-with-shawn-wang).\r\n24. **Build Tools For Yourself**. This is a superpower and a sandbox all rolled in one that is guaranteed to make you happy.\r\n \r\n {% twitter 1342896023350304768 %}\r\n25. **Collect Questions**\r\n - Obsess on collecting good answers and you might be precise but irrelevant.\r\n - Obsess on collecting good questions and you will be approximately right.\r\n - My Work-in-Progress list of questions [here](https://github.com/sw-yx/brain/tree/master/R%20-%20Better%20Questions), but see also the [Reverse Interview repo](https://github.com/viraptor/reverse-interview) and Feynman's [12 Problems](https://medium.com/@SparksRemarks/my-12-favorite-problems-3088f90acea).\r\n26. **Systems > Goals**. \"You don't rise to the level of your goals. You fall to the level of your systems.\" — [James Clear](https://twitter.com/swyx/status/1385356659032137728)\r\n27. **Play Games You Cannot Win.** Our world is full of \"winnable\" games - likes, retweets, #1 of the day, employee of the month. External motivators destroy our intrinsic drive. You don't play infinite games to win. Only way to keep [childlike creativity]( https://twitter.com/swyx/status/968688836468453376) is to play games that you cannot win. \r\n28. **Use Your Calendar as a Todo List.** Normal todo lists don't force you to make tradeoffs. Sequence your work, set limits, and know when to decline or delegate tasks. When time block planning, eat your frog: Put First Things First. \r\n \r\n {% twitter 1364107473724919809 %}\r\n29. **Practice Stoicism**. It'll never stay as great as you want, it's never really as bad as you feel. This, too, shall pass.\r\n30. **Have a Productivity Keystone.** If you start a day unproductive, you are extremely likely to be unproductive the rest of the day. Instead, start off with something productive that you do every morning, you reinforce the idea that today is going to be a productive day.\r\n31. **Incorporate.** Companies pay expenses before taxes, People pay taxes before expenses. (Singapore is [pretty great](https://twitter.com/swyx/status/1355099275252785153) if you have this choice).\r\n32. **Stay in the Game**. Berkshire Hathaway originally had a third partner, Rick Guerin. He got caught out with margin loans and had to sell out. Warren and Charlie survived 14 recessions. [https://www.swyx.io/psychology-of-money/](https://www.swyx.io/psychology-of-money/)\r\n33. **Don't Skimp On Your Equipment.** Spending a few hundred dollars on your keyboard and monitor setup will save [tens of thousands of physiotherapy and pain in future](https://twitter.com/swyx/status/1274054230911803392?lang=en).\r\n34. **Earn White Collar, Spend Blue Collar**. Don't let your expenses rise as fast as your income - you probably don't need what you're thinking of buying. Spend part of your white collar income making up for white collar downsides - gym, group classes, [personal trainer](https://twitter.com/swyx/status/1323550900816764928).\r\n35. **Always Turn Lessons To Principles**. When we make mistakes or have great success, we should form them into principles so we can write them down and learn from or repeat them. [It is the only way for past versions of you to communicate lessons to future you.](https://twitter.com/swyx/status/952232991455174656)\r\n\r\nThe full thread and discussions are here:\r\n\r\n{% twitter 1385349095074656259 %}\r\n\r\nIf you're keen on my career-focused principles, I run a book community for [the Coding Career Handbook](https://www.learninpublic.org/). Join us!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/35-principles-for-35-years-1n2h","devToReactions":74,"devToReadingTime":7,"devToPublishedAt":"2021-04-22T20:45:31.218Z","devToViewsCount":804,"title":"35 Principles for 35 Years","published":true,"description":"I turn 35 today. Here are 35 principles I have accumulated and try to live by.","tags":"Reflections, Advice","slug":"35-principles","canonical_url":"https://www.swyx.io/35-principles","disclosure":"Some of these ideas I've lived with for a very long time, as sourced - some are aspirational goals I have not fully internalized yet, but want to."},"title":"35 Principles for 35 Years","description":"I turn 35 today. Here are 35 principles I have accumulated and try to live by. ","category":"note","tags":["reflections","advice"],"canonical":"https://www.swyx.io/35-principles","slug":"35-principles","date":"2021-04-22T20:45:31.218Z","readingTime":"7 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/289","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/289/comments","title":"35 Principles for 35 Years","created_at":"2022-01-18T00:09:54Z","updated_at":"2022-06-15T16:32:08Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/289/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Side Projects on the Modern Web Podcast","slug":"side-projects-modern-web","categories":["Creator"],"description":"In this episode, Lindsay Wardell and Hunter Miller talk side projects with Shawn Wang. We discuss the projects they do on the side, and what kind of side projects they enjoy working on. Shawn also talks about his book, \"The Coding Career Handbook\", and how it started as a side project as well. We also talk about the importance of writing your own blog posts, and sharing your experience and learning in public to help both yourself and others, rather than blogging for numbers. We wrap up with a discussion on being a part-time creator, and finding a company that supports their employees and match what you're looking to do.","instances":[{"venue":"ModernWeb Podcast","date":"2021-04-22","video":"https://www.youtube.com/watch?v=3DjrhpxuDOk"}],"category":"talk","date":"2021-04-22T00:00:00.000Z"},{"title":"Side Projects on the Modern Web Podcast","slug":"side-projects-modern-web-pod","tags":["LIP"],"venues":"ModernWeb","date":"2021-04-21T00:00:00.000Z","url":"https://modernweb.podbean.com/e/s08e09-modern-web-podcast-sides-projects-with-shawn-wang/","description":"In this episode, Lindsay Wardell and Hunter Miller talk side projects with Shawn Wang. We discuss the projects they do on the side, and what kind of side projects they enjoy working on. Shawn also talks about his book, \"The Coding Career Handbook\", and how it started as a side project as well. We also talk about the importance of writing your own blog posts, and sharing your experience and learning in public to help both yourself and others, rather than blogging for numbers. We wrap up with a discussion on being a part-time creator, and finding a company that supports their employees and match what you're looking to do.","category":"podcast"},{"title":"Grifters and Content Creation Traps","slug":"content-grifter","categories":["Creator"],"description":"We'll discuss how to grow and build your reputation online. Ethical ways to build your audience on Twitter. Things to avoid as a content creator. How to write things that matter.","instances":[{"venue":"Maksim Ivanov","date":"2021-04-21","tweet":"https://twitter.com/ivanov_dev/status/1384553300914180097?s=20","video":"https://www.youtube.com/watch?v=sL_uefhT51g"}],"category":"talk","date":"2021-04-21T00:00:00.000Z"},{"title":"Technical Community Builders","slug":"tech-community","categories":["Community"],"description":"Who builds developer communities, why are companies investing in them, and why now? I joined Idan Gazit and Brian Douglas to talk about my post on Technical Community Builders.","instances":[{"venue":"GitHub OCTO","date":"2021-04-13","tweet":"https://twitter.com/githubOCTO/status/1372568532190306304","video":"https://www.youtube.com/watch?v=lN9FphNMJbY"},{"venue":"Jamstack Boston","date":"2021-04-21","video":"https://www.youtube.com/watch?v=ecSq1Sl6h7M"},{"venue":"Sourcegraph","date":"2021-12-14","video":"https://www.youtube.com/watch?v=L1ATAYQFMn4"}],"category":"talk","date":"2021-04-13T00:00:00.000Z"},{"title":"swyx on GraphQL","slug":"graphql-guide","categories":["GraphQL"],"description":"I chatted with Loren as part of the bonus features for the GraphQL Guide book.","instances":[{"venue":"GraphQL Guide","date":"2021-04-12","video":"https://www.youtube.com/watch?v=K4jzDASCPFM"}],"category":"talk","date":"2021-04-12T00:00:00.000Z"},{"type":"blog","content":"\nThis post is my attempt at a \"red pill\" for those who haven't had McLuhanite ideas applied to the world they live in.\n\nI think people don't appreciate enough how much we are a product of our environment — and how much of our environment is socially constructed. Not only that, it is constructed by a small group of builders who never really thought they'd ever get this far (such is the nature of leverage).\n\nTo paraphrase Churchill: [First we shape X, then X shapes us](https://quoteinvestigator.com/2016/06/26/shape/). If a defining characteristic of humanity is making and using tools, then a defining characteristic of society is being shaped by those same tools.\n\n## Social Everything Optimization\n\nWe are well past debating [linguistic relativity and Sapir-Whorf](https://en.wikipedia.org/wiki/Linguistic_relativity). \"Language shapes thought\"? That's cute. Try *everything around us* shaping *everything we do*.\n\n**[The Tough Tomato Principle](https://florentcrivello.com/index.php/2019/04/29/software-the-tough-tomato-principle-and-the-great-weirdening-of-the-world/)** by Florent Crivello, among many things, spotted the impact of Google Maps on names of hotels (\"Good Hotel San Francisco\"). How long until someone is *born* named \"Best Lawyer NYC\"? \n\nOnce you see it, you see it everywhere. Game developers optimizing for Twitch spectator experience, Museums optimizing for Instagram, [Musicians optimizing for TikTok](https://switchedonpop.com/episodes/whosafraidoftiktok) and their [labels too](https://www.rollingstone.com/pro/features/tik-tok-hits-changing-titles-983383/). We're even [renaming human genes because Excel](https://www.theverge.com/2020/8/6/21355674/human-genes-rename-microsoft-excel-misreading-dates).\n\nInstagram is God's gift to colorful and niche products. Living in New York, I've personally seen the explosion of color [even in ice cream shops](https://edition.cnn.com/travel/article/best-ice-cream-new-york/index.html) - I used to work in SoHo, where the Black Tap put out increasingly obnoxiously unrealistic sundaes that work great on Instagram but would be a nightmare to actually eat.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/108opfwrujxck57njih3.jpg)\n\nHow about clothes? [Listen to Jenn Hyman](https://mastersofscale.com/jenn-hyman-the-secret-business-behind-the-business/) directly credit Instagram for women's increased desire for more variety in clothing, which helped her business, Rent the Runway.\n\nA lot of people will deny the influence of media on their own preferences. The illusion of free will and desire for self-determination is strong. \n\nBut you can't deny the impact of media changing the real world/economy. And people who's job it is to reach people (marketers and politicians) are depressingly attuned to how much media shapes us. Alex Danco [made a strong case](https://alexdanco.com/2019/10/17/the-audio-revolution/) that TV helped elect JFK, Radio helped Trump. AOC isn't on Tiktok, but you can bet [she is reaching her voters](https://twitter.com/aoc/status/1279438522102013952?lang=en) in that format.\n\n## Design is King\n\nI used to call this \"Modern McLuhanism\", because it was McLuhan that asserted [the non-neutrality of media](https://www.oxfordreference.com/view/10.1093/oi/authority.20110803100145151). \n\nHe observed that in the 1960s. Fast forward half a century, and we now live in a world where [every company is a media company](https://twitter.com/balajis/status/1313587476015935488?lang=en) and [every person is a media company](https://www.garyvaynerchuk.com/every-single-one-of-you-is-a-media-company/). The modern affliction is not simply that the choice of medium affects us, but also that we are complicit in creating the medium in the first place. \n\nModern McLuhanism is *reflexive*.\n\n**In such a world, design is king**. Thoughtful product design genuinely nudges society forward. Carelessness can tear it apart. Wilson Miner called out the implications of this for software in his classic talk, [When We Build](https://vimeo.com/34017777). \n\nI'd go so far as to make it required viewing, and this idea required digestion, for all builders. We who have this awesome power, correspondingly have an awesome responsibility.\n\n> Side note: I have previously written about the duality of [Mimicry and Reflexivity](https://www.swyx.io/mimicry-reflexivity/) exploring more applications of reflexivity on its own.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/reflexive-mcluhanism-kmn","devToReactions":18,"devToReadingTime":3,"devToPublishedAt":"2021-04-08T16:51:38.028Z","devToViewsCount":170,"title":"Reflexive McLuhanism","published":true,"description":"First we shape X, then X shapes us.","tags":"Reflections, Reflexivity, McLuhanism","slug":"reflexive-mcluhanism","canonical_url":"https://www.swyx.io/reflexive-mcluhanism","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/108opfwrujxck57njih3.jpg","disclosure":"These are patterns I have been observing for years, but don't really have an insightful or punchy perspective on it apart from noting this is a thing."},"title":"Reflexive McLuhanism","description":"First we shape X, then X shapes us. ","category":"note","tags":["reflections","reflexivity","mcluhanism"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/108opfwrujxck57njih3.jpg","canonical":"https://www.swyx.io/reflexive-mcluhanism","slug":"reflexive-mcluhanism","date":"2021-04-08T16:51:38.028Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/290","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/290/comments","title":"Reflexive McLuhanism","created_at":"2022-01-18T00:09:56Z","updated_at":"2022-06-18T17:47:44Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/290/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"State of Svelte","slug":"state-of-svelte","categories":["JavaScript"],"description":"I joined the CodingCat stream with Alex and Brittney to talk Svelte!","instances":[{"venue":"CodingCat","date":"2021-04-08","video":"https://www.youtube.com/watch?v=JfZm0tPUxjE"}],"category":"talk","date":"2021-04-08T00:00:00.000Z"},{"type":"blog","content":"\n*[Listen to narrated version here!](https://swyx.transistor.fm/episodes/set-explicit-help-timeouts)*\n\nThis is the backstory of how a 1-2 hour task stretched into 2 weeks because I kept it to myself:\n\n{% twitter 1378020519774019587 %}\n\nA few weeks ago a customer conversation resulted in a simple documentation request. Take something undocumented, and document it. I've done this a gazillion times. I happily took it on.\n\nBut when I actually looked into it, this task was different. I knew in theory how it worked, but I had never personally used this functionality before. So to document it, I had to learn it. And there was no source material, no YouTube tutorial, no Stackoverflow answer. \n\nI felt that little \"uh oh\" pit of despair. Our CTO had given some pointers, so I fired up my sample code, and tried them out. Didn't work. Several variations also didn't work. By then my time was up and I had to go to the next meeting.\n\nThe next attempt, I realized that I didn't have an optional dependency (Elasticsearch) configured for this feature to work. Stupid me! Of course nothing I tried worked! That was on us for not having helpful errors to warn about such things, but that's a task for another day. I enabled it, and went on to try out the exact same pointers given.\n\nStill didn't work. Several variations also still didn't work. Then my time was up.\n\nIf you had asked me, at the outset, how long this task would take, I would have said 1-2 hours at most. I ended up intermittently banging my head on it for **2 weeks** before admitting defeat.\n\nOnly when I asked for help after 2 weeks - literally typing \"I need help\" into Slack - did I find out that the pointers given were incorrect and we needed a deeper inspection of the source code.\n\nThere were multiple failures here - my failure to go back to my CTO to pin down what exactly he meant, my lack of familiarity with something I only conceptually understood, my failure to open up source code when surface level attempts didn't work ([something I preach](https://twitter.com/swyx/status/1010705321772318720)!).\n\nBut I think my biggest failure of all was letting it drag on for 2 weeks. I should have just asked for help after the first day. Or first week. Anything would've been better than 2 weeks.\n\nThe real reason was this: I was new at the company and wanted to appear like I knew what I was doing, so I didn't ask for help. Keep in mind I'm someone who tells people to [embrace the power of ignorance](https://twitter.com/swyx/status/1202315814071717888). And yet, that's what I did. I was in a supportive environment and it still felt embarrassing to type the words \"I need help\".\n\nFrom now on I'll make it a point to simply call out where I'm stuck when I'm stuck. \n\n## Personal Help Timeout Policy\n\nThe trick is setting the \"help timeout\" — how long before you ask for help? Clearly zero timeout is too noisy, and 2 weeks is too quiet. I put it to a poll:\n\n{% twitter 1378029651012984834 %}\n\nIf you have a daily standup, this is the kind of \"blocker\" that is ideally brought up there, limiting your help timeout to 1 day. However, in practice, there are many long-running async tasks, \"important but not urgent\", that don't get brought up as blockers in daily standups.\n\nIt's obviously context dependent, but I'm personally fine with a 1-4 hour timeout for most things I do. Struggle is useful and you can learn a lot through it, but you should never have to struggle for more than 4 hours alone on a problem, when you have a team.\n\n## Shared Help Timeout Policy\n\nAs much as this policy might be helpful individually, I think it might be even better when set as a team. I am not in any real danger when I ask for help. But others might feel like they are. \n\nWithout having a real conversation about help timeouts, it is easy to end up in a situation where implicit help timeouts vary from 1 hour to infinity, and team progress is slowed by having to overcome this barrier every time. Make it explicit, and shared, and you enable [lampshading of lack of progress](https://www.swyx.io/lampshading/) and normalize asking for help. Team leaders should role model this too, instead of merely saying it's ok for everyone *else* to ask for help.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/set-explicit-help-timeouts-1dlg","devToReactions":3,"devToReadingTime":3,"devToPublishedAt":"2021-04-05T14:29:47.172Z","devToViewsCount":115,"title":"Set Explicit Help Timeouts","published":true,"description":"A simple way to normalize asking for help.","tags":"Reflections, Advice, Lampshading","slug":"help-timeouts","canonical_url":"https://www.swyx.io/help-timeouts","disclosure":"This is a new policy I have made for myself, but have not applied at a team level yet."},"title":"Set Explicit Help Timeouts","description":"A simple way to normalize asking for help. ","category":"note","tags":["reflections","advice","lampshading"],"canonical":"https://www.swyx.io/help-timeouts","slug":"help-timeouts","date":"2021-04-05T14:29:47.172Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/291","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/291/comments","title":"Set Explicit Help Timeouts","created_at":"2022-01-18T00:11:11Z","updated_at":"2022-06-18T17:47:44Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/291/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n\nRegular readers will notice that my posts often change rapidly soon after publication. This means they get *better over time*, as a result of self editing and feedback from readers. I've come to call this **Blogpost Annealing**.\n\n[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6c04prajhklrwwlu1wwz.png)](https://excalidraw.com/#json=4569679704096768,NWOVidbYqnVz9erY36Pf3g)\n\nAnnealing is a borrowed term from [metallurgy](https://en.wikipedia.org/wiki/Annealing_(metallurgy)) where heating up metal makes it softer and easier to shape to its ideal end state, and also irons out any internal inconsistencies. I obviously don't know anything about metallurgy — I came by it via machine learning, where [simulated annealing](https://en.wikipedia.org/wiki/Simulated_annealing) serves as a powerful metaheuristic for optimization.\n\nBut the analogy holds — **if you want to make something better, apply heat to get it out of its normal state, and shape it while it cools**. This makes for a higher quality end result than trying to launch something in its final form from a standing start.\n\n## Example\n\nFor example, you can take my post on Preemptive Pluralization and peek at the difference between [the initial publish](https://604bf32dcfdb601163498323--scout-videos-51664.netlify.app/preemptive-pluralization/) and [the latest](https://604bfc8099765a1bd20fce77--scout-videos-51664.netlify.app/preemptive-pluralization/) (this is easy because Netlify uses [Immutable deploys](https://www.netlify.com/blog/2018/10/05/netlify-and-the-functional-immutable-reactive-deploy/)). Some changes that happened in the 48 hours after publishing:\n\n- Added the Twitter and Reddit discussions to the post so future readers can find them\n- Added extra concerns from readers I didn't think of, again for future readers\n- **Bolded the single most quoted sentence** ([the one about cardinality](https://twitter.com/search?q=cardinality%20of%202%20to%203%20than%20it%20is%20to%20refactor%20from%20a%20cardinality%20of%201%20to%202&src=typed_query)) to give it some visual distinction for skimmers. Before publishing, I had no idea this would resonate that much.\n- Added an extra relevant example on Pagination, from an [authoritative source](https://twitter.com/simonw/status/1370542711288209411?s=20)\n- Reworded my intro from \"ask if you are likely\" to \"ask if you could *ever* possibly\" to strengthen the claim\n- In future, I may also return to add a visualization of the idea once I figure out something I like\n\n## Benefits\n\nI find this work extremely rewarding and valuable, because it represents the delta between what I thought of before publication and what I now know after. Some resource posts, like [How to Name Things](https://www.swyx.io/how-to-name-things/) and [My New Mac Setup](https://dev.to/swyx/my-new-mac-setup-4ibi/) and [Eponymous Laws](https://www.swyx.io/eponymous-laws/), get updated *months* after publication*.* \n\nWhere the median blogpost is usually static/immutable after publish, a blog with an annealing policy will usually **improve** in quality *after* publication. **More exposure = More \"heat\" = More quality.**\n\nIronically, most of my readership will miss out on these changes, because blogpost publication is usually a singular event (a tweet, or HN, or Reddit posting). Sometimes I will [post diffs](https://twitter.com/swyx/status/1313900029824823301), but often it just goes completely unannounced. (*RSS subscribers can [theoretically receive updates](https://stackoverflow.com/questions/1984381/find-out-if-something-has-changed-in-a-website-using-an-rss-feed), but I'm honestly not sure how well this works in practice. Let me know if there's ways I should improve [my RSS feed](https://swyx.io/rss.xml).)*\n\nThere's a small benefit that happens after running an Annealing policy for a while — readers become incentivized to engage on new posts, because they know that if they add value early, their perspectives will be highlighted for others to see. This is a virtuous cycle that you should want to encourage (especially if a reader can disagree ***well***).\n\n## Responsibility\n\nOne of the fundamental tensions with Blogpost Annealing comes when you are fundamentally playing a different game than your readers expect. People get *very* mad at me when I publish something wrong, and don't see my subsequent retractions or modifications. \n\nNote that I take my responsibility as a writer seriously, and articulated my process: \n\n- After idea validation with my [Three Strikes Rule](https://twitter.com/swyx/status/1351197649727352836)\n- I do a lot of research via [Mise en Place Writing](https://www.swyx.io/writing/writing-mise-en-place)\n- I put big theses through a [Workshopping](https://www.swyx.io/workshopping) process\n\nIt is still not enough for some people, who only care about the end result and silencing opinions they disagree with on behalf of the masses, who are too ignorant to be exposed to bad takes.\n\n**I do not encourage irresponsible Learning in Public** and people who do that give the rest of us a bad name. But I *also* do not wait until I know everything before publishing, because that is impossible, and sometimes I learn the most *after* publishing (Godwin's Law to the rescue!).\n\nIf you Learn in Public persistently, you will naturally build an audience over time. [**With great audience, comes great responsibility**](https://swyx.transistor.fm/episodes/career-jam-session-with-jeff-escalante-of-hashicorp). You are right to fear being wrong, and it should make you take more care. But it must not prevent you from shipping altogether. \n\nI think the resolution to this conundrum is to establish clear terms of service (FYI, this site/blog/whatever you call it has a [Digital Garden Terms of Service](https://www.swyx.io/digital-garden-tos/)) and make responsible disclosures ([like this](https://twitter.com/swyx/status/1369361340243079171)) on whether something is \"just an idea\" or \"truth from experience\". A Garden run according to these terms will naturally result in an Annealing policy.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/blogpost-annealing-pod","devToReactions":11,"devToReadingTime":4,"devToPublishedAt":"2021-03-28T19:07:06.863Z","devToViewsCount":114,"title":"Blogpost Annealing","published":true,"description":"Letting my writing improve under the heat of feedback","tags":"Reflections, Writing, LearnInPublic","slug":"blogpost-annealing","canonical_url":"https://www.swyx.io/blogpost-annealing","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6c04prajhklrwwlu1wwz.png"},"title":"Blogpost Annealing","description":"Letting my writing improve under the heat of feedback ","category":"note","tags":["reflections","writing","learninpublic"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6c04prajhklrwwlu1wwz.png","canonical":"https://www.swyx.io/blogpost-annealing","slug":"blogpost-annealing","date":"2021-03-28T19:07:06.863Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/292","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/292/comments","title":"Blogpost Annealing","created_at":"2022-01-18T00:11:13Z","updated_at":"2022-06-18T17:47:45Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/292/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nThere are two prevalent solutions for injecting dynamic content into markdown: Shortcodes and MDX. I think most people should use shortcodes, but there are also valid cases for picking MDX. Here's my breakdown.\n\nThere's some confusion between these content formats ([Gatsby's docs for shortcodes](https://www.gatsbyjs.com/plugins/gatsby-plugin-mdx/#shortcodes) literally just make them synonyms for MDX) so I figure it is worth setting some definitons upfront.\n\n## Defining Shortcodes\n\nThe earliest instance I can find of Shortcodes is in [WordPress](https://codex.wordpress.org/Shortcode). The whole goal is that you can continue writing in standard plain text, but insert special components just by using a special syntax that wouldn't show up in normal writing:\n\n- Wordpress: `[gallery id=\"123\" size=\"medium\"]`\n- Dev.to: `{ % twitter 834439977220112384 % }` (remove spaces)\n- Elder.js: `{{shortcode foo=\"\"}} optional inner content {{/shortcode}}`\n\nThese are mostly used for inserting anything from Tweet embeds to YouTube videos to GitHub gists to image galleries. But there's really no limit to what you can define for your shortcodes, to cover anything from simple Tip and Alert displays to interactive Quiz components!\n\nShortcodes are the plaintext analog of Web Components - where a `<custom-element>` might extend HTML, shortcodes extend plaintext (typically Markdown). You could write your shortcodes in React or Vue or Web Components - it doesn't matter, because they are inserted after the fact. \n\n## Defining MDX\n\nMDX, [introduced in 2018](https://twitter.com/rauchg/status/962021643227865088), inverts this model of content vs code. It renders your markdown as a React component (or Svelte component, with [MDsveX](https://mdsvex.pngwn.io/)), so it is very natural to add more React components inline:\n\n```jsx\nimport Video from '../components/video'\n\n# My blog post\n\nHere's a video:\n<Video width={300} src=\"video.mp4\" />\n```\n\nMDsveX goes [a little further](https://twitter.com/swyx/status/1375498831828197378), offering layouts, frontmatter, syntax highlighting, styling, and state. But MDX is by far more popular because of React. In [my 2020 survey of the React ecosystem](https://twitter.com/swyx/status/1326271632751558656?lang=en), all blogging documentation tools now offer MDX support by default.\n\n## Comparing the Two\n\nSuperficially, both Shortcodes and MDX do the same job, which is why it feels a little silly to write up a blogpost like this. But they do have important differences, that I myself did not appreciate until [Nick Reese](https://twitter.com/nickreese?lang=en) converted me when I was arguing for MDsveX in [Elder.js](https://elderguide.com/tech/elderjs/#shortcodes).\n\n- **Portability and Future-proofing**\n - MDX requires you to use React and a bundler plugin, tying you in to that ecosystem. Great if you stay within the lines of what they imagine, problematic if you want something slightly different or need to move off React (you now have to go through and convert all your content)\n - Shortcodes are framework and platform agnostic. This is how I can [blog on Dev.to and render on my own site](https://www.swyx.io/devto-cms/) (the inverted [POSSE pattern](https://indieweb.org/POSSE)), and have both render correctly in their native environments.\n - Though shortcodes still require a build chain to process them (including injecting scripts if needed), the minimal viable shortcode processor is no more complex than `String.replace`. Ultimately, shortcodes are more likely to show graceful degradation: I have seen 20 year old blogs with shortcodes that are no longer active, but are still readable because they just fall back to plain text.\n- **Scope**\n - Shortcodes are limited to their immediate responsibility area - starting and ending with the brackets that designate them.\n - MDX has a broader scope than Shortcodes in that it transforms the entire file - meaning that you can (and often should) supply [your own versions of markdown components](https://mdxjs.com/advanced/components). This is handy for, for example, adding classes and preload handling to `<a>` tags, or adding hash links and id's to `<h2>` headers like I do on my blog.\n- **Customizability**\n - Shortcodes require you to predefine all the components you are going to use up front. If you'd like to add a new type of component, you'll have to jump out of your writing mode, go add some code to your components folder, and then jump back in to keep writing.\n - With MDX, you can compose components as freely as you do JSX:\n \n ```jsx\n import GroupThing from '../components/GroupThing'\n import ItemThing from '../components/ItemThing'\n\n # My blog post\n\n Here's a thingy:\n <GroupThing foo=\"bar\">\n \t<ItemThing baz={1} />\n \t<ItemThing baz={2} />\n \t<ItemThing baz={3} />\n </GroupThing>\n\n ## You can even define stateful components inline!\n\n export const MyCounter = () => {\n const [counter, setCounter] = React.useState(0);\n return (\n <button onClick={() => setCounter((c) => c + 1)}>\n Increment {counter}\n </button>\n );\n };\n\n <MyCounter />\n\n Yes this is still MDX even though it looks like a React/JSX file!\n ```\n \n Since you are already using a JS build tool to compile MDX, it is easy to inject further JS as needed and have the bundler properly resolve and code split things for you.\n\n- **WYSIWYG**\n - This is a minor point, but the fact that everything in markdown corresponds to a visible rendered element is a nice correspondence. MDX breaks this by having `import` and `export` statements that compile away to nothing. In practice this is no big deal but it slightly rankles me.\n\n## Conclusion\n\nI think most developer bloggers spring for MDX because they enjoy using JSX, but they end up using the same 3-4 components on every single post or document they write. In those scenarios, they are accepting the downsides of MDX, without really benefiting from the customizability. \n\nIn fact, I think you can go pretty far with shortcodes. Does it really matter if you have 30 components that you pull in via shortcodes? Not really, amount of components isn't really a motivating factor. I think this covers most bloggers. **Most bloggers should use shortcodes.**\n\nHowever, there are still valid usecases of MDX.\n\nFor a design system or frontend component library, one might argue that MDX allows you to display the exact components that you are documenting:\n\n```jsx\nimport Button from './components/Button'\n\n# Button\n\nThis is our default Button!\n\n<Button />\n\nThis is our secondary Button!\n\n<Button type=\"ghost\" />\n```\n\nHowever for backend code, or for complex-enough frontend code that you'd like to run integration tests on, you may wish to [transclude](https://en.wikipedia.org/wiki/Help:Transclusion) from a source file, and that may use shortcodes. Storybook's [Component Story Format](https://storybook.js.org/docs/react/api/csf) also provides a nice convention that keeps your documentation agnostic of MDX.\n\nBecause MDX compiles to a React component, you could build tooling that can typecheck MDX (as far as I know this doesn't yet exist, hence this point is all the way down here). The same is doable for shortcodes, but since there is very little restriction on how shortcodes are processed, it is far less likely that successful shared tooling will arise.\n\nFinally, there's the question of customization. If you need to compose components inline as you write, then MDX is unquestionably the right choice. This is why Hashicorp went with MDX, and you can listen in on [my conversation with Jeff Escalante](https://swyx.transistor.fm/episodes/career-jam-session-with-jeff-escalante-of-hashicorp) for more on this.\n\nMy final \"quote\" on this, if you will, is this: \n\n- **MDX works best as a more concise way to write React *pages***. MDX optimizes for flexibility - great for complex docs!\n- **Shortcodes are best for including custom components in a future-proof way.** Shortcodes optimize for longevity - great for blogs!\n\n## Appendix: Structured Content\n\nPerhaps a third \"alternative\" to Shortcodes vs MDX is structured content - discrete \"blocks\" of content rendered inside of a CMS, like you see in Notion, [Sanity.io](https://www.sanity.io/structured-content) or in WordPress Gutenberg. I don't have a lot of personal experience with this, but my sense is that it locks you in to these systems, in exchange for WYSIWYG and no-code editing. In a way, structured content is what would happen if your writing is *entirely* made up of data inside shortcodes.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/shortcodes-vs-mdx-3d4e","devToReactions":15,"devToReadingTime":5,"devToPublishedAt":"2021-03-26T21:40:42.355Z","devToViewsCount":934,"title":"Shortcodes vs MDX","published":true,"description":"Comparing the two popular custom dynamic content solutions!","tags":"writing, shortcodes, react","canonical_url":"https://www.swyx.io/shortcodes-vs-mdx-3d4e"},"title":"Shortcodes vs MDX","description":"Comparing the two popular custom dynamic content solutions! ","category":"note","tags":["writing","shortcodes","react"],"canonical":"https://www.swyx.io/shortcodes-vs-mdx-3d4e","slug":"shortcodes-vs-mdx-3d4e","date":"2021-03-26T21:40:42.355Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/293","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/293/comments","title":"Shortcodes vs MDX","created_at":"2022-01-18T00:11:15Z","updated_at":"2022-06-18T17:47:45Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/293/reactions","total_count":1,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":1,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> 2021 updates: Featured on the [Compressed.fm](https://www.compressed.fm/episode/64) podcast! I also wrote a followup about [the Swipe Files Strategy](https://www.swyx.io/swipe-files-strategy).\r\n>\r\n> 2022 updates: I expanded on this with [Jess Sachs](https://www.youtube.com/watch?v=S-UxzCtpB74) (on getting started) and [Stripe DevChats](https://youtu.be/S-UxzCtpB74?t=182) (on making money)\r\n\r\nSomething unexpected happened when [my side project](https://www.learninpublic.org/) crossed $100k in sales: \r\n\r\n**I didn't want to quit my job.**\r\n\r\nNo urge to blog about leaving the \"rat race\". No tweet about how becoming a creator \"changed my life (and yours can too! Buy my course!)\". No Jerry Maguire letter.\r\n\r\nI wondered if something was wrong with me. Being on social media exposed me to a lot of hustle porn constantly telling me to quit my job. That freedom is an all-or-nothing nirvana, and once you taste it, you don't go back. Isn't that how this movie script is supposed to go?\r\n\r\nI want a new script for Part Time Creators. We need to define what it is, why it's worth doing, make it work, then make it *cool*.\r\n\r\n## More Than Just Money\r\n\r\nMaking $100k a year has always been my bar for successful \"independent income\". It's more than my parents ever made at their peak earning, and in most cities it's enough to support yourself and even raise a family on. Even better if totally passive — I harbored dreams of traveling the world and making money in my sleep.\r\n\r\nBut after 4 years of [Learning in Public](https://www.swyx.io/learn-in-public), I got there — and realized my desires had shifted. Part of this is surely due to the [hedonistic treadmill](https://en.wikipedia.org/wiki/Hedonic_treadmill) — I had reached Senior level at a [FAANG](https://medium.com/@teamblind/seven-reasons-why-engineers-want-to-join-faang-ec4f93374384) by then. But I realized it was mainly because I enjoy applying myself to hard problems and working with smart people, that I would never have encountered on my own. \r\n\r\nYet, while employment is great, I enjoy the **growth** that successful side projects afford. It isn't just about the money — side projects do NOT need to make money right away to be successful. \r\n\r\n- It's about self-sufficiency: [what you learn](https://twitter.com/swyx/status/1330092717649645571?s=20) shipping something from end to end.\r\n- It's about self-actualization: having creative control and autonomy and [not ending the week with nothing](https://training.kalzumeus.com/newsletters/archive/do-not-end-the-week-with-nothing).\r\n- It's about [long term games](https://twitter.com/swyx/status/1281424520100737025): building a personal network and reputation that will outlast any employer.\r\n- It's about optionality: having a backup plan if something goes wrong, and incubating dozens of business ideas that *could* be big, [creating luck](https://swyx.io/create_luck) for yourself.\r\n\r\n**It's about having a job while not *being* your job.** \r\n\r\n## #PartTimeCreator\r\n\r\nI like the term **Part Time Creator** for what I'm doing. The creator economy has many one-percenters — full-time Indie Hackers [making well over $1m a year](https://www.indiehackers.com/podcast/034-mike-carson-of-park-io) all by their lonesome. These are remarkable accomplishments and should be celebrated. \r\n\r\n*But the majority of us will **never** get there.* 90% of creators on Gumroad [make less than $20k a year](https://twitter.com/swyx/status/1368353739799588866?s=20). It's not a full-time income, but they should not feel like failures. They built something valuable on their own and that is *awesome*. \r\n\r\nBecause I don't derive all my self worth from my employer, I stand a little taller. Dream a little bigger. Negotiate a little harder.\r\n\r\nI want to clearly acknowledge that **this path requires privilege and is not for everyone**. The cards are stacked against you from the beginning: \r\n\r\n- Existing creator platforms mainly reinforce [the Economics of Superstars](https://www.uvm.edu/pdodds/files/papers/others/1981/rosen1981a.pdf).\r\n- Parents are already achieving superhuman feats balancing family and work.\r\n- Many IP assignment agreements are actively hostile to Part Time Creators — Employers want to pay you for 40 hours a week but own your output for all 168.\r\n- Independent creation has far less health, safety, diversity, accessibility, or other forms of protection offered by traditional employment.\r\n\r\nPart Time Creation *must* get easier for the less privileged, and its rewards must be more equitable, which is why all creator platforms should explore the ideas Li Jin published in [her seminal article on the Creator Middle Class](https://li.substack.com/p/building-the-middle-class-of-the), and eventually legal and banking reforms made to democratize access.\r\n\r\nStill, being a Part Time Creator *is* a viable path for many thousands of people, who can feel this possibility and desperately want to figure this out. I think there will be many more Part Time Creators in future, and courses and platforms will evolve accordingly. There's already signs of extreme demand: Ali Abdaal's [Part-Time YouTuber Academy](https://academy.aliabdaal.com/) sells out in *seconds*, Ryan Hoover's [Weekend Fund](https://medium.com/@rrhoover/weekend-fund-%EF%B8%8F-72dfdc830f00) specifically invests in side projects, and Andrew Gazdecki's [Microacquire](https://microacquire.com/) makes it easy to sell them.\r\n\r\n## Making Part Time Work\r\n\r\nThere are a lot of objections to working outside of work, even if that work is for yourself. Many of them are valid. I only write for people like me, who have the energy and desire to make this work but have been lacking a guide.\r\n\r\n- The first thing that needs to happen is to get an employment situation that doesn't completely drain you of after hours productivity. I am no stranger to this kind of job — before 2017 I worked in finance, which completely consumed my life and intellectual output. I didn't know this was a red flag because I didn't know better.\r\n \r\n If part time creation is something you want, just know that there are companies, like [ConvertKit](https://twitter.com/nathanbarry/status/1247890780456288257?s=20), where side projects are not only tolerated, but encouraged. Your current company may be actively hostile to side projects, but there are plenty of companies that will see it as a plus (though it should **NOT** be a hiring requirement). If you are open to not working full time, there are plenty of [startups that are only looking for part time help](https://parttime.careers/).\r\n- The second is to **get your proverbial shit together and make time**. Talk is cheap. Your actions are the real vote for what you want to be. If you say you want to be a Part Time Creator but [spend almost 40 hours a week watching Youtube/Netflix](https://en.wikipedia.org/wiki/Television_consumption), then you're really a Full Time Consumer. Make the time. I have some pointers below, but here are a few thematic inspirations for you:\r\n - **Five for Them, One for Me**: aka the \"Weekend Warrior\" approach. Pick Saturday or Sunday, but do take one day to rest. This is a long game; do not burn out.\r\n - **Personal 20% Time**: Google is famous for allowing employees to work on side projects 20% of the time, but employees joke that it's really \"120% Time\" because they still have to do their full day jobs anyway. That works out to an extra 1.5-2 hours before work.\r\n - **Batched Time**: Ben Orenstein is known for taking [Codecations](https://thoughtbot.com/blog/you-should-take-a-codecation) - holidays where you work on shipping a side project. Take a week off work (and family) obligations and just go ham. This is a great option for those who simply cannot make a weekly commitment, or if you must accumulate context rather than context switching every day or week.\r\n\r\nFor those extremely worried: **You don't have to make money right away**. There are plenty of ways to create valuable personal assets without monetizing right away, from writing a newsletter to building a YouTube channel. The point is to learn to create, and build your network. Have a chat with your manager if in doubt — you may be surprised how okay they are with this. Some may even offer you an intrapreneur opportunity, like [Jenn Hyman before Rent the Runway](https://mastersofscale.com/jenn-hyman-the-secret-business-behind-the-business/) or [Ben Orenstein before Tuple](https://mixergy.com/interviews/tuple-with-ben-orenstein/). As the Part Time Creator movement grows, this will be increasingly accepted.\r\n\r\nThis post is already longer than I intended and borders on generic productivity advice you can find elsewhere, so I'll just drop six principles and resources on you:\r\n\r\n- **Before Work**: [Alex West](https://www.alexwest.co/) (my Creators interview [here](https://codingcareer.circle.so/c/workshops/guest-chat-alex-west-on-side-hustling-to-2k-mrr)) and [Swizec Teller](https://twitter.com/Swizec/status/1368740304560345088?s=20) both note that working on personal projects **before** the day job begins is the best way to ensure you actually work on it (this is what I do). Of course the opposite - [2 hrs after the family goes to bed](https://twitter.com/bagder/status/1372572657317711876?s=20) - works for some folks as well.\r\n- **Start Now:** It's easy to desire something long term, but have barriers short term. I have news for you: **There's never going to be a perfect time to start.**\r\n \r\n {% twitter 1148338745600598016 %}\r\n \r\n Pretend you've already been a Part Time Creator for 5 years straight and run into whatever your situation is today. Would you stop? If no: then why put off starting? Figure out how to make it work even when things aren't ideal, because things are **never** ideal.\r\n- **Keep Shipping:** It's natural to want to sink a lot of time into creating something great, and many people find success doing so. However I find that **most** people get stuck in a perfectionist loop, and never ship. I explored [the Quality vs Consistency tradeoff](https://www.swyx.io/quality-vs-consistency/) in a separate post, but TL;DR, when in doubt, choose Consistency, and work your way up to Quality rather than expect to jump there from a cold start. Ship at least every month. If you can't, **scope down until you have no excuse not to ship**. Part Time Creator is an identity, and you are what you do repeatedly. If you repeatedly find ways to not ship, that's what you are.\r\n- [**Productize Yourself**](https://nav.al/productize-yourself): Part Time Creation is distinct from taking on a Part Time *Job* where you sell time for money like you do in the day job. Focus on formats that deliver value disconnected from your time. [Friendcatchers](https://www.swyx.io/friendcatchers/), Writing, podcasting, drawing, and some categories of software. If you are a developer, apply to teach for [Egghead.io](http://egghead.io) - they take extremely good care of their part time creators. I [still get $100-300 a month](https://twitter.com/swyx/status/1368744251203284993) from courses I made 3 years ago. Note: Most beginners aren't able to productize right away — they need to [stair-step](https://robwalling.com/2015/03/26/the-stairstep-approach-to-bootstrapping/) up to it with some sweat equity. That's normal.\r\n- **Shameless Plug**: [My book](https://www.learninpublic.org/) has an entire chapter dedicated to Side Project ideas and productivity methods!\r\n\r\n## Making Part Time *Cool*\r\n\r\nPart Timers will *never* get their due as long as they are perceived to be the minor league shadow of Full-Timers. Customers instinctively equate \"part time\" with \"not committed\". Of course, you can dispel that notion by doing your thing for 10 years. But that'd take 10 years.\r\n\r\nTo *really* make a strong case for Part-Time Creators, it's interesting to consider what Part-Timers can do *better* than Full-Timers. The best way I know how to phrase this: **The work informs the side hustle, the side hustle informs the work**. \r\n\r\nEveryone draws the line on what is acceptable. You should definitely NOT compete with your employer or share trade secrets. But there are a *zillion* other ways to create without conflict of interest, in a way that also adds value to your employer:\r\n\r\n- [**Oren Ellenbogen**](https://twitter.com/orenellenbogen) runs [Software Lead Weekly](https://softwareleadweekly.com/), one of the most popular newsletters on engineering leadership. This surely helps in his day job as a VP of Engineering. Likewise with [Rosie Sherry](https://twitter.com/rosiesherry)'s work on [the Rosieland community](https://rosie.land/) informing her work as [Community Manager at Indie Hackers](https://growthtoday.fm/rosie-sherry-indiehackers/).\r\n- [**Julia Evans**](http://twitter.com/b0rk) built a massive following writing [programming comics based on surprising facts](https://jvns.ca/blog/2020/12/05/how-i-write-useful-programming-comics/) based on generalizable lessons from her work at Stripe. She's since left, but her work surely helped Stripe burnish its reputation as an attractive employer.\r\n- [**Kent C. Dodds**](http://twitter.com/kentcdodds) bootstrapped his [Consume-Build-Teach](https://epicreact.dev/podcast/learn-by-consuming-building-and-teaching/) cycle at Paypal for [4.5 years](https://twitter.com/kentcdodds/status/1368754733054234625?s=20), where he generalized lessons from solving Paypal problems into popular open source, and a successful teaching career. Both these \"extracurricular\" efforts improved the engineering culture at Paypal, which was only too happy to let him do his thing.\r\n- [**Janel Loi**](https://twitter.com/janelsgm)'s authority putting [NewsletterOS](https://newsletteros.com/) and [PodcastOS](https://gumroad.com/l/podcastoperatingsystem) together with No-Code tools informs her new job at On Deck, where she will meet more creators to serve, and also serve them better because she has her ongoing side projects.\r\n- **Jack Conte**'s bands [Scary Pockets](https://www.youtube.com/watch?v=XYeuvbhKy4I) and [Pomplamoose](https://www.youtube.com/channel/UCSiPjfAJBgbFlIUsxOWpK0w) give him the deep empathy, credibility, and outlet he needs in his day job as CEO of Patreon.\r\n- **Troy Hunt** [blogged and wrote online](https://www.youtube.com/watch?v=-MUhcgXBj_A) for years before finally finding his ultimate niche as \"the Security Guy\" with his side project [HaveIBeenPwned.com](https://haveibeenpwned.com/). It isn't a straight line to success - you have to allow for months and years of wandering in the wilderness before you find your thing. Stay employed.\r\n\r\nFor Part-Time Creators, the ultimate source of synergy with the day job is *expertise*. Expertise is [specific](https://www.navalmanack.com/almanack-of-naval-ravikant/find-and-build-specific-knowledge) and [tacit](https://commoncog.com/blog/tacit-knowledge-is-a-real-thing/) knowledge. Everything that cannot be taught: all the judgment you hone by doing, all the untold stories and relevant data recalled at your fingertips. Your work history will also give you credibility, although you must not over-represent what you can speak to.\r\n\r\n- If you can deliver your expertise concisely, you are now a viable **consultant**.\r\n- If you can package it into a repeatable process, you have a **productized service**.\r\n- If you can create something valuable disconnected from your time, you now have a **product**.\r\n- You don't have to choose; you *could* offer all three as three different tiers (1x, 2x, 5x) to suit different customer needs, also known as [Do It Yourself, Done With You, Done For You](https://github.com/sw-yx/launch-cheatsheet/blob/master/README.md#pricing) pricing. Higher revenue, but more complexity.\r\n\r\nThe other side of the feedback loop works too. Venture Capitalists often hire \"Entrepreneurs in Residence\" — former or future CEOs who simply sit in on meetings, give counsel, and look for ideas. I'd like to see a democratization of this to all sorts of employers and expertise fields. The power dynamic completely shifts if a Part Time Creator is hired as an \"Expert in Residence\" rather than being \"given\" a job.\r\n\r\n![the part time creator flywheel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6ynmrjt1qtsfvhmydd36.png)\r\n\r\nLastly, Part-Time Creators with \"real\" jobs are infinitely more relatable than Full-Timers. This lets them stay grounded and avoid the [Meta Creator Ceiling](https://www.swyx.io/meta-creator-ceiling/). This is a trap that many premature Full-Timers run into, because they run out of interesting problems and unique expertise.\r\n\r\n## A Creator Middle Path for the Creator Middle Class\r\n\r\nI think there's [a LOT of folks that want a middle way](https://twitter.com/swyx/status/1368732639557918725) between being a \"My Company is My Life\" salaryman and \"Stick it to The Man\" ronin. We indulge the social media escapism, but we kind of like our normie careers. \r\n\r\nYet, the days of spending 45 years with one company and retiring on a pension, like our parents' parents were promised, are long gone. We need to establish independent value because our employers simply do not have our long term interests at heart.\r\n\r\nI'm hopeful for growing acceptance of Part Time Creators from employers, but ultimately, I think more people *can already* be Part Time Creators in their existing situations. This is not only viable today, but sorely needed. We are all fed up with over-SEO-ed content and generic lowest-common-denominator products. Part Time Creators can offer far more diversity, creativity, and unique expertise to fulfil every niche need of humanity. And they can make money, share valuable knowledge, and have more dignity doing so.\r\n\r\nThis is my utopian dream for a thriving Creator Middle Class. There's already dozens of us doing it. Join us!\r\n\r\n**Further reading:**\r\n\r\n- Steph Smith's [You Don't Need to Quit Your Job to Make](https://blog.stephsmith.io/you-dont-need-to-quit-your-job-to-make/) has some important mindset shifts to undergo this process.\r\n- The usefulness of [Purposeful Side Projects](https://devbizops.substack.com/p/purposeful-side-projects) by Mark Birch\r\n- Zeno Rocha's journey to [100k in a year with Dracula Pro](https://draculatheme.com/pro/journey)\r\n- [Weekend Club](https://weekendclub.co/) is a paid community of weekend warriors - I have not personally tried it.\r\n- [Ask HN: How do I find energy to work on hobbies after the work day ends?](https://news.ycombinator.com/item?id=26500021)\r\n- Working on random side projects may have helped Claude Shannon invent information theory https://timharford.com/2021/05/cautionary-tales-fritterin-away-genius/\r\n- [My AMA on long tail infoproducts](https://www.indiehackers.com/post/made-121-326-since-launching-my-book-last-july-63-of-it-after-launch-month-ama-about-long-tail-infoproducts-41b55f5670) as a Part Time Creator\r\n- (2022) [Brian Lovin’s design crits](https://brianlovin.com/writing/design-critique-for-fun-and-profit#consulting-is-a-slow-wealth-building-strategy) are a perfect part time project for designers!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-part-time-creator-manifesto-46i1","devToReactions":132,"devToReadingTime":12,"devToPublishedAt":"2021-03-14T21:56:04.965Z","devToViewsCount":2584,"title":"The Part Time Creator Manifesto","published":true,"description":"Why we need more people creating Part Time and how you can do it too.","category":"essay","tags":"Creators, Reflections","slug":"part-time-creator-manifesto","canonical_url":"https://swyx.io/part-time-creator-manifesto","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hkvir806a2jsyqtsqsoh.png"},"title":"The Part Time Creator Manifesto","description":"Why we need more people creating Part Time and how you can do it too. ","category":"essay","tags":["creators","reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hkvir806a2jsyqtsqsoh.png","canonical":"https://swyx.io/part-time-creator-manifesto","slug":"part-time-creator-manifesto","date":"2021-03-14T21:56:04.965Z","readingTime":"12 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/294","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/294/comments","title":"The Part Time Creator Manifesto","created_at":"2022-01-18T00:11:17Z","updated_at":"2024-04-16T02:14:33Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/294/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n*See discussions on [Twitter](https://twitter.com/swyx/status/1370513317379280897), [Reddit](https://www.reddit.com/r/programming/comments/m3wovo/preemptive_pluralization_is_probably_not_evil/), [Lobste.rs](https://lobste.rs/s/wddhi8/preemptive_pluralization_is_probably), and [my mixtape](https://swyx.transistor.fm/episodes/preemptive-pluralization-is-probably-not-evil)*\r\n\r\n**Before you write any code — ask if you could ever possibly want multiple kinds of the thing you are coding.** If yes, just do it. Now, not later.\r\n\r\nA few common examples to illustrate:\r\n\r\n- You assume that one team has many users, and correspondingly, one user belongs to one team.\r\n - Eventually, you find that a user may need multiple teams.\r\n - This is actually fantastic for your business!\r\n - But you are depressed because you now have to **spend 2 months refactoring every line of code and database schema** that assumed the one-to-one mapping 😱 More examples [here](https://twitter.com/andrewingram/status/1370540227954102274?s=20).\r\n- You assume that loading state only has two states — true / false — so you make a boolean `isLoading` variable\r\n - Then you realize you need to track error state, so you do, with `isError`. You do some work to make sure the 4 combinations of states behave intuitively. You write tests for each of them like the good developer you are. Of course. \r\n - Then you realize you need an `isCanceled` state. 8 and counting...\r\n - Eventually you realize every addition or modification takes **exponentially longer** to account for each edge case. It's hard to even tell if you've covered them all. Most don't.\r\n - The solution is [explicit state machines](https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-logic-598i) - but at this point you're too far in to justify a rewrite. \r\n- **Internationalization**. If you winced at that, you know the pain.\r\n- **Pagination**. To quote [Simon Willison](https://twitter.com/simonw/status/1370542711288209411?s=20), co-creator of Django, \"Refactoring an existing non-paginated API to support pagination will break everything. Better to fake pagination but only ever return a single page, just in case\".\r\n\r\nYou can listen to [Ben Orenstein of Tuple discuss this on my mixtape](https://swyx.transistor.fm/episodes/preemptive-pluralization-is-probably-not-evil):\r\n\r\n> **I've done this refactoring a million times**. I'll be like, I thought there would only ever be one subscription team, user plan, name, address , and it always ends up being like, \"Oh, actually there's more.\" I almost never go the other way. What if you just paid the upfront cost of thinking \"This is just always a collection\"?\r\n\r\nDonald Knuth is famous for noting that [Premature Optimization is the Root of All Evil](https://www.explainxkcd.com/wiki/index.php/1691:_Optimization#Explanation) (there's [some nuance to that](https://twitter.com/hillelogram/status/1370514421936689154?s=20), btw). I am very sympathetic to the appeal to simplicity — if \"You Ain't Gonna Need It\", then don't use it. But I think **Preemptive Pluralization** — projecting forward into hypothetical situations when you need N types of a thing — is exempt, even though you are literally optimizing for a future you don't currently live in.\r\n\r\n**It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2.** This is a fundamentally under-appreciated nonlinearity. In other words, Preemptive Pluralization can make the difference between \"sure, I'll add that today\" and \"this is going to take us 2 months and we'll introduce merge conflicts with every other in-progress feature.\"\r\n\r\n## Write Robust Code\r\n\r\n[Requirements volatility is a core problem of software engineering](https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/). As a software engineer, writing code that does what you ask of it today is the bare minimum. Your real skill comes in what happens next — what you do when requirements inevitably change, whether by new feature request or scaling issues arising from I/O or compute bounds.\r\n\r\nIt may not be enough to write code for what you foresee in the near term — those are just more requirements. Software design and architecture is all about making it *easy* to respond to *unforeseen* changes.\r\n\r\nHillel Wayne has proposed calling these [requirement perturbations](https://twitter.com/hillelogram/status/1189024161127190528?s=20). If a small, typical feature request can throw your whole design out of whack, then you have **fragile code**. Clearly you want the opposite of fragile — I am tempted to call it \"Antifragile\" because that gets clicks — but really the best you can hope for is code that mostly doesn't fall apart due to 1-2 standard deviation changes in requirements. In other words: **robust code**. Robust code is [optimized for change](https://twitter.com/swyx/status/1081190319343906816) (more in a future blogpost).\r\n\r\nThe nonlinearity in how expensive it is to make a change comes from the \"[emergent sclerosis](https://twitter.com/david_perell/status/1369534971535298560?s=20)\" of code. Code that is robust to future changes is far cheaper to write today, than when written later, as delayed technical debt that you must pay up before you can proceed to a feature request. Fragile code is like the payday loan lender of technical debt.\r\n\r\n**Preemptive Pluralization creates Robust Code**.\r\n\r\n## Is it Even Premature?\r\n\r\nI'm so committed to not prematurely optimizing that I want to make a final pitch for why Preemptive Pluralization is _not_ premature.\r\n\r\nLet's address obvious criticisms of Preemptive Pluralization:\r\n\r\n- **Increased code complexity**: Functional languages and other abstractions can help make array or matrix operations almost as easy to work with as regular operations.\r\n- **Slow performance from doing extra loops**: Loops only cost significantly when you have lots of N. By definition, if you are pluralizing prematurely, N = 1.\r\n- [Perf bottlenecks from excessive joins](https://twitter.com/mikesherov/status/1370577582614323201?s=20)\r\n- [Misleading code](https://twitter.com/mikesherov/status/1370578158194454528?s=20): your code communicates current state of things. \"Premature\" plurality can lead to communicating wrong thing to new observers of the system.\r\n\r\nUltimately I think what makes something premature or not is your definition of what you need to write:\r\n\r\n- If you view \"code that works today\" as your job, preemptive pluralization is premature. \r\n- If you view \"code that doesn't blow up in my face a year from now\" as your job, then it is not.\r\n\r\n**Just make Robust Code a design requirement from the start** and then figure out what that means :)\r\n\r\n## Related Preemptive Moves\r\n\r\n- Timestamps! [you might as well turn your boolean into a timestamp](https://changelog.com/posts/you-might-as-well-timestamp-it). `created_at`, `updated_at`, `deleted_at` (2022 edit: soft deletions were of some [recent debate](https://news.ycombinator.com/item?id=32156009)). But also `modified_by`, `created_by`, [and more](https://twitter.com/webology/status/1384588570594140160)\r\n- [UUID, Timestamps, and Versions](https://twitter.com/MichaelDrogalis/status/1391454881068720131) - don't use the UUID as a PK.\r\n- [Simon Willison has called](https://twitter.com/simonw/status/1410678459756552198) them [PAGNIs: Probably Are Gonna Need Its](https://simonwillison.net/2021/Jul/1/pagnis/)\r\n\r\n## More Pluralization Points\r\n\r\nMore awkward things to pluralize:\r\n \r\n- Single tenant open source -> Multi tenant hosted service\r\n- Versions -> from no version to v1/v2, or going from \"legacy\"/\"new\" to \"new new\" (hence Stripe [just uses dates](https://stripe.com/blog/api-versioning))\r\n- Number of independently shipping frontends in your company (hence [module federation](https://blog.bitsrc.io/revolutionizing-micro-frontends-with-webpack-5-module-federation-and-bit-99ff81ceb0))\r\n- Number of clouds in your company (you think you will avoid this... until you can't, per [the Hashimoto lemma](https://www.reddit.com/r/devops/comments/91afzz/why_multicloud/))\r\n\r\nMore from [@nivertech on Twitter](https://twitter.com/nivertech/status/1397069627814027264):\r\n\r\n- in-memory→persistent\r\n- single node→cluster\r\n- single language→i18n\r\n- no pagination→pagination\r\n- single user→multi-user\r\n- single tenant→multi-tenant\r\n- single branding→white-labeled\r\n- free→paid\r\n- hard-coded configs→separate config from code\r\n- hard-coded features→feature flags\r\n- online-first→offline-first\r\n- web-first→mobile-first\r\n- no 3rd party API→API-first\r\n- DB-specific→ORM\r\n- local desktop SW→Client/Server\r\n- Client/Server→P2P\r\n- Centralized→Decentralized\r\n- Static→Dynamic\r\n- SSG→SPA\r\n\r\n## Acknowledgements and Further Reading\r\n\r\n- *Thanks to [Jon Wong](https://twitter.com/jnwng/status/1370524452480454665?s=20) for reviewing a draft of this post and contributing the boolean and internationalization examples*\r\n- *Endorsements & Horror stories from [Simon Willison](https://twitter.com/simonw/status/1370541425465520130?s=20), [Ben Orenstein](https://twitter.com/r00k/status/1370520023995985922?s=20), [Andrew Culver](https://twitter.com/andrewculver/status/1370527597885599746?s=20), [Andrew Ingram](https://twitter.com/andrewingram/status/1370540227954102274), [Tanner Linsley](https://twitter.com/tannerlinsley/status/1370567716935888897?s=20), [Ryan Murphy](https://twitter.com/rdmurphy/status/1370544608896192513?s=20), [David Welch](https://twitter.com/david_welch/status/1370916290584403971) and [Khrome](https://twitter.com/KhromeDotDev/status/1370544511408033794?s=20)!*\r\n- Daniel Buckmaster compares this idea to [Sandi Metz's POODR](https://dev.to/crabmusket/comment/1cc36).\r\n- [Martin Gronlund](https://dev.to/martingronlund/comment/1ccce) compares this to [data oriented design](https://www.youtube.com/watch?v=rX0ItVEVjHc).\r\n- [Jared Palmer](https://twitter.com/jaredpalmer/status/1370529091804364801?s=20) and [Daniel Yokomizo](https://twitter.com/dyokomizo/status/1370598973036199936?s=20) mention the [Zero, One, Infinity rule](https://en.wikipedia.org/wiki/Zero_one_infinity_rule) - though this article argues FOR preemptively favoring \"infinity\" over \"one\"","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/preemptive-pluralization-is-probably-not-evil-1mp3","devToReactions":11,"devToReadingTime":6,"devToPublishedAt":"2021-03-12T23:02:49.409Z","devToViewsCount":197,"title":"Preemptive Pluralization is (Probably) Not Evil","published":true,"description":"What if we just assumed we might have two of everything?","tags":"Reflections, Programming, Advice","slug":"preemptive-pluralization","canonical_url":"https://www.swyx.io/preemptive-pluralization","cover_image":"https://i.ytimg.com/vi/INzAc4iI5Zo/maxresdefault.jpg","disclosure":"This is an idea I have been mulling for a while, but have not practiced at scale. Written in a couple hours after a prompt from a podcast."},"title":"Preemptive Pluralization is (Probably) Not Evil","description":"What if we just assumed we might have two of everything? ","category":"note","tags":["reflections","programming","advice"],"image":"https://i.ytimg.com/vi/INzAc4iI5Zo/maxresdefault.jpg","canonical":"https://www.swyx.io/preemptive-pluralization","slug":"preemptive-pluralization","date":"2021-03-12T23:02:49.409Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/295","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/295/comments","title":"Preemptive Pluralization is (Probably) Not Evil","created_at":"2022-01-18T00:11:19Z","updated_at":"2022-08-21T07:34:34Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/295/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Learning in Public on Developer Love","slug":"dev-love-podcast","tags":["LIP"],"venues":"DeveloperLove","date":"2021-03-11T00:00:00.000Z","url":"https://www.heavybit.com/library/podcasts/developer-love/ep-15-learning-in-public-with-shawn-swyx-wang/","description":"In episode 15 of Developer Love, Patrick speaks with Shawn “Swyx” Wang of Temporal. They discuss divorcing your identity from your work, transparency in developer marketing, and the merits of learning in public.","category":"podcast"},{"title":"Devrel and Dev Community on PodRocket","slug":"podrocket-1","tags":["Devrel"],"venues":"Podrocket","date":"2021-03-09T00:00:00.000Z","url":"https://podrocket.logrocket.com/swyx","description":"Ben and Brian talk to Shawn Wang, better known as Swyx, about infinite building, his experience as a Reddit moderator, blogging platforms, scaling developer relations, and more.","category":"podcast"},{"type":"blog","content":"\nIn 2018, I applied to [React Rally](https://2018.reactrally.com/) with the most interesting React problem I could think of: **Why do [the React docs](https://reactjs.org/docs/design-principles.html#scheduling) say that React is not fully Reactive?**\n\nHere's the talk that resulted:\n\n{% youtube nyFHR0dDZo0 %}\n\nYou can also read the accepted [React Rally CFP here](https://twitter.com/swyx/status/1112513571315830784?s=20) with long form details.\n\nIt's a 30 min talk but with a lot squeezed in there, because it was my first conference talk and I wanted to look smart in front of people I admired.\n\n## TL;DR\n\nRecently there has been some talk about [the \"reactivity\" of React](https://twitter.com/wycats/status/1368046172594565123?s=20) on Twitter recently, so I figured I would put up a quick TL;DR:\n\n1. React *could* be fully push-reactive - i even wrote a PoC ([reactive-react](https://github.com/sw-yx/reactive-react)) to explore this. \n \n I later realized this is basically the default state of things if you write any JS user interface with no scheduler.\n\n2. But then you run into problems with [backpressure](https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7), where you need batching, and expensive renders (eventually causing the need for [time slicing and other async rendering techniques](https://www.swyx.io/react-outside/#why-look-outside-react)).\n\n3. The solution is to **push updates** (reacting to external events) into a queue, but only **pull views on demand**. \n\n ![https://pbs.twimg.com/media/Ev0gpXpVoAIzGHa?format=png&name=small](https://pbs.twimg.com/media/Ev0gpXpVoAIzGHa?format=png&name=small)\n \n This is also known as [scheduling](https://reactjs.org/docs/design-principles.html#scheduling). It's possible to implement this inside of an Rxjs-like paradigm, but it would be so finnicky that you'd basically be rebuilding push-pull reactivity inside of the scheduler anyway.\n\nThat's as short as I can make it. Let me know if this makes sense or you have better ways to put this!\n\n*P.S. I was invited back for React Rally 2020, where I presented on [Growing a Meta-Language](https://www.youtube.com/watch?v=18F5v1diO_A), briefly sketching out some ideas for [React Single File Components](https://www.swyx.io/react-sfcs-here/).*","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/tl-dr-of-why-react-is-not-reactive-p7p","devToReactions":15,"devToReadingTime":2,"devToPublishedAt":"2021-03-06T20:48:22.718Z","devToViewsCount":565,"title":"TL;DR of Why React is Not Reactive","published":true,"description":"A recap of my first ever conference talk","tags":"React, Speaking, Summary","slug":"ReactRally","canonical_url":"https://www.swyx.io/ReactRally","cover_image":"https://user-images.githubusercontent.com/6764957/110220121-9f0aa500-7efe-11eb-8e7f-f2baddde1bbb.png"},"title":"TL;DR of Why React is Not Reactive","description":"A recap of my first ever conference talk ","category":"note","tags":["react","speaking","summary"],"image":"https://user-images.githubusercontent.com/6764957/110220121-9f0aa500-7efe-11eb-8e7f-f2baddde1bbb.png","canonical":"https://www.swyx.io/ReactRally","slug":"reactrally","date":"2021-03-06T20:48:22.718Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/296","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/296/comments","title":"TL;DR of Why React is Not Reactive","created_at":"2022-01-18T00:11:21Z","updated_at":"2022-06-18T17:47:45Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/296/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n*This post has been discussed at further length in podcasts with [GitHub's Office of the CTO](https://swyx.transistor.fm/episodes/weekend-drop-why-invest-in-developer-community-github-octo-speaker-series) and [Orbit.Love](https://swyx.transistor.fm/episodes/weekend-drop-marketing-to-developers-learnin-in-public-and-communities-as-marketplaces-with-patrick-woods-on-the-developer-love-podcast).*\n\nThere's a big shift going on in how developer tools companies approach their userbase. In the past week alone, I've had 3 chats with startups that all concluded with some version of:\n\n> \"By the way, we're really looking to ramp up our community effort right now. If you can think of anyone who can help us build a developer community, can you send them my way?\"\n\nOne week, three pings. If this isn't a big trend already, it's at least worth writing about (per [my Three Strikes rule](https://www.swyx.io/three-strikes/)). **Who builds developer communities, why are companies investing in them, and *why now*?**\n\n![Developer Journey](https://user-images.githubusercontent.com/6764957/109877182-a71fd600-7cad-11eb-9c9e-48a8c79668ad.png)\n\n## Who's Job Is It Anyway?\n\n \n\nDevelopers have had a long history of spontaneous community formation dating back to the IRC and BBSes of yore. (*Misery loves company?*) There is still a strong ethos of self organized community in modern dev culture, but the vast majority of this lies on the shoulders of a small group of under-funded volunteers.\n\nBut in the last couple decades, company-centric communities, where [**the community is almost the entire competitive moat**](https://hbr.org/2020/01/when-community-becomes-your-competitive-advantage) of the company, have become a central part of developer life: \n\n- **StackOverflow** serves [11m visits a day](https://stackexchange.com/sites?view=list#traffic) with community contributed Q&A's and sells ads and knowledge base software on the side.\n- **GitHub** builds developer collaboration software, but at its core is a [56m-developer](https://octoverse.github.com/) social network atop Git.\n- **Hacker News** (serving at least [4m a day](https://news.ycombinator.com/item?id=16076041)) is a big part of Y Combinator's unfair advantage in getting both founder mindshare and hiring talent.\n\nYou would expect that this realization would spawn a dedicated discipline to prioritize it, in the same way that [Startups = Growth](http://www.paulgraham.com/growth.html) justifies the need for a [Growth Hacker](https://andrewchen.co/how-to-be-a-growth-hacker-an-airbnbcraigslist-case-study/) at every company serious about growth.\n\nBut as far as I can tell, it hasn't happened.\n\nSure, companies do hire community managers to groom their forums and post inoffensive memes (*j/k of course, good community managers do much more than this*). Some developer advocates may focus on community, but most developer evangelists create content and do outreach to other communities, to \"meet developers where they are\". Marketing folks might run the company mailing list, host webinars, or organize conferences, all mini-communities in their own right. Everyone intuitively gets the importance of community, and does their best within given boundaries. \n\nBut who's job is it to define the overall community strategy, and has the resources to develop it as aggressively as engineering? If this describes someone in your management team, great. But often the community builders are at the bottom of the totem pole.\n\nThe Venn diagram of people who can scale code and people who can scale community is going to be [exceedingly valuable](https://www.heavybit.com/library/podcasts/jamstack-radio/ep-51-community-over-code-with-shawn-wang-of-netlify/). You don't strictly **need** to be technical to run community — Ben Popper, StackOverflow's Director of Content, is [still new to code](https://stackoverflow.blog/2019/10/22/ben-popper-is-the-worst-coder-in-the-world/) — but developers can tell when they aren't talking to a technical person and that limits the depth of conversation. A technical community builder will have instincts informed by direct personal experience, and be able to empathize with member needs and make targeted recommendations.\n\nThe job title probably won't stay \"community builder\", by the way. [Patrick McKenzie once observed](https://twitter.com/patio11/status/1299217439671025665?s=20) that the DevOps movement led to \"a once-in-a-lifetime upgrade in status, impact, authority, and career prospect\" for sysadmins. I think a similar rebrand is due. As community goes from a side activity to a core driver of product, support, and marketing ([great thoughts from Lisa Xu on this](https://blog.usejournal.com/the-rise-of-the-community-department-232d427de65f)), the status and pay change will need a new name for people to rally behind. \n\nWhat shall we call it? \"Community [Tummler](https://dangerouslyawesome.com/2014/04/community-management-tummling-a-tale-of-two-mindsets/)\"? \"Community Developer\"? Let me know if you have a better name. I've settled on \"Technical Community Builder\" for now, in the same way that Microsoft and Amazon have Technical Product Managers.\n\n## Why Invest in Community?\n\nTL;DR: **Traditional marketing and support isn't cutting it**.\n\nDevtools companies get that \"build it and they will come\" usually doesn't work. The sub-industries of technical marketing and developer relations are well developed enough now that there are [books](https://learn.samjulien.com/getting-started-in-developer-relations) and [conferences](https://www.devrelcon.net/) about it. We get that marketing can be just as important as product. (*Let's leave the topic of \"how much devrel and marketing overlap\" for a future post...*)\n\nBut a buyer's journey can start long before — and continue long after — their first contact and passage through the marketing funnel:\n\n- Marketing attribution in developer tools is kayfabe — we play at tracking Twitter clickthroughs and podcast direct response, but everyone in marketing knows you need at least [7-13 touches](https://www.socialmediatoday.com/content/seven-touches-basic-marketing-principle-action) before someone really considers you. As a developer I often wait out *an entire year* after hearing about something before even trying it out, just to see if it has staying power.\n- After buying into a solution, I still need help to be successful with the tool. Developer tools are ultimately creative tools, and sometimes the imagination needs a little inspiration. Setup hurdles need to be overcome. If I buy something and end up not using it, it's going into the do-not-use pile for a very, very long time before I ever give it another shot.\n\nThis adoption process needs to turn from a mostly-transactional, finite game, to a relationship-based infinite game. You might envision Community as carefully designing the broader environment around the traditional sales and marketing funnel:\n\n![Developer Journey](https://user-images.githubusercontent.com/6764957/109989150-31fee000-7d43-11eb-9818-59daf4797147.png)\n\nOr you could **reject the funnel** altogether. To quote [Patrick Woods](https://twitter.com/patrickjwoods/):\n\n> \"Characterizing the developer journey as a linear funnel doesn’t really tell the whole story, as it’s essentially scoped to awareness and conversation — the journey is much more complex. I think onboarding to the community itself, retaining over time, and advocating for others to join, is a huge part of the journey... In this world, you want to understand how folks are engaging with the community *as well as* with the company/product, with product metrics (activation, adoption, etc) existing as second-order effects of the community. [The Orbit Model](https://github.com/orbit-love/orbit-model), versus the funnel, tries to tell this nonlinear and comprehensive story.\"\n\nWhen most developers make technical choices, you are just as likely to hear them praise the strength of the \"ecosystem\" (aka a community, with thriving third parties) as they do the core technical merits. In terms of [the Rogers curve](https://twitter.com/swyx/status/1360882870638665731), this is the kind of argument made by \"mainstream\" developers:\n\n![Community crossing the chasm](https://user-images.githubusercontent.com/6764957/109990452-5e672c00-7d44-11eb-8a0b-159491db2d6b.png)\n\n**Community is how developer tools cross the chasm** from early adopters to the majority. Every devtools company looking to scale eventually has to figure this out, whether consciously or otherwise. \n\nOther arguments in bullet point form, but feel free to request elaborations:\n\n- **Retention**: Build product and they may not come, but **build community and they will stay.**\n- **Hiring**: Community can just as easily net you employees as it does users and customers.\n- **Marketing**: Community is highest-signal social proof/word of mouth you **cannot** buy.\n- **Moat**: Community is a \"feature\" that cannot be copied. By Hamilton Helmer's 7 Powers Framework (*[the strategy framework du jour](https://www.sachinrekhi.com/7-powers-hamilton-helmer)*), Community helps you gain Network Economies, increase Switching Costs and Corner one of the most precious resources on Earth: Developers!.\n- **Scaling**: Community is many-to-many, where Marketing/Devrel is one-to-many. The value of a community-focused user base scales by Metcalfe's law instead of Sarnoff's law. A thriving third-party *ecosystem* scales by Reed's law — even better!\n\n ![Reed's law](https://user-images.githubusercontent.com/6764957/109877251-bd2d9680-7cad-11eb-8a18-4b4330745d6c.png)\n\n- **Risks**: But you also do not \"own\" your community - the best you can do is lead by example, encourage helpful behavior, and enforce clear codes of conduct. Community is \"user-generated content\", and that bears with it great responsibility. Poor handling can [backfire horrifically](https://www.fastcompany.com/90401254/ea-gets-a-guinness-world-record-for-the-most-downvoted-comment-in-reddit-history).\n- **Free Work?** Community members can answer questions to each other and develop integrations to help you grow beyond your limited resources. To avoid expecting members to \"do free work\", this effort must be reciprocated by careful stewardship.\n- **Lifespan**: One of the best measures of community success is when your users' relationship with you outlasts their current employment. **[Come for the software, stay for the community](https://hunterwalk.medium.com/coming-for-the-content-staying-for-the-community-started-with-video-games-or-maybe-religion-5083f3773a2)**. Help your users get jobs, help your customers hire your users, and you will have fans for life.\n- **Open Source**: Commercial Open Source companies must foster a viable community to be successful open source, rather than being de-facto \"source available\". In [Nadia Eghbal's terms](https://www.thepullrequest.com/p/nadia-eghbal), more Federations than Stadiums, but both are definitely preferable over Clubs and Toys.\n- **Product Insights**: Speaking to users helps you build things people want, but often these conversations are done by outreach (user survey or feedback session) rather than observation (*in situ,* natural environment). Community is where your deepest and most authentic user insights will originate.\n\nAll in all — **a devtools company that prioritizes an engaged and inclusive developer community will run circles around one that doesn't.**\n\nThere are multiple ways to do this well, but I am particularly fond of community that \"serves a bigger purpose\". A community that is strictly centered around a company (eg Dreamforce → Salesforce) is less appealing than one with room for multiple players (eg No Code → Webflow, Jamstack → Netlify), at least while you aren't yet a decacorn. Every great community is a great marketplace (*tbc in a future post...*), and every marketplace is a kind of platform, and every platform must respect [the Bill Gates Line](https://twitter.com/swyx/status/1360729115372920832) with its participants.\n\n## Why Now?\n\nDev Community has felt fringe for as long as I've been involved. I always felt like a bit of a middle schooler talking about [my /r/reactjs work](https://www.swyx.io/moderating-rreactjs/) to companies, like \"that's nice dear, but let's talk about more serious work now\". I have friends running other popular Discords and forums that feel the same way.\n\nThat's why this shift is meaningful. This thing we used to do for fun, in service to our community, is suddenly a legitimate and highly in-demand skillset.\n\nI don't know why community building is trendy again (there have been [several](https://www.listennotes.com/podcasts/village-globals/hacking-communities-with-KoTc4_tQfZw/) [waves](https://www.listennotes.com/podcasts/village-globals/greg-isenberg-on-the-world-UPO9NJc25qz/)), but D'Arcy Coolican at a16z nailed the current wave with his thesis on [the Power of Social+](https://a16z.com/2020/12/07/social-strikes-back-social-plus/). Greylock is promoting the virtues of [Community-Led Growth](https://corinneriley.medium.com/community-led-growth-the-product-led-growth-expansion-pack-b474ab9a7940) and investing aggressively. [Patrick Woods also observes](https://softwareengineeringdaily.com/2021/03/25/developer-community-management-with-patrick-woods-and-josh-dzielak/) that VCs are pressuring founders to “have a community strategy” from the outset, and noticing that devrel hires are moving earlier from employee #20 to employee #5.\n\nClearly the pandemic forcing everyone online was a forcing function: \n\n- People were displaced from their existing IRL communities and needed a replacement\n- Geography doesn't matter for online community (*modulo timezones*)\n- Online communities are far more discoverable (searchable, join with a URL) and scalable (no room limits on community!)\n\nCommunity-building software has also gotten a lot better:\n\n- Realtime: Twitch and [Discord](https://www.swyx.io/slack-fumble/) and [Clubhouse](https://www.swyx.io/clubhouse-hate/)\n- Conferences: [Hopin](https://techcrunch.com/2020/11/10/hopin-raises-125m-for-its-online-events-platform-on-the-back-of-surging-growth/) and [Bevy](https://techcrunch.com/2020/05/19/bevy-series-b/)\n- Async: Circle ([where I am an investor](https://techcrunch.com/2021/02/16/the-creator-movement-is-entering-primetime-and-so-is-circle-with-a-fresh-4m/)), Forem (the creators of Dev.to), and Hashnode\n- Metrics: [Orbit.love](http://orbit.love) ([Martin Casado writeup here](https://a16z.com/2020/12/02/investing-in-orbit/)) helps quantify developer engagement ([Commsor](https://techcrunch.com/2021/02/20/chief-community-officer-is-the-new-cmo/) is less dev centric but noteworthy) and [Weavr](https://weavr.ai/) offers a \"Front for dev community\".\n- Aggregators: [Common Room](https://greylock.com/portfolio-news/networkedusers/)\n\nI also think the developer relations field has reached a level of maturity where companies are feeling the limits of one-to-many content creation and hiring [developer influencers](https://softwareengineeringdaily.com/2019/12/19/no-code-with-shawn-wang/), so they are exploring other ways to scale their community engagement as [an enablement role](https://www.swyx.io/enablement-vs-ownership).\n\n## Become a Technical Community Builder\n\nOne of the telltale signs that this field is rife with opportunity is how much cruft it lacks. There's no book or course or conference teaching you how to do this job. There's no set career path, and \"[Chief Community Officer](https://techcrunch.com/2021/02/20/chief-community-officer-is-the-new-cmo/)\" isn't really a thing. We don't even have a commonly-accepted name for this role! And we certainly lack role models and thought leaders and the rest of the paraphernalia that comes with a mature industry.\n\n- If that excites you, rather than intimidates you, [get in touch with me](https://twitter.com/swyx) and I'll send you to the exciting startups hiring for this role: [WorkOS](http://workos.com/), [Render](http://render.com/), [Begin](https://begin.com/), [Sourcegraph](https://about.sourcegraph.com/company/careers#marketing) and more. (If you're hiring: you can add yourself to [the technical-community-builders repo](https://github.com/sw-yx/technical-community-builders) here!)\n- If you're starting a company to help Technical Community Builders (or whatever we end up calling this), [you can browse my angel network here](https://github.com/sw-yx/devtools-angels/) for investment and advice.\n- If you're building a community, check Patrick's [tactical guide to kickstarting your community\n](https://orbit.love/blog/a-tactical-guide-to-kickstarting-your-community/)\n- If you just want to keep up on this space, you can come subscribe to [the DX Circle blog](https://codingcareer.circle.so/c/dx-blog/technical-community-builder-is-the-hottest-new-job-in-tech) where we will discuss Developer Communities, Developer Tools, Documentation, and everything else Developer Experience!\n\n*deep thanks to [Patrick Woods](https://twitter.com/patrickjwoods), [Uma Chingude](https://twitter.com/umanagineer?lang=en), [Gareth Dwyer](https://twitter.com/sixhobbits?lang=en), [Rob Ocel](https://twitter.com/robocell/status/1367222048754401280?s=20) and others for reviewing drafts of this post.* ","frontmatter":{"source":"devto","devToUrl":"https://dev.to/dx/technical-community-builder-is-the-hottest-new-job-in-tech-8cl","devToReactions":61,"devToReadingTime":10,"devToPublishedAt":"2021-03-04T16:03:47.938Z","devToViewsCount":733,"title":"Technical Community Builder is the Hottest New Job in Tech","published":true,"description":"What if the real product was the friends we made along the way?","tags":"DX, Community","slug":"community-builder","canonical_url":"https://codingcareer.circle.so/c/dx-blog/technical-community-builder-is-the-hottest-new-job-in-tech","cover_image":"https://user-images.githubusercontent.com/6764957/109992808-996a5f00-7d46-11eb-9078-fc10e97b4d87.png"},"title":"Technical Community Builder is the Hottest New Job in Tech","description":"What if the real product was the friends we made along the way? ","category":"note","tags":["dx","community"],"image":"https://user-images.githubusercontent.com/6764957/109992808-996a5f00-7d46-11eb-9078-fc10e97b4d87.png","canonical":"https://codingcareer.circle.so/c/dx-blog/technical-community-builder-is-the-hottest-new-job-in-tech","slug":"community-builder","date":"2021-03-04T16:03:47.938Z","readingTime":"10 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/297","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/297/comments","title":"Technical Community Builder is the Hottest New Job in Tech","created_at":"2022-01-18T00:11:23Z","updated_at":"2022-06-18T17:47:46Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/297/reactions","total_count":1,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":1,"eyes":0}}},{"type":"blog","content":"\nMuch is made of [the tradeoff between Quality and Consistency](https://www.swyx.io/quality-vs-consistency/). But have you ever wondered how Broadway musicals achieve their world renowned quality on launch day so consistently? They [workshop it](https://en.wikipedia.org/wiki/Workshop_production) first! \n\n{% youtube uPEVkOjtldE %}\n\nThe practice of workshopping on Broadway began with [A Chorus Line](https://en.wikipedia.org/wiki/A_Chorus_Line#Production_history) in the 1970s and is now a staple part of the creative process. \n\nHamilton, the hit musical, spent [two years](https://en.wikipedia.org/wiki/Hamilton_(musical)#Background) in workshop mode before graduating to Off-Broadway. \n\n[![the Hamilton cast in workshop mode at Vassar College](https://pbs.twimg.com/media/DRVA1RQWsAAa6-U?format=jpg&name=large)](https://twitter.com/Lin_Manuel/status/942730985669644288/photo/1)\n\nExtensive changes to cast, book, and stage continued to be made over *another 6 months*, leading up to the full Broadway debut of the musical you know and love today.\n\nThe key element of the workshop is that you are only performing your work-in-progress material for a small audience. Everyone in the room is sworn to secrecy, and understands that everything is subject to change. They get to see something before everyone else, and in exchange, you get their feedback.\n\nYou see this pattern in a lot of other creative, high stakes pursuits. [Avengers Endgame made notable cuts](https://screenrant.com/avengers-endgame-katherine-langford-deleted-scene-response/) based on screen tests. [Dave Chapelle tests material](https://www.latimes.com/entertainment/tv/la-xpm-2013-mar-13-la-et-st-chappelle-returns-20130313-story.html) at the Comedy Cellar before doing new specials.\n\nYou can tier workshops for yourself. For example: \n\n- You write consistently every day, but don't publish everything.\n- You can return to your drafts a day later to see if it still makes sense or sparks joy.\n- The ones that make it through your self filter can be shared with a peer review group or mastermind ([join mine here](https://www.learninpublic.org/#buy)), before final publication.\n\nThis is how you build a system for quality, atop a baseline of consistency.\n\nEphemerality, privacy, and concision can be useful workshop boundaries. My most successful talk started life as a [tweet](https://twitter.com/swyx/status/1100809424963219456), then a [blogpost](https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-react-hooks-really-work/), then a [workshop](https://twitter.com/danieljcafonso/status/1266099074421456902?s=20), before arriving at [the final performance](https://www.youtube.com/watch?v=KJP1E-Y-xyo). In the same way, you can use group chats, meetups and Clubhouses to workshop ideas because **the whole point is that they are smaller**, semi-private venues — where you can still get feedback before anything is \"final\".\n\nA workshop creates a low-risk buffer for failure. **Consistency consistently goes in, Quality occasionally comes out**. \n\nBy definition, most of what the public sees is just the quality that makes it out. \n\nBut only you — and a small group of friends — will know the work that went on behind the scenes.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/workshopping-1ec0","devToReactions":10,"devToReadingTime":2,"devToPublishedAt":"2021-03-04T02:32:13.052Z","devToViewsCount":168,"title":"Workshopping","published":true,"description":"Produce Consistency, Publish Quality by buffering.","tags":"Reflections, Blogging, Creation","slug":"workshopping","canonical_url":"https://www.swyx.io/workshopping","cover_image":"https://pbs.twimg.com/media/DRVA1RQWsAAa6-U?format=jpg&name=large"},"title":"Workshopping","description":"Produce Consistency, Publish Quality by buffering. ","category":"note","tags":["reflections","blogging","creation"],"image":"https://pbs.twimg.com/media/DRVA1RQWsAAa6-U?format=jpg&name=large","canonical":"https://www.swyx.io/workshopping","slug":"workshopping","date":"2021-03-04T02:32:13.052Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/298","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/298/comments","title":"Workshopping","created_at":"2022-01-18T00:11:25Z","updated_at":"2022-06-18T17:47:46Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/298/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Talking Svelte on Purrfect.Dev","slug":"svelte-purrfect","tags":["Temporal"],"venues":"Purrfect","date":"2021-03-04T00:00:00.000Z","url":"https://codingcat.dev/podcast/1-15-whats-up-with-svelte","description":"I joined Brittney and Alex to talk Svelte and SvelteKit","category":"podcast"},{"type":"blog","content":"\nI grew up in Singapore and moved to the US for college and work, so I have a good sense of what the average American thinks about Singapore. I think there is something they seriously under-appreciate: **Singapore Mixed Rice**. \n\nIts [Wikipedia entry](https://en.wikipedia.org/wiki/Economy_rice) is wholly unappetizing. Let's fix that.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/198zbwawk6xizv37de74.jpg)\n\nThis dish costs 2.45 USD (GDP per capita is the same in both countries), isn't actively bad for you and is enjoyed by rich and poor alike. \n\nBy contrast, you cannot get a decent meal in US (coastal) cities for under $10 without resorting to fast food. This has knock-on effects on healthcare.\n\n**Mixed Rice is the great leveler of Singaporean society and nobody talks about it.**\n\nWhen Americans talk about Singapore, they often talk about three things: the [public housing](https://en.wikipedia.org/wiki/Public_housing_in_Singapore) system, [Michael Fay](https://en.wikipedia.org/wiki/Michael_P._Fay#Theft_and_vandalism_in_Singapore), and most of [the locations in *Crazy Rich Asians*](https://www.vogue.com/article/crazy-rich-asians-movie-singapore-travel-guide). If you're particularly wonky, you might think about [the civil service](https://marginalrevolution.com/marginalrevolution/2018/06/take-singapore-works-well.html), [healthcare](https://www.nytimes.com/2017/10/02/upshot/what-makes-singapores-health-care-so-cheap.html), and [education system](https://www.economist.com/leaders/2018/08/30/what-other-countries-can-learn-from-singapores-schools). \n\nAll great points, but if you've spent most of your adult life straddling both countries like I have, they can often feel like putting the idea of the country on a pedestal. Normal people don't think in terms of healthcare or housing policy. \n\nBut food? Everyone can get behind food. It's the one thing that unites literally every overseas Singaporean.\n\n## Mixed Rice as Choice Factory\n\nThe reason mixed rice is \"mixed\" is that all the food in a mixed rice store is **modular**. You start with rice (optional), and then pick whatever ingredients you want.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3kytw559k7x0t3se4wps.jpg)\n\nA standard meal might take 3-4 ingredients (e.g. 2 veg, 1-2 meats). So the 38 dishes in this picture generate **between 8,436 to 73,815 unique meals** to serve every possible preference. Try putting that on a menu?\n\nTrick question: **there is no menu**. You point at the thing you want and they put it on your plate. Think about this every time you sit down at a restaurant and stare at a long inscrutable list of names.\n\nMixed Rice is primarily served in [hawker centres](https://en.wikipedia.org/wiki/Hawker_centre) and [food courts](https://en.wikipedia.org/wiki/Food_court), which themselves are choice factories - a dining group can eat together but pick their meal according to individual preference. \n\n## Mixed Rice as Business Model\n\nThe low price of mixed rice surely owes a lot to the shared-real-estate economics of food courts, sometimes with explicit subsidy from the government, sometimes implicit with migrant workers. \n\nBut I think it is also due to the **high-volume** nature of the business model. Mixed rice stalls, in direct opposition to restaurants and even their neighboring hawker stalls, adopt a factory-line-and-warehousing model of production. All food is precooked, so there is zero wait time for prep. Customers line up with one worker, who then packs what they pick, and the pair move down the line right to the cashier. The worker then cycles back to start processing the next customer.\n\nOnce you start, your meal can be in your hands in 2-3 minutes. Usually 2-3 workers do this in parallel so there is a constant flow of customers down the line. \n\nThink about this the next time you sit down at a restaurant, order something, wait 15 minutes for to be served, and when you're done, waiting 15 minutes for the bill to come to you.\n\nWhile a normal hawker stall might handle 10-20 customers per meal time, a mixed rice stall can process 100-200. Amortizing the cost of workers over this higher volume, as well as not directly paying for seating, leads to lower unit prices. (*Though its worth noting that [rent is higher](https://www.youtube.com/watch?v=PHrKFm5b3pQ) and the number of mixed rice stalls is typically limited to 1 per food court*)\n\n## Mixed Rice as Inflation Hedge\n\nHaving the \"floor\" of your cost of living be so cheap has a lot of knock-on effects for your economy:\n\n- Lower-income earners can save more, or even pass on their low cost of living to other essential businesses (the median cost of a men's haircut in Singapore has plummeted from $10 to $2 in the last decade — THAT's a story I'd love to learn more about)\n- The poor don't make themselves so unhealthy that their healthcare costs explode\n- It costs about the same to eat out as it does to cook - if health permits, the average person can **eat out for every single meal** and save hours of life per day to do something more productive\n- That they can live so cheap and yet have *choice* and some agency in their lives has immeasurable quality of life benefit\n\nIn my memory, the inflation of mixed rice itself is negligible - I'd guesstimate 20% over the last 20 years. I have no proof and a limited understanding of how all the contributing factors came together to produce this result, but I have a strong suspicion that managing Cost of Food is the baseline to managing Cost of Living which is the baseline to keeping \"real\" inflation in check (Food is traditionally excluded from [Core Inflation](https://www.investopedia.com/terms/c/coreinflation.asp) measures, but of course it is inescapable for the average citizen).\n \n## Conclusion\n\nI hope to have expanded your notion of a key part of Singaporean living today. Americans who know Singapore food tend to gravitate to the delicacies - [Chilli crab](https://en.wikipedia.org/wiki/Chilli_crab), [Laksa](https://en.wikipedia.org/wiki/Laksa), [Chicken rice](https://en.wikipedia.org/wiki/Hainanese_chicken_rice). But you can't have those every day, especially if you want any meaningful amount of vegetables in your diet. \n\nI often look at American food courts and wonder how something that works so well for Singapore (cheap and not-horribly-unhealthy) can work so badly there. The closest analog America has are the Panda Express stores, which offers far less choice, fries everything beyond recognition, and charges you $10-15. I do hope someone figures out how to replicate this model someday.\n\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ex3nbborg17ke40v6vjj.jpg)\n\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/love-letter-to-singapore-mixed-rice-1fep","devToReactions":11,"devToReadingTime":5,"devToPublishedAt":"2021-02-28T21:29:33.825Z","devToViewsCount":179,"title":"Love Letter to Singapore Mixed Rice","published":true,"description":"The most underrated part of Singapore that foreigners don't appreciate","tags":"Reflections, Singapore","slug":"mixed-rice","canonical_url":"https://www.swyx.io/mixed-rice","cover_image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/198zbwawk6xizv37de74.jpg"},"title":"Love Letter to Singapore Mixed Rice","description":"The most underrated part of Singapore that foreigners don't appreciate ","category":"note","tags":["reflections","singapore"],"image":"https://dev-to-uploads.s3.amazonaws.com/uploads/articles/198zbwawk6xizv37de74.jpg","canonical":"https://www.swyx.io/mixed-rice","slug":"mixed-rice","date":"2021-02-28T21:29:33.825Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/299","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/299/comments","title":"Love Letter to Singapore Mixed Rice","created_at":"2022-01-18T00:11:27Z","updated_at":"2022-06-18T17:47:46Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/299/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Third Age of Javascript","slug":"third-age-of-js","categories":["JavaScript"],"description":"In this stream, we chat to Shawn Swyx Wang, developer, author of the Coding Career Handbook, and learn-in-public advocate. Come along and ask him your questions!","instances":[{"venue":"JSWorld","date":"2021-02-25","tweet":"https://twitter.com/swyx/status/1364977488657412101","video":"https://www.youtube.com/watch?v=8cQ7ukBbrbA"},{"venue":"JSNation Preview","date":"2021-05-20","url":"https://portal.gitnation.org/contents/the-third-age-of-javascript","video":"https://www.youtube.com/watch?v=Nan1hqQ90_4"},{"venue":"JSNation Live","date":"2021-06-09","description":"My first time as opening keynote speaker","video":"https://www.youtube.com/watch?v=7sowEZQa3Tc&t=5740s"},{"venue":"Swyx YouTube","date":"2021-04-04","video":"https://www.youtube.com/watch?v=UKDjW0uRZGo"},{"venue":"CityJS Conf","date":"2021-07-31","video":"https://www.youtube.com/watch?v=oRnli8zrEBM"},{"venue":"Web Directions Global Scope","date":"2021-06-11","url":"https://webdirections.org/blog/web-directions-hover-21-session-spotlight-temporal-modern-dates-and-times-in-javascriptthe-third-age-of-javascript/"},{"venue":"Infobip Shift","date":"2021-10-13","tweets":["https://twitter.com/tlakomy/status/1435256423315877889?s=20","https://twitter.com/m4d_z/status/1435253892523171843?s=20","https://twitter.com/giltayar/status/1435258266729205762?s=20","https://twitter.com/CompuIves/status/1435258964242059268?s=20","https://twitter.com/kenny_io/status/1435313957099745282?s=20","https://twitter.com/jen_ayy_/status/1435568073700958210?s=21","https://twitter.com/kenny_io/status/1435639380991954946?s=21","https://twitter.com/giltayar/status/1435876021681758208?s=21","https://twitter.com/dabit3/status/1436932234263597058?s=21"],"video":"https://www.youtube.com/watch?v=lU-zEoGqjc8"}],"category":"talk","date":"2021-02-25T00:00:00.000Z"},{"title":"Scrimba Livestream - Q&A","slug":"scrimba-livestream","categories":["Careers"],"description":"In this stream, we chat to Shawn Swyx Wang, developer, author of the Coding Career Handbook, and learn-in-public advocate. Come along and ask him your questions!","instances":[{"venue":"Scrimba","date":"2021-02-25","tweet":"https://twitter.com/scrimba/status/1364579629634363396?s=21","video":"https://www.youtube.com/watch?v=t6A0jVDRymw"}],"category":"talk","date":"2021-02-25T00:00:00.000Z"},{"title":"Prerecording Conference Talks - 15 Tips to Make It Bigger and Better","slug":"prerecording-conf-talks-gdcfp-day","categories":["Careers"],"description":"MI prepared this talk for Global Diversity CFP Day 2021 and here is the high quality backup for posterity!","instances":[{"venue":"GDCFP Day","date":"2021-02-20","video":"https://www.youtube.com/watch?v=Tz1Fotm-hnk"}],"category":"talk","date":"2021-02-20T00:00:00.000Z"},{"type":"blog","content":"\nI have just received my copy of Stefan Baumgartner's [TypeScript in 50 Lessons](https://typescript-book.com/) in the mail. It is the first book for which I have served as technical reviewer!\n\n{% twitter 1361712610593316866 %}\n\nI was enormously tickled not just to see my name in the Acknowledgements, but also to learn that apparently technical reviewing is important enough to make it on to the official book credits!\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wdbkd8oc4ck9se3qiwgf.jpg)\n\n\n*(For what its worth - I got a small stipend for reviewing, and zero dollars whether or not you buy the book - but I'm writing it up anyway because I thoroughly enjoyed both the book and the process of reviewing it!)*\n\n\n## Another TypeScript Book?\n\nIn general, one might wonder why the need for another TypeScript book. [Orta](http://twitter.com/orta) has led a total revamp of the docs since he joined the team, and now the official docs are much more readable and well organized than when I first started with them. \n\nSome folks might also recall that I did a well received [review of Boris Cherny's Programming TypeScript](https://twitter.com/swyx/status/1135525665971695617) in 2019. I even did a book report on it at a TS NYC meetup! (unrecorded, sadly)\n\nThis is something Stefan struggled with for months. When he originally pitched me on working with him, the brief was no more complicated than \"write a TS book for Smashing Magazine\". Fortunately, [Markus Seyfferth](https://twitter.com/indysigner)'s intuition shone through here and advised Stefan to move toward a \"quick lesson approach\" in the style of the enormously influential [CSS Secrets](https://twitter.com/csssecretsbook) (which [I have also reviewed](https://twitter.com/swyx/status/996094173081194498/photo/1)).\n\n**The truth is that there is no one right way to approach a topic, much less teach it.** You can read through a dry list of rules and documentation, but it is quite another proposition to read realistic examples and explore ways to problem solve through the eyes of an expert. This is what *50 Lessons* does for TypeScript, going from introductory (what is TypeScript really about?) to expert (generics, variadic tuples, `infer`, and more).\n\n[Stefan's blog](https://fettblog.eu/) speaks to his expertise and absolute mastery of the subject matter. His blogpost on [Low Maintenance Types](https://fettblog.eu/low-maintenance-types-typescript/), though new, is already an instant classic, and his post on [Why I don't use React.FC](https://fettblog.eu/typescript-react-why-i-dont-use-react-fc/) is often quoted in the React + TS commmunity. I can't do justice to the rest - just [check out his archive](https://fettblog.eu/articles/)!\n\nWhat you get with the book, over the blog, is worked examples well organized for both a gentle introduction (when read from end to end) and revisiting on demand (when need arises). Check the full list of 50 lessons on [the book's site](https://typescript-book.com/). Even if you think you already know TypeScript, here's likely *something* here that could probably know better.\n\n## Learning TypeScript in Public\n\nOne of the most unexpected outcomes of [learning in public](https://www.swyx.io/learn-in-public/) for a few years is that opportunities come **inbound** to you. The reason I stress the importance of **inbound** opportunities is two-fold: people find you based on your interests, and you get opportunities that you would never have considered yourself suitable for.\n\nThis is how I felt when Stefan first approached me in 2019:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vnbybdj8kn8jp0lf1l39.png)\n\nAt that point I had only been curating [the React TypeScript Cheatsheet](https://react-typescript-cheatsheet.netlify.app/) for less than a year. I had [never](https://twitter.com/swyx/status/1107814140792524801?s=20) served as a technical reviewer and almost turned it down because I didn't feel qualified. But I took up the challenge anyway. It turned out that I didn't have much to worry about - Stefan was the perfect collaborator, and came back with a full manuscript about a year later that was already very well fleshed out.\n\nNot having ever written a book before, I focused on double-checking the technical accuracy of the code samples and whether or not I could see the recommendations working in my former (React + TS Design System) team. I think it's also helpful not to know *too* much - having a beginner's mind is something valuable since that is the target audience of the book. If a sentence requires too much context to parse, it is probably worth breaking out or restating. In terms of the [3 Types of Editing](http://www.keypersonofinfluence.com/3-types-of-editing-and-which-is-right-for-you/), I counted myself lower down (copyediting and proofreading) rather than making more sweeping changes (structural editing).\n\nI think the way that Stefan has built out his TypeScript expertise over the years is also exemplary of the #LearnInPublic ethos. He put his hometown, Linz (Austria) on the map with the quality events he runs, from [ScriptConf](https://scriptconf.org/) to [TSConf EU](https://tsconf.eu/). His [blog](https://fettblog.eu/articles/) and [guides](https://fettblog.eu/guides/) map out years of public learning with an incredible amount of polish and thoughtfulness. I'm incredibly inspired by him and honored to work with him in some small capacity.\n\n\n> P.S.: if you do check out the book, look for a little cameo by yours truly on page 182!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/reviewing-typescript-in-50-lessons-10m4","devToReactions":127,"devToReadingTime":4,"devToPublishedAt":"2021-02-18T15:48:57.560Z","devToViewsCount":8959,"title":"Reviewing \"TypeScript in 50 Lessons\"","published":true,"description":"My first time being a technical reviewer for a published book!","tags":"Reflections, TypeScript","slug":"ts-50-lessons","canonical_url":"https://www.swyx.io/ts-50-lessons","cover_image":"https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/6c3fd0d1-e97a-42a7-ab31-f9c3224c9869/20-typescript-book.jpg"},"title":"Reviewing \"TypeScript in 50 Lessons\"","description":"My first time being a technical reviewer for a published book! ","category":"note","tags":["reflections","typescript"],"image":"https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/6c3fd0d1-e97a-42a7-ab31-f9c3224c9869/20-typescript-book.jpg","canonical":"https://www.swyx.io/ts-50-lessons","slug":"ts-50-lessons","date":"2021-02-18T15:48:57.560Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/300","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/300/comments","title":"Reviewing \"TypeScript in 50 Lessons\"","created_at":"2022-01-18T00:11:29Z","updated_at":"2022-06-18T17:47:46Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/300/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Clubhouse chat - Growing Digital Gardens w/ Maggie Appleton","slug":"digital-gardens-maggie","tags":["DigitalGardens"],"venues":"Swyx YouTube","date":"2021-02-13T00:00:00.000Z","url":"https://share.transistor.fm/s/41a6f89a","description":"Maggie and I hosted a Clubhouse chat on Digital Gardens and here is the recording! Later joined by Nikita Voloboev and other listeners.","category":"podcast"},{"type":"blog","content":"\nIf you go to `https://swyx.io`, you get my blog.\n\nIf you go to `https://is-this.netlify.app/https://swyx.io`, you get this:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/7sds0o2n6ctdhctjfs15.jpeg)\n\nThis is a [little utility](https://twitter.com/swyx/status/1144365946804588545?s=20) I made that solved the very specific pain point of figuring out whether or not a potential customer was a Netlify user or not (or had configured another CDN atop Netlify).\n\nI originally did this as a browser extension, but the benefit of doing this as a microsite is I can now access it on my phone.\n\n## Prefixed URLs\n\nThis is a little behavior that I call **Prefixed URLs**, after [GitPod's name for it](https://www.gitpod.io/docs/getting-started/#prefixed-url). \n\nIt's a really nice way to **enhance the open web** - by creating a route that specifically accepts either any URL or some specific set of URLs, and then does something with that info to give you even more. To use this microsite, you just prepend the URL to whatever you're interested in.\n\nI was recently reminded of this when [the **Github1s** project](https://github.com/conwnet/github1s) went viral [on HN recently](https://news.ycombinator.com/item?id=26083919). It lets you swap out any `github.com` repo for `github1s.com` and it opens up a VS Code file explorer for easier navigation (GitHub's default file navigation is slow and clunky).\n\n![github1s demo](https://raw.githubusercontent.com/conwnet/github1s/master/resources/images/demo.png)\n\n## Other Instances\n\nI've also seen this behavior in website ranking tools: https://www.similarweb.com/website/dev.to/ shows you the traffic of Dev.to:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/dlh3972klyfbcmkwsot2.png)\n\nIn the \"we deploy your code\" industry it is also pretty common to use Prefixed URLs as \"Deploy Buttons\" like [Netlify](https://docs.netlify.com/site-deploys/create-deploys/#deploy-to-netlify-button) and [Codesandbox](https://codesandbox.io/docs/importing#import-from-github).\n\nPomber has a little Github history suffix for codesurfing: \n\n{% twitter 1092827841509707778 %}\n\nI think this is a wonderful little user experience and encourage more people to think of creative ways to consume URLs and extend the Open Web.\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-simple-magic-of-prefixed-urls-46l1","devToReactions":37,"devToReadingTime":2,"devToPublishedAt":"2021-02-12T19:51:57.000Z","devToViewsCount":1388,"title":"The Simple Magic of Prefixed URLs","published":true,"description":"You can enhance the web by making wrappers around it.","tags":"ideas","slug":"prefixed-urls","canonical_url":"https://www.swyx.io/prefixed-urls","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/7sds0o2n6ctdhctjfs15.jpeg"},"title":"The Simple Magic of Prefixed URLs","description":"You can enhance the web by making wrappers around it. ","category":"note","tags":["ideas"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/7sds0o2n6ctdhctjfs15.jpeg","canonical":"https://www.swyx.io/prefixed-urls","slug":"prefixed-urls","date":"2021-02-12T19:51:57.000Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/301","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/301/comments","title":"The Simple Magic of Prefixed URLs","created_at":"2022-01-18T00:12:03Z","updated_at":"2022-06-18T17:47:47Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/301/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"How to Launch Your Product and Sustain Revenue - with Ryan Chenkie's Entrepreneurial Coders Podcast","slug":"ecoder-book","tags":["Creators"],"venues":"EntrepreneurialCoder","date":"2021-02-11T00:00:00.000Z","url":"https://share.transistor.fm/s/1cfa55cb","description":"Shawn Wang (aka swyx) chats about his experience writing and publishing his book, The Coding Career Handbook. He goes into detail about the challenges he encountered, how he learned from other people's launches, and how he was able to successfully launch the book and make it into something that provides meaningful revenue. He also talks about how to sustain revenue for your product after you launch.","category":"podcast"},{"type":"blog","content":"\nI've noticed that companies invest very differently in their respective job functions:\n\n- Stripe had no Product Manager for its first five years of existence ([source](https://twitter.com/shreyas/status/1301910476570329088?s=20))\n- GitHub serves 50 million developers, has 1,677 employees, and only 2 developer advocates (last I heard), whereas Netlify, serving [1.3 million](https://www.netlify.com/blog/2020/12/21/top-10-from-2020-netlify-features-announcements/) developers and <200 employees, has [six](https://www.netlify.com/blog/2021/01/06/developer-experience-at-netlify/).\n- Netflix famously has a [minimal expense and leave policy](https://hbr.org/2014/01/how-netflix-reinvented-hr), with each line manager presumably loosely responsible, whereas other companies may have entire departments dedicated to tracking and enforcing these things.\n\n*I wish I had more examples of surprising allocations for you but I don't right now - please [let me know](https://twitter.com/swyx) if you think of any!*\n\nThe implication here is that you don't have to have people holding the job title, in order to perform the function. \n\n- At the extreme, you have [Companies of One](https://www.goodreads.com/en/book/show/37570605), where one person (or a small group) literally does everything from beginning to end. Some people do very well at this because the reduced overhead makes for faster/better decisionmaking. The developer equivalent of this is the fabled \"full stack\" engineer.\n- However, specialists can often do better than generalists can, at least through [comparative advantage](https://www.investopedia.com/terms/c/comparativeadvantage.asp), if not due to outright expertise and network.\n- Yet, there are drawbacks to specialization, too. At the extreme, a simple project might need signoff from 10 different stakeholders just to get started (I have been in this exact meeting). This always starts with good intent - why not get expert input? - but down that path lies TPS reports in octuplicate.\n\nI think the problem lies when we conflate **specialization** with **ownership**. \n\n## Ownership\n\nGiving experts ownership is a good idea - skin in the game is important for getting the best out of your people, and you want the most qualified people in on your team to take point on the things they are good at.\n\nBut, perhaps more often than commonly realized, this can have drawbacks. When one specialist person or team owns a domain, it can be very tempting for the rest of the company to defer completely to them. There are two primary downsides to **ownership roles**: \n\n- They have a natural chilling effect on ideas and opinions from people who might have valuable input.\n- They add an extra stakeholder in the decision chain, with their own priorities and political incentives.\n\nI'll confess that this comes out of some bitter personal experience; I've sometimes had good ideas slowed down or lost steam completely because I had to wait for the already overloaded domain owner to get to it, when I could have just done the thing myself, perhaps 50% as good, but 500% faster. Of course there are very good reasons to stick to the process anyway — expertise matters, mistakes can be catastrophic (particularly where security, public relations and the law are concerned), and my judgment can just outright be wrong.\n\n## Enablement\n\nI think the alternative is to **separate specialization *from* ownership**: hire a dedicated team of experts who are not directly responsible for producing results, but whose job is to remove all barriers for the rest of the company to do what they do. At larger companies this might be called a [Center of Excellence](https://en.wikipedia.org/wiki/Center_of_excellence), at modern startups this could be viewed as \"Internal tooling and Infrastructure\".\n\nConsider that HR departments don't actually do the hiring for individual teams. Instead, most companies have individual line managers become hiring managers, who basically have the final say. Instead of **owning** hiring, HR departments **enable** hiring managers to do hiring *as part of their jobs*, by building infrastructure for as much of the job as possible - buying ATS software, determining benefits, sourcing candidates, organizing onboarding, and so on.\n\n## Ownership to Enablement\n\nWonderful things can happen when you **turn ownership roles into enablement roles**.\n\n**Documentation**. Many developer tools companies have technical writers. The tendency is to have them write all docs and make all decisions on structure, language, voice and tone, pedagogy, and so on. However, they may not have full empathy with the target audience, because they do very different jobs and move in very different circles. New product development can also be very fluid, which is extremely frustrating to overloaded technical writers who desire more structure. Some companies are therefore shifting the job to have every engineering team be responsible for the docs of the features they work on. The role of the docs team shifts towards **enabling** the rest of the company to create docs independently, with the docs team being responsible for documentation infrastructure and overall cross-cutting concerns.\n\n**Developer Relations**. People like hearing from Dev Advocates, but what works even better is hearing directly from engineers who worked on the features that they use. Instead of delivering talks and writing blogposts themselves, Dev Advocates can make it *easy* for the rest of the company to produce at their level, by offering office hours, sourcing and proposing speakers, and ghostwriting blogposts for those without the time or experience at doing the public facing parts. This also helps scale DevRel sublinearly as a function of the company's total number of users, which is necessary for the company bottom line.\n\n**Infrastructure teams**. Every dev can be pushing features, but there's always going to be someone on the team more than averagely interested in the dev tooling that everyone uses. Anecdotally, the ratio of Infra devs to other devs is between 1:30 and 1:50 in a company. This makes sense - if a dedicated resource can raise developer productivity by at least 2% (as measurable by any of [the Accelerate metrics](https://twitter.com/swyx/status/1341491268593991681?s=20)), someone should be in charge of it once you get big enough. [Jon Wong at Coursera](https://twitter.com/jnwng) and [Ryan Burgess at Netflix](https://twitter.com/burgessdryan/status/1346841514534707200?s=20) are notable examples that come to mind. An older more enterprise-y term for this would be establishing [Centers of Excellence](https://en.wikipedia.org/wiki/Center_of_excellence) in a company.\n\nThis is further outside of my wheelhouse, but I believe that Data Science turning from an Ownership Role (\"pls run all the reports for me by Monday morning\") to an Enablement Role (\"help me run my own reports\") is a key enabler of trends towards data warehouses on the backend, and democratized visualization/interaction tools like Looker, Tableau, and Retool on the frontend.\n\n## Problems with Enablement Roles\n\nEven though I've spent the majority of this blogpost talking about the benefits of Enablement Roles, the takeaway isn't that I think *everything* should be an enablement role. There are some clear \"the buck stops here\" Ownership roles in a company. Legal should handle legal. Engineering should be the only group committing production code. And so on.\n\nI also think there are two interrelated problems with enablement roles that I haven't figured out yet: measurement and motivation. Because enablement is about helping *other people do the thing*, rather than doing it yourself, your results are naturally not entirely within your control. The extremes are clear: if a team is knocking it out of the park in the area you helped with, that's a Good Job. If nobody on the team thinks you've been helpful at all, that's probably (not necessarily) bad. But the humdrum in-betweens, where we realistically spend most of our time, are entirely unclear. People in enablement roles must be able to live with this ambiguity, and genuinely take pride in the messy business of helping people succeed in things which, by definition, are not their main responsibility and therefore care less about.\n\n## Related Reads\n\n\n- From me: [The difference between Ensemble and Committee Teams](https://www.swyx.io/ensembles-vs-committees/)\n- Ben Thompson: [the difference between functional and divisional companies](https://stratechery.com/2013/why-microsofts-reorganization-is-a-bad-idea/) with [part 2 here](https://stratechery.com/2013/the-uncanny-valley-of-a-functional-organization/)\n- [Team Topologies: Enabling Teams](https://teamtopologies.com/key-concepts)\n- [Adam Ahmed pointed out](https://twitter.com/typesthings/status/1359228307728789505?s=20) Haier, \"a Chinese company that is organized as 1000s of internal teams that can hire each other. Your assessment is done by your customer teams. Definitely cons to it, but interesting way to measure enablement.\" [HBR article](https://hbr.org/2018/11/the-end-of-bureaucracy source) [[Wayback machine archive](https://web.archive.org/web/20210209042727/https://hbr.org/2018/11/the-end-of-bureaucracy)]","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/enablement-vs-ownership-roles-3eok","devToReactions":21,"devToReadingTime":6,"devToPublishedAt":"2021-02-08T22:29:47.226Z","devToViewsCount":111,"title":"Enablement vs Ownership Roles","published":true,"description":"Two ways to approach responsibility in a company.","tags":"Reflections, Management, Ownership","slug":"enablement-vs-ownership","canonical_url":"https://www.swyx.io/enablement-vs-ownership"},"title":"Enablement vs Ownership Roles","description":"Two ways to approach responsibility in a company. ","category":"note","tags":["reflections","management","ownership"],"canonical":"https://www.swyx.io/enablement-vs-ownership","slug":"enablement-vs-ownership","date":"2021-02-08T22:29:47.226Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/302","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/302/comments","title":"Enablement vs Ownership Roles","created_at":"2022-01-18T00:12:05Z","updated_at":"2022-06-18T17:47:47Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/302/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Build and deploy dynamic Jamstack apps with AWS Amplify","slug":"aws-amplify-2021","categories":["AWS"],"description":"Jamstack is a modern web development architecture built with JavaScript, APIs, and Markup. This new way of building websites and applications delivers performance, higher security, lower cost of scaling, and a better developer experience. In this session, you learn how to bring your Jamstack applications to life in record time when you develop and deploy with AWS Amplify. You also learn how to easily and quickly develop cloud-enabled applications with your choice of REST or GraphQL APIs, rapidly release new features, avoid downtime during application deployment, and handle the complexity of simultaneously updating the front end and backend of your applications.","instances":[{"venue":"AWS Reinvent","date":"2021-02-06","video":"https://www.youtube.com/watch?v=nlifa0c-PFU"}],"category":"talk","date":"2021-02-06T00:00:00.000Z"},{"type":"blog","content":"\n*You can listen to [an audio version of this essay](https://share.transistor.fm/s/6719542d) and read [reactions on Twitter](https://twitter.com/search?q=https%3A%2F%2Fwww.swyx.io%2Fclubhouse-hate%2F&src=typed_query).*\n\nTrust me, I *tried* to make the Clubhouse bear case.\n\nThe original title of this post was \"Everything Clubhouse Did Right — and Why It Will Fail Anyway\". The exercise forced me to list the reasons why it wasn't worth $1 billion - why live conference calls are inferior to existing formats like podcasts and Discord. \n\nWhen I was done, I went for a walk to think about it. By the time I came back, I had done a complete 180. (Note - *this was even before I heard about the Elon event*)\n\nI *still* dislike the Clubhouse experience. I wouldn't recommend it to you. But all the reasons I dislike it are the same reasons it will work:\n\n- **Clubhouse is exclusive**. You have hoops to jump and gates to open every step of the way. It's iOS only. Invite only. Requires your phone number for no goddamn reason. And once you're through *all of that* you gain the privilege of being in the voiceless audience hoping senpai will notice your raised hand and puffed up bio.\n- **Clubhouse is ephemeral**. Conversations aren't recorded. Your work doesn't compound and isn't searchable. This is *horrible* for ROI on your time as a content creator.\n- **Clubhouse is live-only**. If all the convos are happening in Pacific Time and you live in Europe, tough luck. If you came in halfway and have no idea what was said, tough luck. The only way to be fully involved is to turn on mobile notifications and track scheduled chats. Causing more — not less — distraction and work for you.\n- **Clubhouse enhances existing privilege**. Because automated recommendations aren't possible, Clubhouse mostly relies on a Twitter-like follow graph. To gain a following you mostly already have to be famous off-platform or well-connected to people who will bring you up on stage (\"second-degree famous\"). Choosing a [Status as a Service](https://www.eugenewei.com/blog/2019/2/19/status-as-a-service) model (Twitter) over a [Sorting Hat](https://www.eugenewei.com/blog/2020/8/3/tiktok-and-the-sorting-hat) model (TikTok) sacrifices discovery for establishment.\n- **Clubhouse is a terrible listening experience**. There's no audience chat or polling. Obnoxious speakers can dominate the conversation. [Trolls](https://twitter.com/wongmjane/status/1355817942093496320?s=20) and [harassment](https://www.dailydot.com/unclick/tiffany-haddish-bullies-doctor-on-clubhouse-covid/) abound. You can't play at 2x or rewind an important part. Podcasts were trending towards better audio and editing, Clubhouse regresses to shitty phone mics with feedback and connection issues. Signal is scarce, noise is rampant.\n\nIn my original write up I listed the many better offerings in every dimension. Want to listen to interviews with great audio and show notes? Podcasts. Want ultrascalable livestreaming? Twitch. Want livestreamed audio with recording and submitted questions? [Capiche](https://twitter.com/N8Elliott/status/1355203379392176131?s=20). Want to do an audio webinar? Use Zoom with the camera off. Want voice with text chat? Discord. Just want a Clubhouse clone with less friction? [Twitter Spaces](https://twitter.com/TwitterSpaces).\n\nWhen I was done listing the alternatives, I knew I had made a mistake. They checked more boxes on a feature comparison basis. But social media doesn't work like that. I was trying to be logical in a *socio*-logical domain.\n\nI had conclusively *PROVED*, with my big brain and fancy words, how profoundly inferior Clubhouse was. No compounding creator should prefer it, and no self respecting listener should enjoy it, compared to alternatives.\n\nBut the majority of people don't work like that:\n\n- Some people are turned off by exclusivity and friction. But *most people* take it as social proof of something cool.\n- Some creators are turned off by ephemerality. But *more people* will start trying precisely because it's easy and doesn't matter. The Elon Musks and Vlad Tenevs of the world will be less guarded, despite clearly knowing anything they say will be recorded (EDIT: [a16z is even publishing these now](https://a16z-live.simplecast.com)), because *[the medium is the message](https://en.wikipedia.org/wiki/The_medium_is_the_message)*.\n- Some people are turned off by demands on their time. But *most people* leave mobile notifications on and the live nature of chats creates some of the most urgent notifications you'll get on your phone, second only to a call from your mother. The synchronicity creates an *event* — a clear Before and After where you can excitedly gossip and feel superior to people out of the loop. This is a rarity in an everything-async world.\n- Some people are turned off by stacked decks. But *most people* just want to follow celebrities and experts and aren't interested in the challenging, messy work of finding people on the way up.\n- Some people are turned off by the listening experience. But Clubhouse is [Good Enough](https://www.swyx.io/good-enough/), especially if content is created sooner and in bigger quantity than available anywhere else.\n\nClubhouse should've died [in July when the VC and Media abuse cases erupted](https://www.theverge.com/interface/2020/7/8/21316172/clubhouse-content-moderation-taylor-lorenz-harassment-abuse). Instead it came back stronger than ever, standing at [2 million weekly active users](https://web.archive.org/web/20210131175202/https://www.businessinsider.com/why-the-hype-about-1-billion-clubhouse-not-so-crazy-2021-1). **If any of these negatives mattered**, the app should have seen extreme churn. Instead, [Andrew Chen](https://a16z.com/2021/01/24/investing-in-clubhouse/), [Ryan Hoover](https://twitter.com/rrhoover/status/1353393250552270850), and [Sahil Lavingia](https://www.indiehackers.com/post/gumroad-is-switching-from-zoom-to-clubhouse-34e4b4e5e1) — who do this for a living and have insider knowledge of metrics — value it above $1 billion dollars, six months after it was [valued at $100 million](https://www.forbes.com/sites/alexkonrad/2020/05/15/andreessen-horowitz-wins-vc-sweepstakes-to-back-clubhouse-voice-app/?sh=5b8466d56f2a). \n\n**People. Aren't. Churning.** No matter how much you may hate the app — usage is going *up*. This is scary and worth taking note. Clubhouse is already showing signs of successful expansion in Asia (read: non-English Clubhouses). \n\nInstagram had 30 million MAUs when Facebook bought it for $1 billion. Whatsapp had 450m for $19 billion. By Whatsapp metrics, Clubhouse is wildly overvalued (lets say it has 10m MAU right now). But audio isn't text. [Alex Danco says](https://alexdanco.com/2019/10/17/the-audio-revolution/) that texting is a cold medium, while audio is the hottest medium of all. He was mildly wrong — podcasting is still kinda lukewarm — but ***live, ephemeral*** audio is so hot you will literally drop everything and stay up late and ignore your partner to go listen to Elon.\n\nWorse is better. The exact reasons you hate Clubhouse — the kind of thing that drives you to read an article like this to the end — are the exact same reasons it is going to win.\n\n---\n\n*if you're interested - here was [my initial negative conclusion](https://gist.github.com/sw-yx/d3e27a36eba965fcd4183d0575d34640).*\n\nOther takes:\n\n- https://latecheckout.substack.com/p/welcome-to-the-spontaneous-internet\n- ryan dawidjan https://paper.dropbox.com/doc/BBbGZjzVnRxzQx1yXXfAq","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/everything-you-hate-about-clubhouse-is-why-it-will-win-3lc2","devToReactions":27,"devToReadingTime":5,"devToPublishedAt":"2021-02-01T17:59:18.122Z","devToViewsCount":490,"title":"Everything You Hate About Clubhouse Is Why It Will Win","published":true,"description":"Understanding new social media is a *sociological* exercise, not a logical one.","tags":"Reflections, Product, Startups","slug":"clubhouse-hate","canonical_url":"https://www.swyx.io/clubhouse-hate"},"title":"Everything You Hate About Clubhouse Is Why It Will Win","description":"Understanding new social media is a *sociological* exercise, not a logical one. ","category":"note","tags":["reflections","product","startups"],"canonical":"https://www.swyx.io/clubhouse-hate","slug":"clubhouse-hate","date":"2021-02-01T17:59:18.122Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/303","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/303/comments","title":"Everything You Hate About Clubhouse Is Why It Will Win","created_at":"2022-01-18T00:12:07Z","updated_at":"2022-06-18T17:47:47Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/303/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n*[listen to me explain this in a podcast](https://share.transistor.fm/s/c10e417a)*\n\n## TL;DR\n\n- Errors are unrecoverable, Exceptions are routine. \n- Most languages (Java, PHP) build the distinction into the language. Yet others (Go) name them the other way round. Some languages (JavaScript, Python) treat them as synonyms. \n- No matter what way you name things, you should handle Errors and Exceptions separately in your code or bad things happen.\n\nBecause I started out in JS/Python and then went to Go, without touching Java, getting this distinction right took me a few hours of thinking and research. It's not self-evident!\n\n## Context\n\nIf you've ever `throw`n an error in a function *expecting* its invoker to `catch` it, **you're doing it wrong**.\n\n> Ok, I'll admit I'm just hamming up a mere opinion for a more eye-catching opening. But I do feel strongly about this so...\n\nI was recently reminded of this while going through the Go FAQ and being reminded that [Go does not have exceptions](https://golang.org/doc/faq#exceptions).\n\n*What?* If you've always coded in a language that has exceptions, this ought to jump out at you.\n\n**Go does not have `try` or `catch`.** Despite those language constructs existing for decades, Go chose to have [Defer, Panic, and Recover](https://blog.golang.org/defer-panic-and-recover) instead. By convention and design, Go encodes an extremely strong opinion that **errors should be returned, not thrown**.\n\n## But Why\n\nRelying on *exception* handling to handle *errors* either leads to convoluted code or unhandled errors.\n\nThis kind of code is common in JavaScript:\n\n```jsx\nfunction trySomethingRisky(str) {\n\t\tif (!isValid(str)) throw new Error('invalid string!')\n\t\treturn \"success!\"\n}\n\nfunction main() {\n\ttry {\n\t\treturn trySomethingRisky(prompt('enter valid name'))\n\t} catch (err) {\n\t\tif (err instanceof Error) {\n\t\t\t// handle exceptions\n\t\t} else {\n\t\t\t// handle errors\n\t\t}\n\t}\n}\n```\n\nIf you're thinking that you don't write this sort of code very often, you're probably not thinking through your failure modes enough. \n\n- JavaScript doesn't have a native way to indicate whether a function can throw, if you invoke it. So **you cannot lint against it** — you must either pay this cost earlier in manual code review or later in bug reports.\n- An innocent `fs.readFileSync` call can bring down a whole server ([or memory-leak descriptors](https://github.com/mcollina/make-promises-safe)) given the wrong string.\n- Promise calls without a `catch` in the browser will simply log silent errors (a terrible user experience).\n\nThe more function and module boundaries you cross, the more you need to think about defensively adding `try`/ `catch` and handling the gamut of errors that can happen, and the harder it is to trace where errors begin and where they are handled. \n\n> Aside - some authors like [this Redditor](https://www.reddit.com/r/golang/comments/9t7con/why_no_trycatch_in_golang_whats_the_theory_behind/e8ust3m/) and [Matt Warren](https://mattwarren.org/2016/12/20/Why-Exceptions-should-be-Exceptional/) make a performance driven argument for encouraging developers to not overuse exceptions. Exceptions involve a memory and compute intensive stack search. This matters at scale, but most of us will never run into this so I choose not to make a big deal out of it.\n\n## Errors vs Exceptions\n\nLet's attempt a definition:\n\n- **Exceptions are expected failures**, which we should recover from.\n- **Errors are unexpected failures**. By definition, we cannot recover elegantly from *unexpected* failures.\n\nYou might notice the ironic inversion - it is *errors* that are \"exceptional\", while *exceptions* are routine. This was very confusing to your humble author.\n\nThis is no doubt due to the fact that [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Control_flow_and_error_handling#exception_handling_statements), [Python](https://docs.python.org/3/tutorial/errors.html), and other languages treat errors and exceptions as synonyms. So we throw `Error`s when we really mean to throw exceptions.\n\n[PHP](https://www.guru99.com/error-handling-and-exceptions.html) and [Java](https://stackoverflow.com/questions/5813614/what-is-difference-between-errors-and-exceptions) seem to have this difference baked into the language. \n\nTo make things extra confusing, Go uses `error` where other languages would call exceptions, and relies on `panic` to \"throw\" what other languages would call errors. \n\n> Notes: Chris Krycho observes that you can use Rust, F#, and Elm's `Result` in a similar way, and Haskell's `Either`.\n\n## Exception Handling vs Error Checking\n\nThe realization that we need different paradigms for handling errors and exceptions is of course not new. [Wikipedia's entry on Exception Handling](https://en.wikipedia.org/wiki/Exception_handling#Criticism) quotes Tony Hoare ([creator of QuickSort, CSP and the null reference](https://en.wikipedia.org/wiki/Tony_Hoare)) saying that exception handling is \"**dangerous. Do not allow this language in its present state to be used in applications where reliability is critical.**\"\n\nThat was said in 1980, yet here we are 40 years later.\n\nThe alternative to exception handling is error checking. \n\n### Error Checking in Go\n\n> Note: Go seems to have a strong opinion that \"Errors\" are routine and Exceptions (not formally named, but used in `panic`) are Exceptional - in direct opposition to other languages. I have opted to use Go-native terminology - minimizing confusion locally at the cost of increasing global confusion.\n\n[Errors are values](https://blog.golang.org/errors-are-values) in Go — made to be passed, not thrown. Go's FAQ is worth quoting here:\n\n*We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.*\n\nWhen something goes wrong, your default choice should be using multi-value returns to report errors:\n\n```go\ni, err := strconv.Atoi(\"42\")\nif err != nil {\n fmt.Printf(\"couldn't convert number: %v\\n\", err)\n return\n}\nfmt.Println(\"Converted integer:\", i)\n```\n\nThis pattern would be subject to the same weaknesses I outlined above, except for the fact that Go will refuse to compile if you 1) don't assign all returned values at the callsite or 2) don't use values that you assign. These two rules combined guide you to handle all errors explicitly near their origin.\n\nExceptions still have a place — but the language reminds you how rarely you should use it, by calling it `panic()`. You can still `recover()` and treat it like a backdoor `try`/ `catch` in Go, but you will get judgy looks from all Gophers.\n\n### Error Checking in Node\n\nJavaScript lacks the 2 features I mention above to force you to handle errors.\n\nTo work around this and gently nudge you, Node uses [error-first callbacks](https://nodejs.org/api/errors.html#errors_error_first_callbacks):\n\n```jsx\nconst fs = require('fs');\n\nfunction errorFirstCallback(err, data) {\n if (err) {\n console.error('There was an error', err);\n return;\n }\n console.log(data);\n}\n\nfs.readFile('/some/file/that/does-not-exist', errorFirstCallback);\nfs.readFile('/some/file/that/does-exist', errorFirstCallback);\n```\n\nThis pattern is idiomatic in most Node libraries, but the further we get away from Node, the more we tend to forget that there is an alternative to throwing errors, when writing libraries and app code.\n\nLastly, it is tempting to `promisify` those callbacks:\n\n```jsx\nconst util = require('util');\nconst fs = require('fs');\n\nconst stat = util.promisify(fs.stat); // i am using fs.stat here, but could be any error-first-callback userland function\n\n// assuming top-level await\ntry {\n\tconst stats = await stat('.')\n\t// do something with stats\n} catch (err) {\n\t// handle errors\n}\n```\n\nAnd we are right back where we started - being able to fling errors and exceptions arbitrarily high up and having to handle both in the same place.\n\n## Other Reads\n\n- [Dave Cheney on Go Errors and Exceptions](https://dave.cheney.net/2015/01/26/errors-and-exceptions-redux)\n- Haskell Wiki on [Errors vs Exceptions](https://wiki.haskell.org/Error_vs._Exception)\n- You can implement a `Result` or `Maybe` in JS: https://true-myth.js.org/\n\n*Thanks to [Charlie You](https://twitter.com/charlieyouai) and [Robin Cussol](https://twitter.com/robincsl?lang=en) for reviewing drafts of this post.*","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/errors-are-not-exceptional-1g0b","devToReactions":97,"devToReadingTime":5,"devToPublishedAt":"2021-01-29T15:18:16.000Z","devToViewsCount":2502,"title":"Errors Are Not Exceptions","published":true,"description":"Many language ecosystems use try/catch paradigms to represent both errors and exceptions. This is wrong.","tags":"languages, golang, javascript","slug":"errors-not-exceptions","canonical_url":"https://www.swyx.io/errors-not-exceptions"},"title":"Errors Are Not Exceptions","description":"Many language ecosystems use try/catch paradigms to represent both errors and exceptions. This is wrong. ","category":"note","tags":["languages","golang","javascript"],"canonical":"https://www.swyx.io/errors-not-exceptions","slug":"errors-not-exceptions","date":"2021-01-29T15:18:16.000Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/304","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/304/comments","title":"Errors Are Not Exceptions","created_at":"2022-01-18T00:12:09Z","updated_at":"2023-07-22T04:03:10Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/304/reactions","total_count":3,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":3,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n*You can [listen to the associated podcast with audio clips here](https://share.transistor.fm/s/bad711bd).*\r\n\r\nEvery creator wrestles with the tradeoff between quality and consistency. I think I've found the answer: Default to consistency, and cut scope. Once you have a fanbase, do a [strategy turn](https://www.swyx.io/strategy-turns) to quality.\r\n\r\n## Consistency\r\n\r\n> \"You just need three things to change your life. Number one, create useful content. Number two, post it once a week. And number three, do that for two years. And if you do that I can 100% guarantee that your life will change in ways that you can't imagine.\" - [Ali Abdaal](https://jayclouse.com/podcast/ali-abdaal/)\r\n\r\nThe benefit of pursuing **consistency** is that it forces output. Good or bad, when your deadline comes you have to ship the thing. Again, and again. And again.\r\n\r\n- A lot of people fail to cross the **[Ira Glass Taste Gap](https://jamesclear.com/ira-glass-failure)** and stop while they still suck.\r\n- **[But sucking at something is the first step towards being sorta good at it](https://medium.com/lets-dave-this/sucking-at-something-is-the-first-step-towards-being-sort-of-good-at-something-991361349e03)**.\r\n- Consistency means you keep going when no one - not even you - believes in you yet.\r\n- People will become your supporters and mentors just because you keep earnestly showing up.\r\n\r\nThe cost of pursuing **consistency** is psychology and lack of direction. It's hard to keep trying your best when your best goes straight into a black hole. Committing to an arbitrary schedule guarantees you *will* publish work you aren't proud of, and some people will be turned off by the hit-and-miss (mostly miss) of your work.\r\n\r\n## Quality\r\n\r\n> \"Doing a pretty good article every week, is far less likely to build a big career, than writing a great article sporadically, because the great article will stand out and people will forget [the rest].\" - [Tim Urban](https://jayclouse.com/podcast/tim-urban/)\r\n\r\nThe benefit of pursuing **quality** is that quality always stands out. \r\n\r\n- The competition for producing commodities in quantity is a fierce race to the bottom. But there is never enough quality in the world.\r\n- Quality is also non-linear: **[30% of people click the first Google result](https://www.searchenginejournal.com/google-first-page-clicks/374516/#close),** yet only half that click the second. Winner takes most.\r\n- The Internet is a max() function — by definition, most people will only encounter your best work. Spiky greatness over consistent \"meh\".\r\n- Quality builds your brand: A single great achievement is an instant-credibility calling card you can keep using for years.\r\n\r\nThe cost of pursuing quality is **perfectionism**. The last mile is the most valuable, but it also sees diminishing returns. Nobody tells you when you've gone too far tweaking and adding, ruining a good thing long after you should have shipped it. Many end up not even shipping.\r\n\r\n## The Debate\r\n\r\nWe can put both together and observe \"**A Law of Conservation of Inconsistency**\".\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/q2oozgw72oyl4otfw2ai.png)\r\n\r\nEither consistent output and inconsistent quality, or consistent quality and inconsistent output. It's near impossible to have both.\r\n\r\n*Near* impossible.\r\n\r\n## Solution 1: Cut Scope\r\n\r\n> \"I have this internal quality bar that I just like cannot get myself to release anything that is not good... So the compromise that I've come to with myself is something has to get out but I don't care how--what I will compromise on is not the schedule and not the quality, but I will compromise on the scope.\" - [James Clear](https://jayclouse.com/podcast/james-clear/)\r\n\r\nWhat people forget when considering the quality-consistency dilemma is that there is a third axis - the scope of work. \r\n\r\nMaybe you can't produce a great essay every week. But perhaps you could scale it down and make one great tweet or newsletter. \r\n\r\nMake up for lack of skill by spending disproportionately more hours on a thing than people normally do for that format. Relative effort stands out and the constraint breeds creativity.\r\n\r\nSmaller scope encourages brevity. Society increasingly rewards those who can deliver a message in [2 minute pitches](https://news.crunchbase.com/news/a-quick-snapshot-of-y-combinators-demo-day-ii/), 30 second soundbites, [15 second videos](https://boosted.lightricks.com/tiktok-video-length-video-formatting-guide/), 280 characters, and [Two Words](https://www.swyx.io/two-words/).\r\n\r\n> I think the future of \"big content\"/\"10X content\" is, paradoxically, bite-sized content. - [Rand Fishkin](https://twitter.com/randfish/status/607674960123826176)\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/qnrxrczlxu1cpfyjg6bo.png)\r\n\r\n## Solution 2: Default to Consistency\r\n\r\nAs I conclude in [my podcast recap](https://share.transistor.fm/s/bad711bd), both Tim Urban (Mr. A+ Quality) and James Clear (Mr. Cut Scope) agree with Ali Abdaal (Mr. Consistency) that **you should start out with consistency**. Get your [10 bad talks](https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/episode-39-give-10-bad-talks-all-in-a-row-and-then-get-fired/) out of the way. Master your tools. Figure out what \"good\" even means, to you.\r\n\r\n100 seems like a magic number for the \"consistency starter pack\". @visakanv says to \"[Make 100 Thing](https://twitter.com/visakanv/status/1344327942055161856)\" (sic). Ali Abdaal's \"one video a week for 2 years\" works out to 100 videos.\r\n\r\nBut even *after* you have achieved greatness, I think there is *still* an argument to continue being consistent: **We are LOUSY judges of our own work.**\r\n\r\nThis is known as [the Equal Odds rule](https://sarneckalab.blogspot.com/2017/12/simontons-equal-odds-rule.html) in academia — the unintuitive finding that the prior reputation of the author has no bearing on a paper's success. This is replicated in many other settings. Famous comedians bomb all the time. Writers of highly successful books and movies flop afterward. Einstein [changed our understanding of space, time, mass, and energy in a single year](https://en.wikipedia.org/wiki/Annus_Mirabilis_papers) and then spent the rest of his life [being wrong about quantum mechanics, gravitational lensing, and universe expansion](https://astronomy.com/news/2018/09/5-times-einstein-was-wrong).\r\n\r\nThe `max()` rule applies to all great thinkers of our time. Euler published 1500 articles. Picasso made 50,000 works of art. Beethoven made 722 compositions we know of. Van Gogh produced one painting every day for the last two years of his life. They're each only really known for a dozen things at best.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0w3yy9fmg2fa5ooho6ag.png)\r\n\r\n## Other Notes\r\n\r\n> Edit from the future: [**Workshop it**](https://www.swyx.io/workshopping)!\r\n\r\n**Use Competition**. Friendly competitive spirit brings out the best in people. We have no problem asking athletes to consistently be great at tournaments and sports leagues. The intellectual equivalent is conferences, hackathons, and mastermind groups.\r\n\r\n**Automate and Build Infrastructure**. After a period of consistent output, observe repetitive work and build systems to eliminate it. Make greatness easier.\r\n\r\n[**Strategy Turns**](https://www.swyx.io/strategy-turns). After you get off the ground, it can be useful to throttle back the consistency of your output (but not your input) and go for more quality. Use [Workshopping](https://www.swyx.io/workshopping/) as a buffer.\r\n\r\n**Enjoyment**. This may sound simplistic but make sure you pick something you enjoy. You approach creative work as an artist, not as a profit maximizing machine. You are more likely to stay in the game (Consistency) and have great taste (Quality) if you have a great love for the thing you do.\r\n\r\n## Related Reads\r\n\r\n- Julian Shapiro - [The Creativity Faucet](https://twitter.com/Julian/status/1327765347936522240/photo/1)\r\n- James Clear - [Creativity](https://jamesclear.com/creativity) - Create on a schedule, finish something, stop judging your own work, hold your self accountable\r\n- Steph Smith - [How to be Great? Just be Good, Repeatably](https://blog.stephsmith.io/how-to-be-great/)\r\n- Jason Lengstorf - [How to Build a Consistent Content Creation Habit](https://lengstorf.com/build-consistent-content-creation-habit/)\r\n- [Everything is a funnel](https://www.youtube.com/watch?v=5EuWCFCgy58), a classic video by Jack Conte. Main quote: \"Let your audience decide what's good\", just publish to fill the funnel.\r\n- Quality\r\n - Rand Fishkin - [How to Create 10x Content](https://moz.com/blog/how-to-create-10x-content)\r\n - Michael Simmons - [The Blockbuster Model](https://medium.com/accelerated-intelligence/the-1-mental-model-for-writers-who-want-to-write-high-quality-viral-content-43ecf0d4ec05)\r\n- Bilal Zaidi - [Thread](https://twitter.com/bzaidi/status/1365457931454529540?s=20) on what happens AFTER consistency/quality\r\n- I have more thoughts on using consistency to get good at writing [in Chapter 18 of my Coding Careers book](https://www.learninpublic.org/).\r\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/how-to-solve-the-quality-vs-consistency-debate-31he","devToReactions":25,"devToReadingTime":6,"devToPublishedAt":"2021-01-25T18:29:24.448Z","devToViewsCount":171,"title":"Solving the Quality vs Consistency Tradeoff","published":true,"description":"Every creator wrestles with the tradeoff between quality and consistency. The answer - Default to consistency, and cut scope.","tags":"Reflections","slug":"quality-vs-consistency","canonical_url":"https://www.swyx.io/quality-vs-consistency","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/q2oozgw72oyl4otfw2ai.png"},"title":"Solving the Quality vs Consistency Tradeoff","description":"Every creator wrestles with the tradeoff between quality and consistency. The answer - Default to consistency, and cut scope. ","category":"note","tags":["reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/q2oozgw72oyl4otfw2ai.png","canonical":"https://www.swyx.io/quality-vs-consistency","slug":"quality-vs-consistency","date":"2021-01-25T18:29:24.448Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/305","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/305/comments","title":"Solving the Quality vs Consistency Tradeoff","created_at":"2022-01-18T00:12:11Z","updated_at":"2022-06-11T14:38:51Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/305/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n*[Listen to narrated version](https://share.transistor.fm/s/05ccbc28)*\r\n\r\n**How many should be teaching people how to succeed instead of just succeeding in their own way?**\r\n\r\nAs independent creators carve out a new career path for themselves, I suspect that some are unintentionally picking a path that limits their growth and robs the world of their true potential.\r\n\r\nThis theory was triggered by this Hunter Walk tweet:\r\n\r\n![Hunter Walk: the emerging newsletter playbook seems to be \"B-Players Writing About A-Players While Being Subscribed to by C-Players\"](https://dev-to-uploads.s3.amazonaws.com/i/s1btlni3fe2mzxhghkm6.png)\r\n\r\nThe message is clear: By doing B player things, you are at least doing better than C players. **But you will *never* be an A player using the B player playbook.**\r\n\r\nIs that a tradeoff you are consciously making?\r\n\r\nOf course it is too reductive to reduce pluripotent people to \"A players\" and \"B players\". You can be both in different domains, or transition from one to the other. And of course this is nowhere near as bad as the real-life \"[glass ceiling](https://en.wikipedia.org/wiki/Glass_ceiling)\" or a \"[bamboo ceiling](https://en.wikipedia.org/wiki/Bamboo_ceiling)\" in normal careers, where a certain set of the workforce is unable to progress by sheer fact of *who they are*. That is obviously despicable and is a far more important societal issue.\r\n\r\nBut the meta-creator ceiling is interesting to me because it is a path that new creators **follow by choice,** yet *without being aware of it's limitations* because nobody is incentivized to warn them. Perhaps because it is an easier game than others, or perhaps because of hype and marketing.\r\n\r\nNo judgment — I of all people know that there are many ways to avoid asking what it is I really want to do with my life.\r\n\r\nPerhaps some definitions are in order: **A \"Meta-Creator\" is someone who creates content about creating, instead of just creating.**\r\n\r\nThe temptation toward being a Meta-Creator is extremely high. There are three paths:\r\n\r\n- **The A-B-C Loop**: People want success porn. They are oblivious to the [narrative fallacy](https://medium.com/@coffeeandjunk/cognitive-bias-narrative-fallacy-9cff93a597b2) and ignore luck and complicating details. Your success creating success porn gains you access to more successful people who are only too happy to let you write their hagiography. You can spend an entire career mythologizing successful people, living a life of a bard rather than a hero. Always the vibesmaid, never the vibe.\r\n- **The Creator Strange Loop:** To [quote the always-brilliant Philip Kiely](https://twitter.com/philip_kiely/status/1349361401316446211?s=20): \"First you do X, then you make content about doing X, then you make content about that content... One day you realize you haven't done X for six months. And there is only so much room for content at the highest levels of abstraction.\" Every single step makes logical sense because you have credibility from having just done the thing. After a while every step you take you wind back up at the same spot because you're in the generic Creator [strange loop](https://en.wikipedia.org/wiki/Strange_loop) everyone has pigeonholed you in.\r\n- **The Audience-Building Loop:** The natural end game of the current **Audience-First** and **Build in Public** memes is that you naturally attract an audience of wannabe builders. There are only so many topics they want to buy, and so many things to incestuously sell to each other. The successful cohorts will be supported by the far bigger unsuccessful ones in a self-organizing pyramid scheme.\r\n\r\nTo be extremely clear: You can be enormously successful and happy being a Meta-Creator, and bring success and happiness to millions, and that is no small feat. I enjoy Tim Ferris' podcasts and Tren Griffin's blogposts. No judgment if that's your thing. The economics make sense too — in a gold rush, go mine a bit of gold, then sell copies of the shovel you used because it is now \"proven\" to work. Just don't spend too long thinking about [who arranged those economics in the first place](https://twitter.com/swyx/status/1284597930398105600?s=20). \r\n\r\nBut, one, you may have a lower chance of success pursuing this path than others, because it is both available to everyone and zero-sum.\r\n\r\nBut I write for reason two: the sneaking suspicion that *even if you win* and are top of the heap at the Meta-Creator game, you are still limiting yourself from what you could be doing with your life. What the people you *actually* look up to are doing with theirs. What the world could be benefiting from if the greatest minds of our generation just applied themselves to other problems than \"How to Crush it on Twitter\" or \"Get a Million YouTube Subscribers\" or the 3923rd \"How Warren Buffett and Charlie Munger Think\" blogpost. I promise you Musk or Bezos or Obama or Malala or whoever you look up to spend zero time as meta-creators.\r\n\r\nSmart, capable people like you and I can often approach life with more **ambition** than **direction**. We want **success** more than we want to **solve hard problems**.\r\n\r\nI think the way to approach the question of \"what do I do to be successful\", may be to flip it on its head:\r\n\r\nAssume you will be successful at whatever game you play. **Are you playing a game worth winning?**\r\n\r\n> \"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.\" - [Theodore Roosevelt](https://www.mentalfloss.com/article/63389/roosevelts-man-arena)\r\n\r\n## Responses\r\n\r\n- [\"Felt like a punch in the gut\"](https://aden.substack.com/p/stumbling-into-the-meta-creator-trap)\r\n- [Are you a Grifter? Content Creation Traps](https://www.youtube.com/watch?v=sL_uefhT51g)\r\n- My subsequent reflection - [better to show, than tell](https://twitter.com/swyx/status/1379808194080382982?s=20)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-meta-creator-ceiling-203h","devToReactions":26,"devToReadingTime":5,"devToPublishedAt":"2021-01-20T16:27:45.445Z","devToViewsCount":230,"title":"The Meta-Creator Ceiling","published":true,"description":"Don't play games you don't want to win.","tags":"Reflections","slug":"meta-creator-ceiling","canonical_url":"https://www.swyx.io/meta-creator-ceiling","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/s0y2b7m3lx0cqgjd363i.jpg"},"title":"The Meta-Creator Ceiling","description":"Don't play games you don't want to win. ","category":"note","tags":["reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/s0y2b7m3lx0cqgjd363i.jpg","canonical":"https://www.swyx.io/meta-creator-ceiling","slug":"meta-creator-ceiling","date":"2021-01-20T16:27:45.445Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/306","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/306/comments","title":"The Meta-Creator Ceiling","created_at":"2022-01-18T00:12:13Z","updated_at":"2022-03-17T04:03:10Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/306/reactions","total_count":1,"+1":1,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nHere's how to stop being so darn precious about your blogging: **The third time you use an idea in a conversation, you have to blog about it.**\r\n\r\n![Visualized three strikes rule](https://dev-to-uploads.s3.amazonaws.com/i/dgn7cqkm5385vom48amy.png)\r\n\r\n## Why\r\n\r\nPeople often wonder what to blog about. You can get really fancy with Google keyword research and content calendars and the like. It's too complicated for me, and often leads to the kind of impersonal, SEO-driven blogposts that are slowly ruining the web.\r\n\r\nWe need a simple, authentic heuristic to decide. Let's think about the upper and lower bounds:\r\n\r\n- It's possible to blog too much — nobody wants you to broadcast every waking thought. \r\n- But it's more likely that we are just *not blogging enough*. \r\n\r\nWhat's obvious to you is often not obvious to others. How often do you speak with someone and casually mention something that is new to them?\r\n\r\nPretty often.\r\n\r\n![xkcd 1053](https://imgs.xkcd.com/comics/ten_thousand.png)\r\n\r\nIt's natural to want to hold off publishing our insights and discoveries until the magical right time when it all clicks together in one beautiful, perfect essay that springs forth fully formed from our foreheads, making us famous and showing the world how smart we are.\r\n\r\nWe want it so much we end up **never writing it**. \r\n\r\nThis is how the world misses out on so much of our unique voices, taste, and perspectives.\r\n\r\nThe Three Strikes Rule is designed as both a filter (for passing thoughts) and a prompt (for you to write more). \r\n\r\n**To stop being so precious** about your blog.\r\n\r\n**To share ideas** more openly and freely with your readers.\r\n\r\n**To [Create Luck](https://www.swyx.io/create-luck/)**.\r\n\r\n**To create one reference** for that bunch of links you always end up searching for when you write or answer questions.\r\n\r\nAnd, quite honestly, **to write shorter blogposts**. Nobody has time to read the 3,000 word preamble to your magnum opus. It's a blog, not a physical book — you can return over time to expand it if it's worth it (like [this](https://www.swyx.io/LIP) or [this](https://www.swyx.io/how-to-name-things/)). \r\n\r\n> Sidenote: Some people call these \"blogs that grow over time\" a [digital garden](https://joelhooks.com/digital-garden). The mental masturbation crowd prefer [Zettelkasten](https://writingcooperative.com/zettelkasten-how-one-german-scholar-was-so-freakishly-productive-997e4e0ca125) because it sounds foreign. It doesn't matter what you call it, it matters that you do it and grow it.\r\n\r\n## How\r\n\r\nLet's say we accept that \"the 3rd time we reference an idea in a conversation, we have to blog about it\". What does that really mean?\r\n\r\nI take an expansive view of what \"ideas\" and \"conversations\" means.\r\n\r\n- **Ideas** includes great talks, good books, useful concepts, obscure names, handy definitions, copied-and-pasted code snippets, historical facts, surprising charts, and even blogposts by other people. (Yes, you can blog about other blogs. [Like this](https://css-tricks.com/the-power-of-lampshading/). Why not?) Sometimes the idea will be your own, most times it will be your takes on others'. \r\n- **Conversations** include in-person, on Zoom, on Twitter, wherever you communicate and exchange ideas.\r\n\r\n**The first time** you refer to an idea, you probably just learned about it. It might be a fad; you may never find the idea useful again. Let it go.\r\n\r\n**The second time** you refer to the idea, you should be taking note. Ideas are things we find useful in our day-to-day conversations, and there's probably a good amount of our readers who would too. But it might *still* fade away, so we hold off on it. It still needs to **prove its usefulness**.\r\n\r\nBy **the third time** you refer to an idea, it's no longer a coincidence. It's a pattern. You're increasingly likely to refer to it again in future. It's marinated in your head for a bit, and you've likely gained some experience explaining it to others. It's also not so old that it may have lost relevance. It's time to write it down [to save keystrokes](https://www.hanselman.com/blog/do-they-deserve-the-gift-of-your-keystrokes).\r\n\r\nDo I *literally* write everything down after the 3rd time? No, sometimes the \"three strikes\" becomes the \"five strikes\" or the \"ten strikes\" rule, mostly out of laziness. But I know I *should*. With this rule, I find that I blog more and people still get value out of the core idea.\r\n\r\n> In case you were wondering... yes the \"reference counter\" on the Three Strikes rule itself got up to about 8 or 9 before I wrote this post. 🙈\r\n\r\n## Delivery\r\n\r\nFollowing this rule will dramatically increase the volume of your output. There's then the question of how to deliver these high frequency things. There are a few methods:\r\n\r\n- Tweet it out\r\n- Dump them in a github repo ([like this](https://github.com/jbranchaud/til))\r\n- Split your blog from \"only having essays\" mode to having both \"essays\" and \"notes\". Publish separate RSS feeds for them.\r\n- Buffer them up for a \"grab bag post\" like [Tyler Cowen](https://marginalrevolution.com/marginalrevolution/2021/01/what-ive-been-reading-183.html)\r\n\r\nPersonally, I am exploring doing this with a [daily podcast](http://swyx.transistor.fm/). See what works for you.\r\n\r\nIf you're worried that people will think you're too noisy, you probably shouldn't. \r\n\r\n> \"You’ll worry less about what people think about you when you realize how seldom they do.\" - David Foster Wallace, *Infinite Jest*\r\n\r\n\r\n**I'd love for you to share great ideas more freely.** Great ideas deserve to be shared, and your readers will appreciate it.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/my-three-strikes-rule-for-blogging-4b5i","devToReactions":56,"devToReadingTime":4,"devToPublishedAt":"2021-01-18T15:34:46.807Z","devToViewsCount":851,"title":"My Three Strikes Rule for Blogging","published":true,"description":"A simple way to decide when and what to write.","tags":"Writing","slug":"three-strikes","canonical_url":"https://www.swyx.io/three-strikes","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/dgn7cqkm5385vom48amy.png"},"title":"My Three Strikes Rule for Blogging","description":"A simple way to decide when and what to write. ","category":"note","tags":["writing"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/dgn7cqkm5385vom48amy.png","canonical":"https://www.swyx.io/three-strikes","slug":"three-strikes","date":"2021-01-18T15:34:46.807Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/307","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/307/comments","title":"My Three Strikes Rule for Blogging","created_at":"2022-01-18T00:12:15Z","updated_at":"2022-08-18T23:50:50Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/307/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Amplify and DataStore - FSJam Podcast","slug":"amplify-fsjam","tags":["AWS"],"venues":"FSJam","date":"2021-01-18T00:00:00.000Z","url":"https://fsjam.org/episodes/episode-12-amplify-and-datastore-with-shawn-swyx-wang","description":"In this episode we discuss Amplify, DataStore, the difference between teaching and learning in public, migrating existing projects to AWS, containers vs. serverless, and the endgame of layer 2 clouds.","category":"podcast"},{"type":"blog","content":"\nReal rockets don't go straight up. They go up, and then they *turn*.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/vj0hvuk66juvtz5x6wp4.jpg)\n\nRockets do this to transition from \"mostly going up\" to \"mostly going sideways\" in order to achieve orbit. This is known as a [gravity turn](https://en.wikipedia.org/wiki/Gravity_turn) (*technically, they [pitchover](https://wiki.kerbalspaceprogram.com/wiki/Gravity_turn#Mechanics), but that's a less catchy title*).\n\nI see a lot of \"turns\" in life - when something makes sense to do at first, but becomes a bad idea once you're established, and you notice the \"pros\" do something else instead. \n\nThis was inspired by listening to [a recent Creator Lab podcast with Tim Urban](https://www.creatorlab.fm/tim-urban-wait-but-why-podcast/). In his words:\n\n> \"Early on, it was all about 'How do we get these posts to be read by the most people'... I was trying to do enticing headlines and feature drawings... I think early on, I definitely think you want to think about SEO and keywords and headlines, and all of that.\"\n\nAnd the turn:\n\n> \"As the blog started to get more attention and there were more people signing up, it doesn’t matter what the headline is for the newsletter... So it’s become less about \"how do we get this to go viral on social media\", and more about \"the newsletter is going to automatically bring a certain minimum people\".\n\nYou can [listen to the podcast](https://www.youtube.com/watch?v=tl2a6H1E7DU) for the rest. But essentially one of the most successful bloggers in the world is telling us that you should use clickbait and SEO when you are just starting out, even though he doesn't do it. Tim's first post was [7 Ways to Be Insufferable on Facebook](https://waitbutwhy.com/2013/07/7-ways-to-be-insufferable-on-facebook.html), written for a Facebook audience). But once you achieve some form of \"escape velocity\", you earn the right to title your posts authentically to your artistic sensibilities (like \"[The Fermi Paradox](https://waitbutwhy.com/2014/05/fermi-paradox.html)\").\n\nI've taken to calling these **Strategy Turns**. \n\n## Examples of Strategy Turns\n\nYou see them everywhere once you know how to look:\n\n- **Founders**: \"First time founders are obsessed with product. Second time founders are obsessed with distribution.\" - [Justin Kan](https://twitter.com/justinkan/status/1059989657218248704)\n- **VC Startups**: many VC funded startups have the explicit strategy of going for growth first by not charging anything. The Monetization Strategy Turn can be brutal, and most startups would be better off trying to figure out positive unit economics before scaling, but it can be the right call *if there is a land grab* to be had. \n- **Project choice**: \"The danger of pursuing many good projects is not having the time to pursue many great projects. A rule of thumb: Move slowly when choosing what to focus on. But move very quickly once you've decided.\" - [Julian Shapiro](https://twitter.com/Julian/status/1350848867713990657?s=20)\n- **Technology Adoption**: Otherwise known as [Crossing the Chasm](https://en.wikipedia.org/wiki/Crossing_the_Chasm). You start out motivated by pure technical excellence, which attracts enthusiasts and early adopters. But when you try to go for the mass majority you will hit a wall — unless you can execute a strategy turn. This often means investing in less technical factors like documentation, third party ecosystem, and lighthouse users. Cheng Lou of the React and Reason teams famously called this [the Metalanguage](https://frantic.im/meta-language) around your code.\n- **Developers**: most developers hit a point where the impact they can have is rate-limited by other developers and nondevelopers. This can result in a career change to engineering management or architect role. This can even get to the point where you are making a mistake if you are coding *at all*.\n- **Blogging**: There is a tradeoff between blogging on your own site (more ownership and email list building) vs blogging on a community site like Medium, Dev.to, or Hashnode (more discoverability and social features) vs microblogging on social media like Twitter, LinkedIn or Facebook (even more discoverability and social). I think you should start blogging on a community site, and then do a strategy turn to your own. I've written before about how you can [use Dev.to as a Headless CMS](https://www.swyx.io/devto-cms/) (this is what I am doing to write this very blogpost), but when in doubt, [do not let get coding get in the way of your blogging](https://codingcareer.circle.so/c/learn-in-public/how-to-build-my-learn-in-public-website#comment_601161).\n- **Audiences**: Newer creators get the [Audience First](https://twitter.com/search?q=audience-first&src=typed_query) and [Build in Public](https://twitter.com/search?q=build%20in%20public&src=typed_query) religion and think it's the holy grail to business success — because they are new at building audiences. Experts — who can build audience in the middle of a desert — understand that [product first](https://fizzle.co/product-first/) and [building in private](https://jmj.medium.com/raycast-built-in-private-157588803d2a) has benefits. [Better to be rich and anonymous](https://twitter.com/naval/status/1041513555961438208?s=20), than rich and trapped by your business. Paul Jarvis [deleted his newsletter, social media, and website](https://twitter.com/khemaridh/status/1328770143564877824). I used to admire people with big Twitter followings, now I understand why CEOs *hire* people with big Twitter followings and choose to keep a low profile themselves.\n- **Investing**: It's a good idea for most people to create a diversified portfolio of small bets and to [stay invested in the market](https://www.swyx.io/psychology-of-money/#getting-wealthy), but at the elite levels you see Chris Sacca [going all-in on Twitter](https://techcrunch.com/2011/02/27/jp-morgan-twitter-chris-sacca-10-percent-secondary/) and Warren Buffett [sitting on $137 billion in cash](https://www.silverlightinvest.com/blog/why-warren-buffett-making-argument-passive-investing) (so he has capital to make concentrated bets in bad times) — even as he tells most Americans to invest in index funds.\n- **Learning** is basically the same as Investing. Start as an explorer going wide, then go deep when you strike gold. [More in my post on Learning Gears](https://www.swyx.io/learning-gears/). Also known as the Explore/Exploit transition, and modeled by [Simulated Annealing](https://news.ycombinator.com/item?id=23100668) \n- **Regulation**: As a startup founder, you want no regulation to minimize the cost of business and to enable more experimentation. But once you are established, you want your industry to be **as regulated as possible** to [make it harder for newer startups to come up the way you did](https://news.ycombinator.com/item?id=25601814) and to draw clear lines on complying with the letter of the law instead of the endless task of making tradeoffs on behalf of all stakeholders. You want this so much that you will [publicly call for governments to regulate you](https://www.nytimes.com/2019/03/30/technology/mark-zuckerberg-facebook-regulation-explained.html), and of course you will gladly make yourself available for consultation out of the kindness of your hearts.\n- Tech Infrastructure: It makes sense at the early stages to outsource as much of your IT as possible, but as you scale up, the high margins of your dependencies start coming into question. Eventually it's not even out of the question to [build your own datacenter and move off public clouds](https://codingcareer.circle.so/c/devtools/a16z-on-infra-companies) if it will save a few billion dollars.\n\n> Sidenote: These kinds of turns are also a common fantasy trope, from [Discworld](https://en.wikipedia.org/wiki/Granny_Weatherwax#Headology) to Star Wars (I tried but cannot find a source for this idea - the closest is the [Too Awesome To Use](https://tvtropes.org/pmwiki/pmwiki.php/Main/TooAwesomeToUse) trope). Magic users start out using magic for everything, but the wizened masters of the craft spend more time thinking about when *not* to use it. \n>\n> \"You haven't mastered a tool until you understand when it should not be used.\" - [Kelsey Hightower](https://twitter.com/CodeWisdom/status/1354478025228873731?s=20)\n\n## Learning from Strategy Turns\n\nMy takeaways from observing strategy turns are simple:\n\n- **Mind the difference between \"noob game\" and \"pro game\"**: You instinctively only want to hear from famous people in your industry who have \"made it\", but understand that you shouldn't use a playbook that you haven't earned yet, even though it might work well for others.\n- **Today's success stories are based on yesterday's rules**: The rules of the game are constantly shifting — what worked for successful people starting out may not work for you. Yet we tend to only pay attention to advice from people who are already successful today. Tim Urban is pretty honest about this [in his podcast interview](https://www.creatorlab.fm/tim-urban-wait-but-why-podcast/):\n \n > \"It is a different world. 2013 happened to be a good time to start a blog. Totally luck of the draw for me, but it was a time when Facebook especially was a crazy engine for growth of something new like this.\" He goes on to describe how you could get a blogpost in front of 500,000 people for $500 in the early days of Facebook.\n \n Learning from successful people is good, but you should balance that by swapping notes with peers actively exploring new directions *today* to ensure you don't try to replicate strategies that no longer work. (I [run a mastermind](https://www.learninpublic.org/#workshops) for this purpose)\n- **Mind the Metagame**: Just when you have achieved some success with one playbook, you should be looking ahead to how that playbook should change. Sometimes the \"turn\" is such a strong turn that you fully [invert](https://fs.blog/2013/10/inversion/). This isn't an easy call — sometimes you haven't exhausted your playbook yet, and you shouldn't try to fix what isn't broken.\n\n## What's the Third Level?\n\nFans of both [poker](https://evpoker.org/tips/flop-turn-river.html) and [Christopher Nolan movies](https://en.wikipedia.org/wiki/The_Prestige_(film)) know that there should be a third level after a \"turn\". Thesis and antithesis are always followed by synthesis. \n\nStrategy is probably no different. **What comes after Strategy Turns?**\n\n> Note: I have figured this out and will talk about it in an upcoming post on **Strategy Moonshots**.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/strategy-turns-4ng8","devToReactions":13,"devToReadingTime":7,"devToPublishedAt":"2021-01-17T09:44:04.609Z","devToViewsCount":323,"title":"Strategy Turns","published":true,"description":"What got you here won't get you there.","tags":"Strategy, Advice","slug":"strategy-turns","canonical_url":"https://www.swyx.io/strategy-turns","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/vj0hvuk66juvtz5x6wp4.jpg"},"title":"Strategy Turns","description":"What got you here won't get you there. ","category":"note","tags":["strategy","advice"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/vj0hvuk66juvtz5x6wp4.jpg","canonical":"https://www.swyx.io/strategy-turns","slug":"strategy-turns","date":"2021-01-17T09:44:04.609Z","readingTime":"7 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/308","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/308/comments","title":"Strategy Turns","created_at":"2022-01-18T00:12:17Z","updated_at":"2022-06-18T17:47:48Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/308/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n**Too much of our most important data is ephemeral.**\r\n\r\nThere are a lot of data points in our digital lives that only really exist as live updating numbers. They flash for a moment, and are then forever lost to history. \r\n\r\nHowever these numbers would gain much more value if we add an extra dimension: time. This is why we love watching charts of [github star histories](https://star-history.t9t.io/) and [npm downloads](https://npmcharts.com/). If we could only cheaply and easily automate tracking everything else, we would have a lot more megatrend and market share information available at our fingertips.\r\n\r\nI have previously written about [scraping with GitHub Actions](https://www.swyx.io/github-scraping), but that isn't really a scalable solution as it wasn't something git and GitHub Actions were really designed to do.\r\n\r\nToday I want to share how to do data scraping with AWS Amplify. \r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0rg293moffxmxufitl8o.png)\r\n\r\n## High Level Architecture\r\n\r\nOur demo project is going to be scraping Twitter follower count on a periodic basis and storing it in a database for later analysis. (But of course we can extend this to scraping anything and storing anywhere)\r\n\r\nWe're going to use the AWS Amplify CLI to spin this up in minutes:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/bb0tj9h29rrs2iw25g8j.png)\r\n\r\nThe heart of this is the AWS Lambda function we will write. It will fetch data from Twitter and then store it in DynamoDB. We'll have two ways to trigger a scrape - an event based trigger from CloudWatch, and a manual trigger from a public API (done via API Gateway).\r\n\r\n## Set Up\r\n\r\nI'm going to assume you have the [Amplify CLI installed and setup](https://docs.amplify.aws/cli/start/install).\r\n\r\nWe'll start our amplify project and initialize our resources:\r\n\r\n```bash\r\namplify init # choose all defaults\r\n\r\namplify add api # choose the options according to the below\r\n```\r\n\r\nIn that one command, you can actually choose to set up the scheduled CloudWatch Lambda invocations and the DynamoDB database associated with that Lambda function as well. Pretty neat, right?\r\n\r\n```bash\r\n# STEP ONE: Creating API\r\n\r\n? Please select from one of the below mentioned services: REST\r\n? Provide a friendly name for your resource to be used as a label for this category in the project: scrape\r\n? Provide a path (e.g., /book/{isbn}): /scrape\r\n? Choose a Lambda source Create a new Lambda function\r\n? Provide an AWS Lambda function name: scrape\r\n? Choose the runtime that you want to use: NodeJS\r\n? Choose the function template that you want to use: CRUD function for DynamoDB (Integration with API Gateway)\r\n\r\n\r\n# STEP TWO: Creating Database\r\n\r\n? Choose a DynamoDB data source option Create a new DynamoDB table\r\n? Please provide a friendly name for your resource that will be used to label this category in the project: scrapingd\r\nb\r\n? Please provide table name: scrapingdb\r\n\r\n? What would you like to name this column: date\r\n? Please choose the data type: string\r\n? Would you like to add another column? No\r\n\r\n? Please choose partition key for the table: date\r\n? Do you want to add a sort key to your table? No\r\n\r\n? Do you want to add global secondary indexes to your table? No\r\n? Do you want to add a Lambda Trigger for your Table? No\r\nSuccessfully added DynamoDb table locally\r\n\r\n\r\n# STEP THREE: Schedule function invocation\r\n\r\nAvailable advanced settings:\r\n- Resource access permissions\r\n- Scheduled recurring invocation # <---- we want this!!\r\n- Lambda layers configuration\r\n\r\n? Do you want to configure advanced settings? Yes\r\n? Do you want to access other resources in this project from your Lambda function? Yes\r\n? Select the category storage\r\nStorage category has a resource called scrapingdb\r\n? Select the operations you want to permit for scrapingdb create, read, update\r\n? Do you want to invoke this function on a recurring schedule? Yes\r\n? At which interval should the function be invoked: Hourly\r\n? Enter the rate in hours: 6\r\n? Do you want to configure Lambda layers for this function? No\r\n? Do you want to edit the local lambda function now? No\r\nSuccessfully added resource scrape locally.\r\n```\r\n\r\n## Develop\r\n\r\nYou can now work on the AWS Lambda function that you have just scaffolded. Here is the sample code that worked for me:\r\n\r\n```js\r\n// amplify/backend/function/scrape/src/index.js\r\nconst fetch = require('node-fetch')\r\nconst cheerio = require('cheerio')\r\nconst util = require('util');\r\nconst AWS = require('aws-sdk')\r\nAWS.config.update({ region: process.env.TABLE_REGION });\r\nconst dynamodb = new AWS.DynamoDB.DocumentClient();\r\nconst ddb = util.promisify(dynamodb.put);\r\n\r\nlet tableName = \"scraperesults\";\r\nif(process.env.ENV && process.env.ENV !== \"NONE\") {\r\n tableName = tableName + '-' + process.env.ENV;\r\n}\r\nexports.handler = async (event, context) => {\r\n let data\r\n try {\r\n data = await (await fetch(\"https://twitter.com/swyx\", {\r\n headers: {\r\n 'User-Agent': \"Googlebot/2.1 (+http://www.google.com/bot.html)\"\r\n }\r\n })).text()\r\n const $ = cheerio.load(data)\r\n const count = Number($('.ProfileNav-item--followers .ProfileNav-value').attr('data-count'))\r\n const Item = {\r\n count,\r\n date: (new Date()).toString()\r\n }\r\n const data = await ddb({\r\n TableName: tableName,\r\n Item: Item\r\n })\r\n return {\r\n statusCode: 200,\r\n body: JSON.stringify({message: 'data saved!', Item})\r\n }\r\n } catch (error) {\r\n return {\r\n statusCode: 500,\r\n error\r\n } \r\n }\r\n};\r\n```\r\n\r\nMake sure to install `node-fetch` and `cheerio` as these are new dependencies in your AWS Lambda function.\r\n\r\n## Test\r\n\r\nAs you develop your function, you'll want to test it locally without deploying it, so that you can have a fast iteration cycle. Amplify has [basic function mocking](https://docs.amplify.aws/cli/usage/mock#function-mocking-setup) - note it will not mock the DynamoDB part for you, unless you mock a GraphQL API (which we are not using here).\r\n\r\n```bash\r\namplify mock function <function_name> --event \"src/event.json\" # this file only matters if you are trying to simulate an event payload to your lambda function\r\n```\r\n\r\n## Deploy\r\n\r\nOnce you're happy with your setup working locally, you can push it up to the cloud:\r\n\r\n```bash\r\namplify push\r\n```\r\n\r\nAnd it will be deployed and running! You'll be able to see your Amplify project in the Amplify Console (which you can also access via running `amplify console` in your terminal):\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/isif4es9ym9lnhtk4h8z.png)\r\n\r\nAnd you can even dive into the individual Lambda, API Gateway, DynamoDB, and CloudWatch consoles for full observability into the underlying services you have set up:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ans0srf5df1mc0hsveud.png)\r\n\r\n## Takeaways\r\n\r\nIt's easier than ever to spin up custom serverless infrastructure to get stuff done! \r\n\r\nDo note that a highly reliable implementation of this will probably need to run JS or ping an API instead of scraping HTML, and rotate IP's in case of rate limiting and IP blocking. I have [more web scraping notes on my GitHub cheatsheet](https://github.com/sw-yx/automation/#scraping) if you are interested in learning more.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/super-easy-automated-scraping-with-aws-amplify-5eag","devToReactions":45,"devToReadingTime":5,"devToPublishedAt":"2021-01-13T18:31:43.376Z","devToViewsCount":1379,"title":"Super Easy Automated Scraping with AWS Amplify","published":true,"description":"A tutorial on data scraping with AWS Amplify","category":"tutorial","tags":"AWS, Tech, JavaScript","slug":"aws-amplify-scraping","image":"https://dev-to-uploads.s3.amazonaws.com/i/0rg293moffxmxufitl8o.png"},"title":"Super Easy Automated Scraping with AWS Amplify","description":"A tutorial on data scraping with AWS Amplify ","category":"tutorial","tags":["aws","tech","javascript"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/0rg293moffxmxufitl8o.png","slug":"aws-amplify-scraping","date":"2021-01-13T18:31:43.376Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/309","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/309/comments","title":"Super Easy Automated Scraping with AWS Amplify","created_at":"2022-01-18T00:12:19Z","updated_at":"2022-06-18T17:47:13Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/309/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n**What determines the optimal amount of overhead in a system?**\r\n\r\nThis question has been bothering me ever since I began my informal study of computer and human systems. Systems thinkers are usually very thoughtful types, but as far as I can tell nobody's answered it yet.\r\n\r\nThis strikes me as odd, because it is an *incredibly* important number to manage.\r\n\r\n![Optimal Overhead drawing](https://dev-to-uploads.s3.amazonaws.com/i/c1o3owg0liv43ixque75.png)\r\n\r\n## Defining Overhead\r\n\r\nI use the word in the conceptual sense here, closer to [StackOverflow](https://stackoverflow.com/questions/2860234/what-is-overhead) than [Wikipedia](https://en.wikipedia.org/wiki/Overhead_(computing)). I'm pretty poor at defining things – but it's important, so here's my attempt:\r\n\r\nPretend your job is to do as much as possible of a certain task (producing **output**), given limited resources (*time, CPU, memory, bundle size, people...*). **Overhead** is the percentage of resources you spend **not** directly producing — in order to do *produce even more* with the remaining resources.\r\n\r\nSometimes overhead is also known as \"footprint\".\r\n\r\n## Some Examples\r\n\r\nBefore I lose you, here are some examples of overhead (of course, these are very imprecise, just roll with it):\r\n\r\n- **Operating Systems**: We could run our apps on \"bare metal\", but we don't. In this case the goal isn't necessarily running the most apps or running them the fastest; we use OSes to improve user and developer experience.\r\n - Windows 10's [idle CPU usage is 2-4%](https://howmonk.com/how-much-cpu-usage-is-normal/) (high variability)\r\n - MacOS is less conclusive, maybe [6%](https://apple.stackexchange.com/a/377067) (high variability)\r\n - iOS \"System Storage\" takes up [25% of a 16GB iPhone](https://www.imyfone.com/iphone-space-saver/ios-storage-management/#:~:text=The%20%E2%80%9CSystem%E2%80%9D%20storage%20is%20the,64GB%20iPhone%20would%20be%209GB.) (less with more memory)\r\n- **Virtualization** has between [9-35% overhead](https://serverfault.com/questions/261974/how-much-overhead-does-x86-x64-virtualization-have) (or [1-5% of CPU and 5-10% Memory](https://serverfault.com/questions/135431/is-virtual-machine-slower-than-the-underlying-physical-machine)). Docker has [minimal performance overhead](https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container) and it seems so does [Kubernetes](https://www.researchgate.net/figure/Performance-overhead-of-Kubernetes-and-Docker-Swarm-in-comparison-to-VM-Docker-and_fig2_329830385) (the learning curve overhead is a different question, discussed below).\r\n- Cloudflare Workers [abandon containers for isolates](https://blog.cloudflare.com/introducing-workers-unbound/). If you believe the image shown, the process overhead inverts from ~90% to ~10%. \r\n - Obviously the image is not drawn to scale, but it's clear the overhead reduction is large (*If you're a knowledgeable reader, I'd love to get actual ballpark numbers on this*)\r\n- React takes about 8% of compute in apps, [by FB's own numbers](https://twitter.com/sebmarkbage/status/1201251406604197888?s=20)\r\n- **Management Overhead**:\r\n - 1 Manager should support 6-8 engineers, says [Will Larson](https://lethain.com/sizing-engineering-teams/). Aka 12.5% to 16.7% overhead.\r\n - Cal Newport [takes 10-20 minutes to plan out every work day](https://www.calnewport.com/blog/2013/12/21/deep-habits-the-importance-of-planning-every-minute-of-your-work-day/). Assuming an 8hr work day, that's just a 3% overhead.\r\n - Every entrepreneur struggles with the balance between \"working ON the business\" and \"working IN the business\" (coined by [Michael Gerber](https://www.quora.com/What-is-the-difference-between-working-in-the-business-and-working-on-the-business)). I think a ratio of 1:4 works well (say [10%](https://davidcummings.org/2015/11/08/working-in-the-business-vs-on-the-business/)-[25%](https://makersbusinesstoolkit.com/working-on-your-business-and-working-in-your-business/) overhead in reality).\r\n- **Marketing Overhead**: [Matt D'Avella says](https://jayclouse.com/podcast/matt-davella/) you should spend 80% of your time working on content, then 20% working on title, thumbnail, marketing.\r\n- **Platforms**: Matt Mullenweg [recently formalized](https://www.joincolossus.com/episodes/6786509/mullenweg-the-past-present-and-future-of-the-internet) [the Bill Gates Line](https://stratechery.com/2018/the-bill-gates-line/) by noting that open platforms should capture about 5% of the ecosystem value they enable.\r\n - Apple app store takes 30%, while Amazon marketplace takes 10-15% (https://overcast.fm/+x5q9ESZhA)\r\n- Engineering: The FAA regulates that [airplanes must be rated for 50% heavier load](https://surjan.substack.com/p/the-most-expensive-number-in-engineering) than they strictly need. (Wilbur Wright claimed a factor of 5)\r\n- Misc: “If I had eight hours to chop down a tree, I’d spend the first six of them sharpening my axe.” ― Abraham Lincoln\r\n\r\n## Too Much, or Too Little?\r\n\r\nWe don't directly care about how much overhead we use; we just want to maximize output. But clearly everything about how we plan and do our jobs will be wildly different depending on whether optimal overhead is 5% or 50%. (This can serve as a very useful filter for choosing tech and architecture, for example.)\r\n\r\nIncreasing overhead often makes sense. This goes by many names: [Slow down to speed up](https://www.mckinsey.com/business-functions/organization/our-insights/the-organization-blog/slowing-down-to-speed-up). [Sharpen the saw](https://www.franklincovey.com/the-7-habits/habit-7/). [Automate repeated tasks](https://xkcd.com/1319/).\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/s0juvjpuholarztbyfx8.png)\r\n\r\nBut sometimes the overhead isn't worth it, and we can't tell. Sometimes we should just be doing the thing rather than doing setup to do the thing. You see variants of this debate all over the place, from [Virtual DOM is pure overhead](https://svelte.dev/blog/virtual-dom-is-pure-overhead) to [Do Things That Don't Scale](http://paulgraham.com/ds.html).\r\n\r\nBy definition, **overhead is indirectly linked to output**. This link can be nonlinear, and noisy:\r\n\r\n- Imagine if you were taught to keep 30% overhead, but decided to try dropping down to 10%, and observed **no change** in output efficiency. ([like Uber did](https://www.inputmag.com/culture/uber-burned-through-100-million-thanks-to-digital-ad-fraud))\r\n- You would go from spending 70% of your resources producing, to 90% of your resources producing, with the same output per resource. This would be **a 29% increase** in output you've been missing out on the entire time! You'd be pissed!\r\n- And then imagine if someone else did it and got completely different results instead — and everyone was okay with it. No further study conducted.\r\n\r\n**That's our state of understanding of overhead in systems as of today.** \r\n\r\nThis is closer to how real life overhead charts might look like:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/s8o529o897x1z2vmyx4h.png)\r\n\r\nImagine if we had a \"Science of Overhead\". I'd settle for just being able to do [napkin math](https://github.com/sirupsen/napkin-math) on it. A ballpark range for overhead would reduce our uncertainty and help us find optimal (or tolerable, see below) overhead.\r\n\r\n## Determinants\r\n\r\n**I don't have an answer.** This post is me thinking aloud. But here are some hypotheses I am exploring.\r\n\r\n### Big O\r\n\r\nOverhead is governed by Big O as well. It's not super meaningful to measure the storage overhead of an operating system in percentages, because it is a fixed size - O(1). \r\n\r\nYou can make an argument that virtualization overhead scales O(N) with N being the number of VMs.\r\n\r\nAnything involving networking and communication suffers combinatorial/Metcalfe's law explosion, leading to nonlinearly increasing O(N^2) or worse inefficiency.\r\n\r\n### Learning Curve\r\n\r\nA unique form of overhead is something you can pay once and amortize *across repeated projects*, instead of only having a useful life of one project. This is known as a **learning curve**. \r\n\r\nAll frameworks bear this sort of overhead: For any one project, you might be able to get things done faster AND have faster running code, if you just did the project using \"vanilla\" code instead of learning the framework and then doing the project. You only see the benefits down the line once you work on multiple similar projects.\r\n\r\nYou might also then overinvest in the framework, only to find out that other projects aren't a fit, or, vice versa, the framework doesn't scale for your needs in some unforeseen way.\r\n\r\nThere are two unknowns to learn:\r\n\r\n- learning about the problem\r\n- learning about various solutions\r\n\r\nOne very good reason to use a framework is that it encodes more knowledge about the problem than you may have. But it can also be a crutch that gets in the way of you learning about the problem in the first place. And when you know enough about the problem and enough about the limitations of existing solutions, you may be forced to make your own.\r\n\r\n**All of this is very familiar to experienced programmers.**\r\n\r\n**And all of this is (tiresome, sometimes very unproductive) overhead.**\r\n\r\nThe primary challenge of \"learning curve\" type overhead isn't the amortization math. This is intuitive. \r\n\r\nWhat is particularly intractable is [Knightian uncertainty](https://en.wikipedia.org/wiki/Knightian_uncertainty) around **not knowing what you don't know**. By definition, if you haven't learned it yet, you may not really know how to evaluate it fully and have to rely on secondhand reports and endorsements.\r\n\r\nI hold out faith that this is a manageable, if not solvable problem. I have a strong suspicion that becoming a technical or people leader **means** developing some skill in managing for unknowns. It is a truism that scaling yourself, beyond just you, means you have to manage people whose jobs you have never done and technologies whose alternatives you have never used.\r\n\r\n> Note: Done badly, the above can be a particularly loathsome form of [bullshit job](https://www.newyorker.com/books/under-review/the-bullshit-job-boom). And yes — this includes product management and blogging — both roles that I perform. Always beware [Gell-Mann Amnesia](https://www.epsilontheory.com/gell-mann-amnesia/).\r\n\r\n### Humans vs Machines\r\n\r\nYou might be tempted to conclude that human systems naturally have higher overhead, as I was. Joel Spolsky's discussion of [Development Abstraction Layers](https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/) noted:\r\n\r\n> \"It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1.\" \r\n\r\n[Will Larson](https://lethain.com/) also commented that [Parkinson's Law originated from a similar observation that the British Navy's bureaucracy](https://www.bbc.com/worklife/article/20191107-the-law-that-explains-why-you-cant-get-anything-done) kept growing at the same rate regardless of the underlying work declining by 2/3rds.\r\n\r\n> Side note: [David Golden](https://xdg.me/) notes that military [\"tooth to tail\"](https://en.wikipedia.org/wiki/Tooth-to-tail_ratio) ratios aren't really the same thing as overhead.\r\n\r\nBut it's not always true. The US civil service is about 2% of the overall US labor force (you may be surprised to find, as I was, that Singapore's equivalent \"overhead\" is ~4%). Something that some operating systems would be proud of.\r\n\r\n## Tolerable Overhead\r\n\r\nPerhaps it is too much of an optimization exercise to aim for *optimal* overhead, given how noisy this whole process is. A lower bar we can aim for is **Tolerable Overhead**, suggested by [David Golden](https://xdg.me/). To me this is like a \"first do no harm\" principle of overhead - make sure you are at least no less productive with overhead than you were without it.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/v1vigbjn6g13d7qhi30t.png)\r\n\r\n## Postscript: Redundancy vs Overhead\r\n\r\nYou can find examples of \"redundancy\" everywhere in distributed systems. MongoDB recommends [3 member replica sets](https://docs.mongodb.com/manual/core/replica-set-architecture-three-members/), but Google famously requires [5 nodes for fault tolerance](https://dataskeptic.libsyn.com/byzantine-fault-tolerant-consensus). Of course by nature these are >100% numbers - and [David Golden](https://xdg.me/) rightly pointed out to me that they aren't comparable to overhead.\r\n\r\n## Related Reads\r\n\r\nI will update this post with more reads and numbers as I come across them. Ultimately I'd like to achieve a good reference table like this epic [Dan Luu post on Computer Latency](https://danluu.com/input-lag/).\r\n\r\n- [Buridan's Ass](https://en.wikipedia.org/wiki/Buridan%27s_ass) - analysis paralysis in philosophy\r\n- [Efficiency is the Enemy](https://fs.blog/2021/05/slack/) - Shane Parrish's take on the importance of Slack\r\n- I did do a fun talk about [Svelte and the Great Space Elevator](https://www.youtube.com/watch?v=atOIxTHylF8) where I discussed how we pay for overhead in frontend frameworks.\r\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/what-drives-optimal-overhead-2p3a","devToReactions":17,"devToReadingTime":8,"devToPublishedAt":"2021-01-08T13:33:00.939Z","devToViewsCount":144,"title":"What drives Optimal Overhead?","published":true,"description":"The biggest unanswered question in the study of systems.","tags":"Research, Systems","slug":"optimal-overhead","canonical_url":"https://www.swyx.io/optimal-overhead","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/c1o3owg0liv43ixque75.png"},"title":"What drives Optimal Overhead?","description":"The biggest unanswered question in the study of systems. ","category":"note","tags":["research","systems"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/c1o3owg0liv43ixque75.png","canonical":"https://www.swyx.io/optimal-overhead","slug":"optimal-overhead","date":"2021-01-08T13:33:00.939Z","readingTime":"8 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/310","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/310/comments","title":"What drives Optimal Overhead?","created_at":"2022-01-18T00:12:21Z","updated_at":"2022-03-24T13:51:30Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/310/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n\n> Joseph Heller and I were at a party given by a billionaire\n> on Shelter Island. \n>\n> I said, “How does it make you feel to know that our host only yesterday may have made more money than your novel ‘Catch-22’ has earned in its entire history?”\n>\n> And Joe said, “I’ve got something he can never have.”\n>\n> And I said, “What on earth could that be, Joe?”\n>\n> And Joe said, “Enough.”\n>\n> — Chapter 3: Never Enough\n\nI've just completed the audiobook version of Morgan Housel's [The Psychology of Money](https://www.collaborativefund.com/blog/the-psychology-of-money/) ([affiliate link here](https://amzn.to/2My6fNH)). This is the sort of book that will hit differently depending on the kind of money management experience you have. \n\nI won't bury the lede: I thought it was **excellent**. I'm going to set some personal context (which you can skip) and then mark out the three (related) themes of the book which particularly stood out to me:\n\n- Getting Wealthy\n- Risk\n- Staying Wealthy\n\nI'll also link chapters I reference with publicly available versions of stuff that Morgan has written in the past ([like this](https://www.collaborativefund.com/blog/the-psychology-of-money/)), but of course if you want the most concise/polished version you'll have to get the book.\n\n## My Context\n\nMy background is a longish story but in short: I accumulated all the paper qualifications during my finance career. BSc from Wharton, MSc from Chicago, CFA, CAIA. Some years of sell- and buy-side experience. \n\nIt took me a lot of time in the markets (and some family financial mismanagement) to understand that the paper stuff doesn't matter. Have you spent years at the world's best universities only to be completely trounced by someone who didn't even graduate high school? I have. Reality is extremely humbling to people who were brought up in ivory towers.\n\nIn particular I reflect a lot on my hedge fund days. We did all sorts of terrible trades. We failed to be sufficiently long on big tech because it was \"consensus\". We lost money shorting the Taiwanese display industry because we got squeezed - in a year when the sector eventually went down >50%. I spread myself thin \"covering\" 300 names when a normal workload should be like 30 (it was, however, a ridiculously mind-expanding time with unparalleled access - highlights include visiting [Dentsu's](https://en.wikipedia.org/wiki/Dentsu) glittering HQ in Tokyo, [Mobile World Congress](https://en.wikipedia.org/wiki/Mobile_World_Congress) in Barcelona, [LINE](https://en.wikipedia.org/wiki/Line_(software)) in Seoul, [the MAGIC trade show](https://www.magicfashionevents.com/en/home.html) in Vegas, and touring the [Tesla Fremont Factory](https://en.wikipedia.org/wiki/Tesla_Fremont_Factory) with their CFO). Our boss made mid-seven figures as our PM, yet mostly rode the coattails of G, the real star on our team.\n\nI think what we neglected was, for lack of a better word, our \"Psychology of Money\". It's no surprise to me that a psychiatrist is a central character of the hedge fund drama [Billions](https://en.wikipedia.org/wiki/Billions_(TV_series)). I wish we had one. I quit the industry because I couldn't handle the stress from our high risk, earnings day whipsaw positions. We habitually lied that we were looking for 18-24 month investment theses when the reality was that we'd be out after the next earnings. We chased after >50% [win-rates](https://www.investopedia.com/terms/w/win-loss-ratio.asp) but cut winners short at the first sign of trouble. We attributed luck to skill. Our boss often spent money as fast as he could make it - fancy sports car, fancy seaview condo, fancy everything. He had everything but I don't think he ever had *enough*. It rubbed off on me - despite making perhaps $250k after taxes, I saved almost none of it.\n\n## Getting Wealthy\n\n**Save Money** ([Chapter 10](https://www.collaborativefund.com/blog/saving-money-and-running-backwards/)). Seems obvious, but many people don't do it, so it is worth mentioning. You can't control what you make. But you can control what you save.\n\n**Stay in the Game**. You need **Room for Error** (Chapter 13) to **let compounding work** ([Chapter 4](https://www.collaborativefund.com/blog/the-freakishly-strong-base/)). If Warren Buffett had only been an investor for 30 years (ages 30–60 like most people), **you would not have heard of him**.\n\n> *\"Warren Buffett’s net worth is $84.5 billion. Of that, $84.2 billion was accumulated after his 50th birthday... [If he started at age 30 and] generated 22% annual returns, and retired at 60 to play golf, his net worth would only be $11.9 million (**99.9% less than current**).\"*\n\nIt's compounding for 70 years – not 30 – that made the difference.\n\nThere's a flip side to this too: Most people don't know that Rick Guerin was the **third** member of Warren Buffett and Charlie Munger's investing group when they started out in the 1960s. \n\nWarren and Charlie survived 14 recessions. [Rick got caught out levered with margin loans](https://www.fool.com/investing/general/2013/01/10/mohnish-pabrai-what-ive-learned-from-warren-and-ch.aspx). Today — you've already forgotten his name.\n\n> \"*The trick when dealing with failure is arranging your financial life in a way that a bad investment here or missed financial goal there won't wipe you out so you can keep playing until the odds fall in your favor.*\" (Chapter 2)\n\n**Time Horizons Matter**. The historical odds of making money in U.S. markets are 50/50 over one-day periods, 68% in one-year periods, 88% in 10-year periods, and (so far) 100% in 20-year periods. ([Chapter 11](https://www.collaborativefund.com/blog/you-better-love-this/))\n\n**Fight Overoptimism *AND* Overpessimism**. \n\n- Your bias is based on your context and personal experience ([Chapter 1](https://web.archive.org/web/20200515185905/https://www.collaborativefund.com/blog/no-one-is-crazy/)). \"*Your personal experiences with money make up maybe 0.00000001% of what’s happened in the world, but maybe 80% of how you think the world works*\". \n\n- Beware taking financial cues from people that are playing a different game than you are. **Bubbles** form when the momentum of short-term returns attracts enough money that the makeup of investors shifts from mostly long term to mostly short term. ([Chapter 16](https://www.collaborativefund.com/uploads/Collaborative%20Fund%20--%20The%20Reasonable%20Formation%20of%20Unreasonable%20Things2.pdf))\n\n- Pessimism is extremely seductive ([Chapter 17](https://www.collaborativefund.com/blog/the-seduction-of-pessimism/)). Optimism is the best bet for most people because the world tends to get better for most people most of the time. Pessimism isn’t just more common than optimism. It also sounds smarter. It’s intellectually captivating, and it’s paid more attention than optimism, which is often viewed as being oblivious to risk. \n\n > “For reasons I have never understood, people like to hear that the world is going to hell.” — Historian Deirdre McCloskey \n\nTo square the two, learn to be comfortably bipolar: [Save like a Pessimist, Invest like an Optimist](https://www.collaborativefund.com/blog/save-like-a-pessimist-invest-like-an-optimist/).\n\n## Risk\n\n> \"Things that have never happened before happen all the time.\" \n>\n> — *Scott Sagan*\n\nMorgan notes in Chapter 12, [Surprise](https://www.collaborativefund.com/blog/surprise/): *\"History is mostly the study of surprising events, but is used by economists as an unassailable guide to the future.\"* The \"Historians as Prophets\" fallacy was always my biggest problem in the quantitative aspects of finance. \n\nPut aside the unsolvable problem of hilariously small sample sizes and lack of controlled experiments in finance. The simple assumption that what has happened before sets the upper and lower bounds for what can happen in future is laughable — considering how much technology, society, and even geography change within a single human lifespan. John Templeton is known for saying that \"This Time Is Different\" are the four most dangerous words in investing, but [even he concedes](https://www.advisorperspectives.com/commentaries/2019/06/13/this-time-its-different) that 20% of the time it really is different.\n\nWe adopt this because of some combination of [physics envy](https://en.wikipedia.org/wiki/Physics_envy) and [politician's syllogism](https://en.wikipedia.org/wiki/Politician%27s_syllogism). We want to believe something so **we'll believe anything** ([Chapter 18](https://www.collaborativefund.com/blog/when-youll-believe-anything/)). It works well enough for 95% of days, and then is completely useless (or worse than useless) for the 5% of the time things are new. (*It's even more frustrating when regulators encode this arrogance into law, but that's a huge tangent...*)\n\n> “We need to believe we live in a predictable, controllable world, so we turn to authoritative-sounding people who promise to satisfy that need.” — Philip Tetlock\n\n5% is a small number; we'd be able to live with it if this other fact weren't true — **investment returns are strongly determined by fat tails** ([Chapter 6](https://www.collaborativefund.com/blog/tails-you-win/)), created by **outside forces** rather than individual effort ([Chapter 2](https://www.collaborativefund.com/blog/the-laws-of-investing/)), with forcing out weak hands with no **Room for Error** ([Chapter 13](http://www.collaborativefund.com/blog/when-things-get-wild/)). Meaning that 5% of the time things are new can determine 95% of total return, especially when taking investor response into account. \n\nThis is an argument for **diversifying by indexing** (as Morgan notes, this even works for art markets), and simply sticking it out long enough for it to work. Also means *not* pursuing the biggest short term returns - merely good returns for the longest possible amount of time.\n\nThis approach to luck and risk also applies to forgiveness and social judgment. Not all success is due to hard work, and not all poverty is due to laziness.\n\n> “Risk is what’s left over when you think you’ve thought of everything.” — Carl Richards\n\n## Staying Wealthy\n\nThis book taught me that **Wealth is What You Don't Spend** ([chapter 9](https://www.collaborativefund.com/blog/gains/)). We spend on flashy things mostly to impress other impressive people. This is a never ending pit of emptiness because there will always be someone who can outspend you, and in the end all you are left with is the empty joys of the stuff you bought and a smaller net worth than when you started.\n\nWe need to fight the urge that we can **Never have Enough** ([chapter 3](https://www.collaborativefund.com/blog/fat-happy-and-in-over-your-head/)). This is the sort of greed that lead Rajat Gupta, a widely well respected former CEO of McKinsey, to [commit insider trading](https://en.wikipedia.org/wiki/Raj_Rajaratnam/Galleon_Group,_Anil_Kumar,_and_Rajat_Gupta_insider_trading_cases#Gupta_charges_and_trial) to save less than $3 million in losses. He was already worth ~$100 million. He wanted to be a billionaire. He ended up going to jail instead.\n\n> \"*The hardest financial skill is **getting the goalpost to stop moving**.*\"\n\nIt takes a very different skillset and mindset to **Stay Wealthy after Getting Wealthy** ([chapter 5](https://www.collaborativefund.com/blog/getting-rich-vs-staying-rich/)). The annals of finance are riddled with famous investors who knew the latter but not the former. Jesse Livermore made the equivalent of $3 billion in one day after shorting Black Monday in 1929 - then proceeded to lose it all, file for bankruptcy by 1934 and kill himself in 1940. \n\n> \"*There are a million ways to get wealthy... but there is only one way to **stay** wealthy - some combination of frugality and paranoia. Wealth is the nice cars **not** purchased. The diamonds **not** bought. The watches **not** worn, the clothes **forgone** and the first-class upgrade **declined**.*\"\n\nInstead of pursuing the image of wealth (being the Man in the Car nobody cares about - [chapter 8](https://fourpillarfreedom.com/rich-man-in-the-car-paradox/)), you can use wealth to buy **Freedom** (chapter 7 - can't find anything close but this is [a nice ladder to think about](https://www.collaborativefund.com/blog/the-spectrum-of-financial-dependence-and-independence/)). \n\n> *\"The ability to do what you want, when you want, with who you want, for as long as you want, is priceless. It is the highest dividend money pays.\"*\n\n## Closing Thoughts\n\nMorgan is one of the best financial writers of our generation. This was honed over a decade of writing about finance for the Motley Fool and WSJ. It's not easy to make these \"soft\", non-technical points to someone as technically inclined as myself. But perhaps I just happen to be in the right mental space to receive this message.\n\nI think, above all, Morgan makes an extremely compelling case that Pyschology, not math, governs our personal relationship with money and finances. \n\n> \"*Important financial decisions are not made in spreadsheets or in textbooks. **They are made at the dinner table**. They often aren’t made with the intention of maximizing returns, but minimizing the chance of disappointing a spouse or child.*\" - Chapter 20\n\nOf course, he isn't the first to observe this. But he is the first, in my mind, to do it well, [more cogently than Charlie Munger](https://twitter.com/Coding_Career/status/1332289858652389377?s=20), who is the inspiration for this book. Academic behavioral finance studies this in isolated cases, but Morgan makes it relatable by setting these in real life contexts.\n\nFor those interested in the audiobook version ([you can get your first free here](https://amzn.to/2My6fNH)), I found [Chris Hill's](https://twitter.com/TMFChrisHill/status/1285948369584689153?s=20) narration pleasant and undistracting. I wondered if he was a professional narrator, but it turns out he is a friend and ex-colleague of the author.\n\n## Other Notes I found\n\n- https://sohilgupta.medium.com/the-psychology-of-money-by-morgan-housel-notes-5bdbc9882041","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/book-review-the-psychology-of-money-inb","devToReactions":24,"devToReadingTime":9,"devToPublishedAt":"2021-01-03T22:54:43.124Z","devToViewsCount":236,"title":"Notes on The Psychology of Money","published":true,"description":"A review and reflection of Morgan Housel's bestselling collection of essays on personal/behavioral finance","tags":"finance, money, books","slug":"psychology-of-money","canonical_url":"https://www.swyx.io/psychology-of-money","cover_image":"https://rupiko.in/wp-content/uploads/2020/11/Books-The-Psychology-of-Money.png"},"title":"Notes on The Psychology of Money","description":"A review and reflection of Morgan Housel's bestselling collection of essays on personal/behavioral finance ","category":"note","tags":["finance","money","books"],"image":"https://rupiko.in/wp-content/uploads/2020/11/Books-The-Psychology-of-Money.png","canonical":"https://www.swyx.io/psychology-of-money","slug":"psychology-of-money","date":"2021-01-03T22:54:43.124Z","readingTime":"9 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/312","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/312/comments","title":"Notes on The Psychology of Money","created_at":"2022-01-18T00:13:00Z","updated_at":"2022-06-18T17:47:13Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/312/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nI've realized that the problem with my old New Year's Resolutions is *not* that I give up halfway. It is that I overly fixate on 1 year *outcomes*, without holding myself accountable to a *system* that gets me there. While [the reasons to favor Systems over Goals](https://www.google.com/search?q=systems%20over%20goals) are well explored, I am still unwilling to abandon goals altogether. Goals are wonderfully motivating, especially if they are [Big, Hairy, and Audacious](https://www.swyx.io/bhags/).\n\nI think the solution is to make a **system of goals** for yourself.\n\n![Fibonacci Goals](https://dev-to-uploads.s3.amazonaws.com/i/ngkl2oyb7gmtw0gu1vap.png)\n\nI've dubbed my system **Fibonacci Goals**. They work like this:\n\n- On Day 1, I make a 1 day goal.\n- If I achieve that goal, I can make a 2 day goal.\n- If I achieve *that* goal, I am allowed to make a 3 day goal.\n\nAnd so on, with goal commitment ramping up by the [Fibonacci sequence](https://en.wikipedia.org/wiki/Fibonacci_number): `1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...`.\n\n> Note: Technically, the Fibonacci sequence starts at 0, but I've opted to start at the second 1. Move your start point left or right as you wish.\n\nIf I fail a goal, I slide back toward the previous step. If I miss my 21 day goal, I must complete another 13 day goal before re-attempting the 21 day goal. This gives me a win before I attempt another milestone.\n\nYou can start a Fibonacci goal game at any time of the year, and take breaks between goals. If you start on Jan 1, an unbroken chain of successful goal completion from 1-day up to the 89-day goal takes 232 days (August 20). Taking into account breaks and backslides, there's enough for a full year of wins.\n\nI suspect I will achieve more with this system than if I go for a 365-day goal on my first attempt.\n\nIn [Hegelian terms](https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic), if Goals are the thesis, and Systems are the antithesis, then Fibonacci Goals are the synthesis. A system made up of progressively increasing mini-goals. \n\nMy first goal in 2021 is to write this post. I will set my next tomorrow. I hope this gives you some ideas for your personal goals and systems too. No matter what you use, I would love to hear about them and to support you in your progress!\n\n> ICYMI: Randall and I chatted about [Systems vs Goals](https://careerchats.transistor.fm/episodes/goals-vs-processes-why-your-goals-are-actually-wishes) for the New Year's Eve episode of our podcast!\n\n> You may also like: [Dump your Inner Drill Sergeant](https://www.breaker.audio/the-happiness-lab-with-dr-laurie-santos/e/78771360) on the Happiness Lab podcast. Being too harsh on yourself doesn't work!\n\n## Problems Solved \n\nComparing Resolutions to Fibonacci Goals:\n\n- We set 1 year goals without any evidence that we are able to achieve even half of that\n- We don't know how to estimate what we can achieve in a year\n- We get discouraged when we slip up mid year and then our whole year's motivation is shot with no way to \"get back on the horse\"\n- We don't build momentum with progressive wins, it is all or nothing\n- There is no system allowing for natural breaks\n- We don't feel able to start a Resolution on a random date, say, October 3rd, and instead put off our hopes for Jan 1st.\n\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/fibonacci-goals-46ai","devToReactions":44,"devToReadingTime":3,"devToPublishedAt":"2021-01-01T19:58:00.938Z","devToViewsCount":1302,"title":"Fibonacci Goals","published":true,"description":"A system for goalsetting.","tags":"Ideas","slug":"fibonacci-goals","canonical_url":"https://www.swyx.io/fibonacci-goals","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/9swbddr03q4gplf05jnk.png"},"title":"Fibonacci Goals","description":"A system for goalsetting. ","category":"note","tags":["ideas"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/9swbddr03q4gplf05jnk.png","canonical":"https://www.swyx.io/fibonacci-goals","slug":"fibonacci-goals","date":"2021-01-01T19:58:00.938Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/313","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/313/comments","title":"Fibonacci Goals","created_at":"2022-01-18T00:13:02Z","updated_at":"2022-06-18T17:47:13Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/313/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n\n[Alex Lakatos](https://twitter.com/lakatos88) interviewed me for the Devrel Advent calendar he put together. Extracts below:\n\n> **How did you get into Developer Relations?**\n\nMy first dev job was extremely unfulfilling, so I started blogging and speaking at meetups on the side to continue learning outside of work. After about 6 months of this I got a DM from Matt Biilmann, Netlify’s CEO!\n\n> **What advice would you give people looking to join you?**\n\nStart Learning in Public. *what else did you expect me to say?*\n\n> **How has your role changed in the past year?**\n\nI’ve begun to realize that individual speaking and writing can only scale so much, and you can have much more impact working behind the scenes on docs, demos and reusable resources, helping others to speak, and developer exceptions.\n\n> **How do you see the future of DevRel?**\n\nDevRel will split into community-focused, product-focused, and content-focused specializations. \n\n---\n\nYou can [read the full piece here](https://avocados.dev/adventcado/2020/12/08/shawn-wang/). \n\n## Further Reading\n\nLinked resources from me:\n\n- https://dev.to/swyx/moderating-a-220k-developer-community-3doj\n- https://www.swyx.io/learn-in-public/\n- https://www.swyx.io/learn-in-public-hack/\n- https://www.swyx.io/writing/marketing-yourself/\n- https://www.swyx.io/developer-exception/\n- https://dev.to/swyx/tips-for-speakers-prerecording-talks-for-online-conferences-4ic9","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/my-path-to-developer-relations-and-thoughts-on-the-future-of-devrel-d00","devToReactions":8,"devToReadingTime":1,"devToPublishedAt":"2020-12-30T22:06:02.484Z","devToViewsCount":119,"title":"My Path to Developer Relations and Thoughts on the Future of DevRel","published":true,"description":"Alex Lakatos interviewed me for the Devrel Advent calendar he put together","tags":"Reflections","slug":"adventcado-qna","canonical_url":"https://www.swyx.io/adventcado-qna","displayed_publish_date":"2020-12-08"},"title":"My Path to Developer Relations and Thoughts on the Future of DevRel","description":"Alex Lakatos interviewed me for the Devrel Advent calendar he put together ","category":"note","tags":["reflections"],"canonical":"https://www.swyx.io/adventcado-qna","slug":"adventcado-qna","date":"2020-12-30T22:06:02.484Z","readingTime":"1 minute","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/314","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/314/comments","title":"My Path to Developer Relations and Thoughts on the Future of DevRel","created_at":"2022-01-18T00:13:04Z","updated_at":"2022-06-18T17:47:14Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/314/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n\nI was interviewed by [Pete Codes](https://twitter.com/petecodes) on [No CS Degree](https://www.nocsdegree.com/shawn-noob-aws-job/), here are some extracts.\n\n> **I see you started coding with Free Code Camp. Would you recommend that for newbies?** \n\nYes! It can [genuinely take you from zero knowledge of coding to employable within the first 6 - 12 months](https://hackernoon.com/no-zero-days-my-path-from-code-newbie-to-full-stack-developer-in-12-months-214122a8948f) if you really keep at it. FCC was the only one that I've found that had the full HTML, CSS and JavaScript curriculum that I figured was in the highest demand. It's also free so you risk very little by trying it out.\n\n> **How did you enjoy Full Stack Academy bootcamp?**\n\n - I particularly enjoyed the learning sections of the bootcamp because it gave me the opportunity to really solidify the knowledge that I had vaguely skimmed over during FreeCodeCamp.\n - The bootcamp is also laser focused on teaching employable skills and even organises **a hiring day at the end which is where I got my first developer job**. The job hunt is the hardest part of transitioning careers so it is very helpful to have an organisation dedicated to helping you succeed.\n\n> **How did you get your first entry level software engineer job?**\n\n - I got my first software engineer job (at Two Sigma) straight out of the hiring day of my bootcamp! I think it was a combination of luck because it was the very first person I sat down with, and also a fit in terms of background because they were looking for someone who had some financial exposure.\n - What was more important was to be able to intelligently answer questions that were given to me during the on-site interviews, for example one of the interviews I had to justify why people use Redux, with the interviewer taking the other side for argument's sake. **It can be intimidating to debate during a job interview, but they are looking for you to stand your ground with technical substance if you can.** This is how you can show that you add value to the team before you join it.\n\n> **What advice do you have for someone without a CS degree who wants to get their first programming job?**\n\n - Keep going! The software industry is far more open to people without credentials than most. There are two things that people want to know when hiring you: that you have **covered your bases**, and that you have **done cool things**.\n - “Covering your bases” means knowing fundamental knowledge like how to work with git and how to write a basic program in your chosen language or framework. \n - “Doing cool things” can include a side project that experiments with new technology or having contributed to open source projects that the company uses.\n - Mekka Okereke, a hiring manager at Google, adds a third dimension - [something with a story](https://twitter.com/mekkaokereke/status/1266051694284038144?s=20). You’ll get these with more experience.\n\nYou can [read the interview in full here](https://www.nocsdegree.com/shawn-noob-aws-job/)!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/my-journey-from-no-cs-degree-to-aws-from-age-30-34-2bmd","devToReactions":22,"devToReadingTime":2,"devToPublishedAt":"2020-12-30T21:21:47.942Z","devToViewsCount":221,"title":"My Journey from No CS Degree to AWS from Age 30 - 34","published":true,"description":"I was interviewed by Pete from No CS Degree on my journey, here are some extracts!","tags":"Reflections, Interviews","slug":"nocsdegree-pete","canonical_url":"https://www.swyx.io/nocsdegree-pete","displayed_publish_date":"2020-09-11"},"title":"My Journey from No CS Degree to AWS from Age 30 - 34","description":"I was interviewed by Pete from No CS Degree on my journey, here are some extracts! ","category":"note","tags":["reflections","interviews"],"canonical":"https://www.swyx.io/nocsdegree-pete","slug":"nocsdegree-pete","date":"2020-12-30T21:21:47.942Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/315","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/315/comments","title":"My Journey from No CS Degree to AWS from Age 30 - 34","created_at":"2022-01-18T00:13:06Z","updated_at":"2022-06-18T17:47:14Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/315/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n\nI was interviewed by [Chris Bongers](https://twitter.com/DailyDevTips1) on [Daily Dev Tips](https://daily-dev-tips.com/posts/interview-with-shawn-swyx-wang-from-finance-to-tech/), here are some extracts.\n\n> **What tips would you give someone interested to switch to tech?** \n\n - It takes time, but it's a long term investment. The tech industry is one of those industries where we will always have a job. \n - You must never stop learning and improving yourself. The tech industry shifts rapidly so you need to keep up with the latest technology.\n - Market yourself in every possible way. Start writing, live streaming, being an active contributor, and promote yourself. \n\n> **You're a big advocate for writing in public. Why is that?**\n\n - It makes you understand the subject better.\n - It's a way of organizing learning while people also point out your mistakes.\n - When you are writing in public, keep your ego small. If you are genuinely learning, people will want to help and then follow your journey.\n\nYou can [read the interview in full here](https://daily-dev-tips.com/posts/interview-with-shawn-swyx-wang-from-finance-to-tech/)! \n\n\n## Further Reading\n\nLinked posts I referenced:\n\n- https://www.swyx.io/create_luck\n- https://www.swyx.io/friendcatchers/\n- https://www.learninpublic.org/","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/swyx-interview-on-daily-dev-tips-5dck","devToReactions":4,"devToReadingTime":1,"devToPublishedAt":"2020-12-30T21:04:35.366Z","devToViewsCount":67,"title":"Swyx Interview on Daily Dev Tips","published":true,"description":"I was interviewed by Chris Bongers on Daily Dev Tips, here are some extracts.","tags":"Reflections, Interviews","slug":"dailydevtips1","canonical_url":"https://www.swyx.io/dailydevtips1","displayed_publish_date":"2020-09-05"},"title":"Swyx Interview on Daily Dev Tips","description":"I was interviewed by Chris Bongers on Daily Dev Tips, here are some extracts. ","category":"note","tags":["reflections","interviews"],"canonical":"https://www.swyx.io/dailydevtips1","slug":"dailydevtips1","date":"2020-12-30T21:04:35.366Z","readingTime":"1 minute","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/316","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/316/comments","title":"Swyx Interview on Daily Dev Tips","created_at":"2022-01-18T00:13:07Z","updated_at":"2022-06-18T17:47:14Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/316/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n> This post was featured on [CSS Tricks](https://css-tricks.com/make-your-own-tools/) with more commentary and I also discussed side projects on the [Modern Web Podcast](https://modernweb.podbean.com/e/s08e09-modern-web-podcast-sides-projects-with-shawn-wang/)!\n\nI read a list of [Things You're Allowed To Do](https://milan.cvitkovic.net/writing/things_youre_allowed_to_do/) on Hacker News recently. These are useful reminders for a well paid, technical audience, but one thing stuck out to me: **It didn't mention making your own tools**. Not even once.\n\nEven the greatest software has parts that aren't so great for you. But the difference between you and everyone else is that you can code. \n\nHere's a list of tools (*that you don't need anyone's permission*) to code for yourself:\n\n- **You can make your own Stylesheet**: Long before [GitHub got Dark Mode](https://twitter.com/swyx/status/1336363173838909441), developers had been making their own with the [Stylus Userstyles Manager](https://github.com/openstyles/stylus).\n- **You can make your own Query Generator**: Most platforms have advanced features that are poorly documented and don't have good UIs. You can make your own. I made my own [Advanced Twitter Search UI](https://twitter.com/swyx/status/1328086859356913664?s=20) embedding all the little tips and tricks that people pass around by word of mouth. I know of two ongoing attempts to [do the same for Google's advanced operators](https://twitter.com/swyx/status/1335627133956153344).\n ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/jntu0l1zk2o3xz8bu5fz.png)\n- **You can make an Inspo Generator**: Projects like [What to Tweet](https://whattotweet.com/), [Components.ai](https://components.ai/) and [Doodle Strudel](https://www.doodlestrudel.com/) get ridiculously popular compared to their technical complexity - because inspiration loves combinatorial explosions!\n- **You can make your own scripts**: [Like this guy](https://github.com/NARKOZ/hacker-scripts#hacker-scripts). Developers have apparently been automating coffee machines for so long that I recently learned that the infamous [HTTP Error 418](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418) was inspired by an actual real life situation.\n- **You can make your own CLIs**: CLIs are essentially interactive scripts. If you do JavaScript, I made a course on Egghead about [building custom CLIs with oclif and TypeScript](https://egghead.io/courses/build-custom-command-line-interface-cli-tooling-with-oclif-and-typescript?af=95qfq1)!\n- **You can make personal proxies**: Frustrated with slow searches (I am often on mobile 3G), [gamed search results](https://news.ycombinator.com/item?id=25538586), and [assorted crap in my URLs](https://twitter.com/shanselman/status/1341583883947544578?s=20), I recently [made my own Google Search proxy](https://twitter.com/swyx/status/1342625544320339969). A proxy is different from \"just the UI\", because it involves setting up a server or serverless function to process data for you. Because you have total control of server data, you have the ability to postprocess, combine, persist, and optimize it for your specific preferences. [Scraping public data is probably legal](https://www.reuters.com/article/dataprivacy-linkedin-datascraping-idUSL2N2GM1ZV), but personal means personal - Be careful about sharing it with others and definitely do not sell it. But this is ethically no different than setting up your own [Pi-hole](https://pi-hole.net/).\n \n ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/56r2dhdtgq8qw3qsi3jo.png)\n > My personal [cheatsheet of automation resources is available here](https://github.com/sw-yx/automation/).\n\nThese ideas are great, scoped projects that let you try out new languages and frameworks and improve your quality of life as a side effect. Always wanted to [try Svelte](https://www.swyx.io/svelte-why/)? Make a query generator! Want a new CLI? [Deno ships binaries now!](https://deno.land/posts/v1.6) [Supabase](https://supabase.io/) claims to be an Open Source Firebase Alternative? Put it to the test!\n\nAnd there's a compounding effect to these as you make them. More often than not, the lessons you learn from making a tool for yourself will find their way into your work. If you get *really* lucky - [your side projects might even become your life's work](https://medium.com/who-what-why/how-side-projects-saved-our-startup-a83a80f3b3ae).\n\nDon't take it from me. Here's [Dan Abramov](https://twitter.com/dan_abramov/status/1140259247680315393?s=20):\n\n> Here’s a thing that I learned at FB that I wish I knew much earlier. Invest in building custom tools! \n\n> You might think only bigcos make custom tools. But a tool doesn’t have to be sophisticated. It can be a script you could write in a day. And at small and medium companies, even a little effort can yield a huge return. Because **nobody optimized anything yet**.\n\nThe beauty of specializing in moving bits instead of atoms is that we can iterate in minutes, rather than months. That's a skill that customers pay us handsomely for, and we should remember that we can simply be our own customers too.\n\n> Author's Note: I wrote a longer treatment of the benefits of, and ideas for, Side Projects in [The Coding Career Handbook](https://www.learninpublic.org/). I also commented in [the KeyCuts podcast](https://www.thekeycuts.com/dear-analyst-50-walking-through-a-vba-script-for-trading-billions-of-dollars-worth-of-derivatives-with-shawn-wang/) on how all young finance traders make their own pricing tools as a rite of passage — like how [Jedi make their own lightsabers](https://starwars.fandom.com/wiki/Knighting_ceremony/Legends#New_Jedi_Order) before becoming Jedi Knights.\n\n> If you are making a DevTools startup, I am [incubating a small community in DX Circle](https://codingcareer.circle.so/c/devtools), my proto-blog for investing in Developer Tools and Developer Communities.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/you-re-allowed-to-make-your-own-tools-85k","devToReactions":41,"devToReadingTime":4,"devToPublishedAt":"2020-12-26T18:04:11.076Z","devToViewsCount":829,"title":"You're Allowed To Make Your Own Tools","published":true,"description":"Making personal side projects for fun and profit.","tags":"Advice","slug":"make-your-own-tools","canonical_url":"https://www.swyx.io/make-your-own-tools","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/jntu0l1zk2o3xz8bu5fz.png"},"title":"You're Allowed To Make Your Own Tools","description":"Making personal side projects for fun and profit. ","category":"note","tags":["advice"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/jntu0l1zk2o3xz8bu5fz.png","canonical":"https://www.swyx.io/make-your-own-tools","slug":"make-your-own-tools","date":"2020-12-26T18:04:11.076Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/317","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/317/comments","title":"You're Allowed To Make Your Own Tools","created_at":"2022-01-18T00:13:09Z","updated_at":"2022-06-18T17:47:14Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/317/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nThe React team [announced React Server Components](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html) this week with a [talk](https://www.youtube.com/watch?v=TQQPAU21ZUw&feature=emb_title), [RFC](https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md), and [demo](https://github.com/reactjs/server-components-demo/). It is a lot to go through (especially for a holiday week), but I did. Here are my notes.\n\n> Apr 2021 update: they have now published [an Architecture Q&A](#2021-architecture-qampa-notes), notes below.\n\n## TL;DR\n\n**What are React Server Components?**\n\nThey are an experimental, upcoming feature of React that lets you render Components **only** on the Server. This has a few implications; here are my top 2:\n\n - RSCs have **Zero** client JS bundle impact, so they can greatly reduce your overall bundle size. Despite only rendering on the server, they don't have to be static; you can refetch Server Components and the server will *stream* updates down, *without losing state* in Client Components.\n - You can **directly query your database** inside a Server Component *without setting up GraphQL, API endpoints, or state management* - and keep the query up to date as your serverside data changes. These queries are also faster because you save client-server roundtrips and waterfalls.\n\n> Note: They must be named with a `.server.js` extension and follow [some constraints](https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#capabilities--constraints-of-server-and-client-components) - mainly, they can't use state, effects, or DOM APIs.\n\n**What problems do React Server Components solve?**\n\nThey solve for Good User Experience, Cheap Maintenance, and Fast Performance in React apps (*as defined in the talk notes below*). There are multiple benefits for both developers and users, and the size of benefit depends on the use case, which makes this difficult to fully explain. \n\nHowever the headline opportunity here is to **greatly** reduce production React app bundle sizes (tests have seen as much as 29% reduction, but can easily be higher depending on your app) while not sacrificing modern app-like user experiences (*this again has multiple meanings - demonstrated in the demo below*).\n\nFinally, React Server Components make it *easy* to create **hybrid** apps - giving you the power to pick a sliding scale between a fully clientside app or a fully serverside app and everything in between - and not have to do major rewrites to change paradigms as requirements change.\n\n## Annotated Talk With Timestamps\n\nI will link to the timestamps with my commentary below, but you can view Dan Abramov and Lauren Tan's full talk here:\n\n{% youtube TQQPAU21ZUw %}\n\n- [1:45](https://youtu.be/TQQPAU21ZUw?t=105) Dan introduces the main constraints that React is trying to solve for:\n - **Good User Experience** - we want to [orchestrate intentionally designed loading states](https://reactjs.org/docs/concurrent-mode-suspense.html#what-suspense-lets-you-do). Items that should appear together must appear together, instead of jumping around on screen based on async API requests resolving.\n - **Cheap Maintenance** - we want to [optimize for change](https://overreacted.io/optimized-for-change/). Make it easy to delete and move code around from component to component or from client to server or from stateless to stateful. To do this, data requirements should be delegated as low down the component tree as possible, rather than hoisted up to the highest common parent.\n - **Fast Performance** - we want to decrease JS bundle size, avoid client-server roundtrips and [network waterfalls](https://reactjs.org/docs/concurrent-mode-suspense.html#traditional-approaches-vs-suspense). If components are not dynamic, we should render them once on the server (and fetch their data), and not send their JS to the client. We should cache results on the client if possible. Requests that can be done in parallel should not be done in sequence.\n - Historically, React forced you to choose 2 out of 3 of these constraints. With React Server Components, you can have all 3. (Facebook already had all 3 with Relay and GraphQL, but not everyone has a GraphQL backend, nor should they. React Server Components are a more general and easily adopted alternative.)\n- [12:05](https://github.com/reactjs/server-components-demo/https://youtu.be/TQQPAU21ZUw?t=725) Lauren introduces the [React Server Components Demo](https://github.com/reactjs/server-components-demo/)\n - Server Components are indicated by the new `.server.js` extension ([separate Module Conventions RFC here](https://github.com/reactjs/rfcs/blob/235f27c12aa893efd2378ec3c4a9b0b221641861/text/0000-server-module-conventions.md)).\n - Client Components are also indicated by a `.client.js` extension. You can switch Client Components to Server Components simply by renaming them.\n - (Explained later) Shared Components just have the standard `.js` extension.\n - (Explained later) There are three new React I/O libraries used in the demo:\n - react-fetch (wraps the fetch API)\n - react-pg (to access PostgreSQL)\n - react-fs (to access the Filesystem)\n - These are [caches that let you Suspend](https://reactjs.org/docs/concurrent-mode-suspense.html#solving-race-conditions-with-suspense) rendering while data is being requested.\n - Fetching data on the server is much faster than fetching from the client, so this is a good optimization\n- [16:10](https://youtu.be/TQQPAU21ZUw?t=975) Server Components have zero bundle size impact\n - React doesn't download any JS for Server Components, *including for any of their dependencies.* This is a great strategy for heavy dependencies that are only used on the server.\n - (Explained later) JSX props/children will be rendered by the Server Component *before* it reaches the Client. So you can pass them Shared Components and save on bundle size too.\n- [17:25](https://youtu.be/TQQPAU21ZUw?t=1046) Limitation: Server Components cannot be interactive\n - No `useState` or `useEffect`, no event handlers (e.g. `onClick`)\n - Client Components must receive *serializable* props from Server Components (e.g. no functions. JSX children/props is fine)\n - The RFC has more on [the limitations of Server and Client Components](https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#capabilities--constraints-of-server-and-client-components).\n- [22:50](https://youtu.be/TQQPAU21ZUw?t=1370) Difference between SSR and Server Components\n - You can refetch the Server Component tree so that HTML updates stream down, *without any extra JS for the refetched Server Components.*\n - **But the parts of the app with clientside state are preserved**. This is the main difference!\n - [Lauren later elaborated](https://twitter.com/sugarpirate_/status/1341141200808624128?s=20): \"SSR of client JS apps is an illusion. You render your JS on the server into HTML. You serve that HTML to your client so it appears to have fast startup. But you still have to wait for your JS to reach the user before anything can be interactive (hydration). **After hydration, SSR can't be used again - it's typically only used for initial loads. We can refetch React Server Components as many times as we like.**\"\n - [The RFC FAQ](https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#does-this-replace-ssr) also comments on the differences and complementarity of SSR and Server Components.\n- [26:45](https://youtu.be/TQQPAU21ZUw?t=1605) Shared Components\n - Shared Components can render on either the server OR the client. They just have a `.js` extension.\n - Shared Components have [the combined limitations of Server and Client Components](https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#sharing-code-between-server-and-client), explained in the RFC.\n - Shared Components rendered on the server won't be sent to the client, *unless* they are rendered on the client, in which case they will be **downloaded on demand!**\n- [30:26](https://youtu.be/TQQPAU21ZUw?t=1828) Server Components can directly query the database\n - Because we can refetch the Server Component tree (as explained above)...\n - a single Server Component that takes dynamic props and runs a database query (like a Search component) **can update live!** \n - *No local state management or API requests needed.* Just changing props and refetching the Server Component.\n - This Component stays updated even as you add new items to the database!\n - **Don't skim over this part** - This is a literal WOW moment - see us realize this at the 1h 10min mark on [the React Serverless Components demo livestream](https://youtu.be/La4agIEgoNg) \n- [33:21](https://youtu.be/TQQPAU21ZUw?t=2001) Suspense and Slow Network UX\n - When the network is slow, we should show some immediate feedback to users as they wait. Suspense and Server Components work well together for this.\n - Method 1: We can use Suspense fallbacks to show user some feedback on Server Components, even while waiting for the rest of the server tree to be rendered (eg due to fetching data)\n - This is possible because **Server Components don't render to HTML**, they render to a special format to be streamed down to clients.\n - Method 2: We can also use Suspense transitions to respond immediately even before the response has started streaming down.\n- [36:50](https://youtu.be/TQQPAU21ZUw?t=2216) Recap of Demo Points. Server Components...\n - [36:54](https://youtu.be/TQQPAU21ZUw?t=2214) **have ZERO effect on bundle size**\n - having the ability to decide which components to put on the client or on the server gives you more control over bundle size\n - [37:42](https://youtu.be/TQQPAU21ZUw?t=2262) **let you access backend resources DIRECTLY**\n - You can use the same paradigm for server & client data fetching\n - The community will be able to create more React IO library wrappers to cache results for more data sources\n - [41:04](https://youtu.be/TQQPAU21ZUw?t=2464) **let you only load the code that is necessary**\n - if a Server Component conditionally renders a Client Component, the server will only send an instruction to download the Client Component *if it is present in the server output*\n - This works like dynamic imports, but is automatically done instead of requiring manual loading\n - To enable this, Integrated plugins are being written with webpack, Next.js, and Parcel teams.\n - [43:17](https://youtu.be/TQQPAU21ZUw?t=2597) **let you decide the tradeoff for every concrete usecase**\n - Eliminate the artificial boundary between client and server:\n - Put data fetching and preprocessing code on Server\n - Put fast interaction response code on Client\n - But they expect that the majority of components will be Shared.\n - Example: CMS where you render articles on the server (so can be Server component most of the time) but when in admin panel you want to edit them (so need to render on client)\n - [44:25](https://youtu.be/TQQPAU21ZUw?t=2665) **provide modern UX with server-driven mental model**\n - create modern and app-like UI's\n - but write them like an old-school web page\n - Example: the Search component in Lauren's demo is a Server Component that refetches based on a Client Component's state, but that Client Component's state persists\n - Usecase: CSS animation on property change can fire because now the DOM will not be destroyed\n- [47:14](https://youtu.be/TQQPAU21ZUw?t=2834) Recap of Recap & looking ahead\n - It's Opt-in, still in R&D (missing core APIs eg Server Component Router, and need to finalize Concurrent Mode), and will be available to everyone even those who don't use Next.js\n - Production tests at FB have seen up to 29% reduction in bundle sizes\n - Don't make courses on this or put this in production. Just play with the demo.\n\nYou can also see more commentary on [the Twitter thread here](https://twitter.com/swyx/status/1341122002866749440).\n\n## Demo Walkthrough\n\nThe React Team also released the demo shown in the talk: https://github.com/reactjs/server-components-demo/\n\nHowever there are some difficult setup steps and a lot of things to try in the demo. I recently did a 2 hour walkthrough of every part, with timestamps.\n\n{% youtube La4agIEgoNg %}\n\nYou can also put Server Components into a serverless function, [as I found today with a lot of difficulty](https://youtu.be/VA3TFymZlW4).\n\n## Personal Reflections\n\nThis is **the beginning of the end** of a very, very long journey in React stretching as far back as 2014, when [Jordan Walke first mentioned Async Rendering](https://twitter.com/jordwalke/status/500587022890061824) (the old name for [Concurrent React](https://github.com/sw-yx/concurrent-react-notes/tree/master/legacy)) was a possibility.\n\nMy relationship with React Suspense started just after Dan Abramov's JSConf Iceland 2018 talk introducing it. It blew everyone's mind and ripped up everything I thought I knew about how React apps could and should be written. I stayed up all night to [write a walkthrough of that demo](https://twitter.com/swyx/status/969451899849191425?s=20). I had no React presence at the time but I've been following this idea throughout the ensuing 2.5 years.\n\nI suspect how React Server Components look to people who have followed the journey are wholly different to people who are only just looking at this today. Kind of like how you might really enjoy a movie just for your snobby annoying friend to tell you **\"the book was better\"**.\n\nTo me, \"the book\" provided a whole lot more context that, while it is irrelevant today, gives me a great deal more appreciation for how we got here and how things might work under the hood.\n\nHere is all the jargon we did NOT discuss at any point in the talk or demo (because they are implementation details or irrelevant today):\n\n- [`maxDuration` and Just Noticeable Difference heuristics](https://github.com/sw-yx/concurrent-react-notes/blob/master/legacy/apis/react-suspense.md#important-concepts)\n- [Priority Lanes](https://github.com/sw-yx/concurrent-react-notes/blob/master/legacy/apis/time-slicing.md#important-concepts)\n- [`hidden={true}`](https://github.com/sw-yx/concurrent-react-notes/blob/master/legacy/apis/hidden.md)\n- [Progressive Hydration](https://twitter.com/dan_abramov/status/1200111677833973760)\n- [Selective Hydration](https://twitter.com/swyx/status/1193101703215759361)\n- [Scheduling](https://philippspiess.com/scheduling-in-react/)\n- [Transparent Asynchrony](https://twitter.com/acdlite/status/969747179731533824?s=20)\n- [Idempotency vs Purity](https://twitter.com/dan_abramov/status/969629411996766208)\n- [Coroutines](https://twitter.com/acdlite/status/972542669040865280?s=20)\n- [Concurrency, Algebraic Effects, Lazy Eval](https://www.swyx.io/react-outside/)\n- [Two pass SSR](https://itnext.io/tips-for-server-side-rendering-with-react-e42b1b7acd57)\n- [Streaming SSR](https://github.com/sw-yx/concurrent-react-notes/blob/master/legacy/Timeline.md#streaming-ssr-specific)\n- [Trisomorphic Rendering](https://developers.google.com/web/updates/2019/02/rendering-on-the-web#trisomorphic)\n- [Islands Architecture](https://jasonformat.com/islands-architecture)\n\nInstead, we are given one concept today - **Server Components**. If you squint hard enough, you might even observe [there is no API](https://mobile.twitter.com/swyx/status/1341535594543910912).\n\n## Takeaways\n\nBecause the React team has consistently communicated their thoughts through the years, the main benefit of React Server Components is the same as I've commented on in [my writing](https://twitter.com/swyx/status/1317635707838496768?s=20) and [speaking](https://www.youtube.com/watch?v=18F5v1diO_A).\n\nGiven a baseline React runtime, React Server Components let you:\n\n- Greatly reduce real-world app sizes by making it easy for you to not send down unnecessary JS (the proverbial [disappearing app](https://twitter.com/dan_abramov/status/1259618524751958016?s=20))\n- Have Client and Server components seamlessly operate in the same tree so you don't have to change paradigms when requirements change. \n- Serve data much faster and easier by skipping client-server waterfalls and directly accessing backend resources.\n- Preserve clientside state and DOM nodes even when loading Server Components so you can even do page transitions, CSS animations and persist input focus.\n\nThis is a wonderful new area of opportunity for React developers, and the ecosystem is set to see tremendous growth in 2021. I feel certain that it is also going to spark similar efforts in other frameworks (because the case for Concurrent Mode has for the first time been made beyond time slicing and lazy loading components).\n\n## Related Reads\n\nI will update this with selected other pieces over time. \n\n- Dan's [comment](https://www.reddit.com/r/reactjs/comments/khlrsy/introducing_zerobundlesize_react_server_components/) about an unmentioned **Instant Transitions** feature\n- [Dan's responses to RFC comments](https://github.com/reactjs/rfcs/pull/188#issuecomment-753502950)\n- Addy Osmani's take on [React Server Components](https://addyosmani.com/blog/react-server-components/)\n- https://hotwire.dev DHH's bundling of the Turbolinks + Stimulus + Strada stack used in the Hey email app. RSCs have been (loosely!) compared to \"[Turbolinks for Virtual DOM](https://twitter.com/dan_abramov/status/1341230932729192448?s=20)\" \n\n\n## 2021 Architecture Q&A notes\n\n{% youtube jK0Vg8XbIXk %}\n\n- 5:15 **What's left?**\n - Everything about Server Components connects both to server rendering and the client and specifically the part of how Suspense works. So there's a few missing pieces in our server rendering story:\n - **Streaming Server Renderer.** \"We're currently working on a new implementation of the streaming server renderer which has some new interesting features but particularly that's how we plan to integrate the data stream from Server Components so that you will be able to server render into HTML together with Server Components.\"\n - **Smart Bundling Strategy**. \"The other parts that are kind of missing is we want to make sure that when you're bundling the output, Server Components kind of implicitly gives you this fine-grained bundle splitting built-in, but we want to make sure that there's a particularly useful bundling strategy that doesn't just regress the strategy because if you're splitting your bundles into too small pieces then that can be worse than not splitting them at all. So we're working on at least providing a prototype or ideally a full implementation of a webpack plugin that will let you have a pretty decent out-of-the-box experience and there's other ways you can do that and I'm interested to see kind of what the community comes up with with various types of bundling strategies. But we want to at least be able to ship our best thinking so far in this space.\"\n - **Data Fetching**. \"And then there's an another piece which is how does this connect to the API you use for actually kicking off the fetch like routing or pagination or other things like that. We don't necessarily see ourselves being particularly opinionated about that but there are certain patterns that work well and certain patterns that don't work well so we want to at least provide a prototype and a demo showcasing how you can think about solving those problems.\"\n- 7:50 **When?**\n - **Hopefully this year**. we're working towards having a Release Candidate of the Client aspects and we're hoping to introduce both the new release for a React 18 version together with a Server Components MVP, and possibly some streaming rendering as \n kind of a preview package, hopefully this year.\n- 8:30 GraphQL cache shared between server and client?\n - Jae: \"Following on from what you said about it how it ties into server and client rendering and data fetching, our app is built around GraphQL and specifically Apollo GraphQL, which means it's built around this GraphQL cache that is warmed during server rendering, transferred to the client, and then on a user's journey through a session that cache gets modified by new queries and mutations. How are you thinking about things like this, things like a GraphQL cache that right now is shared between server and client, are you planning on making something that works with Server Components, or is it something that the ecosystem and and us as developers will have to rethink how we interact with data in that way?\"\n - Joe: \"So, we kind of see it as a sort of progression of how you might evolve your app that uses GraphQL or even other data fetching approaches.\n - The first step is to go from non-Suspense based data fetching to using Suspense. The idea being instead of fetching in a useEffect or something, to switching to Suspense-based data fetching. To make that work with server rendering, that would require that some of the pieces that Sebastian talked about in terms of the new Suspense streaming-aware server rendering work. That's kind of the first piece, and what that gets you is the ability to mostly keep the same patterns that you use in your app today, and to continue doing server-side rendering.\n - But the thing is that that sort of gets you the ability to fetch at multiple points in your tree, and to have all those queries sort of happen on the server while avoiding round trips for your initial page load. But what that doesn't really solve is now you're on the client and now you want to do a page transition or something, now you're kind of going to be back in the world of: you start rendering, maybe you you hit multiple queries as you're rendering your app, and those could cause waterfalls, and so that's where we think Server Components can help.\n - But that's kind of a like a second stage after you've moved to Suspense with data fetching, and in terms of the broader question of how does GraphQL or other kind of normalized data stores fit into the Server Components world, we don't foresee that really going away. There are going to be parts of your app that are interactive that require data consistency on the client and those will continue, I think, to make sense to build with the existing approaches that we're all using today.\n - And there's lots of good approaches: GraphQL, REST, and various different data libraries. I think what's really going to change is for the parts of your app that makes sense to convert to Server Components you start to want to think about splitting up what's sort of state and what's sort of canonical server data a bit more.\n - Seb: The strategy in general is like you need a Suspensey... all this builds on the Suspense API, so you have to build that regardless. And we expect a lot of these libraries that exist today to build some kind of support for that out of the box, and that lets you do the Server Components approach including colocating your data fetching in your component without the waterfalls for initial load. But if that collocation or that transformation could cause a regression compared to what you're doing today, if you have a very optimized solution, and then Server Components could be the solution to that. So sometimes I suspect you'll actually want to wait to roll it out, even though that it's a two-step adoption process, until you have both pieces just so that you don't regress performance overall in the meantime.\n - Jae: I guess just to make sure that I'm understanding correctly is that we're looking at the components that are Server Components will not be updating in response to updates in the cache so we're looking at Server Components being things that are rendered using kind of canonical data like data from a CMS or something, but not things are part of interactivity and those things would be Client Components.\n - Joe: I don't think it's necessarily that the data that you fetch in Server Components, that might very well come from GraphQL, it might come from the same data source that your Client Components are fetching data from, but often, within the data that you fetch, some of it changes at different regularity. Just to take the Facebook example, like perhaps the text of a story might not change very often especially if it's a post that you haven't written, the only time that data is going to change is if you actually just refetch the whole story to begin with, at which point you're going to the server so you could just refetch the actual Server Component output. And so there's just different types of data and so some of it changes less frequently and therefore you could just re-fetch it in full, and when you do you just refetch the Server Component instead of fetching the data and then re-rendering the client-side, so it's kind of about the sort of rate of change of the data and how how consistent it has to be.\n - Seb: the way to think about it is that you're writing a Client Component first and then if you see that that component doesn't have any state or effects you can convert that to a Server Component. But it doesn't have to be that you kind of go all-in to converting a whole tree or a whole subtree of components. It can be that you're just converting individual components as you go. So some of them in the tree might be fetching client-side or as part of initial server rendering and some of them might be Server Components embedded in one tree.\n - Andrew: a theme here is that there are some components that don't update very \n frequently and there's other components that are like highly interactive and have more local state, like UI state... and maybe it receives data from from the server but like you can pass it from a parent component.\n - So a lot of folks today who are already using a data framework like Apollo or Relay are probably already writing code in roughly that pattern where there's some some sort of separation between super highly interactive Client Components versus things that are really about managing data and passing it down. That pattern works really well with Server Components.\n - But there might be some folks who are just kind of throwing everything into the same kind of source of state, maybe like a store or something like that, and those those patterns might take a little bit more work to migrate to this world where you're kind of thinking a little bit more carefully about what types of data that you have.\n- 16:50 Streaming server rendering\n - Yen-Wei: I was specifically curious to understand how you're thinking about the interop between Client Components and Server Components, Client Components and server rendering, all together.\n - Seb: Client Components and server rendering, all together. Yeah so for server rendering there's a couple of pieces where we're building server rendering with the Suspensey approach in mind. So that is decoupled from Server Components: \n if Server Components didn't exist that would still be a thing. That approach allows you to stream chunks of HTML in if you have, for example, one slower data source than another, so you can kind of see the UI progressively streaming as you go. And it kind of ties into the whole Suspense approach in general. But then you can see that each of those Client Components could be converted to a Server Component and what happens then is it's similar to what happens on the client. \n I think of the server renderer as more of a simulated client environment where \n the server renderer is the thing that receives the original requests. But \n then it can request data just like the client can request additional data, and that \n data could be a subtree of Server Components that then gets fed into the server renderer that acts as a client, and then streams out the resulting HTML, and then it also embeds the Server Component output in in the HTML as JSON data.\n - Seb: One key distinction there is that current approaches tend to embed data in its rawest form, so if you're fetching a REST API on the server you might embed a REST response in your HTML for use with hydration. But in the Server Components approach, we're embedding the result of the Server Components in the JSON which means you're getting kind of denormalized and processed data in the output which can sometimes be bigger but faster to render, and sometimes be smaller because you're you're just loading the the data that you actually needed for that component rather than the whole REST response.\n - Andrew: I personally find it very confusing sometimes even though I know the \n difference between all the pieces, just because the naming is very confusing because nowadays when people think \"well, it's called Server Components, I already have a thing called a server renderer, well the server renderer must be rendering the Server Components\" but it's actually not quite that. The thing that outputs HTML, the thing we traditionally think of as server rendering today, before Server Components — in this new architecture, that thing doesn't actually render \n Server Components. It only renders the Client ones which is kind of mind-bending. It actually receives already — see, I'm even struggling to think of the words to use right now, but there's like a layer that runs your Server Components, it sends that to a client renderer, and then there's two types of client renderers: ones that runs in the browser and one that runs on the server. I don't know if I'm clarifying it at all but but there's this distinction there between the thing that outputs HTML and the thing that fetches the data and generates this streaming output that you can then turn into HTML. If that helps at all.\n - Yen-Wei: Yeah, so I guess in this case the server renderer is like the simulated client runtime, basically, right? And so I guess kind of following up there does that also mean that the assumption that Client Components only run on the client is kind of false in that world?\n - Andrew: yeah, by default Client Components do run on the Node server environment and output like initial HTML or they run in the browser. There is a use case for like some components that maybe you don't even want to try and render the initial HTML on the server renderer — so we're thinking of an API where you can just bail out and say, just don't bother to try and render this this tree on the server and we'll pick it up on the client which is a pretty nice feature because it gives you some granular control over which things are able to run in both environments and which things aren't. But yeah, in general you're right: Client Components in this world don't necessarily mean you can just like access window and all these browser-only APIs. If you want to take full advantage of streaming HTML generation then same restrictions apply.\n - Seb: In terms of naming, I think there's some other interesting ways of looking at it because the Server Components is really about utilizing the server for what it's good at: like close to the data and relieving some resources and having code already loaded. Whereas the server rendering is more like a magic trick and I think that's a good way of looking at it because it's just about rendering this snapshot that the user gets to see before they can interact with it. But hopefully with, especially with, progressive hydration approaches it won't feel any different when you try to interact with it but that's really the purpose of the server rendering. It's to provide this magic trick of a fast initial snapshot. It's similar to kind of how on an iOS app where you can see a snapshot in terms of pixels of what was previously there when you start it and then it actually starts. It's a similar kind of trick making it feel like it's starting fast whereas the Server Components is really about this is a permanent approach that helps navigations further down in the app and permanently avoids having to load that code.\n - Andrew: Yeah I like the \"snapshot\"... if anyone has a good suggestion for naming by the way we're open to them. This \"snapshot\" thing I like because it reminds me of like a V8 snapshot.\n - Lauren: I think one term I've been using personally is \"bootstrapping\", it kind of like bootstraps the page just so that React can take over and actually do what it needs to. But yeah, it's the server-side rendering that gives you that initial skeleton to actually do anything off of.\n - Jae: Yeah, at FindMyPast we've often called it the \"pre-render\" because server rendering made people think of like ASP .NET MVC kind of application. It's not really what it's doing so we started calling it the pre-render because it is this kind of optimization.\n- 25:00 Performance of Server Components\n - Jae: one of the things when I first talked about Server Components with a colleague that is a principal on the front-end platform team — one of the things that he immediately was concerned about was our server render — server pre-render — so it's already like quite a resource-intensive piece of our stack and that's just pre-rendering like once per session and he was thinking what is it going to be like, what are going to be the performance characteristics of this Server Component provider that is going to have to do much more work over the lifetime of a user session both in terms of connections and in terms of processing with Server Components. Is there going to be any built-in optimizations for, say, caching or memoizing the result of Server Components that might be the same even for different users or even for the same user across the session requesting it again and again?\n - Seb: It's not super resource-intensive for us at Facebook so far that we've seen \n in comparison, and I think part of that has to do with just how resource-intensive is your REST API today, or the processing of the data, or the GraphQL endpoint. And the other part is that the Server Components subsequent requests are not necessarily as intensive as the initial server rendering because it's only the Server Components and not the Client Components, and it's also a subtree. So it will have this ability to kind of re-fetch the subtree but it's definitely a concern that we have that we want to meet by having that ability to refetch a subtree rather than kind of re-fetching all the data for a whole page when you're when you're refreshing it.\n - Seb: And to the caching point, we have some ideas about ability to cache subtrees in various forms. So caching is always kind of tricky because you have to make sure that you can invalidate it properly. But it also ties into context where because we have the ability to fetch subtrees like I just mentioned, you want to preserve that ability, then we'll also have the ability to cache those subtree responses within any particular tree. But we have to encode the inputs to that which is, for example, if you're having an HTTP fetch or a file read, all the inputs that go into this other than just the initial props or all the data that you read need to participate and give us a way to invalidate that — whether it's a timestamp or a file watcher or a subscription approach. So we haven't quite figured out what the API for that invalidation is going to be and it might be tricky to add after the fact so we're still kind of figuring out should that be something that is a part of the data fetching API contract from the beginning so that you don't lose that ability later, or is it something that you can gradually adopt later on.\n - Lauren: I want to add that at the client level, the Server Component response is also cacheable, determined by the needs of the product. So for example if you have a part of your application that is really static, and the rate of change for the data that powers that, those components — like let's say a navbar — so you don't have to re-render the Server Components necessarily if those initial Server Component responses are cached. And there's nothing really special or unique about these Server Component responses that don't make them easy to cache. So for example in Relay we do cache the Server Component response and we essentially make use of that if the data has not changed. Instead of refetching the Server Component, we just restore it from the Relay store.\n - Joe: One thing to add is that you mentioned that your server side rendering — what you described as pre-rendering — is currently resource-intensive. \n I think one thing to note there is that for certain libraries, the only way to do server \n rendering with data fetching and useEffect right now is to kind of... certain libraries in the ecosystem are doing multiple passes over the tree just to figure out what data the UI needs. And once the cache has been then warmed up then they can actually do like a full render, but obviously that's doing multiple passes over the tree. With Relay we don't see that because we're actually fetching all the data upfront, and one of the benefits of Server Components is that it makes that a bit easier to do. So with Server Components, it makes it a bit easier to structure your app so you can actually avoid the need to walk the tree again and again just to figure out what you're rendering. Also the new streaming Suspensey server rendering will actually be able to resume work. Fetching with Suspense, we can resume work where we left off as opposed to having to start over so I think that even in terms of that initial baseline of seeing that pre-rendering today is maybe expensive, that might change too, right? It's not just about \"oh we're adding more work\" it's actually potentially making all of the work that you're already doing a bit more efficient as well.\n - Seb: I have a question: where is your GraphQL implemented, is that a \n JavaScript service or a different language?\n - Jae: Yeah, GraphQL is mostly in JavaScript but it's a distributed graph — so we have a central Node.js server that proxies different requests for different parts of the schema to back-end services written in a variety of languages but mostly Node.\n - Seb: I think the reason I ask is because there's some overhead in just the runtime itself and if, for example, if you have a REST API today and the REST API is built in Node, you can just add Server Components as an additional layer to the end of the same runtime. And similarly if you have a GraphQL implementation in Node or even in front then you can just add Server Components at the end of the same service to amortize a little bit of the overall cost because you're utilizing the same service for both processing your data and processing your Server Components because \n essentially it's just a data processing pipeline.\n- 33:10 Caching Server Component responses\n - Yen-Wei: Yeah so I think this is kind of a continuation of the previous question. So we talked about caching of Server Component responses and I'm kind of curious if like — you know, today something we do is we cache the resulting data in a client-side store or a provider. We use Redux in our app. I'm wondering if — talking about Relay store caching the responses for Server Components — is that something that React itself is gonna be opinionated about or is that something that's just going to be up to \n userland and sort of the needs of the product?\n - Seb: Yeah I was just gonna tie it back to what I was saying in the intro about the pieces that are missing. There's a piece here about routing and triggering the fetches which also includes the caching. And we have some ideas around how you might want to do that without any additional library, just like the simplest possible you can do, where you would have the cache — there's this Cache primitive built into React that would hold — it's actually both used on the server to hold the responses that you use on the server and a cache that holds the response on the client as well. But the Cache is also used for any ad-hoc thing you might fetch on the client, \n so for example you might want to have images in there to support kind of like Suspensey images technique, or you might want to have one ad-hoc client request that also goes into the same Cache. So that that's kind of the basic approach and we have some opinions about how that's rooted — it's rooted in — certain subtrees have a lifetime in React, and that lifetime controls the Cache. But then you can also build this into an existing cache that is more globally rooted, like Relay for example.\n - Andrew: if you've ever played with Suspense, like the preview versions of Suspense that we've published in the past, we have very glaringly not solved this caching issue. We've kind of just given you like a recipe for how to do a user space cache and we've kind of just put a giant TODO in front of the whole area of like how you doing invalidation or how you decide which which parts of the tree need to be consistent. So the API that Seb is alluding to is the thing that we are now going to have more opinions on. And so if you are using Suspense, there will be this unified built-into-React Cache API that different frameworks can hook into. And so each framework might have different implementations for how it fills in that Cache but there will be a unified pattern for, this is how you should invalidate it or this is how you decide which parts of the tree to be re-fetched or which parts of the tree need to be updated after a server mutation or something. There'll definitely be additional layers on top of this that a framework like Relay will have particular implementation opinions on, but the lowest level substrate of where does the cache actually live, we will have an API for that.\n - Seb: And to fill in what the purpose is — this is kind of a deep dive — the purpose of that Cache is to provide a consistency for the subtree. So if you imagine you're doing a fetch for Server Components but your Server Components can layer in Client Components, and the Client Components might also do fetches around the same time, filling the same Cache. And the idea is that you can invalidate all of that as one unit, and you get a new server request for fresh data, but you also get client requests for fresh data as well for the same subtree. And it's all tied with that subtree in React on the client.\n- 38:10 Error Handling in Server Components\n - Jae: So I was wondering what your thoughts are on what if there's an error in a Server Component, what if the service providing the Server Component becomes unavailable, is there going to be a way for the client to say something like \"well if you can't fetch the subtree, display this in the meanwhile\" or is it a case of if there's some some subtrees that fail to fetch from Server Components, the app \n isn't in a state where it can continue rendering?\n - Seb: So I can start by kind of talking about the general mechanisms, and how it can fill in with best practices. There's a couple of places that errors can happen.\n - There's errors that can happen in the runtime outside of React itself. That's more up to the infrastructure metaframework to handle those.\n - And then there's errors that can happen as as part of network, maybe you don't get the response at all or you get part of the response but the connection errors.\n - And then there's errors that can happen within a Server Component.\n - Seb: So when there's an intentional thrown error within the Server Component that is on the server, there's two things that happen.\n - One, you get to log it on the server so that you can kind of track this. If they don't even end up on the client you still want to know that that you have some kind of errors happening.\n - The other part is that it gets embedded as part of the response. And then that component, where it kind of abstractly conceptually gets rendered in the tree on the client, an error is rethrown so that the client's error boundaries can handle it.\n - If an error happens because of, for example, you've gotten piece of the response but not not all of it, or even if you didn't get the response at all, the client runtime throws an error for all the pieces of the tree that haven't already rendered. So if you render a part — remember, this is a streaming protocol so you can partially render the data that you already have, but the error happens in the places that haven't yet rendered — so the nearest error boundary to those places is where the error gets handled. And then it's really up to the error boundaries to determine what to do with that, whether it should display the error or if it should retry that request.\n - Jae: Yeah that sounds very flexible and like it will give us a lot of options for all of the different error handling cases that you have and it sounds easier than how things are right now about errors on the server, errors on the client.\n - Seb: Yeah one thing that is a little bit tricky in this space is that you might have a general-purpose error boundary that just renders an error message for all the \n errors. But in this world if if you're never using errors like I/O errors to be thrown as \n an error boundary then those boundaries might not be aware that they should special-case I/O boundaries or maybe rethrow if it's an IO error. So it's a little tricky now that an error boundary has to be aware of I/O errors as something special so that it can know to delegate those or know to handle it itself. Because otherwise if you have a deep boundary that handles the I/O error, it might not refetch, whereas if it would have bubbled through that error boundary it would have gotten the parent that knew how to refetch it. So that's still a little tricky but I think \n it's pretty flexible still.\n- 43:05 Pagination\n - Yen-wei: One thing we werecurious about was specifically in terms of — a \n lot of our pages are basically giant feeds — so pagination is something that we think about a lot. And I'm curious how that would look like in terms of like Server Components and pagination and fetching subsequent pages.\n - Joe: Yeah that's a great question, and I think being very honest here, we're not sure yet. We've thought about this, we've explored it, but currently, for example, we're using Relay for our pagination, so for example we're using Server Components for individual items and I don't think actually we're using Server Components within a feed-like situation yet. But if we were, it would likely be kind of Relay on the outside, Server Components on the inside, and I think our idea is to gradually explore that space.\n - Joe: I think one challenge there is even with Relay, we're still evaluating what is the right way to do streaming pagination with Suspense, where you want to have new items arriving from the server and getting incremental rendering. But obviously with Suspense integration so that you show the first item and then subsequent items even if maybe the second item is ready first, right? So it has to be integrated with SuspenseList. So yeah this is like a non-answer, others may have more thoughts, but that's the current state of where we're at, what actually works that is known.\n - Seb: I think that there's actually more known there than it might seem because there's a bunch of possible versions that we don't think are gonna work. We don't have the exact API but we think roughly the same structure. We've explored various forms for example, if you refetched the whole page and told the server to now include more in that list, that would be one approach. But the approach that we think is going to be there, which probably seems the most intuitive too, is you imagine each item in a list being its own subtree and we will have the ability to refetch just a subtree picking up the context for where you left off.\n - Seb: So the idea is basically you have a Client Component that is managing the list and it's sending a request for \"give me this list of extra items\" and it server renders those, or Server Component renders those, and then you get the result back and that's what you render at the end of the list. That's effectively what we're doing in Relay. There's nuances in exactly how you design that API but I think that's the general principle, and some of the reasons for that particular approach is that the page itself is kind of stateful in the sense that where you are in the list is a client concept. If you just refetched — and this is especially true with Facebook because every time you refresh the newsfeed you get a completely different order — it doesn't have any inherent order.\n - So because the underlying data can change, the list can change throughout time. So we don't actually want to refetch the list itself as a part of this request, we just want to add an extra page and just fetch that page and add that to the data we already have. And to do that we need to be able to pick up the context. But which context should it be — should it be the context of the freshest data or should it be the context that you rendered with at the time that you rendered the outer list? And we think that it probably should be the context that you had when you were rendering at the outer list. So there's a lot of things that we concluded and the end results ends up looking a lot like like Relay paginations, so I would look at that as an inspiration.\n- 47:53 Testing\n - Jae: so another environment where all of this will have to run that we're thinking about is tests. So right now we have quite a few tests running React against jsdom, for some quick tests that can be run more quickly than, say, Cypress end-to-end tests that actually run a browser. So I've been wondering how Server Components fit into that. Will it be a case of being able to have this Server Component provider running locally as part of the same process that is running the tests, or how do you imagine that?\n - Lauren: Currently in our prototype we do have testing but the only tests we have are basically end-to-end tests where we do actually run the Server Component rendering infrastructure in that test. I think the unit test story is still kind of at least not super clear to me, so others may have thoughts on that. But yeah we do run our tests end-to-end so we get to see the actual full end-to-end flow of rendering a Server Component and then making it into the initial load and then any interactions that might be expressed in the end-to-end test, those are all testable there. So it should plug in into existing end-to-end frameworks assuming that you can run your Server Component rendering infrastructure as well. But the interesting thing about Server Components is that there will be paths that we're exploring like we're currently researching some ways to run Server Components in a different environment, like not on your server, like maybe in a Worker or something like that, that could help with the unit testing story.\n - Andrew: there's different types of unit tests. I don't always know what people mean by that, I think it usually means some part of the layer is mocked out or stubbed.\n - So like if you wanted to unit test a Client Component that expects Server Component data then that'd probably be pretty similar to today where instead of rendering it inside of a Server Component you just render inside something else that gives it props.\n - If you wanted to unit test the Server Component itself, since Server Components can render a UI, the way I would probably do that is actually simulate the request environment and actually generate the output. And then feed that into the, what are we calling it, the pre-renderer API. And then assert on the React output the way you would for a client component unit test. You probably shouldn't assert the actual data format that this spits out so I guess it depends on what layer or part of the stack that you're trying to test.\n - But even for things that I call unit test, I usually find it valuable when you keep it as \"end-to-endy\" as possible. So yeah I probably wouldn't recommend asserting on anything except for the final tree output if that makes sense.\n - Seb: I'll add also that a lot of what we call Server Components are actually Shared Components that you can run on either the client or the server, and one way if you're just looking to test the logic and not the integration is to just render them as a client just like you would test them today. I do think though that our observation is that moving more towards the direction of end-to-end, whether that is more of a simulated end-to-end like a jsdom environment or a richer full browser end-to-end test, seems to be the way a lot of things are going because it definitely simplifies testing a lot of asynchronous behavior, like Promises.\n- 53:12 Testing a Subtree\n - Jae: I guess that the end-to-end testing, especially like full browser, removes a lot of complexities setting up the environment, but there's still a trade-off there in between performance and how many tests you can write and still have them run \n performantly. So yes, specifically I was wondering like yeah this kind of like, but \n we want to test just a subtree in jsdom and especially what happens if that subtree includes both Server Components and Client Components, and can that just be run in-process in Jest or is it a thing well no you have to spin up a separate server worker process that does the Server Component stuff and then?...\n - Seb: That's a good question because the infrastructure is a little tricky with this environment just because we special-case how imports are handled so in general the server can't... well, ideally it's set up so that the Server Component renderer is its own process from even the \"pre-renderer\", that \"bootstrap\" renderer thing, but you can run them in the same environment as long as they're built as separate module systems. So for example a lot of production environments for server rendering use webpack bundling before it's loaded in Node. And since webpack has its own module system and graph, you can put two of those in the same process.\n - Sev: But also if you're able to run it as a Client Component, it more or less behaves similarly. It's not exactly the same but putting a Client Component where a Server Component would have been inside of a client tree as is more or less the same, and that's the idea. You mentioned towards the beginning that one of the things you're thinking about before releasing is a webpack plug-in. I'm wondering if there are plans for first-class support for non-webpack bundling and also whether or not bundling on the server for example is actually a requirement for Server and Client Components. Yeah, so we're doing webpack first but we want to support first-class bundling for any bundler that can support a good experience out of the box for this for the client.\n - There's a few constraints there, particularly the reason even the runtime is coupled to webpack right now is because we're kind of relying on some internals to be able to synchronously extract and require modules lazily even though they've already been loaded and pre-load them early. So to get really the ideal of performance we're relying on a lot of these features that are not necessarily part of the standard API but there's more other bundles that support the same things we can definitely support that. The other part is just getting the bundling strategy which we don't really know exactly how that will work. But definitely something that could be built for others and we could even maintain it as a first-class package if it's a high-quality implementation and we're happy to help with that.\n - The other part of the question is whether the Server Components, the server part, needs to be bundled. And none of this needs to be necessarily bundled as part of development, and I think there's a large shift now in the ecosystem trying \n to explore other ways of development where the development experience can be faster. For example by not bundling. But we also think that an ideal developer experience for debugging could actually be to run the server part in the Service Worker which might require some kind of bundling or at least some partial bundling or partial compilation to get JSX and stuff. But then even our demo doesn't actually bundle the server and I think this is actually the big missing part that it doesn't.\n - And the reason I think it's ideal to do it but you don't have to, it's two things. One is that it's a little bit faster to just have a bundle running in the Node environment in general.\n - But the other part is that we might want to use the graph that we determined during the bundling of the server to determine what the best bundling strategy for the Client Components are. I know Tobias from webpack has some ideas of even designing webpack to have a shared graph between a server bundle and a client bundle so that it would have this information. But that really depends on \n what your bundling strategy is. At Facebook we use a data-driven bundling approach where we see previous visits and try to determine using a statistical model how best to group certain Client Components.\n - But if you don't have that you have to get as much information as you can from a static build and a lot of the information is dependent on the \n server graph. So for example if you have a Server Component that always pulls in these three Client Components, you want to be able to know that as part of building the Client Components so that you know to group those.\n - But you don't have to because you can just build all the Client Components as a separate graph and treat all them as entry points but you don't have a lot of information then about how to group the best chunks. There's middle ground here \n too, you could have something that doesn't actually run the bundling of the server but just uses that as an analysis to feed into a client's bundling. But I think that the first approach that we want to build, the missing pieces, is a unified approach where the out-of-the-box experience is that you build the server first and use that as input to build the client.\n- 1:00:30 Styling Server Components\n - Jae: I was thinking about CSS as well and with the Server Components can render UI, how will the CSS get to the client at the right time when the Server Component UI is fetched, both in CSS-in-JS and also CSS Modules. Especially if we're talking about how these Server Components might not... the code that runs them might \n never be downloaded to the client, how does the client know to download the \n right CSS and put it in the right place?\n - Seb: There's basically three different strategies of these that we observed.\n - The strategy that we currently use at Facebook is basically a static analysis where we analyze the file and then we create the CSS bundles, they're basically \n one bundle that has all the CSS more or less, and in that world you just have \n to make sure that the analysis is able to traverse these files so that it doesn't \n just traverse the client, it has to traverse — and that kind of ties into the previous question too, right — you have to have something that traverses the server files to find the CSS in them.\n - The other strategy is more like in the out-of-the-box experience with webpack with no plug-in where you can import a CSS file as part of the module. In that case it's kind of implied that if you load that file that the CSS file will be loaded with it. But there's no explicit connection between the CSS file and the component, it's just that you import it and it's there. That needs a little special consideration because that module won't be pulled into the webpack client bundle, so the dependency won't be there in the graph. That's part of the thing that we probably want to add in our official webpack plugin since that's a basic webpack feature, plugin since that's a basic webpack feature, and we have to do something clever like transform the file so that it injects the call so that we know that this file is associated with this component somehow.\n - But the third option, I think, is the more common one which is whether you do it static or at runtime there's somethingin the component that determines that this \n class name is associated with this component and it needs to be injected. Either it needs to download the dependency or it needs to be done dynamically injected on the fly. And you can certainly do that, kind of, in userspace third-party code, but I think we actually want to expose a particular API for this case so that \n you can say that \"this is the class that I want to associate with this output\". And if this output gets included in this part of the subtree then there's some metadata that goes along with that in the Server Component's response and then the client can inject that to load that CSS or to include that CSS in the server renderer. But I think that's going to be a missing piece that we'll have to add before it's really useful.\n - Lauren: I just want to add something really quick, not specifically about CSS but I think this is also generally in the class of problems where some side effect that used to happen on the client now happens on the server so you need some way to keep track of all the side effects that happen — whether it's \n logging or an error is thrown or it's CSS-in-JS that's being used — and thendepending on the needs of your product replay that on the client.Like in the error case where we re-throw the error or like in the CSS case you might need to request for that CSS or add inject some CSS class to those components. So I think it's a very similar class of problem that we were working on.\n - Seb: Yeah and we have a similar issue with Relay, right? Where we we want to emit a data dependency because we know from the server that we need this data to be part of the client component we're about to render.\n - 1:05:30 Preparing for Server Components\n - Yen-Wei: Is there anything we should be doing today to make it easier — obviously we want to be able to adopt Server Components as soon as it comes out — is there anything we should be prioritizing in our own codebase to help that migration eventually?\n - Andrew: so there's multiple layers to this. We mentioned upfront at the beginning of this chat that there is a dependency on some concurrent rendering features, \n we've talked about this in the past before. Our next version of React, React \n 18, will support concurrent rendering. Not all features of Server Components depend on you being a 100% compatible with Concurrent Mode. But just by start adding Suspense boundaries and starting to use Server Components in parts of your app you're kind of opting in those subtrees into some amount of concurrent behavior. So we thought a lot about this and our rough strategy is that you will upgrade your app to React 18 and basically almost nothing will change in terms \n switch to the new root API then there's like a few very subtle legacy quirks that we've gotten rid of but everything will still be synchronous. And then \n as you adopt feature by feature, screen by screen, component by component, and some things will get a little bit into the more Concurrent Mode side of things. So if you want to start preparing today there's some fixed upfront costs that you have to care of. And then there are things that you can incrementally do later on. So one of the fixed ones, if you don't already have Node running, you might want to figure that out so that by the time you get to like later this year or whenever that happens, that's already solved. A lot of people are \n already in that world if they're using Relay or to be Strict Mode compatible.\n - Andrew: We have an API today is you can start getting your components \n to be Strict Mode compatible. We have an AI called Strict Mode that we released a few years ago that was designed to surface in development certain concurrency issues so that you can solve them now before Concurrent Mode is released. The basic things it does is it'll warn about some old class component lifecycles that just don't really work well in Concurrent Mode. A really \n important thing it does is it'll double-invoke pure render functions, only in development, to try and flush out any possible side effects.\n - Andrew: We have a whole document describing how you can start wrapping this Strict Mode around certain parts of your app to incrementally get things migrated over. That general strategy of starting small and then gradually spreading it out until you get more of your surface covered is roughly how we're going do it in a post React 18 as well. One thing that's important to emphasize is i think we might have been a little overly pedantic in the past when communicating about Concurrent Mode compatibility.\n - Andrew: What we've realized converting Facebook surfaces to Concurrent Mode is that a lot of things that are theoretical problems just don't really come up in practice that much. I mean it is annoying when they do arise but we've been able to convert large swaths of our app with really not that many problems. So we are going to have a way for you, even once Concurrent Mode is out to, for instance, if you have some old class components with unsafe lifecycles that are running in a part of your tree that's not using y concurrent features, there's really no reason for us to warn you about that. So we'll have a way to either opt out of those warnings and delay them until later once you actually do start adopting things, or use the Strict Mode component API to fix those ahead of time. But the general \n message is we're working really hard to make sure it's gradually adoptable, and you only have to pay the cost of migration once you start using new features in a particular part of your app.\n - So yeah, short answer:\n - if you want to start today you can start using Strict Mode to fix those issues and you should be hopefully very ready once the day comes to start \n incrementally adding features.\n - The one other thing I'll mention is that there is — my whole thing \n about how in practice you don't really tend to hit Concurrent Mode bugs — that is true of components and Hooks. It's less true maybe of frameworks or infra-level code. So there will be some work, this is why we're planning to do a release candidate\\ before we do a final release, because we're going \n to do some work with open source library authors, particularly things that do a lot of state management type stuff or read from external data sources. Those are the ones that tend to have the most concurrency issues, and so that's really important for us to address that the ecosystem is unblocked from being able to... by the time we go wide with the actual release, people are unblocked from being able to migrate. But the nice thing about it, even \n though that sounds scary, the nice thing about that is if we fix, for instance, I'm just gonna pick Redux, if we fix Redux for Concurrent Mode, we fix it for everyone. We already did this with Relay at Facebook, we fixed a bunch of concurrency compatibility things in Relay, and as a result everything at Facebook that uses Relay, which is tons of stuff, kind of mostly just worked after that. Hopefully that provides some insight.\n - Seb: The other part is around how you do data fetching today. If you're interleaving data fetching into a normalized store and you're mixing and matching state and data that way, then it can be hard to to know how to separate the client parts from the server parts. or a certain part of your app you might want to keep that ability, but for the parts where you're really thinking Server Components could be helpful, it's nice to be able to split out the data fetching parts from the state parts. And a pattern that's particularly useful for that is getInitialProps or getServerProps in Next.js because it's very clear that this is all the data that you need for the initial rendering pass or \n even you could potentially invalidate it too. And then for anything else that you need to do for data to be more dynamic, that's a different thing. So that pattern, whether you use Next.js or not, is a good way to prepare because you can mostly put all of your getInitialProps or getServerProps data fetching into Server Components once you adopt them.\n - Lauren: I also wanted to add that in addition to the points that Andrew and Sebastian were highlighting, when Server Components are released in open source I think we'll also aim to open source some of the internal lint rules that we've written along with the conversion scripts that should help you get some of your components converted to Server or Shared Components. For the conversion script in particular, it doesn't actually change your application architecture or the structure of your component tree, but it will identify components that can be or are Server- or Shared-safe, and if they are, then it tries to convert those components and does a bunch of other stuff to make sure that renamed files are imported correctly and whatnot.\n- Dan: From all of the points that Andrew mentioned and Sebastian in particular where if you can separate your client side state from the data requirements, that will go a long way in helping the conversion script understand which components are actually Server- or Shared-safe, and then it can do the conversion for you. We'll \ntry to aim to release these along with Server Components. The timing may not necessarily match up but I will certainly try my best to do that.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/an-annotated-guide-to-the-react-server-components-demo-2a83","devToReactions":193,"devToReadingTime":45,"devToPublishedAt":"2020-12-23T01:18:46.502Z","devToViewsCount":7316,"title":"An Annotated Guide to React Server Components","published":true,"description":"React Server Components are a nuanced, sweeping addition to React's existing capabilities. This is my guide.","tags":"React","slug":"react-server-components-demo","canonical_url":"https://www.swyx.io/react-server-components-demo","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/cmvph9c0bejsjat1qodc.png"},"title":"An Annotated Guide to React Server Components","description":"React Server Components are a nuanced, sweeping addition to React's existing capabilities. This is my guide. ","category":"note","tags":["react"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/cmvph9c0bejsjat1qodc.png","canonical":"https://www.swyx.io/react-server-components-demo","slug":"react-server-components-demo","date":"2020-12-23T01:18:46.502Z","readingTime":"54 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/318","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/318/comments","title":"An Annotated Guide to React Server Components","created_at":"2022-01-18T00:13:11Z","updated_at":"2022-06-18T17:47:15Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/318/reactions","total_count":1,"+1":1,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> This post was first featured on [freecodecamp](https://www.freecodecamp.org/news/design-and-deploy-backend-with-amplify-sandbox/)\r\n\r\n<div class=\"post-content\">\r\n<p>In this post I'll show you how to design four different example apps - a SimpleNote clone, a Twitter clone, a Slack clone, and an E-commerce store. And we'll do it with the coolest new toy released at AWS re:Invent 2020.</p><h2 id=\"introducing-the-amplify-sandbox\">Introducing the Amplify Sandbox</h2><p><a href=\"https://aws.amazon.com/blogs/aws/aws-amplify-admin-ui-helps-you-develop-app-backends-no-cloud-experience-required/\">Amplify Admin UI</a> is a new low-code interface for building app backends that doesn't require any AWS expertise. However, what many people may miss is that Amplify Admin also includes <a href=\"https://sandbox.amplifyapp.com/\">a wonderful new Sandbox</a> which lets you get started without an AWS account. </p><p>This Sandbox is a publicly sharable version of the Amplify Admin UI where you can create and prototype your data models without even logging in to an AWS account! </p><p>Currently only <a href=\"https://sandbox.amplifyapp.com/start#datastore\">the Data sandbox</a> is built out, but over time the other AWS Amplify categories will be made available as well. </p><p>When you first enter a Sandbox, you are dropped into a visual builder where you can add your <a href=\"https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html\">models, enums, and custom types</a>. Mostly, you'll just be creating models. </p><p>You can name models, add fields, and specify types (including whether they are optional or array fields), and even add one-to-one, one-to-many, or many-to-many relationships <em>between</em> models.</p><figure class=\"kg-card kg-image-card kg-width-wide\"><img src=\"https://www.freecodecamp.org/news/content/images/2020/12/image-147.png\" class=\"kg-image\" alt=\"\" srcset=\"https://www.freecodecamp.org/news/content/images/size/w600/2020/12/image-147.png 600w, https://www.freecodecamp.org/news/content/images/size/w1000/2020/12/image-147.png 1000w, https://www.freecodecamp.org/news/content/images/size/w1600/2020/12/image-147.png 1600w, https://www.freecodecamp.org/news/content/images/2020/12/image-147.png 1790w\" sizes=\"(min-width: 1200px) 1200px\"></figure><p>Further, it even lets you <em>share </em>the data models you create! This means you don’t have to start from scratch each time you create a project, and <strong>you can share your data schemas like you share code gists</strong>.</p><h2 id=\"our-four-sample-sandboxes\">Our Four Sample Sandboxes</h2><p><br>I thought it would be a great idea to demonstrate how powerful this is by sketching out four example sandboxes that you can use:</p><ul><li>A <strong>notes</strong> app (inspired by the free note-taking app <a href=\"https://simplenote.com/\">SimpleNote</a>)</li><li>A <strong>chat</strong> app (inspired by Slack)</li><li>A <strong>social media </strong>app (inspired by Twitter)</li><li>An <strong>ecommerce</strong> backend (inspired by every shopping experience)</li></ul><h2 id=\"how-to-create-entity-relationship-diagrams\">How to Create Entity Relationship Diagrams</h2><p>Amplify Admin UI makes it easy to get going, but it is worth doing some planning before we start. </p><p>The time-tested way to do this is to draw <a href=\"https://www.youtube.com/watch?v=QpdhBUYk7Kk\">entity relationship diagrams</a>. We chose to <a href=\"https://lucid.app/lucidchart/invitations/accept/563dc191-6613-44f5-aef0-24224ad5fbe1\">use Lucidcharts for ours</a>, but you can use any diagramming tool to do this.</p>\r\n\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/h7y34275luztd0fctvvj.png)\r\n\r\n<h2 id=\"the-notes-app\">The Notes App</h2><p>This is a minimal app that I personally use every day, so I like it for its simplicity. We have two models: Notes and Tags, and only one many-to-many relationship between them for easy querying. </p><p>You could extend this by offering collaborative, role based editing, which is available once you deploy this model. You should also make use of the <a href=\"https://docs.amplify.aws/lib/datastore/getting-started/q/platform/js#datastore-with-amplify\">client-side DataStore libraries</a> to make sure your notes work offline.<br><br>You can see the Sandbox here: <a href=\"https://sandbox.amplifyapp.com/schema-design/1c782f02-1fe7-4785-9a02-22a27cc96d0d/clone\">https://sandbox.amplifyapp.com/schema-design/1c782f02-1fe7-4785-9a02-22a27cc96d0d/clone</a>. Note that we use a bidirectional <strong>many to many </strong>relationship here between the models, as notes can have zero or more tags and vice versa.</p>\r\n\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/auformx6karwwplydg77.png)\r\n\r\n\r\n<h2 id=\"the-slack-clone\">The Slack Clone</h2><p>Many of us use chat apps for work, so we are familiar with this app use case from the user side. </p><p>The new nuances here are that every Message belongs to a Channel and a User, and that each User can both create Channels and join them. So there is an interesting three way relationship between the three primary models.<br><br>You can see the Sandbox here: <a href=\"https://sandbox.amplifyapp.com/schema-design/5f863684-fd1e-41b4-bca1-36c2271e21a1/clone\">https://sandbox.amplifyapp.com/schema-design/5f863684-fd1e-41b4-bca1-36c2271e21a1/clone</a>. <strong>Channel</strong> is the most complex model here – notice how we fully utilize all the relationship types available in the Sandbox:</p><ul><li>Channels can have <strong>many</strong> Users, and Users can join <strong>many</strong> Channels</li><li>Channels can only be created by <strong>one</strong> User, and there is no requirement to keep track of what channels any particular user has created</li><li>Channels can have <strong>many</strong> Messages, but each Message can only belong to <strong>one</strong> Channel</li></ul>\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/qjlv1vv2no8kr23vp178.png)\r\n\r\n\r\n<h2 id=\"the-twitter-clone\">The Twitter Clone</h2><p>Social media is often one of the most complex data models to model. We implement the minimum viable social media app – a Tweet and a User model is all we offer. </p><p>However the Tweet itself has a complex set of relationships. It has an author User, and a set of likes, replies, and quotes that need to be modeled. </p><p>Other modifications you can consider for this app: offering other types of tweets, including polls, images, and videos, building in advertisements, and direct messages.<br><br>You can see the Sandbox here: <a href=\"https://sandbox.amplifyapp.com/schema-design/ad5b5b7e-f207-42d1-92b1-0ccef056a26b/clone\">https://sandbox.amplifyapp.com/schema-design/ad5b5b7e-f207-42d1-92b1-0ccef056a26b/clone</a>. Note that recursion is implemented here by modeling likes, replies, and quotes as an <strong>array </strong>of the respective User and Tweet ID's.</p>\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/jhucoh235ji51lus9651.png)\r\n\r\n\r\n\r\n<h2 id=\"the-ecommerce-store\">The Ecommerce Store</h2><p>The stakes are higher when there is money involved. Keeping track of orders and ensuring a great customer experience is paramount. </p><p>We model a typical ecommerce backend by ensuring that we have separate models for Suppliers, Products, Orders, and Customers. To get into the nuances of a typical ordering experience, we also include the ability to specify product quantities in a single order, as well as to apply coupons. </p><p>Since there are infinitely many variations on the ecommerce experience, we can’t possibly model them all, but I hope that this serves as a good enough starting point. Share your own if you have twists on this concept!<br><br>You can see the Sandbox here: <a href=\"https://sandbox.amplifyapp.com/schema-design/aa0e7a61-aa72-4b27-b6db-ea8e2031f95e/clone\">https://sandbox.amplifyapp.com/schema-design/aa0e7a61-aa72-4b27-b6db-ea8e2031f95e/clone</a>. Note the sheer complexity of this model is easily handled by the Sandbox's features. One Order can only have one Customer, but a Customer can have many Orders. </p><p>When you set this up on the Customer model, the Sandbox is smart enough to automatically set up a corresponding customerID field as a \"<strong>Relationship Source</strong>\" on the Order model. This will be very handy for GraphQL queries down the road.</p>\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/q5iuc8ybnrl380qh4apw.png)\r\n\r\n\r\n<h2 id=\"how-to-deploy-the-model-to-aws\">How to Deploy the Model to AWS</h2><p>Once you are done with your model, the Sandbox prompts you to test locally by downloading it with the <a href=\"https://docs.amplify.aws/cli\">Amplify CLI</a>. However, if you just want to get it live on AWS, you can skip that and head straight to the \"Deploy to AWS\" stage:</p><figure class=\"kg-card kg-image-card kg-width-wide\"><img src=\"https://www.freecodecamp.org/news/content/images/2020/12/image-142.png\" class=\"kg-image\" alt=\"\" srcset=\"https://www.freecodecamp.org/news/content/images/size/w600/2020/12/image-142.png 600w, https://www.freecodecamp.org/news/content/images/size/w1000/2020/12/image-142.png 1000w, https://www.freecodecamp.org/news/content/images/2020/12/image-142.png 1248w\" sizes=\"(min-width: 1200px) 1200px\"></figure><p>Once you hit \"Login to deploy to AWS\", you're done! Imagine that – you've just created an actual backend data model <strong>without writing any code</strong> and deployed it straight to AWS. 🤯</p><figure class=\"kg-card kg-image-card kg-width-wide\"><img src=\"https://www.freecodecamp.org/news/content/images/2020/12/image-143.png\" class=\"kg-image\" alt=\"\" srcset=\"https://www.freecodecamp.org/news/content/images/size/w600/2020/12/image-143.png 600w, https://www.freecodecamp.org/news/content/images/size/w1000/2020/12/image-143.png 1000w, https://www.freecodecamp.org/news/content/images/size/w1600/2020/12/image-143.png 1600w, https://www.freecodecamp.org/news/content/images/2020/12/image-143.png 1654w\" sizes=\"(min-width: 1200px) 1200px\"></figure><p>From here you can set up further customization, including adding authentication, inviting users and assigning roles, adding authorization rules on each model, creating content with our WYSIWYG editor, and more. </p><p>If you want to learn more, <a href=\"https://welearncode.com/intro-amplify-admin-ui/\">Ali Spittel did a great blogpost</a> on how powerful the Amplify Admin UI becomes after you deploy it, whereas this article has been about the no-account-needed Sandbox environment <em>before</em> deploying. </p><p>Nader Dabit also wrote about <a href=\"https://acloudguru.com/blog/engineering/10-exciting-features-of-the-new-amplify-admin-ui\">10 other features you may be keen to try</a>.</p><p>With the Amplify Sandbox, it is really easy to model and think through any app backend scenario, so hopefully these examples jog your creativity. If you have any requests or submissions, <a href=\"https://twitter.com/swyx\">please let me know</a>!</p>\r\n </div>","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/how-to-design-almost-any-backend-and-deploy-it-to-aws-with-no-code-45a9","devToReactions":94,"devToReadingTime":7,"devToPublishedAt":"2020-12-18T19:42:48.481Z","devToViewsCount":1730,"title":"How to Design Almost Any Backend and Deploy It to AWS with No Code","published":true,"description":"With the Amplify Sandbox, it is really easy to model and think through any app backend scenario","category":"tutorial","tags":"Tech, AWS, AWSAmplify, No Code","slug":"design-and-deploy-backend-with-amplify-sandbox","canonical_url":"https://www.freecodecamp.org/news/design-and-deploy-backend-with-amplify-sandbox/"},"title":"How to Design Almost Any Backend and Deploy It to AWS with No Code","description":"With the Amplify Sandbox, it is really easy to model and think through any app backend scenario ","category":"tutorial","tags":["tech","aws","awsamplify","no code"],"canonical":"https://www.freecodecamp.org/news/design-and-deploy-backend-with-amplify-sandbox/","slug":"design-and-deploy-backend-with-amplify-sandbox","date":"2020-12-18T19:42:48.481Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/319","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/319/comments","title":"How to Design Almost Any Backend and Deploy It to AWS with No Code","created_at":"2022-01-18T00:13:15Z","updated_at":"2022-06-18T17:46:26Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/319/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"The Future of Dev Tools with Minko Gechev (Angular Core Team)","slug":"devtools-minko-gechev","categories":["Angular"],"description":"Minko has been working tirelessly for years on the Angular developer experience. We'll talk about the Language Server, Angular Schematics, and whatever else team Angular has been cooking up for developers!","instances":[{"venue":"Swyx YouTube","date":"2020-12-16","video":"https://www.youtube.com/watch?v=ECvAl3Ii5vM"}],"category":"talk","date":"2020-12-16T00:00:00.000Z"},{"type":"blog","content":"\n## TL;DR\n\nYou should pre-sell because you can **validate your idea** and **create word of mouth** and **get money upfront to do it**.\n\n## Elaboration\n\nI had the pleasure of chatting with Dru Riley of Trends.vc for [his latest piece on Presales](https://trends.vc/trends-0044-presales/), which is out today. \n\nTrends is a newsletter with high-quality, extremely dense topical research pieces, spiritually similar to the kind of industry initiations I used to do as an equity research analyst. \n\nIt agglomerates inputs from a lot of people, so I thought I would write down my own. Note that I've only done one pre-sale so I'm no expert. But I can tell you that I researched a bunch of creators, all of whom had mixed opinions on the pros and cons of preselling, and after doing my own I have concluded that **I will always pre-sell whatever I do in future.**\n\n> For those who follow me closely, a lot of these repeat from [my book launch reflection post](http://swyx.io/coding-career-launch), which Dru kindly cites at the end of the book. The post is a dense ramble, so I figured I'd split out my views on presales as a standalone post.\n\n- **Validation**:\n - You can validate your idea cheaply. It may feel uncomfortable to take money for something that doesn't yet exist (I know exactly how this feels), but if you have built up trust that you will follow through, some nonzero amount of your friends and the people who really need your product will buy it. You can always return their money if it really does flop.\n - You can validate your product *while you build it*. Your presale buyers *paid* you for the opportunity to give you feedback (well technically, you probably gave them a discount so you're paying them - but almost certainly people view the chance to shape your product as it forms a plus). Where else do you get a captive feedback audience like this?\n- **Word of Mouth**: Most new creators struggle with their first launches. It's very natural and more comfortable to spend all your time building and no time marketing. It's also well known that the most powerful form of marketing is the one you can't pay for - Word of Mouth. So it seems a no-brainer to use the one thing you're definitely going to do before launch (**building**) to create the one thing you definitely are going to need after launch (**Word of Mouth**)\n- **Get Money Upfront**: If you think about it, Kickstarters are *all* presales. People who do kickstarters use the funds for all sorts of things, from buying supplies to doing marketing. Even if you're making a digital product, you can do the same - use the money to pay for editing, design, video production, and whatever else that will improve the quality of the final output. This even builds in an incentive for people to kick in more money during presales to get a better product! (helpful if you can think up stretch goals to offer)\n\nAnd finally, of course, for those who need it, selling something you haven't made yet to your friends and fans is a **commitment device** - both for finishing the thing, and also for finishing the thing with the highest quality. People have different responses to **Skin in the Game**, but I generally think it is a wonderfully positive thing.\n\n## Further Reading\n\n- [Amy Hoy Podcast - How to Pre-Sell Your Online Course](https://janelleallen.com/066)\n- [If You Sell Anything Online, This Book Will Make You Money](https://www.swyx.io/rob_hope_hot_tips/) - My Review of Rob Hope's excellent Landing Page advice","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/why-you-should-pre-sell-2fon","devToReactions":17,"devToReadingTime":3,"devToPublishedAt":"2020-12-15T18:00:25.471Z","devToViewsCount":248,"title":"Why You Should Pre-Sell","published":true,"description":"My thoughts on preselling, from having done it successfully exactly one time.","tags":"Reflections","slug":"pre-sell","canonical_url":"https://www.swyx.io/pre-sell","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/yktjbl39bex16wfj4g1m.png"},"title":"Why You Should Pre-Sell","description":"My thoughts on preselling, from having done it successfully exactly one time. ","category":"note","tags":["reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/yktjbl39bex16wfj4g1m.png","canonical":"https://www.swyx.io/pre-sell","slug":"pre-sell","date":"2020-12-15T18:00:25.471Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/320","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/320/comments","title":"Why You Should Pre-Sell","created_at":"2022-01-18T00:13:17Z","updated_at":"2022-06-18T17:47:16Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/320/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nIn the decade since the 2009 Financial Crisis, I've carried with me two mental models: **Mimicry and Reflexivity**. They describe how perception and reality intermingle, and together they describe some of the most profound ideas on how the human world works.\r\n\r\nAnd I've only just realized these are different sides of the **same** coin.\r\n\r\nMost people think in terms of a 1-way causal relationship between perception and reality, comparable to [Plato's Cave](https://en.wikipedia.org/wiki/Allegory_of_the_cave). Reality is assumed to be **superior** (e.g. more real) to perception. Reality is also perceived as more **objective** than perception - \"Everyone is entitled to their own opinion, but not their own facts.\" \r\n\r\nWhere this model fails is in appreciating how much of reality is *socially constructed*, and *therefore a matter of perception*.\r\n\r\nThis explains everything from money to [manias](https://www.goodreads.com/book/show/367596.Manias_Panics_and_Crashes), from democracy to conspiracy, from fashion to religion, from SEO to product design, from hiring to performance management. I could fill a book spelling out the applications of these general ideas in various domains; but it'd make for an insufferably repetitive blogpost. Instead I'll briefly introduce these mental models and invite you to discuss what you see in the mirror. \r\n\r\n## Mimicry\r\n\r\nSpecifically, [Batesian Mimicry](https://en.wikipedia.org/wiki/Batesian_mimicry). This is best explained by analogy to [Aposematism](https://en.wikipedia.org/wiki/Aposematism) in nature, when an animal signals to predators that it is not worth eating**.** \r\n\r\nAt first, a poisonous frog evolves and its most distinctive outward feature is bright redness. Because they are incentivized to find out about poison *before* eating, predators start to associate bright redness with poison, and avoid bright red frogs.\r\n\r\nPop question: *what happens next?*\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/gph3qkg70pjrkvyr29kl.jpg)\r\n\r\n> Note: While you pause to actually think this through... I'll also observe that the frog is also incentivized to evolve a distinctive signal like bright redness. It is presumably better to help predators figure out you are poisonous than to require them to nibble on you first. This signal is \"costly\" to develop, so you also see [Müllerian mimicry](https://en.wikipedia.org/wiki/M%C3%BCllerian_mimicry) occur, where this cost is shared.\r\n\r\nAnswer: *Other frogs turn red*. Including the non-poisonous ones. The stronger the signal, the stronger the mimicry. An initially \"honest\" signal becomes dishonest. Because signals are easier to mimic than the underlying quality, all honest signals eventually get overwhelmed by dishonest ones and lose all meaning. The poisonous frog must then find another signal. The cycle repeats. \r\n\r\n**Reality *deceives* perception as much as it informs**.\r\n\r\nAs seen in (*this is a living list, feel free to ping me with more*):\r\n\r\n- [Business Cycles](http://falkenblog.blogspot.com/2010/07/batesian-mimicry-explanation-of.html) - also [AAA rated CDO tranches](https://www.wired.com/2009/02/wp-quant/)\r\n- Marketing - [the Law of Shitty Click Throughs](https://andrewchen.co/the-law-of-shitty-clickthroughs/)\r\n- [Goodhart's Law](https://github.com/dwmkerr/hacker-laws#goodharts-law)\r\n- [/r/ActLikeYouBelong](https://www.reddit.com/r/ActLikeYouBelong/)\r\n\r\n## Reflexivity\r\n\r\n[Reflexivity](https://en.wikipedia.org/wiki/Reflexivity_(social_theory)) points out circular relationships between cause and effect. This is perhaps oxymoronic, because we are really asserting that \"effect\" affects \"cause\" so much so that they are indistinguishable.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/qs28inpo3ilfzqhv2w0p.png)\r\n\r\nI understand reflexivity best in economics. In George Soros' dense classic [The Alchemy of Finance](https://www.goodreads.com/book/show/369708.The_Alchemy_of_Finance), he observed the strange mathematics of the 1980's [merger mania](https://www.investopedia.com/terms/m/merger-mania.asp) - profits of conglomerates were more certain and highly valued than small companies. Their high stock prices enabled them to buy out their smaller cousins and add those profits to theirs, further increasing the stock price (aka \"arbitraging\" valuation multiples). We understand this math to be obviously unsustainable today, but there is a genuine way in which the high expectations helped enable fundamental actions that at least partially fulfilled those expectations. \r\n\r\nIn a more modern context, you could view tech hiring as reflexive. Tech company recruiters often tell a story of high and rising stock prices as part of their compensation story. In this way the valuation of a company (perception) directly influences hiring (reality).\r\n\r\nMy third example is perhaps most convincing: Real estate values are reflexive. House prices are influenced by bank lending, and bank lending is determined by the banks' estimation of house prices. Real estate is thus locked in a self reinforcing cycle of boom and bust. Mostly boom, because governments are incentivized to cause boom, and people vote in governments (see a pattern here?).\r\n\r\nWikipedia equates reflexivity to a positive feedback loop - buyers cause a rising stock price, which attracts more buyers, which causes more rising stock prices. It's fine but far too simplistic. Reflexivity is also about perception *legitimately and fundamentally* shaping reality and vice versa.\r\n\r\nMy definition of reflexivity: **The more you believe something to be true, *the more true it becomes*.**\r\n\r\nReflexivity isn't a complete or perfect model:\r\n\r\n- The endless ping-pong between cause and effect must stop somewhere, and Reflexivity is silent on *when* the loop stops (see [Hyman Minsky](https://en.wikipedia.org/wiki/Minsky_moment) for that).\r\n- I am also fond of pointing out *anti-reflexivity* - *the more you believe something to be true, the **less** true it is.* The [Efficient Market Hypothesis](https://en.wikipedia.org/wiki/Efficient-market_hypothesis) is glaringly antireflexive - the more people believe it to be true, they passively invest in index funds and give up on looking for market mispricing - which lets mispricing occur.\r\n\r\nHowever it is clearly at least partially explanatory of our reality, and therefore useful.\r\n\r\nAs seen in (*this is a living list, feel free to ping me with more*):\r\n\r\n- Money ([Liquidity](https://www.investopedia.com/terms/l/liquidity.asp), [Fiat](https://en.wikipedia.org/wiki/Fiat_money), [Inflation](https://www.nytimes.com/2022/07/28/podcasts/the-daily/inflation-federal-reserve.html))\r\n- Religion ([Neil Gaiman](https://en.wikipedia.org/wiki/American_Gods_(TV_series)) and [Terry Pratchett](https://en.wikipedia.org/wiki/Small_Gods) explore this)\r\n- Openness and Capitalism - [Soros' Open Society](https://www.opensocietyfoundations.org/voices/george-soros-open-society-the-financial-crisis-and-the-way-ahead)\r\n- Education - [The Pygmalion Effect](https://en.wikipedia.org/wiki/Pygmalion_effect)\r\n- Personal Success Beliefs - eg [The Secret](https://en.wikipedia.org/wiki/The_Secret_(book))\r\n- [McLuhanism](https://twitter.com/swyx/status/1304099188502716416?s=20)\r\n- Technology - [The Tough Tomato Principle](https://florentcrivello.com/index.php/2019/04/29/software-the-tough-tomato-principle-and-the-great-weirdening-of-the-world/)\r\n\r\n## Synthesis\r\n\r\nFor a long time (over a decade!) I have carried these two models in my head as separate models. But let's put them side by side:\r\n\r\n- **Reality *deceives* perception as much as it informs**.\r\n- **The more you believe something to be true, *the more true it becomes*.**\r\n\r\nReflexivity builds a positive feedback loop between perception and reality, and Mimicry breaks it.\r\n\r\nThis is the insight I had today.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/mimicry-and-reflexivity-360k","devToReactions":12,"devToReadingTime":5,"devToPublishedAt":"2020-12-13T22:35:02.336Z","devToViewsCount":158,"title":"Mimicry vs Reflexivity","published":true,"description":"Two opposing forces that describe how perception and reality do battle.","tags":"Reflections, Philosophy","slug":"mimicry-reflexivity","canonical_url":"https://www.swyx.io/mimicry-reflexivity","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/a6kd9tjqeffnz0d9cwyv.png"},"title":"Mimicry vs Reflexivity","description":"Two opposing forces that describe how perception and reality do battle. ","category":"note","tags":["reflections","philosophy"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/a6kd9tjqeffnz0d9cwyv.png","canonical":"https://www.swyx.io/mimicry-reflexivity","slug":"mimicry-reflexivity","date":"2020-12-13T22:35:02.336Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/321","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/321/comments","title":"Mimicry vs Reflexivity","created_at":"2022-01-18T00:13:18Z","updated_at":"2022-07-28T10:29:36Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/321/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nThe second week of [AWS re:Invent](https://reinvent.awsevents.com/) brought a surprise major announcement from the AWS Amplify team: **You can run Docker containers as AWS Amplify APIs now**!!!\r\n\r\nThe main Achilles heel of migrating to serverless architectures is having to relearn and rewrite traditional serverful code. With [the new Amplify Serverless Containers](https://aws.amazon.com/blogs/mobile/zero-effort-container-deployment-for-graphql-and-rest-apis-and-web-hosting-with-amplify-cli/), it is now possible to deploy code in stateful Docker containers with the *exact same workflow* as the rest of Amplify CLI.\r\n\r\n```bash\r\n# example of the new CLI workflow, see docs for details\r\n# Amplify CLI version 4.39+\r\n\r\n$ amplify init # if you're setting up new Amplify project\r\n\r\n$ amplify configure project\r\n > Do you want to enable container-based deployments? Yes\r\n\r\n$ amplify add api\r\n\r\nPlease select from one of the below mentioned services: REST\r\n? Which service would you like to use \r\n API Gateway + Lambda \r\n❯ API Gateway + AWS Fargate (Container-based) \r\n```\r\n\r\nFor the first time, this opens up the possibility of running **Rails, Django, Laravel**, or any other traditionally serverful APIs *seamlessly* alongside a serverless architecture. If it fits in a Docker container, you can run it! This thus unlocks the full capabilities of their respective ecosystems. \r\n\r\nEmphasis on *seamless* integration: this means that frontend and mobile developers don't need to go to 9 months of cloud school (having to learn the details of VPC, subnets, NACLs, IAM policies, SSL generation, continuous deploy, cost optimization, etc) just in order to get a containerized API up and running on AWS.\r\n\r\nThis, to me, is a big deal for a number of interrelated reasons:\r\n\r\n- **Long Running Code**: AWS Lambda functions are limited to 15 minutes. If I need to run longer tasks, like video conversion or batch processing, I would have to jump out of my existing workflow and use a completely different set of tools. Now, I can run Rails + [Sidekiq](https://github.com/mperham/sidekiq) or [Flask + Celery](https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-xxii-background-jobs) with just an industry standard `docker-compose.yml`. Because Amplify's Serverless Containers feature uses AWS Fargate, we may in future have the option of vertically scaling system resources as needed, beyond the traditional [resource constraints] (https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) of AWS Lambda.\r\n- **Access Entire Ecosystems**: Libraries and frameworks that were written for serverful paradigms typically become useless when shifting to serverless/Jamstack architectures, requiring yet another learning curve and search for tools. Now you are free to mix and match them - anything that runs in a Docker container is fair game (and *everything* runs in a Docker container!)\r\n- **Incremental Migration**: This also means that it is no longer a heavy lift to move existing apps and codebases to a serverless/Jamstack architecture. As long as you can separate your UI layer from your API layer, you are now able to host your UI on [Amplify Console](https://aws.amazon.com/blogs/aws/amplify-console-hosting-for-fullstack-serverless-web-apps/), and your APIs as a REST or GraphQL service with API Gateway + AWS Fargate.\r\n- **Easy Access to other [Amplify categories](https://docs.amplify.aws/cli/start/workflows#amplify-category-add)**: because this plugs right into the Amplify API category workflow, this means that your code inside your containers get all the same benefits of Amplify APIs like easy authentication with Amazon Cognito and easy access to Amplify-managed resources like [Storage](https://docs.amplify.aws/cli/storage/overview), [Functions](https://docs.amplify.aws/cli/function), [GraphQL](https://docs.amplify.aws/cli/graphql-transformer/overview) and more. Because networking is handled for you, you can *even talk to other containers* - the default `docker-compose.yml` example in the CLI shows how you can make an Express (JS) app interoperate with a Flask (Python) app!\r\n\r\nSo, yeah. I think this is awesome - You can run basically anything on AWS Amplify now - meaning that you spend less time wrangling infrastructure and more time writing valuable features. Don't take my word for it, see [Ant Stanley](https://twitter.com/IamStan/status/1337088737243783174?s=20) (organizer of Serverless Days and overall cloud expert):\r\n\r\n{% twitter 1337088737243783174 %}\r\n\r\nP.S. for those who are making comparisons with AWS CDK, note that [this capability was actually made with CDK](https://twitter.com/undef_obj/status/1337217826436747266?s=20) - it solves a higher level problem than CDK. ","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/you-can-run-containers-on-aws-amplify-now-23ka","devToReactions":62,"devToReadingTime":3,"devToPublishedAt":"2020-12-11T14:24:37.337Z","devToViewsCount":4118,"title":"You Can Run Containers on AWS Amplify Now","published":true,"description":"AWS just added the easiest way to deploy long running serverful code alongside a serverless architecture.","category":"tutorial","tags":"Tech, AWS","slug":"amplify-serverless-containers","cover_image":"https://d2908q01vomqb2.cloudfront.net/0a57cb53ba59c46fc4b692527a38a87c78d84028/2020/12/10/Artboard-Copy.png"},"title":"You Can Run Containers on AWS Amplify Now","description":"AWS just added the easiest way to deploy long running serverful code alongside a serverless architecture. ","category":"tutorial","tags":["tech","aws"],"image":"https://d2908q01vomqb2.cloudfront.net/0a57cb53ba59c46fc4b692527a38a87c78d84028/2020/12/10/Artboard-Copy.png","slug":"amplify-serverless-containers","date":"2020-12-11T14:24:37.337Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/322","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/322/comments","title":"You Can Run Containers on AWS Amplify Now","created_at":"2022-01-18T00:13:20Z","updated_at":"2022-06-18T17:47:16Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/322/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nThere's something sublime in the state of Denmark.\n\nIt is a tiny country (5.8m population today - the same size as Singapore where I am from) but it has had an abnormally large impact on computer science and therefore the world. Here is a selection of Danish programming language and compiler pioneers (in no particular order):\n\n- **[Bjarne Stroustrup](https://en.wikipedia.org/wiki/Bjarne_Stroustrup)**: Creator of C++\n- **[Rasmus Lerdorf](https://en.wikipedia.org/wiki/Rasmus_Lerdorf)**: Coauthor of PHP\n- **[Anders Hejlsberg](https://en.wikipedia.org/wiki/Anders_Hejlsberg)**: Creator of Turbo Pascal, Delphi, J++, C#, TypeScript\n- **[Mads Tofte](https://en.wikipedia.org/wiki/Mads_Tofte)**: Coauthor of Standard ML\n- **[Peter Naur](https://en.wikipedia.org/wiki/Peter_Naur)**: of [the Backus-Naur form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) and ALGOL 60\n- **[Per Brinch Hansen](https://en.wikipedia.org/wiki/Per_Brinch_Hansen)**: created Concurrent Pascal\n- **[Poul-Henning Kamp](https://en.wikipedia.org/wiki/Poul-Henning_Kamp)**: creator of MD5crypt, malloc, Varnish, and others\n- **[David Heinemeier Hansson](https://en.wikipedia.org/wiki/David_Heinemeier_Hansson)**: creator of Ruby on Rails\n- **[Lars and Jens Rasmussen](https://en.wikipedia.org/wiki/Lars_Rasmussen_(software_developer))**: creators of Google Maps\n- **[Lars Bak and Kasper Lund](https://blog.creandum.com/the-next-big-computing-platform-is-toit-a461e1e7a5a5)**: coauthors of V8 (Chrome, Node.js, MongoDB), and Dart/Flutter.\n\nI also of course have had the privilege of working for [Mathias Biilmann and Christian Bach](https://en.wikipedia.org/wiki/Netlify), both from Denmark.\n\nMany were born in Copenhagen, Denmark's capital and biggest city, but [Brian LeRoux notes](https://twitter.com/brianleroux/status/1336651506783686659?s=20) that many of the [JVM](https://en.wikipedia.org/wiki/Java_virtual_machine) team were from [Aarhus](https://en.wikipedia.org/wiki/Aarhus). [Lars and Kasper's V8 team of about 70 was sited in Aarhus](https://blog.creandum.com/the-next-big-computing-platform-is-toit-a461e1e7a5a5). Bjarne, the Rasmussen brothers, and the V8 duo are actually from [Aarhus University](https://en.wikipedia.org/wiki/Aarhus_University), though there is decent representation from other Danish universities too.\n\nAnders, the overachiever of the group, speculates: \"[Could it be because the winters and long and dark and there are no mountains to go ski, so you might as well design programming languages?](https://twitter.com/ahejlsberg/status/1135686367034322944)\". This is of course a joke, but I won't lie and say I didn't have a peek to see what neighboring countries (Finland - Linus Torvalds, Norway - Håkon Wium Lie) did. The lowlands \"no mountains\" thesis is perhaps important, so I also checked out the Netherlands (Guido van Rossum, Bert Bos, Edsger Dijkstra).\n\nI find it interesting that [the Lego Group](https://en.wikipedia.org/wiki/Lego) is also from Denmark. \n\n**It's like the Danes are obsessed with giving the world basic building blocks.**","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-strange-case-of-the-danish-aarhus-mafia-8el","devToReactions":25,"devToReadingTime":2,"devToPublishedAt":"2020-12-09T15:46:36.688Z","devToViewsCount":244,"title":"The Strange Case of the Danish Aarhus Mafia","published":true,"description":"Why are so many CS pioneers from Denmark?","tags":"Random","slug":"danish-mafia","canonical_url":"https://www.swyx.io/danish-mafia","cover_image":"https://miro.medium.com/max/3840/1*K4ufvkEE_s3i-FUAMH0Vng.jpeg"},"title":"The Strange Case of the Danish Aarhus Mafia","description":"Why are so many CS pioneers from Denmark? ","category":"note","tags":["random"],"image":"https://miro.medium.com/max/3840/1*K4ufvkEE_s3i-FUAMH0Vng.jpeg","canonical":"https://www.swyx.io/danish-mafia","slug":"danish-mafia","date":"2020-12-09T15:46:36.688Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/323","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/323/comments","title":"The Strange Case of the Danish Aarhus Mafia","created_at":"2022-01-18T00:14:36Z","updated_at":"2022-06-18T17:47:17Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/323/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Learning in Public and the Coding Career Handbook - Developer Tea","slug":"developer-tea","tags":["Careers"],"venues":"Developer Tea","date":"2020-12-07T00:00:00.000Z","url":"https://www.listennotes.com/podcasts/developer-tea/learning-in-public-w-shawn-Q2S4e9qJDpu/","description":"I joined Jon Cuttrell's podcast to talk about the book and got to talk some strategy stuff I rarely talk about!","category":"podcast"},{"type":"blog","content":"\nWhen Svelte 3 [launched](https://news.ycombinator.com/item?id=19719118) in 2019, the top demanded feature was TypeScript support. And when TypeScript support was [finally announced](https://twitter.com/sveltejs/status/1285627864310743043?lang=en) in 2020, the reception was ecstatic. \n\nBut the secret is - not much needed to change in Svelte's core code. It simply added [language tooling](https://github.com/sveltejs/language-tools) to its core responsibilities. Svelte already had TypeScript preprocessors for years - but it wasn't considered to have \"TypeScript support\" until the VS Code extension shipped.\n\nI think this is indicative of a broader trend:\n\n**In the [Third Age of JavaScript](https://www.swyx.io/js-third-age/), all frameworks will provide their own language servers.**\n\nBy way of proof, you see this pattern emerging in other frameworks as well:\n\n- [Vetur](https://github.com/vuejs/vetur) is standard tooling for all Vue.js developers\n- React strongly recommends [ESLint checks](https://reactjs.org/docs/hooks-rules.html#eslint-plugin) to enforce the Rules of Hooks (this is probably an understatement; probably no React professional would trust themselves to write Hooks right without the ESLint checker today)\n- Angular has the [Angular Language Service](https://github.com/angular/vscode-ng-language-service) (thanks [Mike](https://twitter.com/mhartington/status/1335338641447587840)) and Ember is [working on it](https://marketplace.visualstudio.com/items?itemName=lifeart.vscode-ember-unstable) (thanks [Alex](https://twitter.com/vaier/status/1335482247810592768?s=20)) \n- Tailwind Labs' [first hire](https://blog.tailwindcss.com/welcoming-brad-cornes-to-the-tailwind-team) was Brad Cornes, who made the Tailwind IntelliSense plugin\n- [GraphiQL](https://github.com/graphql/graphiql), [Relay Compiler](https://relay.dev/docs/en/installation-and-setup#set-up-relay-compiler) and [Apollo VS Code](https://www.apollographql.com/docs/devtools/editor-plugins/) can be regarded as language servers for GraphQL development\n\nLinting, typing, always-running-compilation and other forms of write-time checks and optimizations are not new. In fact, when dev teams write unit tests and lint rules, they are essentially creating their own bespoke language server for their own app. What's new is that **giving realtime feedback is now a responsibility shared by frameworks**. This standardization increases productivity both when starting a new project and moving between projects.\n\n## Why\n\nThe proximate *reason* this is a thing is simple: Cost.\n\nIBM coined the term \"[Shift Left](https://devops.com/shift-left-can-you-be-left-out/)\" after finding that [the earlier you catch errors, the cheaper they are to fix](https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC) ([Neil](https://twitter.com/mknz/status/1335351649720668161?s=20) points out that this research goes as far back as [Barry Boehm in the 1980s](https://dzone.com/articles/real-cost-change-software)). If you arrange the software development lifecycle from left (design) to right (production), the idea is that if you shift your errors \"left\" then you'd save actual money by catching errors earlier ([this is disputed](https://gist.github.com/Morendil/6d664bf990c17ea0f88f9bb0cc403c64) — and [finding proof is hard](https://buttondown.email/hillelwayne/archive/i-ing-hate-science/)!). \n\nOf course, the flip side of Cost is *Developer Experience*. **Cost is what our bosses pay, DX is what we *feel***. And we always gravitate to tools that guide us down the [pit of success](https://blog.codinghorror.com/falling-into-the-pit-of-success/).\n\nYou could translate this idea to modern terms:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/4nyfjt36m2ueummlqfsc.png)\n\nAnd then plot the slow leftward shift of frameworks:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3xvu11v9ayvaxnakzsk9.png)\n\nRemember I said cost was a *proximate* reason. I believe there's a deeper, more fundamental reason.\n\n## Tom was Right (and still is)\n\nIn 2017, Tom Dale of the Ember core team observed the first part of this evolution, that [Compilers are the New Frameworks](https://tomdale.net/2017/09/compilers-are-the-new-frameworks/). \n\n> My current “investment thesis” is that what we call web frameworks are transforming from runtime libraries into optimizing compilers. When it comes to eking performance out of hand-authored JavaScript and accompanying runtime libraries, we’ve reached the point of diminishing returns.\n\nHe was not only astoundingly right (Svelte is built from the ground up as a compiler) but this process is also not done (Next.js is arguably an optimizing compiler for React, but the React team itself is working on Selective Hydration and a [hybrid client/server model](https://twitter.com/dan_abramov/status/1259615094163607561)). Every framework basically invents its own metalanguage ([React](https://www.youtube.com/watch?v=QiR9viVIJgo), [Svelte](https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934), [ActiveRecord](https://medium.com/@llkktt/blog-707634e025cf)) to solve for developer experience under constraints of a more popular general purpose language, and this language will eventually want to be compiled.\n\nI'm simply extending this train of thought to its natural conclusion: what we call web frameworks are transforming from runtime libraries, into optimizing compilers *with first class language server support*.\n\nI don't know how unique this observation is but it felt revelatory [when I first realized it](https://twitter.com/swyx/status/1259121891555467264?s=20). After you observe the evolution of a few frameworks and developer platforms you start seeing the same movie play out over and over again. To offer better developer experience, you end up creating a language. A language needs a compiler. A compiler eventually wants a language server.\n\n## Sell the Shovels\n\nLanguage servers do a lot of [undifferentiated heavy lifting](https://jeremybower.com/articles/undifferentiated-heavy-lifting-2-0.html) - file watching, processing, reporting, supporting plugins for every IDE, and so on. If we're all going to be building language servers, why do we have to reinvent the wheel every time? \n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/s1ixc6yvv6b1xfj10ate.png)\n\nNaturally, if language servers are the new bar for frameworks, those who *own* the common rails for the language server layer will do very well. Microsoft first developed the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) for VSCode and [standardized it in 2017](https://www.infoworld.com/article/3088698/microsoft-backed-langauge-server-protocol-strives-for-language-tools-interoperability.html). This was a generous move that ensured the protocol would work with non-Microsoft IDEs like [Eclipse](https://www.eclipse.org/community/eclipse_newsletter/2017/may/article1.php), [IntelliJ](https://youtrack.jetbrains.com/issue/IDEABKL-7409) and even [vim](https://www.vimfromscratch.com/articles/vim-and-language-server-protocol/), and non-Microsoft languages like [Python](https://visualstudiomagazine.com/articles/2020/07/01/pylance-vs-code.aspx). Because LSP is ironically language and tooling agnostic, you also greatly lower the barrier for entire generations of language and editor agnostic startups, like [Sourcegraph](https://langserver.org/) and [Kite](https://www.kite.com/).\n\nHere's my advice for anyone who wants to make their dev tools project successful: **time to learn how language servers work.**\n\n> Author's note: Orta from the TS core team [left a great comment](https://dev.to/orta/comment/18o1d) with more resources to learn about LSPs from Anders Hejlsberg and a coming \"Build Server Protocol\"!\n\n---\n\n\n*[see Twitter conversation](https://twitter.com/search?q=https%3A%2F%2Fdev.to%2Fdx%2Flanguage-servers-are-the-new-frameworks-1lbm&src=typed_query)* \n\n---\n\n> Note: this was 1/3 of the thesis of [my second React Rally talk](https://docs.google.com/presentation/d/1sBb7KjhSOiONML61fnYwkVI-7yzJCoP-Zgs6E37T-nY/edit?usp=sharing).\n\n{% youtube 18F5v1diO_A %}\n\n\n----\n\n> [DX Circle](https://codingcareer.circle.so/c/dx-blog) is a new journal on Developer Tools, Developer Communities, and Investing in Developer Experience Startups. If you'd like to submit an article, [let me know](https://twitter.com/swyx)!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/dx/language-servers-are-the-new-frameworks-1lbm","devToReactions":134,"devToReadingTime":5,"devToPublishedAt":"2020-12-05T20:51:05.939Z","devToViewsCount":6718,"title":"Language Servers are the New Frameworks","published":true,"description":"Developer Experience is shifting left, all the way to onKeyUp.","tags":"DX","slug":"language-servers","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/3xvu11v9ayvaxnakzsk9.png","canonical_url":"https://www.swyx.io/language-servers"},"title":"Language Servers are the New Frameworks","description":"Developer Experience is shifting left, all the way to onKeyUp. ","category":"note","tags":["dx"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/3xvu11v9ayvaxnakzsk9.png","canonical":"https://www.swyx.io/language-servers","slug":"language-servers","date":"2020-12-05T20:51:05.939Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/189","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/189/comments","title":"Language Servers are the New Frameworks","created_at":"2022-01-17T23:02:47Z","updated_at":"2022-06-18T17:48:59Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/189/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nIf you swung by my Twitter profile in the last week, you probably saw this:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/olflh5jfvk5clb15p5z9.png)\n\nI'm not sure of the precise causes of me being locked out, but I have several abnormal usage factors that probably put me on the high end of Twitter's bot risk system:\n\n- I currently live in Singapore but am primarily active during US hours and have a US Phone Number\n- I post about 30 tweets a day, probably on the high end of most Twitter users. (30 sounds like a lot, but it's mostly replies, and I maybe post 2-3 actual top tweets a day)\n- I switch between and manage three different accounts ([Coding Career](https://twitter.com/Coding_Career) and [Svelte Society](https://twitter.com/SvelteSociety)) multiple times a day\n- As far as I know I have not been reported on, but I do have people that strongly dislike me and they may have used the report button against me. Can't rule that out as a factor.\n- Anecdotally [some IPs seem more risky](https://twitter.com/b2m9/status/1295748479713779712?s=20) than others - I also use a VPN for work which probably shows me jumping across multiple countries in a single day, which is certainly suspicious on the face of it\n- I have also noticed I get verification checks more often when I use scheduled tweets.\n\nIf you clicked through my scary profile you also saw this:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6xjg8jxiwgidwffvwsnu.png)\n\nI swear that I haven't mass unfollowed everybody! Most people see this and assume that I used some script to mass unfollow everyone and therefore got flagged as a bot. **The reality is the exact opposite** - I got flagged as a bot, and by default Twitter temporarily removes all follows. \n\nIt will be restored once I regain my Twitter account (I've filed a support ticket and am trying to reach out to friends at Twitter for help), but this is the exact user experience I wanted to talk about for this post.\n\nFirst, a quick detour for a personal anecdote.\n\n## Aside: My Time As A Cuban Detainee\n\nA long time ago I visited Havana with some college friends. Right after landing we headed into a restaurant, all our luggage in tow. After we were done eating, I stood up and turned around - only to find all my luggage gone! Someone had stolen it while we were eating. The restaurant staff of course swore up and down that they had not seen who had taken it.\n\nLosing all your luggage on day 1 of a weeklong trip sucks, but what is worse is that **my passport was in my luggage**. I needed it to head back to the US at the end of my trip. \n\nIf you've never lost a passport while traveling before, it's a quick trip to bureaucratic hell. If your country has an embassy where you are traveling, you can usually get it reissued in the embassy. But we were in *Cuba* - and my country had no embassy here. We reported my case to the authorities, but they had no idea what to do. I was an edge case. Worse still, because I said I had come from the US and couldn't produce any papers to prove my identity, I was detained at the police headquarters for questioning on suspicion of being a spy. (*I was never really at any risk - being Asian and speaking poor Spanish, I would have made for a pretty lousy spy*).\n\nThere was a lot to figure out over the ensuing *month* of my ordeal - money, lodging, language barriers, administrative hurdles. My family and friends hit the panic button for me and my case reached the ears of both Arlen Specter on the US Senate Foreign Relations Committee and George Yeo, the Singapore Foreign Affairs Minister. We eventually worked it out, but every night for 4 weeks I would wander up and down [the Malecón](https://en.wikipedia.org/wiki/Malec%C3%B3n,_Havana), listening to the crashing waves, not knowing when I could ever leave the country. If I could swim [the 90 miles to Key West](https://en.wikipedia.org/wiki/Southernmost_point_buoy) and [dry my feet](https://en.wikipedia.org/wiki/Wet_feet,_dry_feet_policy), I might theoretically make it back to the US on my own.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3i8nh2cgaoj3jlrl9ecm.jpg)\n\nBut most of all, I thought a lot about **the humanity of having a piece of paper be more important than the human it represents**. I could be physically standing in front of the immigration officer with a lie detector test on and steadfastly stating all manner of provable personal detail, and they would not let me through unless I had a small piece of paper the size of my hand.\n\nWe do this a lot - passports, voter registration cards, national ID systems, licenses, and insurance proofs - mostly because some humans are untrustworthy and try to exploit the system. \n\nBut we often fail to design for people who are innocent and simply don't fit the system in some way.\n\n## The Consequences of Not Being Provably Human\n\nTwitter has a way in which they expect you to verify you are human - you should get a call or text message with a code, that you then enter to prove humanity. This is what I normally get (about once every 1-2 months), and I can receive text messages from Twitter, so I can usually prove humanity with no issue.\n\nThis time, for some reason, I am on a code path that doesn't offer a text message option, and Twitter somehow doesn't make international US number calls, leading to this infinite loop that I think is a bug:\n\n{% youtube WZFs-QUq2bg %}\n\nAs a result of this unfortunate design:\n\n- My friends think I mass unfollowed them, because Twitter temporarily reduced my follow count to 0\n- People who DM me think I am ignoring them, because Twitter doesn't inform them that I am currently locked out\n- None of my past tweets show up at all in [Twitter search](https://twitter.com/search?q=from%3Aswyx&src=typed_query), which is problematic because I [use Twitter as a Second Brain](https://twitter.com/swyx/status/1245281982797373441?lang=en). If you read any of my blogposts, you will see that the rich link density of my references mainly come from taking notes in public over an extended period of time.\n- I was unable to engage in the normal personal and professional activity I would do during Black Friday and AWS Re:invent\n\nI've filed a support ticket with Twitter, but you can imagine that support for a 330 million user service isn't very responsive. People who have been through this tell me the only way to resolve it is to hit up a Twitter employee to get past the masses of unrelated and less urgent support issues.\n\n## Humans Proving Humanity To Machines\n\nIn the grand scheme of things, I know this is minor. I've actually taken it as a welcome social media detox, which I usually take voluntarily in December anyways. But when it's not on my terms, I lose the ability to manage the personal and professional relationships I've painstakingly built up over the past 3-4 years.\n\nAbove all, I think there's an *indignity* in humans having to prove to machines that they are human, and the error resolution mechanism is to send a ticket to a faceless and unresponsive support email, and the only real way to get around it is again to re-establish human connections. \n\nI think more about all the other ways that we as software developers and designers fail to honor the dignity of humans trying to interact with the systems we create. \n\n[In 2014](https://www.theverge.com/2019/2/1/18205610/google-captcha-ai-robot-human-difficult-artificial-intelligence), Google pitted one of its machine learning algorithms against humans in solving the most distorted text CAPTCHAs: the computer got the test right 99.8 percent of the time, while the humans got a mere 33 percent. It doesn't impact everyone equally - if you as a sighted, able bodied user struggle with CAPTCHAs, imagine the elderly or differently abled. Most services do not offer any alternative resolution when you cannot prove you are human. This is a problem when your service has essentially killed off the offline alternative and is essential for their basic needs. \n\nIn Eric Meyer's [Designing for Crisis](https://meyerweb.com/eric/thoughts/2016/01/25/designing-for-crisis-design-for-real-life/), he describes how an inaccessible hospital website nearly risked the life of his daughter. I shudder to think how it might be made worse by perfectly well meaning software engineers who don't think about the humanity of the failure path. Imagine if you had to log in to something to save your child's life, and it presented you with a CAPTCHA you couldn't pass.\n\n---\n\n*Update: [I've been helped](https://twitter.com/swyx/status/1334901024201445376?s=20), thank you for reaching out. In case you were wondering what it looks like from Twitter's side, this is what they emailed:*\n\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/wgdlczuq2k5ay8uhql2q.png)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-ux-of-proving-our-humanity-to-machines-nf","devToReactions":36,"devToReadingTime":6,"devToPublishedAt":"2020-12-03T16:13:27.790Z","devToViewsCount":984,"title":"The UX of Proving Our Humanity To Machines","published":true,"description":"What happens when we can't convince machines that we are human?","tags":"Reflections, UX","slug":"proving-our-humanity","canonical_url":"https://www.swyx.io/proving-our-humanity","cover_image":"https://venturebeat.com/wp-content/uploads/2014/08/facebook-f8-mark-zuckerberg-21-e1417804264852.jpg?w=1200&strip=all"},"title":"The UX of Proving Our Humanity To Machines","description":"What happens when we can't convince machines that we are human? ","category":"note","tags":["reflections","ux"],"image":"https://venturebeat.com/wp-content/uploads/2014/08/facebook-f8-mark-zuckerberg-21-e1417804264852.jpg?w=1200&strip=all","canonical":"https://www.swyx.io/proving-our-humanity","slug":"proving-our-humanity","date":"2020-12-03T16:13:27.790Z","readingTime":"7 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/190","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/190/comments","title":"The UX of Proving Our Humanity To Machines","created_at":"2022-01-17T23:02:49Z","updated_at":"2022-06-18T17:48:59Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/190/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nI have a lot to be thankful for this year, including [my new job](https://www.swyx.io/writing/hello-aws) and [my new book](https://www.learninpublic.org/), as well as meeting many new friends and excellent opportunities this year. But for today's post I wanted something light, so I figured I would just shout out the new podcasts I've discovered **this year**.\n\n## Technical Podcasts\n\n[The Stack Overflow Podcast](https://stackoverflow.blog/podcast/) has a LONG and weird history. It's been around [since 2008](https://stackoverflow.blog/2008/04/17/podcast-1/) when Jeff and Joel were still around, then it died, then [Jay Hanlon](https://stackoverflow.blog/2017/07/31/podcast-114-every-conference-needs-break-dancing-greeter/) took over, and then it died, and this year it was revived by Ben Popper, Sara Chipps and Paul Ford, all of whom are hilarious, intelligent voices. I would classify this as \"lightly\" technical - it touches on topics and has good guests, but given the typical short length of podcast they don't really have the room to go too deep.\n\n[Software Sessions](https://www.softwaresessions.com/) only started in Sept 2019, and I frankly only discovered it when I was [invited as a guest](https://www.softwaresessions.com/episodes/learning-in-public/). But the thoughtfulness and depths of Jeremy's questions blew me away, and this was much better explained once I learned that Jeremy has hosted [SE Radio](https://www.se-radio.net/) for a while. This is a promising spinoff, much like my other favorite, [SE Daily](http://softwareengineeringdaily.com/). Check out [the episode list](https://www.softwaresessions.com/episodes/) for the insane quality of guests he's had on.\n\nThe next trio of podcasts reflect my growing interest in cloud tech (as distinct from my existing diet of JS/Frontend podcasts):\n\n- [The Cloudcast](https://www.thecloudcast.net/) - A highly technical podcast from [Brian Gracely](https://twitter.com/bgracely) at Red Hat and [Aaron Delp](https://twitter.com/aarondelp) at Nutanix. I think this is associated with [A Cloud Guru](https://acloud.guru/cloudcast) somehow, but I'm not clear how since neither works there. Their recent chat with [Evan Weaver of Fauna DB](https://www.thecloudcast.net/2020/11/serverless-data-apis.html) is exemplary of their discussions.\n- [Software-Defined Talk](https://www.softwaredefinedtalk.com/) an extremely laid back, irreverent discussion of all the cloud/devops topics of the day. Very refreshing to listen in to the cut-the-bullshit convo of Brandon, Cote, and Matt Ray, because there is SO. MUCH. BULLSHIT. in the cloud space.\n- [The Dan Pop podcast](https://popcast-d9f7b6dc.simplecast.com/) is basically Dan Pop and his buddies talking cloud stuff. I really like his ability to get \"OG\" guests like [Clayton Coleman](https://popcast-d9f7b6dc.simplecast.com/episodes/episode-45-the-godfather-of-red-hat-openshift-clayton-coleman) to top founders like [Mitchell Hashimoto](https://popcast-d9f7b6dc.simplecast.com/episodes/episode-22-principals-products-and-principles-at-hashicorp-armon-dadgar-and-mitchell-hashimoto) and [Spencer Kimball](https://popcast-d9f7b6dc.simplecast.com/episodes/episode-46-a-database-that-survives-anything-with-cockroach-labs-spencer-kimball).\n\nMy final pick here was kind of borderline but is so unique I had to mention it - The [Microsoft Research Podcast](https://www.microsoft.com/en-us/research/podcast/). As opposed to the more superficial [Behind the Tech](https://www.microsoft.com/en-us/behind-the-tech) podcast with Kevin Scott (Microsoft's CTO), this one is with the actual researchers at MSR, one of the dying breed of corporate research labs in the world. It is a borderline pick because the podcast hasn't been active for a while, but the backlog is cool to dig through for a survey of what the deepest thinkers are working on.\n\n## Non-Technical Podcasts\n\nIn the Entrepreneurial Mastermind category (usually weekly checkins from two founder-friends) I've picked up two new podcasts:\n\n- [Talk Therapy](https://talktherapy.substack.com/) is Dan Shipper and Nathan Baschez building a Substack bundle business in public. I *wanted* to dislike them for how unfairly privileged they and their customers are (probably more out of envy and spite), but they have proven themselves through thoughtful conversation and objective business success.\n- [Software Social](https://softwaresocial.dev/) is [Michelle Hansen](https://mjwhansen.com) and [Colleen Schnettler](https://twitter.com/leenyburger) talking through their experiences building their own SaaS. I only discovered this through a podcast drop from the Indie Hackers podcast, so for that I am grateful. It's rare to have a podcast with two extremely technical women building in public. Their rapport is great - listen for the War of 1812 story in [Who's the Villain](https://softwaresocial.dev/episodes/whos-the-villain)\n\nI became a writer this year with my new book, and Kent C Dodds turned me onto [Writing Excuses](https://writingexcuses.com/), which is Brandon Sanderson and crew talking about various aspects of professional fiction writing for 15 years. Every episode is remarkably rich thanks to the vast experience of the panel and their guests. I particularly enjoyed their recent [Audiobook Narration](https://writingexcuses.com/2020/10/25/15-43-audiobook-narration-with-bruce-d-richardson/) episode.\n\nMy research on [the Operating System of You](https://www.swyx.io/ideas/?show=Talks&show=Podcasts&filter=operating-system-of-you/) made me start taking [Cal Newport's writing on Deep Work](https://www.calnewport.com/books/deep-work/) a lot more seriously. I envisioned him a grumpy old Luddite yelling at newfangled social media. Instead he's a Computer Science professor roughly my age! [Deep Questions](https://www.calnewport.com/podcast/) is his podcast basically doing Q&A from the absolutely massive audience his ideas have gained. \n\n> I shamefully admit I play it in the background while I work, which kind of goes against the whole Deep Work ethos. I'm working on it!\n\nIn the **Fun** category, I've added both [the Conan O'Brien podcast](https://www.earwolf.com/show/conan-obrien/) and [the Scrubs rewatch podcast](https://www.iheart.com/podcast/1119-fake-doctors-real-friends-60367049/) to my regular rotation. I've fallen into the YouTube Consensus that Conan is one of the best late night talkshow hosts alive, equal parts silly and meaningful, but really I listen for Sona Movsesian, his (un)trusty assistant who doesn't put up with any of his crap. As for Scrubs, it was one of my favorite shows growing up, and having the two main stars of the show relive their moments with participation of the guest stars, writers, and showrunner is just wonderful. Donald Faison in particular doesn't get nearly enough credit for how talented he is.\n\n## My Existing List\n\nThese are just the podcasts I discovered this year - in other words, they aren't necessarily STARTED in 2020, I'm just highlighting ones I personally discovered. \n\nYou can find [my existing favorite podcasts list here](https://www.swyx.io/fave-podcasts/).\n\nOne very imperfect measure of podcast love is how much actual playtime I give it. Here are my top 20:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/irw9u5pwryuk62xsesbh.jpg)\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/878kq93coweu1hm7f6nm.jpg)\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3m1jgwgu5hcdfldc242h.jpg)\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/xzwa6y3vcdev19tyghe9.jpg)\n\n## Shameless plug: My Podcasts!\n\nOf course what would an online creator be in 2020 without a podcast of their own?\n\n- Listen to my [Career Chats podcast](http://careerchats.transistor.fm/) with [Randall Kanna](https://randallkanna.com/the-standout-developer/). We made the kind of podcast we wish existed - short (~10mins), focused (1 topic), actionable (1 takeaway/call to action).\n- I'm a regular panelist on [Svelte Radio](https://www.svelteradio.com/).\n- I've also [been a guest on a dozen podcasts](https://www.swyx.io/ideas/?show=Podcasts) this year.\n- 2021 edit: I now also have [a personal mixtape podcast](https://swyx.transistor.fm/)!\n\n## Your Turn\n\nYour turn: What's a great podcast you discovered this year?","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/my-favorite-new-podcasts-in-2020-42ep","devToReactions":23,"devToReadingTime":5,"devToPublishedAt":"2020-11-27T16:18:14.888Z","devToViewsCount":236,"title":"My Favorite New Podcasts in 2020","published":true,"description":"An update to my favorite podcasts list with the ones I have found this year","tags":"Reflections","slug":"fave-podcasts-2020","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/irw9u5pwryuk62xsesbh.jpg","canonical_url":"https://www.swyx.io/fave-podcasts-2020"},"title":"My Favorite New Podcasts in 2020","description":"An update to my favorite podcasts list with the ones I have found this year ","category":"note","tags":["reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/irw9u5pwryuk62xsesbh.jpg","canonical":"https://www.swyx.io/fave-podcasts-2020","slug":"fave-podcasts-2020","date":"2020-11-27T16:18:14.888Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/191","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/191/comments","title":"My Favorite New Podcasts in 2020","created_at":"2022-01-17T23:02:51Z","updated_at":"2022-06-18T17:49:00Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/191/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nThere is nothing more frustrating than a cryptic error message. \r\n\r\nWhen something goes wrong, chances are you already knew it - all a cryptic error message does is confirm your suspicion *and* tell you that you're gonna need to read through a bunch of code to figure out your error.\r\n\r\nAs framework and library designers, we can and should do better for our users by carefully following a few design principles.\r\n\r\n## Why We Should Care\r\n\r\nWho among us hasn't thrown up their hands at an unhelpful `Error: NullPointerException` or `undefined is not a function`? Of course, this is a [straw man](https://en.wikipedia.org/wiki/Straw_man) - unanticipated errors always leak internals. We should do our best to handle these errors as much as possible! \r\n\r\nThe frustrating part comes from errors that were *anticipated* but obviously not given any thought:\r\n\r\n![Example of unhelpful error message from Twitter screenshot](https://dev-to-uploads.s3.amazonaws.com/i/qiivj3cdvkbo07fwrxq6.png)\r\n\r\nThis is particularly aggravating because it compounds an already unhappy situation with an even worse debugging and bug reporting experience.\r\n\r\nInstead, you could explain and suggest:\r\n\r\n[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/abv8asij07bm1qwkojwr.png)](https://twitter.com/id_aa_carmack/status/735197548034412546)\r\n\r\n## Why It's Important\r\n\r\nThoughtful error message design is one of the less glamorous, but most important, parts of [Developer Exception Engineering](https://www.swyx.io/developer-exception/). Most framework developers instinctively write error messages that make sense to *them*, but a few minutes of extra effort can save DAYS of debugging for *everyone else* (including maintainers!). \r\n\r\nWe must acknowledge two things:\r\n\r\n- there is immense information asymmetry between the framework developer and the framework user (developers know the codebase far better than users)\r\n- error messages are part of your developer experience too\r\n\r\nYou might be familiar with the old adage \"If you fail to plan, you plan to fail.\" Here, we have a slight twist: **If you fail to plan to fail, you are planning to fail your users when they need you most.** Touting great developer experience with lousy error message design is like selling a beautiful car with seatbelts that don't work when there's a crash.\r\n\r\n## Error Message Style Guide\r\n\r\nAt Temporal, our current style guide reflects our engineering roots in [Uber](https://github.com/uber-go/guide/blob/master/style.md#error-types) and [Golang](https://blog.golang.org/go1.13-errors) with some tactical recommendations:\r\n\r\n- Use `errors.New` for simple messages and `fmt.Errorf` for formatted messages. Make sure you're using the standard `errors` go package.\r\n- Error messages start with lowercase and no punctuation at the end: `unable to open file` instead of `Unable to open file..`\r\n- Error messages should be actionable, e.g. `no such directory` instead of `loading service config`.\r\n- Use `unable to...` instead of `failed to...`, `can't...`, or `could not...`.\r\n- Messages should reflect the logical action, not merely a function name: `load service config` instead of `LoadServiceConfig`. This message should add actionable, meaningful context to the existing error message.\r\n\r\nThat said, as we evolve our developer experience philosophy, we are looking toward higher level design principles that help guide successful outcomes.\r\n\r\n## Error Message Design Principles \r\n\r\nWe are still in the early stages of pinning down our beliefs in what makes for great error messages, but here are some candidate principles running through my mind:\r\n\r\n- **Errors should be written for USERS, not maintainers**: Your error should make sense from a user point of view. For example, you should cite user-supplied configs and values familiar to users, not the internal variable and function names familiar to maintainers. \r\n- **Errors should suggest WHY they happened**, or even better - HOW to fix them: As a maintainer, you probably have a high amount of context as to the possible causes of an error - take the time to write down some hints for users. If there's a high probability you know what's wrong, the error message itself can suggest how to fix it. But even without that certainty, think about what the user is likely to need to log out to debug the error, and offer it in the error message itself. Where relevant, **Errors should display what was expected vs what was received**.\r\n- **Errors should be searchable**: Your users are most likely going to paste your errors into the search bars of your issue tracker, docs site, or Google. Consider the \"SEO\" of your errors. Sometimes offering a unique, human readable ID for each error can help narrow things down very quickly!\r\n- **Errors should be logged**: Errors that happen far more often than they ought to are a signal of a deeper issue. If a user code or configuration error happens too often, it isn't the user's fault - you have bad API design. If inside a terminal environment, you should offer some text formatting to make your errors visually distinct from normal log messages.\r\n- Last but not least, **Errors should not be too verbose**: You might be tempted to dump every piece of information under the sun, but this can be very annoying when scrolling through reams of errors. Most users don't read entire errors - make your words count, and link out to docs for fuller context. **Errors are not docs.**\r\n\r\nUltimately, the same high level principle applies to error messages as they do for anything involving human computer interaction: **[Don't Make Me Think](https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think)**!\r\n\r\n## Related\r\n\r\n- \r\n[What the Fastly outage can teach us about writing error messages](https://onlineornot.com/what-fastly-outage-can-teach-about-writing-error-messages)\r\n- [What, Why, and How of Error Messages](https://blog.appsignal.com/2021/09/22/improve-your-life-with-long-error-messages.html)\r\n- [Cut the cutesy errors](https://alexwlchan.net/2022/08/no-cute/)\r\n- https://wix-ux.com/when-life-gives-you-lemons-write-better-error-messages-46c5223e1a2f\r\n- \r\n![image](https://user-images.githubusercontent.com/6764957/196713768-0dc7f952-211b-44f6-89e6-71a0aaebbe37.png)\r\n![image](https://user-images.githubusercontent.com/6764957/196713790-cf2d3f47-0936-43e3-9760-9d8978a63cbf.png)\r\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/temporalio/write-errors-that-don-t-make-me-think-24hg","devToReactions":39,"devToReadingTime":4,"devToPublishedAt":"2020-11-19T19:33:35.885Z","devToViewsCount":374,"title":"Write Errors That Don't Make Me Think","published":true,"description":"How we plan to fail with Thoughtful Error Message Design at Temporal.","tags":"temporal, DX, developerexperience"},"title":"Write Errors That Don't Make Me Think","description":"How we plan to fail with Thoughtful Error Message Design at Temporal. ","category":"note","tags":["temporal","dx","developerexperience"],"slug":"write-errors-that-don-t-make-me-think-24hg","date":"2020-11-19T19:33:35.885Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/192","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/192/comments","title":"Write Errors That Don't Make Me Think","created_at":"2022-01-17T23:02:53Z","updated_at":"2022-10-19T14:04:55Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/192/reactions","total_count":1,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":1,"rocket":0,"eyes":0}}},{"title":"The Coding Career Handbook on the Coder Foundry YouTube","slug":"coder-foundry","tags":["Careers"],"venues":"Coder Foundry","date":"2020-11-19T00:00:00.000Z","url":"https://www.youtube.com/watch?v=bTtb2NF8Gds","description":"I was invited by the Coder Foundry guys to chat about learning in public, what it means to be a senior developer, why you should care where your code fits into the business, and why writing as a developer is so important.","category":"podcast"},{"title":"Trading Derivatives with VBA, No Code, JavaScript, Negotiation, and DevRel on the KeyCuts podcast","slug":"keycuts-podcast","tags":["Careers"],"venues":"KeyCuts","date":"2020-11-16T00:00:00.000Z","url":"https://www.thekeycuts.com/dear-analyst-50-walking-through-a-vba-script-for-trading-billions-of-dollars-worth-of-derivatives-with-shawn-wang/","description":"This is a different beat than my usual - it focuses on my Finance career where I traded interest rate derivatives with Excel and VBA! The show notes are really good too.","category":"podcast"},{"type":"blog","content":"\nWhen we close the history books on the 2020's, what will we say about the decade we have just begun?\n\nIt's obviously too early to say anything, but I'm cautiously optimistic. Much of 2020 seemed like a godforsaken hellscape driven by [the Coronavirus Recession](https://twitter.com/swyx/status/1236164959236653057). But November has led to some hope for reversal in both politics and healthcare. \n\nFirst, the obvious. If we see a successful vaccine rollout (there are [logistical hurdles](https://twitter.com/rjwthree/status/1327519593510948864?s=20)\n), lockdowns will end and the economy will roar back due to deferred spending. This is very similar to the recovery in the 1920's after World War I from 1914-1918 and the Spanish Flu pandemic from 1918-1920. **History doesn't repeat, but it rhymes.**\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/7skp4b2gs8erxps0xo06.png)\n\n## Five Optimistic Themes\n\nBut even apart from the short term rebound, I think there are longer term trends that offer some hope for the 2020's. Here are some ~~wishful thinking~~ themes I am focusing on for 2030:\n\n- **Self Driving Cars**: Yes, Uber has had well documented trouble [recently](https://www.theinformation.com/articles/infighting-busywork-missed-warnings-how-uber-wasted-2-5-billion-on-self-driving-cars). But I don't doubt that by 2030 Level 4 autonomous driving will be the majority of car miles. We could view manual driving as a hobby like we do horseriding today. The 124 traffic deaths per million that happen every year will plummet closer to 1. Parking becomes a thing of the past, freeing up real estate.\n- **Plant-Based Meat**: With even McDonald's testing [plant based burgers](https://www.wsj.com/articles/mcdonalds-sales-largely-recover-as-coronavirus-challenges-persist-11604923085) today, the potential for PBM to capture the popular consciousness on ethical and environmental grounds by 2030 is too great. I don't think we see full replacement but it will probably become a part of our regular diet.\n- **Climate Action**: The [Paris Agreement](https://www.nrdc.org/stories/paris-climate-agreement-everything-you-need-know) will probably fail to meet its already heavily moderated goals. But sincere, earnest action from business leaders like [Stripe](https://techcrunch.com/2020/10/28/stripe-climate-is-a-new-tool-to-let-stripe-customers-purchase-credits-towards-carbon-removal-efforts/) and [Microsoft](https://blogs.microsoft.com/blog/2020/01/16/microsoft-will-be-carbon-negative-by-2030/), cultural and religious leaders like [TED](https://countdown.ted.com/) and [the Vatican](https://insideclimatenews.org/news/06082020/climate-change-pope-francis) give hope. There will be more extreme climate disasters in 2030, but there will also be more [Greta Thunbergs](https://en.wikipedia.org/wiki/Greta_Thunberg) and [Climate Angels](https://climateangel.co/). My sister is 12 years younger than me, and every member of her generation I've met is keenly aware of the absolutely disastrous situation handed to them by their elders. Even if we don't manage to **halve** greenhouse gas emissions by 2030, we'll hopefully not *increase* it, and perhaps achieve some noticeable reduction by sheer collective social will. This is contingent on Asian and African countries managing their environmental impact alongside [their demographic boom](https://www.weforum.org/agenda/2016/09/the-countries-with-the-biggest-populations-from-1950-to-2060) (by 2100, India and Nigeria are projected to overtake China in population) and [renewables continuing their remarkable deflationary curve for these emerging countries](https://ourworldindata.org/cheap-renewables-growth).\n ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3gubjtitm7nuf7lkgout.png)\n- **Man on Mars**: While we wrestle with our Climate bill coming due, our Earth Insurance Plan needs to continue apace. The overall goal is a full Mars colony by 2050. SpaceX appears to be doing well and there is a game plan for all the intermediate steps:\n - 2022: First cargo to Mars\n - 2024: First crewed mission to Mars\n - This leaves plenty of leeway for the first human Mars landing by 2030\n\n Along the way, there will be a lot of space economy innovations as well, e.g. Virgin Galactic doubling the number of humans who have been to space.\n- **Universal Basic Income**: UBI has famous skeptics and famous believers and remains to be proven at large scale. Yet nearly every country turned to some form of financial support during 2020, and the policy probably helped in bad times. The remaining assessment to make is whether it *also* helps in good times. I suspect it does. I suspect multiple countries will try it in the 2020's. Primarily I view UBI as a form of [Progressive Tax regime](https://www.investopedia.com/ask/answers/042415/what-are-differences-between-regressive-proportional-and-progressive-taxes.asp) where the y-intercept just so happens to be negative. This isn't necessarily inflationary and offers the neediest among us a living wage, pulling people out of debt cycles and providing a cushion for risk takers.\n\n## Smaller trends\n\nMostly optimistic, but less certain and/or less impactful.\n\n- **Urban Primacy Reversal**: [Primate Cities](https://en.wikipedia.org/wiki/Primate_city#Urban_primacy) are dominant cities that are \"at least twice as large as the next largest city\". Fewer people will want to live in a crowded, dense city if they can work mostly remote, and effortlessly commute into the city as needed. I don't expect full urban->rural migration reversal, but I could certainly see more [Megalopolis](https://en.wikipedia.org/wiki/Megalopolis) urban patterns instead of urban primacy.\n- **Death of the Mediocre University**: The University bubble will pop as the stigma of online education goes away and the pedagogy and technology improve. The top tier will continue to do well, but there are no longer any reasons for mid/bottom tier colleges to exist. Education will experience the [Economics of Superstars](https://www.jstor.org/stable/1803469), to a far greater extent than already exists today. Accordingly the uniquely [American student debt crisis](https://twitter.com/Austen/status/1325489063231516673?s=20) will abate as society readjusts. The [Biden administration may make a symbolic first move](https://www.washingtonpost.com/opinions/2020/11/11/biden-could-forgive-10000-student-loan-debt-that-doesnt-address-bigger-issue/) on this.\n- **Generative AI**: Generative tech will continue to improve at an aggressive rate. Our expectations have adjusted significantly from 2019 when things like these were \"[too dangerous to release](https://slate.com/technology/2019/02/openai-gpt2-text-generating-algorithm-ai-dangerous.html)\". Generative tech will pass limited Turing tests, but mostly as a society we will be on high alert for fake news. I am optimistic about the potential for Generative AI to serve as a \"bicycle for the mind\" rather than a replacement or threat to humankind.\n - I do not think we reach any sort of \"Singularity\" by 2030 because AI is still shockingly inefficient compared to humans.\n\n## Doubts and Open Questions\n\n- Has [the American Century](https://en.wikipedia.org/wiki/American_Century) permanently ended or will there be a resurgence of **American soft power** in the 2020's? I want to believe that there will be a new hegemon in the 21st Century, but other countries are perhaps even more lacking in global leadership.\n- [Modern Monetary Theory](https://en.wikipedia.org/wiki/Modern_Monetary_Theory) appears to be consensus today but probably won't last the moment **the US Dollar loses reserve currency status** (if it does, Bitcoin probably wins). I don't think this happens by 2030 (due to the above) but I also don't think this has a good end in the final examination.\n- **Genetic Engineering**. 2020 awarded Jennifer Doudna and Emmanuelle Charpentier their inevitable [Nobel Prizes for CRISPR-Cas9](https://cen.acs.org/biological-chemistry/gene-editing/CRISPR-genome-editing-2020-Nobel/98/i39). I have a few smart friends who are doubters but the overall consensus seems to be that this is the start of a revolution. What are the implications? I have no idea at all and I really want to form an opinion here.\n- Society is still not dealing well with **Social Media**. The next generation will be brought up to deal well with it, but families are being torn apart and platforms and companies are being torn in to Red and Blue filter bubbles. When does the current Civil Cold War boil over into an Uncivil Hot one?\n- The \"Roaring 1920's\" wasn't just about the economy and technology. It was also about the arts and cultural revolutions. It marked the start of [the Jazz Age](https://en.wikipedia.org/wiki/Jazz_Age) and [the Harlem Renaissance](https://en.wikipedia.org/wiki/Harlem_Renaissance), the feminist movement empowered by worldwide [suffrage victory](https://en.wikipedia.org/wiki/Women%27s_suffrage), but also saw the rise of [the 2nd Klan](https://en.wikipedia.org/wiki/Ku_Klux_Klan). What new music, movie, arts, and political cultures and countercultures arise in the 2020's? I hold out mild hope for a return in originality - if the 2010's were marked by tiresome remakes and sequels in movies, the 2020's could register our hunger for original material inspired by the likes of *Hamilton* and [financed by the new masters of Hollywood](https://www.forbes.com/sites/sergeiklebnikov/2020/05/22/streaming-wars-continue-heres-how-much-netflix-amazon-disney-and-their-rivals-are-spending-on-new-content/?sh=362e705e623b). The \"Creator\" or [\"Passion\" Economy](https://a16z.com/2019/10/08/passion-economy/) offers some hope for a revival in independent, niche, original creation, though I am not so bullish that it will have impact beyond the socioeconomic elites (because it is so hard to do, as I can attest).\n\nThis is less me gazing into a Crystal Ball, and more me writing a letter to my future self in 2030. I hope I get at least some of these right, because the world will be in a more optimistic place than in 2020, I think.\n\n## Other 10 year perspectives I am enjoying\n\n- [\"Zoom towns\"](https://levels.io/the-greatest-migration-2/) - when Remote goes mainstream\n- [Techno-optimism in the 2020s](https://noahpinion.substack.com/p/techno-optimism-for-the-2020s) by Noah Smith\n- [Biology's \"AI moment](https://www.oreilly.com/radar/the-end-of-silicon-valley-as-we-know-it/) by Tim O'Reilly\n- [HN on Renewables](https://news.ycombinator.com/item?id=25265819)\n- [Chris Herd trends](https://twitter.com/chris_herd/status/1334842553561198593?s=20)\n- [Eli Dorado on space and biotech](https://elidourado.com/blog/notes-on-technology-2020s/) ","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-roaring-2020-s-48kp","devToReactions":29,"devToReadingTime":7,"devToPublishedAt":"2020-11-14T13:25:42.016Z","devToViewsCount":417,"title":"The Roaring 2020's","published":true,"description":"Five themes I am optimistic about for the next decade - and more open questions I have no idea about.","tags":"Predictions","slug":"roaring-2020s","canonical_url":"https://www.swyx.io/roaring-2020s","cover_image":"https://earthsky.org/upl/2019/12/roaring-twenties-trailer-title-still-1-300x225.jpg"},"title":"The Roaring 2020's","description":"Five themes I am optimistic about for the next decade - and more open questions I have no idea about. ","category":"note","tags":["predictions"],"image":"https://earthsky.org/upl/2019/12/roaring-twenties-trailer-title-still-1-300x225.jpg","canonical":"https://www.swyx.io/roaring-2020s","slug":"roaring-2020s","date":"2020-11-14T13:25:42.016Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/193","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/193/comments","title":"The Roaring 2020's","created_at":"2022-01-17T23:13:31Z","updated_at":"2022-06-18T17:49:00Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/193/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n> 2021 Update: I talked over this blogpost with [Adam and Jerod on the Changelog podcast](https://changelog.com/podcast/467) and [Beyang on the Sourcegraph podcast](https://about.sourcegraph.com/podcast/swyx/)!\n\nThe \"API Economy\" is a popular term among VC's and tech media, but I find it curiously unappreciated by developers. I think this is partly because developers know this revolution by other names (\"SaaS\" or \"Devtools\") and partly because the term is *more* popular among nontechnical audiences. **This causes developers to severely underestimate the importance of the API Economy to their own careers.**\n\nIf you're a developer, here's my proposition to you: **The API Economy is developers reshaping the world in their image**. It is both a great opportunity for builders and a threat to people who cannot stay \"Above the API\".\n\n## API Economy Examples\n\nLet's start by motivating the discussion with examples:\n\n- **AWS**: [the API for computer infrastructure](https://www.swyx.io/writing/hello-aws/)\n- **Stripe/Shopify**: the API for taking card payments\n- **Plaid**: the API for connecting to bank accounts\n- **Twilio/Sendgrid**: the API for sending text, email, etc \n- **Lob**: the API for printing and sending physical mail\n- **Okta/Auth0**: the API for authentication\n- **Checkr**: the API for background checks\n- **Shippo**: the API for shipping physical goods\n- **Flexport**: the API for freight\n- **[Stedi](https://www.stedi.com/)**: the API for B2B EDI transactions\n\nThe most influential chart for me has been [the Bessemer chart](https://www.bvp.com/atlas/state-of-the-cloud-2020/) matching domains to logos in the API Economy: \n\n![API economy](https://d33wubrfki0l68.cloudfront.net/cb89c14b80407b4313bb0de2e59fde0be1db91db/b5fcc/assets/media/atlas-soc-25-prediction5.jpg)\n\nThere's no definition of API Economy everyone agrees on. Even a16z, one of the biggest API Economy investors, don't have a single blogpost on their site (beyond [a podcast episode](https://a16z.com/2018/03/13/api-economy-why-what-how/)) dedicated to the idea. However you'll find a [lot](https://growthpoint.com/growthpoint/announcing-growthpoints-devops-startup-landscape-map/) [more](http://alanquayle.com/2019/12/cxtech-market-sizing-and-landscape/) [attempts](https://www.programmableweb.com/news/over-2000-apis-added-2011-social-telephony-open-government/2012/01/04) at [landscape](https://catalyst.com/research_item/the-api-economy-market-map/) [charts](https://medium.com/canvas-ventures/the-third-party-api-economy-891b2a774fa5) by aspiring thoughtleaders, of varying quality with random crap thrown in depending on their point of view.\n\n## My Definition\n\nThe API Economy describes how business functions are increasingly being offered as programmatic APIs for developers to use. It is the [penultimate](https://www.swyx.io/writing/no-code-lie/) result of [Software Eating the World](https://a16z.com/2011/08/20/why-software-is-eating-the-world/). It overlaps strongly with the SaaS business model trend, but doesn't fully circumscribe it, because customers typically pay by their usage of the API (instead of, say, per-seat).\n\nIf the [only two ways to make money in business](https://hbr.org/2014/06/how-to-succeed-in-business-by-bundling-and-unbundling) are bundling and unbundling, then the API Economy represents the developer-powered version of [the Great Unbundling](https://stratechery.com/2017/the-great-unbundling/). In the old economy, we had to decide if an idea is a [Product or a Feature](https://jtbd.info/feature-vs-product-42bf2dad2764). Even [Steve Jobs thought this way](https://techcrunch.com/2012/01/23/dld-2012-drew-houston-yes-steve-jobs-called-dropbox-a-feature/). Today we know that we can [offer features as products](https://twitter.com/swyx/status/1326509989347921925). As industries mature, they become more horizontal ([I wrote about Horizontal vs Vertical businesses in my book](https://www.swyx.io/dev-guide-to-tech-strategy/#horizontal-vs-vertical)). Tech is maturing, and every non-core feature is being extracted into its own horizontal platform.\n\nAPIs (Application Programming Interfaces) offer a clear contract of how a service can be programmatically operated by its users. It is often used in context of a programming language or framework, but equivalently an API Economy company offers APIs to its customers, who then pay per use.\n\n## Implications\n\nBy far the most important implication of the API Economy is how it empowers developers to build full fledged products faster. \n\n### Speed\n\nImagine the steps it used to take to set up an online-to-offline greeting card business like [Postable](https://www.postable.com/cards):\n\n- Rent a garage\n- Buy server equipment\n- Figure out how to take payments online\n- **Write greeting card generation software**\n- Hire humans to print and mail greeting cards\n\nNotice that only one of those things had anything to do with your core differentiator. With the API Economy:\n\n- Pick your server/serverless infrastructure from AWS\n- Sign up for Stripe\n- **Write greeting card generation software**\n- Sign up for Lob\n\nYour time to market goes from months to days.\n\nIn economics terms what we're really talking about here is **turning fixed costs to variable costs** which makes sense for a startup getting off the ground. **Rent, don't buy**.\n\n### Cost\n\nHowever, it also makes sense for mature businesses, because centralizing infrastructure expenses creates incredible [economies of scale](https://www.investopedia.com/terms/e/economiesofscale.asp). I like saying that I don't need to spend any of my dev or founder time on building search capability, I can invoke the PhD-level expertise of Algolia or Elastic with a single API call.\n\nThat said, paid API pricing models can start to be extremely costly at scale. Most large customers don't pay the listed API retail price for their scale, engaging in behind the scenes negotiations instead. Or you could decide that it would be cheaper to build the capability in-house. You have that power.\n\nThe good news is you didn't *need* to build capability earlier when you didn't have the information or the money, thanks to the API Economy. And because it is by definition programmatic, you are likely doing far more with fewer people on your payroll.\n\n### Scalability\n\nThere's also the more subtle point of incredible scalability, both in terms of spikes (scale up an order of magnitude in seconds, not months) and in sustained rates of growth (grow 300% a year with no change in code, no distracting purchasing process).\n\n### Documentation\n\nThe **clear contract** of APIs is important. It's kind of like the difference between having listed prices and \"Call Us\" for something you want to buy. Eliminating the extra friction reduces wasted time on both ends. \n\nThe contracts between companies tends to be much clearer than inside companies. Imagine having a \"Search Department\" with a whole team of devs there, compared to using a \"Search API\" from a dedicated company. It is likely that the API is going to be far better documented, with a clearer (and financially incentivized) [SLA](https://www.cio.com/article/2438284/outsourcing-sla-definitions-and-solutions.html). \n\n> Of course, well run companies could theoretically have internal contracts as solid as external ones, but this is very rare.\n\n### Funding Open Source\n\nA minor point, but an important one to make - Offering hosted open source as SaaS APIs is pretty much one of only two proven ways to fund development of open source (or at least open core) projects (e.g. MongoDB) at scale.\n\n## Downsides\n\nHaving a daisy chain of dependencies for your business has two obvious downsides: \n\n- your business goes down the moment any of your dependencies go down (aka your uptime is a `min()` function of all their downtimes)\n- your billing and account book-keeping is a mess\n\n[Matt Mullenweg has recently gone on record raising these criticisms of the Jamstack](https://thenewstack.io/wordpress-co-founder-matt-mullenweg-is-not-a-fan-of-jamstack/). There are, of course, [counterarguments](https://www.netlify.com/blog/2020/09/15/on-mullenweg-and-the-jamstack-regression-or-future/).\n\nBut by far I think the most underappreciated downside isn't business, it's **societal**.\n\n## Above the API, Below the API\n\nThe insight that APIs are easier and more straightforward to deal with than humans isn't just a matter of office politics. \n\nIt's also quite literally tearing our society apart.\n\nPeter Reinhardt (CEO of Segment) once pointed out that the API Economy is bifurcating society into [Above the API and Below the API](https://rein.pk/replacing-middle-management-with-apis) jobs. \n\n- **Above the API**: You tell machines what to do\n- **Below the API**: Machines tell you what to do\n\nThe thesis being that those Above the API will amass economic power at a far greater rate than those Below the API.\n\nThe endgame implication is that we only use humans to do what machines can't for now... and eventually replace them when machines can do it. \n\n![https://mb21.github.io/blog/assets/2015-05-17-Jobs-below-the-API/above-and-below-the-api-jobs.png](https://mb21.github.io/blog/assets/2015-05-17-Jobs-below-the-API/above-and-below-the-api-jobs.png) \n\nIf you view Uber as an API (Press button, get on car, get off car), then the drivers driving Ubers are quite literally training their self driving robot replacements.\n\nLook, obviously the analogy isn't perfect and you can poke holes at it with counterexamples. But it is probably directionally correct.\n\nOnly 0.65% of the global population are developers (~50m of 7.5billion), people who can bend APIs to their will. We probably can't realistically 100x the number of developers. What happens to those who fall behind the API?\n\nFirst, the obvious. People who can stay **Above the Kanban Board** will fare better than those who are **Below the Kanban Board**. Being able to tell developers what to do has always been more effective than being a developer that gets told what to do. Figuring out how manage developers effectively to achieve business goals grants you **unlimited power** in the API economy.\n\nFor the rest, there is the GUI Economy.\n\n## The GUI Economy\n\nHundreds of millions of people use Excel. What if all the APIs we just talked about were accessible to regular folks, or \"Citizen Developers\"? \n\nWelcome to the \"No Code\" movement. [I wrote about this last year on the Webflow blog.](https://webflow.com/blog/no-code-is-a-lie)\n\n\n## Why I Had To Write This\n\nJust look at the Google search results for \"API Economy\":\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/n4r2ytkr2tmputs58xvi.png)\n\nEntirely unappealing to developers. I know because I've spent hours trawling through these shitty results that have been SEO-ed to death by content marketers, trying to find a halfway decent definition to link to and [failing](https://jamstack.org/glossary/api-economy/). So this is my attempt at making one I'm happy pointing people to.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/the-light-and-dark-side-of-the-api-economy-2m2","devToReactions":191,"devToReadingTime":7,"devToPublishedAt":"2020-11-11T16:07:36.761Z","devToViewsCount":5605,"title":"The Light and Dark Side of the API Economy","published":true,"description":"The 'API Economy' is a popular term for VC's and tech media, however Developers seem ironically out of the loop despite their central importance to the whole story. Here's my explanation, together with a dash of economics and social implications.","tags":"Tech, Economics","slug":"api-economy","canonical_url":"https://www.swyx.io/api-economy","cover_image":"https://d33wubrfki0l68.cloudfront.net/cb89c14b80407b4313bb0de2e59fde0be1db91db/b5fcc/assets/media/atlas-soc-25-prediction5.jpg"},"title":"The Light and Dark Side of the API Economy","description":"The 'API Economy' is a popular term for VC's and tech media, however Developers seem ironically out of the loop despite their central importance to the whole story. Here's my explanation, together with a dash of economics and social implications. ","category":"note","tags":["tech","economics"],"image":"https://d33wubrfki0l68.cloudfront.net/cb89c14b80407b4313bb0de2e59fde0be1db91db/b5fcc/assets/media/atlas-soc-25-prediction5.jpg","canonical":"https://www.swyx.io/api-economy","slug":"api-economy","date":"2020-11-11T16:07:36.761Z","readingTime":"7 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/194","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/194/comments","title":"The Light and Dark Side of the API Economy","created_at":"2022-01-17T23:13:34Z","updated_at":"2022-06-18T17:48:29Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/194/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"What's New in React on React Roundup","slug":"reactroundup-podcast-2","tags":["React"],"venues":"React Roundup","date":"2020-11-11T00:00:00.000Z","url":"https://devchat.tv/react-round-up/rru-124-whats-new-in-react-with-shawn-wang/","description":"In this episode of React Round Up, we talked with Shawn Wang, a prolific React author, speaker and teacher, about the future of React. We discussed what’s new in React Core, the React routing world, React DevTools (webpack, rollup, parcel, etc), CSS, and a whole lot more.","category":"podcast"},{"type":"blog","content":"\n**Latest Release at Time of Writing:** V1.2.1\n\nHey Temporal community, it's been a long week with *ahem* a lot of other things going on in real life, but work has continued apace on Temporal.\n\n# Update November 6, 2020\n\nIt's been a while since we published one of these updates, but in our defence, we were busy: \n\n- [Announcing Temporal v1.0](https://docs.temporal.io/blog/temporal-v1-announcement), our first production-ready release\n- [Announcing our Seed and Series A rounds](https://docs.temporal.io/blog/funding-announcement) led by Amplify and Sequoia\n- Shipping [our new Landing Page](http://temporal.io/) (ft. a well received [2 minute explainer video](https://www.youtube.com/watch?v=f-18XztyN6c&feature=emb_title)) and [three case studies with Box, Checkr, and Coinbase](https://docs.temporal.io/blog/tags/case-study) (fun thing we noticed, they all have [blue logos](https://www.logomaker.com/blog/2017/09/27/blue-logos/))\n- [PostgreSQL 9.6 support](https://github.com/temporalio/temporal/releases/tag/v1.2.1) (`v1.1.x` included schema changes for our MySQL and Cassandra support - see [release notes](https://github.com/temporalio/temporal/releases/tag/v1.1.1) for migration tools)\n\nThe team has grown some (including me!) and [we're absolutely hiring](https://www.temporal.io/careers/)!\n\n## Authentication is Coming\n\n### TL;DR\n\nWe're working on Authentication for Temporal Web, and are looking for beta testers. Please <a href=\"mailto:swyx@temporal.io\">get in touch at `swyx@temporal.io`</a> if you're interested in helping to test!\n\n### Context\n\nTemporal is a highly critical system for many businesses, so security is paramount. \nCommunication is already encrypted with [TLS](https://docs.temporal.io/docs/configure-temporal-server/#tls), \nand you can put Temporal behind a reverse proxy. However, \none of our longest standing requests has been for an authentication/authorization layer for Temporal. \nThis is what we are tackling first, \nas it is also necessary for [the upcoming Temporal Cloud](https://temporal.us17.list-manage.com/subscribe/post?u=2334a0f23e55fd1840613755d&id=bbbbd4709f) service offering. \n\nIt's not ready for release yet, but we'd like to share how we're shipping this major feature. We basically followed the classic converge/diverge pattern:\n\n<img src=\"https://user-images.githubusercontent.com/6764957/98401393-92855580-20a0-11eb-8098-0f331163c87a.png\" align=\"center\" />\n\n- **Diverge**:\n - **Collecting Requirements**: [Ryland](https://twitter.com/taillogs) had been meticulously collecting feedback from prospective customers for the past 6 months. Having this \"CRM\" (entirely done in Notion) ensured that we started with a strong idea of what our customers' most common requirements would be. For example, we realized that many companies use SAML and LDAP for authentication, but virtually everyone uses the OAuth/OpenID Connect (OIDC) open standard ([more info on OAuth and OIDC here](https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc)). We also wanted a solution that would work for both the self-hosted open-source version of Temporal, and for the coming Temporal Cloud offering.\n - **Comparable Research**: Sometimes customers don't tell you what they want. It can help to supplement customer research with comparable products. This helps surface ideas and perspectives we hadn't considered. We did a broad search of peer tools. This offered an even broader range of options, including the controversial \"[The Prometheus project takes the stance that server side security features are outside its scope]( https://www.robustperception.io/prometheus-security-authentication-authorization-and-encryption)\". Our search also showed that a surprising number of tools offered Certificate Authority auth. I was quite impressed by [the wide range of auth options offered by Grafana](https://grafana.com/docs/grafana/latest/auth/).\n- **Converge**:\n - **Narrowing Scope**: One of the most impactful things you can do to ship faster is to say no as much as possible during the design phase. \n - [Maxim](https://www.linkedin.com/in/fateev/) suggested offering authentication within the `tctl` CLI. However it would have involved crossing language and client-server boundaries that would have added undue complexity. \n - [Sergey](https://dev.to/temporalio/why-i-joined-temporal-19dg) had the retrospectively brilliant insight that most customers would demand OIDC Single Sign-On eventually. If we built our own username/password solution, it would be a lot of effort and it wouldn't be used by enterprises anyway. We decided that we would go all in on OIDC Single Sign-On. \n - Finally, we saw that Grafana had a wide range of OAuth options because they were incrementally adopted over the span of 4 years. We, as a greenfield solution, had the opportunity to leapfrog all that.\n - **Researching Implementation**: Temporal Web is in Node.js, and the dominant authentication library has been [Passport.js](http://www.passportjs.org/) for years. After [confirming nothing had changed](https://twitter.com/swyx/status/1315754745412284416), we went with the obvious choice. In my research I had figured that we would pursue [Okta](http://www.passportjs.org/packages/passport-okta-oauth) and [Auth0](http://www.passportjs.org/packages/passport-auth0) integration first. But [Ruslan](https://www.linkedin.com/in/feedmeapples) found a [node-openid-client](https://github.com/panva/node-openid-client) that would fit our generic OAuth requirement found :tada:\n\nThe process we envision will be as simple as providing your OAuth identity provider information in a config file (currently at `/server/config.yml`, both the location and the schema of this config are subject to change):\n\n```yaml\nauth:\n enabled: true\n providers:\n # example provider config\n\t - label: 'googleoidc'\n\t type: oidc\n\t issuer: https://accounts.google.com\n\t client_id: xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com\n\t client_secret: xxxxxxxxxxxxxxxxxxxxxxxx\n\t callback_base_uri: http://localhost:8088\n```\n\nIn future we may support multiple auth providers, but we expect the vast majority of users to just use one.\n\nWe are currently in the implementation phase, and just did our first internal demo of the full authentication process this week. \n\n![temporal1](https://user-images.githubusercontent.com/6764957/98414812-0599c680-20b7-11eb-8d95-aea7ec64e230.gif)\n\nIt felt slightly surreal to be the first people to \"log in to Temporal\", though that is no exaggeration. A normal process might also have involved some UI design to ensure a delightful and accessible frontend experience. However we are holding out for a possible total design revamp sometime in the near future.\n\n### Seeking Beta Testers!\n\nIf you have been waiting for this authentication feature, we'd love to send you an early preview of this for testing and feedback. Please <a href=\"mailto:swyx@temporal.io\">email me at `swyx@temporal.io`</a>!\n\n## Conclusion\n\nWe are working hard to bring you authentication and other top feature requests you are asking for. If you'd like to receive updates on Temporal Cloud, do make sure to [sign up for our mailing list](https://temporal.us17.list-manage.com/subscribe/post?u=2334a0f23e55fd1840613755d&id=bbbbd4709f).\n\nThat's it from the Temporal side, have a great weekend everyone! As always, feel free to reach out with questions, comments or critical feedback via email, Slack or our community forum.\n\nEmail: [swyx@temporal.io](mailto:swyx@temporal.io)\n\nSlack: [temporalio.slack.com](http://temporalio.slack.com/)\n\nForum: [https://community.temporal.io/](https://community.temporal.io/ \"https://community.temporal.io/\")","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/temporal-transparency-update-9-auth-is-coming-2nok","devToReactions":5,"devToReadingTime":5,"devToPublishedAt":"2020-11-07T03:04:37.872Z","devToViewsCount":95,"title":"Temporal Transparency Update","published":true,"description":"Our 9th transparency update describing how we are shipping the upcoming Authentication feature","tags":"temporal, authentication","canonical_url":"https://docs.temporal.io/blog/temporal-transparency-9/"},"title":"Temporal Transparency Update","description":"Our 9th transparency update describing how we are shipping the upcoming Authentication feature ","category":"note","tags":["temporal","authentication"],"canonical":"https://docs.temporal.io/blog/temporal-transparency-9/","slug":"temporal-transparency-update-9-auth-is-coming-2nok","date":"2020-11-07T03:04:37.872Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/195","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/195/comments","title":"Temporal Transparency Update #9: Auth is Coming","created_at":"2022-01-17T23:13:36Z","updated_at":"2022-06-18T17:48:30Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/195/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nIn Hans Christen Andersen's [classic tale](https://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes), two swindlers trick an Emperor by saying their clothes that are invisible to those who are stupid or incompetent. Everybody sees the Emperor is naked, but nobody says anything, until a child blurts out the simple fact that the emperor is wearing nothing at all. Then the silence is broken and everyone realizes that everyone else was seeing what they were seeing.\n\n**There are a lot of Naked Emperors in Tech.**\n\nMostly, these take the form of widely repeated beliefs that are oversimplified (or at least, no longer true). Sometimes these are factual statements that turn out factually wrong. Sometimes these are opinions overstated as fact. Sometimes the cause is [schlep blindness](http://www.paulgraham.com/schlep.html). Sometimes these are [implicit beliefs](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/) - unstated, unconscious, but designed into our products anyway. What makes them Naked Emperors is just somebody visibly pointing out nakedness, and then the lie being retrospectively obvious all along.\n\nHere is a short list I have, with their respective bullshit calls:\n\n- **Asking Five Why's** (aka [the Toyota method](https://en.wikipedia.org/wiki/Five_whys)): Complex failures have multiple causes that are [each necessary, but only jointly sufficient](https://www.kitchensoap.com/2012/02/10/each-necessary-but-only-jointly-sufficient/).\n- **\"There are no stupid questions\"**: Some questions are certainly better than others, and some questions are so bad they beg terrible answers. Better to make it OK to ask stupid questions than to deny their very existence. Allow the answerer to question the question rather than waste time on a flawed premise.\n- **The Golden Rule**: is clearly broken for vulnerable or picky people. [The Platinum Rule](https://www.swyx.io/platinum-rule/) is a higher bar. \n- **[Regret Minimization Framework](https://medium.com/@alyjuma/the-regret-minimization-framework-how-jeff-bezos-made-decisions-4d5a86deaf24)**: Leads to constantly taking the highest risk option, ignoring [risk of ruin](https://en.wikipedia.org/wiki/Risk_of_ruin). The biggest tell of uncritical Bezos fans is how confidently they quote him here based on his DE Shaw anecdote (the same [narrative fallacy](https://jacklimpert.com/2018/04/jeff-bezos-talks-about-writing-and-the-narrative-fallacy/) he despises)\n- \"**[Ideas are worthless, execution is everything](https://twitter.com/APompliano/status/1025137320515850247?s=20)**\": Surely it is a [mix of both](https://twitter.com/hnshah/status/528603634125533184?s=20).\n- \"**Accessibility is not optional**\": Accessibility isn't a binary either-you-have-it-or-you-don't state. Accessibility has a cost. Accessibility experts and libraries that market accessibility don't agree on or [audit](https://twitter.com/devongovett/status/1309346046737227776?s=20) details. That doesn't excuse us from making sincere effort, but let's stop pretending that Accessibility is easily accessible.\n- \"**[Multicloud is a dumb idea](https://www.lastweekinaws.com/blog/multi-cloud-is-the-worst-practice/)**\": [AWS hearts multi-cloud](https://cloudirregular.substack.com/p/aws-hearts-multi-cloud-its-gonna). [Mitchell Hashimoto on Why Multicloud](https://www.reddit.com/r/devops/comments/91afzz/why_multicloud/).\n- \"**You should use React for everything/Gatsby is the best static site generator**\": [It's](https://twitter.com/swyx/status/1313140876894375936?s=20) [very](https://twitter.com/Jayphen/status/1324402985041088514?s=20) [much](https://frontendfirst.fm/episodes/the-convergence-of-frontend-and-backend-frameworks) [not](https://css-tricks.com/comparing-static-site-generator-build-times/). Most devs should at minimum use Preact over React for Sites, but [both offer far less than Svelte](https://dev.to/swyx/svelte-for-sites-react-for-apps-2o8h).\n- \"**Everything is an Infinite Game**\": [No, not everything](https://twitter.com/swyx/status/1039326610867081216?s=20). Many careers hinge on a single \"[Big Break](https://twitter.com/forrestbrazeal/status/1254151795221434369?s=20)\" (arguably the leadup and the follow through is an infinite game, but don't tell me there aren't important Finite Games within the Infinite Game)\n\nWhat other Naked Emperors are parading around out there, too naked for me to even see?\n\n## Additions from the future\n\n- Julian Shapiro: https://twitter.com/Julian/status/1348001394104537089?s=20","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/naked-emperors-in-tech-1iod","devToReactions":28,"devToReadingTime":3,"devToPublishedAt":"2020-11-06T13:01:55.777Z","devToViewsCount":363,"title":"Naked Emperors in Tech","published":true,"description":"Some things we often repeat as truth just aren't. We should call bullshit more often.","tags":"Reflections, Tech","slug":"naked-emperors","canonical_url":"https://www.swyx.io/naked-emperors","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/a7lx48p078zyz6trytbr.jpg"},"title":"Naked Emperors in Tech","description":"Some things we often repeat as truth just aren't. We should call bullshit more often. ","category":"note","tags":["reflections","tech"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/a7lx48p078zyz6trytbr.jpg","canonical":"https://www.swyx.io/naked-emperors","slug":"naked-emperors","date":"2020-11-06T13:01:55.777Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/196","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/196/comments","title":"Naked Emperors in Tech","created_at":"2022-01-17T23:13:38Z","updated_at":"2022-06-18T17:48:30Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/196/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Intro to Flutter and AWS Amplify","slug":"intro-to-aws-amplify-and-flutter","categories":["AWS"],"description":"A General intro to AWS Amplify and Flutter on the Amplify with Friends show on the official AWS twitch stream","instances":[{"venue":"AWS Twitch","date":"2020-11-06","video":"https://www.youtube.com/watch?v=AvTV1tWLv_s"}],"category":"talk","date":"2020-11-06T00:00:00.000Z"},{"type":"blog","content":"\n\n[Slobodan Stojanovic](https://twitter.com/slobodan_/status/1321569045003513856?s=20) is an AWS Serverless Hero and released a well received, 30 minute talk on AWS AppSync today at ServerlessDays Virtual. I've given a (in my opinion) bad Serverless GraphQL talk before, I wanted to take notes on what a good one looked like.\n\nHere is his talk (starts 1h 54mins in):\n\n{% youtube 9oYS_5eL610 %}\n\nHere are his [slides](https://speakerdeck.com/slobodan/the-power-of-serverless-graphql-with-appsync)\n\nAnd here are my notes of his talk.\n\n## Notes on AppSync\n\n**Your requirements**:\n\n- short deadline\n- scalable\n- real-time\n\n### Why GraphQL\n\nStandard origin story from Facebook/FQL. Why should you care if you are not Facebook?\n\nIf you have...\n\n- Clients for multiple platforms (eg Web and Mobile) have different data requirements\n- Backend serves data to clients from different sources\n- Complex state and caching mgmt for both front/backend\n- Slow mobile pages caused by HTTP waterfalls\n\nThen you will benefit from GraphQL's properties:\n\n- Defines a data shape\n- Hierarchichal\n- Strongly Typed\n- Is just a protocol, doesnt prescribe storage\n- Introspective\n- Version free\n- **Supports Queries, Mutations, Subscriptions**\n\n### Why Serverless\n\nSo you dont need to manually scale/distribute the individual pieces of your GraphQL-gated backend.\n\n### Why AppSync for Serverless GraphQL\n\nYou *could* write a GraphQL backend inside of API Gateway + AWS Lambda function... but it'd be a lot easier using AppSync.\n\nThe workflow then becomes: \n\n- Define GraphQL Schema\n- Automatically Provision a DynamoDB data source and connect resolvers\n- Write gql queries and mutations\n- Connect with Frontend\n\n### Why AWS Amplify with AWS AppSync\n\nYou *could* set up AppSync via the [Guided Schema Wizard](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) on the AWS Web Console... but you should use Amplify, CloudFormation or CDK for [IaC](https://en.wikipedia.org/wiki/Infrastructure_as_code).\n\nAmplify reduces all the setup to (at a high level) 3 commands:\n\n```bash\n$ amplify init\n$ amplify add api\n$ amplify push\n```\n\n[Amplify CLI](https://docs.amplify.aws/cli/graphql-transformer/codegen) also automatically generates queries, mutations, subscriptions, and types for the frontend app to consume!\n\nYou can always start with Amplify then move to CloudFormation or CDK:\n\n```ts\nexport class AppsyncCdkAppStack extends cdk.Stack {\n constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {\n super(scope, id, props);\n\n // Creates the AppSync API\n const api = new appsync.GraphqlApi(this, 'Api', {\n name: 'cdk-notes-appsync-api',\n schema: appsync.Schema.fromAsset('graphql/schema.graphql'),\n });\n\n // Prints out the AppSync GraphQL endpoint to the terminal\n new cdk.CfnOutput(this, \"GraphQLAPIURL\", {\n value: api.graphqlUrl\n });\n }\n} \n```\n\n### Realtime Subscriptions\n\nAppSync lets you specify which part of your data should be available in a real-time manner using [GraphQL Subscriptions](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html).\n\n```graphql\ntype Subscription {\n addedPost: Post\n @aws_subscribe(mutations: [\"addPost\"])\n updatedPost: Post\n @aws_subscribe(mutations: [\"updatePost\"])\n deletedPost: Post\n @aws_subscribe(mutations: [\"deletePost\"])\n}\n```\n\nThese then have to be scalable. [AppSync is load tested up to 10 million active websockets](https://aws.amazon.com/blogs/mobile/appsync-realtime/):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/wqyswzajywq4wndgbbmb.png)\n\n### Search\n\n[AppSync supports Amazon Elasticsearch](https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-elasticsearch-resolvers.html). The GraphQL operations support simple lookups, complex queries and mappings, full text searches, fuzzy/keyword searches, even [geo lookups](https://medium.com/@andrewgriffiths/build-a-geosearch-graphql-api-using-aws-appsync-elasticsearch-5d7f0f47f0b3).\n\n### Proxying an Existing Backend\n\nYou can set up [AppSync with AWS Lambda Resolvers](https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-lambda-resolvers.html) so you don't have to do a total rewrite!\n\n### Security: Authorization, Roles, Permissions\n\n4 kinds of authz:\n\n- [API_KEY](https://docs.aws.amazon.com/appsync/latest/devguide/security.html#api-key-authorization) for unauthenticated throttling of APIs, mostly used in development or for public APIs. Manually rotate API keys every 365 days.\n- [AWS_IAM](https://docs.aws.amazon.com/appsync/latest/devguide/security.html#aws-iam-authorization)\n- [OPENID_CONNECT](https://docs.aws.amazon.com/appsync/latest/devguide/security.html#openid-connect-authorization): enforces OpenID Connect (OIDC) tokens provided by an OIDC-compliant service. \n- [AMAZON_COGNITO_USER_POOLS](https://docs.aws.amazon.com/appsync/latest/devguide/security.html#amazon-cognito-user-pools-authorization): enforces OIDC tokens provided by Amazon Cognito User Pools.\n\nThis last one provides a lot of group based controls to make your application multi-tenant. You can finetune which fields and operations are available to various groups of users:\n\n```graphql\ntype Query {\n posts:[Post!]!\n @aws_auth(cognito_groups: [\"Bloggers\", \"Readers\"])\n}\n\ntype Mutation {\n addPost(id:ID!, title:String!):Post!\n @aws_auth(cognito_groups: [\"Bloggers\"])\n}\n```\n\nFor even more finegrained permissions you can use:\n\n- [Resolver Mapping Templates](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-overview.html) (currently written in [VTL](https://velocity.apache.org/engine/1.7/user-guide.html) or [Direct Lambda Resolvers](https://aws.amazon.com/blogs/mobile/appsync-direct-lambda/), though other options are on their way.)\n- Reusable checks (eg authorization checks) can be composed using [Pipeline resolvers](https://docs.aws.amazon.com/appsync/latest/devguide/pipeline-resolvers.html)\n\n### Caching and Offline Data Sync\n\n[I've written about this one before.](https://www.swyx.io/svelte-amplify-datastore/)\n\n### Testing\n\nSlobodan says this is a topic for a future talk... but `amplify mock` offers basic [local mocking](https://aws.amazon.com/blogs/mobile/amplify-framework-local-mocking/).\n\n### Event Sourcing/CQRS\n\nWhen you have to do `client -> mutation -> event storage -> eventbridge -> business logic -> subscription -> back to client`, with another process for OLAP workloads. AppSync can handle all this.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/e8t3cebuueo4bysspasz.png)\n\n## His Summary\n\n- GraphQL makes your frontend and backend connection effortless\n- AppSync makes GraphQL management effortless\n- Serverless GraphQL is a great option.\n\n## Sketch Notes\n\nI love some sketch notes! [The Serverless Days folks did some](https://twitter.com/ServerlessdaysV/status/1321520472987631616?s=20):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/56f9qy0gfh8ua5fz55nh.jpeg)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/notes-on-serverless-graphql-with-aws-appsync-620","devToReactions":37,"devToReadingTime":4,"devToPublishedAt":"2020-10-28T23:28:50.265Z","devToViewsCount":368,"title":"Notes on Serverless GraphQL with AWS AppSync","published":true,"description":"My Notes on Slobodan Stojanovic's Serverless GraphQL with AppSync talk","tags":"AWS","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/hbrezfd9jv20bv0pdvey.png","canonical_url":"https://www.swyx.io/serverless-graphql-appsync","slug":"serverless-graphql-appsync"},"title":"Notes on Serverless GraphQL with AWS AppSync","description":"My Notes on Slobodan Stojanovic's Serverless GraphQL with AppSync talk ","category":"note","tags":["aws"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/hbrezfd9jv20bv0pdvey.png","canonical":"https://www.swyx.io/serverless-graphql-appsync","slug":"serverless-graphql-appsync","date":"2020-10-28T23:28:50.265Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/197","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/197/comments","title":"Notes on Serverless GraphQL with AWS AppSync","created_at":"2022-01-17T23:13:40Z","updated_at":"2022-06-18T17:48:30Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/197/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nI have [noticed](https://twitter.com/swyx/status/1306392344837591041?s=20) that startups with the fastest growing revenue actively \"**find money**\" for their customers. I think this is something people vaguely understand, but as far as I can tell, nobody's really named it or defined it. Strange, for something so important and lucrative.\n\nI've come to call them \"**Found-Money Startups**\".\n\n## Definition\n\n- **Found-Money startups only make money if they directly increase the profit of their customers.** This can be through cost saving, but more often than not this comes through increasing revenue.\n- **Found-Money startups should be plug and play**. I should not have to significantly change the way I work or rewrite anything in order to benefit from them. Literally `npm install free-money` is the ideal.\n- **Found-Money startups should offer scalable money**. It's great if I get back $10 when I spend $1 on you, but if it's only a onetime deal then it's not much of a startup. When I can ramp it up to $100,000 with good, definitive return month after month, then you can have all my money.\n\n**The directness is important.** Many startups only indirectly make their customers money - they provide a service, and it is up to customers to figure out how to make money with that service, or to attribute how much revenue was made or how much cost was saved with the service. Is your tool [a painkiller or a vitamin](https://saasclub.io/candy-vitamin-painkiller-which-one-is-your-product/)? Does adopting Notion or Slack make our company more productive? There's B2B software to track social media mentions, or employee engagement. Maybe that helps us make money?\n\nWho knows? \n\nWith **found money startups**, the cause-effect relationship is so tight that there is no question. Incentives are also extremely aligned. The offer *can* be risk-free - if they don't make you money, there's no cost. *Sign up now!*\n\nBecause the revenue source is so simple, the marketing is simple too. *\"What's in it for them?\"* More money. Spend more, make more. Done.\n\nPricing is simple. You can charge whatever you like as long as your customer makes a multiple of what you make.\n\nGrowth also comes incredibly fast (though it may not be sustainable). Most companies struggle to double their revenue each year. Found Money Startups are the only ones where customers might try you out for $10,000 one month and then ramp up to $100,000 the next because you made them money. (This is often the case with Pay-Per-Click/SEO consultants too)\n\n## Finding Money on the Side of Buildings\n\nI first had this insight when hearing about a Chicago(?) entrepreneur who got his start by offering to sell ads for building owners. This kid had no credentials and no assets, but he managed to convince building owners to let him lease out the sides of their buildings for banner ads. They would get free money, and he'd get a cut of what he brought in. The proposition for advertisers was clear too - this was eyecatching outdoor advertising for cheaper than billboards.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/i1w27k116jq34r1xc99n.jpg)\n\nMost business require invested capital to get off the ground. [Property, Plants, Equipment](https://www.investopedia.com/terms/p/ppe.asp) in classical accounting. Modern startups might invest heavily in engineering expenses (classed as R&D) before starting to make millions. **This kid had neither.** Yet in a matter of months he had a multimillion dollar business selling ads on other people's property. \n\nWhat's more, once his customers saw initial success in a few test properties, they immediately offered up their other properties, and word virally spread, ensuring subsequent triple digit growth.\n\n**That's what happens when you find people money.** They throw **even more** money at you right away. Growth is effortless. You don't even try to be viral.\n\nThe kid went on to do even more notable things as an adult. I've forgotten the exact podcast (probably one of the early How I Built This episodes) where I first heard this story, or I'd be able to name the guy. But for sure the lesson I took away was that there was good money in finding money for people. (Sounds silly when you write it out like that, right?)\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ivqyh3mwyh2j5migksa1.jpg)\n\n## Examples of Found Money Startups\n\nHere's a growing list I have of \"Found Money\" startups:\n\n- [Groupon](https://en.wikipedia.org/wiki/Groupon#History) found money for local businesses by offering group buy discounts and aggregating an audience willing to try new things. It hit a [$1b valuation in 17 months](https://qz.com/398090/groupon-still-the-fastest-company-to-reach-a-unicorn-billion-dollar-valuation/).\n- [Stripe](https://www.bloomberg.com/news/features/2017-08-01/how-two-brothers-turned-seven-lines-of-code-into-a-9-2-billion-startup) found money for developers by making it easier to take money online. It also finds money by [offering fraud and chargeback risk protection with ML.](https://softwareengineeringdaily.com/2017/03/17/stripe-machine-learning-with-michael-manapat/) (all payments companies eventually become anti-fraud companies - [Max Levchin once noted how this was an existential risk for Paypal](https://www.youtube.com/watch?v=lvrDPCTuHKE&feature=emb_title) - another \"found money\" startup)\n- [Rocketrip](https://rocketrip.com/) solved the [principal-agent problem](https://www.investopedia.com/terms/p/principal-agent-problem.asp) in business travel, giving employees half the money they save for their own companies and [taking 2%](https://www.youtube.com/watch?v=l7L80UYFKj8). [Casualty of the pandemic, though.](https://www.pymnts.com/news/b2b-payments/2020/mondee-acquires-rocketrip-expand-travel-spending-incentives/)\n- [Service](https://www.getservice.com/): thanks to [Johan](https://twitter.com/elitasson/status/1337122915846922240?s=20)\n- [Mainstreet](https://www.mainstreet.us/) files for government tax credits on behalf of startups - [hit $3m ARR in 6 months](https://twitter.com/dougludlow/status/1306392033989332992).\n- **Coupons**: [Honey](https://techcrunch.com/2019/11/20/paypal-to-acquire-shopping-and-rewards-platform-honey-for-4-billion/) finds money by automatically applying coupons for you. 4 Billion Dollar Chrome Extension! (thanks [Hassan](https://twitter.com/Nutlope/status/1320863446607548417?s=20))\n- **Cart Abandonment**: [Carthook](https://carthook.com/) finds money by reviving abandoned ecommerce shopping carts. Numbers not public but [case study here](https://carthook.com/blog/case-study-how-a-company-youve-never-heard-of-started-earning-5-2-million-a-month-with-carthook/). [LiveRecover](https://liverecover.com/) does this with texting (thanks [Mitchell](https://twitter.com/mitchellbwright/status/1320750558643474434?s=20)).\n- **ML-enabled ecommerce**: [Jika](https://news.ycombinator.com/item?id=23861435) finds money by doing A/B testing for Shopify stores. It charges a flat fee now but could in future take a % of increased revenue. [Depict.ai](https://news.ycombinator.com/item?id=24252408) does this for product recommendations.\n- **Salary Negotiation**: [Candor](https://candor.co/), [Josh Doody](https://fearlesssalarynegotiation.com/), and [Levels.fyi](https://www.levels.fyi/services/) help developers negotiate higher salaries, and take a cut.\n- Procurement Negotiation: [Buyer](https://www.buyer.co/) offers negotiation as a service\n- **AWS Spend**: [Corey Quinn made a career](https://www.duckbillgroup.com/) out of reducing AWS bills. [Usage.ai](https://www.usage.ai) automates this. [Spot (formerly SpotInst)](https://spot.io/) arguably does this too, but probably takes more retooling than the other solutions.\n- **Underutilized Fixed Assets**: [per Kevin Kwok](https://kwokchain.com/2020/01/23/underutilized-fixed-assets/)\n- *Please [suggest more to me](https://twitter.com/swyx) and I'll add them here with credit!*\n\n## Found Money Marketing\n\nSome companies may not actually be \"Found Money\" businesses, but they may market their side projects or growth channels as \"Found Money\" - e.g. Geico's famous ads asking for 15 minutes of your time to save 15% on your insurance. They don't *actually* know if they're gonna save 15% for you, and they cannot magically save you more money if you spend more on them. \n\nRegardless, the ad works because it *promises* \"Found Money\". So perhaps the \"Found Money Hypothesis\" is good for more than just startup business models.\n\nTo drive this point to an inevitable conclusion, [found money marketing may also be good for fraud](https://www.marketingtodaypodcast.com/194-historic-ad-fraud-at-uber-with-kevin-frisch/) as long as no one looks too closely (and many don't). \n\n\n## Related\n\n- Meb Faber [on Unclaimed.org](https://mebfaber.com/2021/05/14/e311-radio-show/) (UK version [here](https://unclaimedassets.co.uk/)) and [Sidewalk Money](https://mebfaber.com/2020/11/17/sidewalk-money/)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/found-money-startups-3m46","devToReactions":37,"devToReadingTime":6,"devToPublishedAt":"2020-10-26T15:02:59.464Z","devToViewsCount":1076,"title":"Found-Money Startups","published":true,"description":"'I will find free money for you' is one of my favorite business models. Here's a quick definition of Found-Money Startups and a short list I've been keeping.","tags":"Startups","slug":"found-money","canonical_url":"https://www.swyx.io/found-money","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/gpjz8sbwn7c0zit4220l.jpg"},"title":"Found-Money Startups","description":"'I will find free money for you' is one of my favorite business models. Here's a quick definition of Found-Money Startups and a short list I've been keeping. ","category":"note","tags":["startups"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/gpjz8sbwn7c0zit4220l.jpg","canonical":"https://www.swyx.io/found-money","slug":"found-money","date":"2020-10-26T15:02:59.464Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/198","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/198/comments","title":"Found-Money Startups","created_at":"2022-01-17T23:13:42Z","updated_at":"2022-06-18T17:48:31Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/198/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nI have just stepped down from moderating [/r/reactjs](https://www.reddit.com/r/reactjs), the \"Front Page of React\". Here is a braindump of learnings and recollections for my future self and others (like [our new mods](https://www.reddit.com/r/reactjs/comments/jeqeo9/new_moderators_at_rreactjs/)) who might be embarking on a similar journey.\n\n## Why /r/reactjs\n\nMany people don't know that I basically started being Extremely Online™ because I was bored at work. Before 2014 I was a 100% passive consumer of Internet content. The finance day job didn't really encourage creating and engaging online. Someone turned me on to [Tickld](https://www.tickld.com/) for the memes, and by Dec 2014 I had joined Reddit (my [cake day](https://www.redditcakeday.com/) is 28 Dec!). It took [my career change in 2017](https://medium.com/hackernoon/no-zero-days-my-path-from-code-newbie-to-full-stack-developer-in-12-months-214122a8948f) for me to realize you could use Reddit for things *other than memes*.\n\nI recall being very unimpressed by /r/reactjs when I first checked it out. \"Nothing going on here\". It had 20ish-k members - still decent but nothing to write home about. I think this was around the time that [Mark Erikson](http://reddit.com/r/acemarke) and [Dan Abramov](http://reddit.com/r/gaearon) started being actively involved. Since then it's grown to 218,829 as of time of writing (adding 200 a day):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/5ok6a9k5i234kl9wtxld.png)\n\nThat translates to about 1.2m pageviews a month and 263k uniques a month (Reddit discussions are discoverable by SEO, so we get a lot of non-signed-in views):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/xtxqdvk2ktmdn3v65vyy.png)\n\nYou can view more statistics in [our 2019 Survey](https://www.swyx.io/react-survey-2019/).\n\n## Joining /r/reactjs\n\nComing out of bootcamp, I was extremely underutilized at my first dev job, so I poured myself into extracurricular activities in early 2018. One of these things was the /r/reactjs forum. Many social networks like Twitter and YouTube basically require a large following for any piece of content to get significant traction. As a \"special interest group\", /r/reactjs was one of the few places I could post my stuff in public and do well regardless of being a nobody. Like thousands of others, I joined to post my stuff, and then stuck around to learn from others and discuss their stuff. /r/reactjs is a **wonderful** place to [Learn React in Public](https://www.swyx.io/learn-in-public). \n\n> Aside: For experienced React devs, it is also a great way to stay up to date on everything going on in React without spending all your time on Twitter. You could go away for a month, come back, and look for \"Top monthly posts\" and have a reasonable crowdsourced feel for what the notable discussions and releases have been.\n\nI took two initiatives as a regular member that probably made me stand out - I started the [Monthly Beginner's Thread](https://www.reddit.com/r/reactjs/search?q=beginner%27s%20thread&restrict_sr=1) and the [Who's Hiring](https://www.reddit.com/r/reactjs/search/?q=who%27s%20hiring&restrict_sr=1) thread. I didn't ask for permission from anyone, I just saw that these things worked well in other forums, and decided to try it out. I learned a LOT of React simply by promising to answer every beginner question that came in - some months we exceeded 500 questions and answers! I still think the Beginners' thread is a great way for both learners to practice React and for teachers to identify pain points. I also have heard from a few people who've found jobs through the Who's Hiring posts, which is nice :)\n\nThe job of a community \"moderator\" is in the name - you \"moderate\". Just like a moderator in a debate, nobody's there for you, nobody expects you to be an expert. The real stars are the debate participants. But you are responsible for enforcing rules and promoting quality discussion. I think it is nice to have moderators to cool everyone down when discussions get too heated, and to initiate discussion on an important topic when there isn't one. I don't remember exactly when, but it was after one of those heated discussions that Dan Abramov invited me to help moderate /r/reactjs.\n\n## Lessons from Moderating\n\nTime and time again I've found the React core team to care a great deal about the React community - although its not part of the job description, it's an additional responsibility they've taken on themselves. One bad comment does not a community make, but it's true that culture matters and it's true that people imitate or extrapolate behavior from what they see others do. I started by fleshing out the [rules of /r/Reactjs](https://www.reddit.com/r/reactjs/about/rules) and then enforcing and setting an example. By being \"inclusive\" (also sex-positive) we effectively excluded those who didn't agree with these rules. There have been a few very irate people over the years - notably one guy who threatened to fork our community (he failed, but not before showing us his National 2nd Place C++ Trophy - prime [/r/dontyouknowwhoiam](https://www.reddit.com/r/dontyouknowwhoiam/) material). I will fight for the right of these folks to form their own community to run it their way. But I also think that excluding this small group (numbering maybe <100) made it a more welcoming place for the remaining 218,729, many of whom weren't even aware of any drama.\n\nRule 2 was \"No bashing other frameworks\". I made sure to explicitly state that criticism of React is welcome. I remember, but cannot find, one really good exchange I had when there was some React bashing going on. The commenter liked Angular and was writing in very antagonistic language. I honestly felt like this was a lost cause and almost reached for the ban or \"lock discussion\" button. But I decided to turn the other cheek. I confessed that I'd never tried Angular, and asked them to explain what they enjoyed about it. The person changed tone completely, saying they had gotten pre-emptively defensive because they were bashing React in the React subreddit. We then had a very nice discussion.\n\nI wonder how many discussions could be better if we really listened to the other side instead of getting defensive. Thanks to the [Narcissism of Small Differences](https://en.wikipedia.org/wiki/Narcissism_of_small_differences), it is usually two sides who agree on *almost* everything that bicker the most.\n\nIt felt like React's popularity exploded from 2017-2018. /r/reactjs doubled, then doubled again. I experimented with other ideas, like flairing posts (do check out our curated [Project Ideas](https://www.reddit.com/r/reactjs/?f=flair_name%3A%22Project%20Ideas%22) or [Featured Posts](https://www.reddit.com/r/reactjs/?f=flair_name%3A%22Featured%22)), or starting a live chat (quickly ruined by bots). But I knew that my own interests and work were beginning to take up more of my time. I wasn't scaling. It was time to \"hire\" more mods.\n\n## Growing a Mod Team\n\nFor better or worse, /r/Reactjs moderators have never been professional React instructors, names you know like Kent C Dodds or Tyler McGinnis, who make a living off teaching React. You could make the case for some vague conflict of interest here and Reddit is very suspicious of corporate interest. But stars attract gazers. I do wonder if the subreddit would have grown faster or would have more quality discussions if we had pursued that. In any case, I invited [/u/timmonsjg](http://reddit.com/u/timmonsjg), who was giving really good answers in the Beginner threads, and [/u/dance2die](http://reddit.com/u/dance2die), who I knew and trusted from my [Coding Blocks](https://www.codingblocks.net/slack/) days and was doing the same. Ironically we all live in the NY metropolitan area, although we've never met up. [/u/Charles_Stover](https://www.reddit.com/user/Charles_Stover) caught our eye as well with [/r/learnReactjs](https://www.reddit.com/r/learnreactjs) and rounded out our 2019 team.\n\n## Leaving\n\nMy leaving was a slow process. I've always been interested in other frameworks ([Vue was my first love!](https://twitter.com/search?q=from%3Aswyx%20vuejs%20until%3A2017-11-30&src=typed_query)) and I started looking into Svelte after traipsing around Barcelona with Rich Harris and [Jenn Creighton](https://www.youtube.com/watch?v=3s-vgOwNpac) following [his excellent JSCamp talk](https://www.youtube.com/watch?v=BzX4aTRPzno). I started [Svelte Society NYC](https://twitter.com/swyx/status/1179261731304022017?s=20) in Oct 2019 and merged it with Kev from Svelte Stockholm and Antony from Svelte London to [became a global organization](https://twitter.com/SvelteSociety) when Covid struck. Being active in two communities is a fulltime job, but leaving became *urgent* when I decided I would run [a paid community to accompany my book](https://www.learninpublic.org/#community). In June 2020 I gave notice to my fellow mods that I would become inactive (this was a bit of a lie - old habits die hard).\n\nTruly leaving would mean giving up my moderation powers, but I wasn't done with them yet. There's one last job of a mod - to appoint new mods. I wanted to leave /r/reactjs in a better place than when I found it. And you can only have so much of a community when all its active mods are 30something straight white/Asian guys living in the US. So when the craziness of [my book launch](https://dev.to/swyx/lessons-and-regrets-from-my-25000-launch-3aaa) and [new job](https://www.swyx.io/hello-aws) and [conference speaking](https://www.swyx.io/speaking/) died down, I launched /r/reactjs' [first real Moderator Applications](https://www.reddit.com/r/reactjs/comments/j32odm/whos_hiring_and_rreactjs_moderator_applications/). [Rachel Nabors](https://twitter.com/rachelnabors), who among her many talents cares a great deal about docs and community and is one of [many prominent Women of React](https://www.reddit.com/r/reactjs/comments/j5iqj3/help_the_react_team_write_new_docstake_the_2020/g84hpoi/?utm_source=reddit&utm_medium=web2x&context=3), advised and helped me get the word out to many more diverse people than I could on my own. It took a couple weeks to get through everyone, get consensus on the mod team and then to invite [our 4 new moderators](https://www.reddit.com/r/reactjs/comments/jeqeo9/new_moderators_at_rreactjs/), all from diverse backgrounds.\n\nI think it's healthy to have renewal in leadership in a community. We often have the concept of limited terms in government. I think more open source and developer communities should have limited terms. I think more people would sign up for a job if it was a limited 1 year term, that you could pass on. You would have less calcification and leave room for other ambitious folks to come up and take their place. People would also be free to move on to pursue other interests.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1gqhytzorumx1fey9mbu.gif)\n\n## My Failings\n\nA community does not have to constantly grow in order to be great. I increasingly care about quality of engagement, and that I consider one of my greater failings as a mod. Here's [Comments Per Day](https://subredditstats.com/r/reactjs):\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ucydoyea8eig3ojwv7bs.png)\n\nand Posts Per Day:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/z404lrrtkjxbzg8rqyl7.png)\n\nSo the engagement is not growing at all along with the subscriber growth. To some extent I can explain this with Reddit's limited real estate on offer - there is only one default sort order, and on average a Redditor views 2 posts per visit, and there's not that much React news or releases going on every single day. But certain exceptional subreddits like /r/AskHistorians and /r/WritingPrompts get MUCH deeper engagement, and the best way to improve the sub might be to look *outside* programming subreddits for novel ideas. Still, I'm proud of the engagement that we *do* have - the fact that members of the React Core Team, to Gatsby to Nextjs to React-Spring to Blitzjs to Styled Components, all hang out on /r/reactjs make it a wonderful experience, as do the unnamed dozens more who don't do open source but share their vast experience anyway.\n\n## Your Questions?\n\nThis is just a quick braindump on a Tuesday morning. If you're about to manage a large dev community, I'm sure I'm leaving out some critically important piece of info - please ask away in the comments or [ping me on Twitter](https://twitter.com/swyx/status/1318608931938131968) and I'll do my best to answer!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/moderating-a-220k-developer-community-3doj","devToReactions":57,"devToReadingTime":8,"devToPublishedAt":"2020-10-20T17:19:41.632Z","devToViewsCount":1336,"title":"Moderating a 220k Developer Community","published":true,"description":"Reflections from two-and-a bit years helping to run /r/Reactjs","tags":"Reflections","slug":"moderating-rreactjs","canonical_url":"https://www.swyx.io/moderating-rreactjs"},"title":"Moderating a 220k Developer Community","description":"Reflections from two-and-a bit years helping to run /r/Reactjs ","category":"note","tags":["reflections"],"canonical":"https://www.swyx.io/moderating-rreactjs","slug":"moderating-rreactjs","date":"2020-10-20T17:19:41.632Z","readingTime":"8 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/199","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/199/comments","title":"Moderating a 220k Developer Community","created_at":"2022-01-17T23:13:44Z","updated_at":"2022-06-18T17:48:31Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/199/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> [Original tweet here](https://x.com/swyx/status/1317635707838496768?s=20). Translations: [中文版](https://nextfe.com/svelte-for-sites-react-for-apps/). Referenced on [CSS Tricks's 2020 roundup](https://css-tricks.com/its-always-year-zero/)\r\n\r\nIn 2020, my personal recommendation to web developers is to use **Svelte for Sites, and React for Apps**. This is, remarkably, a nuanced enough opinion that it pisses off fans of *either* of them. \r\n\r\nI mentioned this in my [Shoptalk Show interview](https://shoptalkshow.com/432/) and Chris Coyier encouraged me to blog about it. Let me try to explain.\r\n\r\n## Sites vs Apps\r\n\r\nFirst, I have to make a distinction between (Web) Sites and (Web) Apps. There are serious, intelligent people who insist that there isn't one. They want to build everything on the web with the same tech. Respectfully, [they are wrong](https://macwright.com/2020/08/22/clean-starts-for-the-web.html).\r\n\r\n**Web Sites** primarily display content, while interaction is limited. First-load times are paramount since users may bounce and/or their limited data/power/CPU may deprive them of important information (see [Alex Russell for math on a reasonable baseline](https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/) but let's say you definitely want <200kb in the critical path). This was the web's original usecase - displaying information - and it is what HTML/CSS/Browsers are great at.\r\n\r\n**Web Apps** primarily exist for interaction. CRUD apps, livestream apps, games, whatever. These apps tend to be heavier, which is unfortunate because that affects their performance. But: \r\n\r\n- even a 2MB JS app doesn't sound so bad when it is literally competing with a 200MB mobile app, and \r\n- (let's say) you're developing a B2B app where everyone is on high power and high bandwidth devices anyway. \r\n- You're typically also keeping apps open longer, so the first-load issue doesn't matter as much (and can be mitigated with service workers). \r\n- The challenge is even higher once you account for the fact that the Web App must ship with it all the UI components and behaviors for it to work, whereas a typical native app will usually heavily lean on platform-provided components. The web platform still lacks a lot of standard components/APIs and developer experience needed to make writing great Web Apps easy - hence the gap is filled by frameworks.\r\n\r\nI view Sites vs Apps as a spectrum. Of course, if your sites dont need ANY interaction at all, don't use any JS. But most sites have app-like features (login, reactions, comments), and many apps need to perform under site-like constraints.\r\n\r\n> Aside: Check out Jason Miller's [Application Holotypes](https://jasonformat.com/application-holotypes/) for more thinking on matching the architecture of a web project to its intended use.\r\n\r\nYou'll notice that most businesses already recognize this - `www.mysaas.com` is the marketing site, `app.mysaas.com` is the app. They may start out the same codebase, but due to the vastly different requirements, they eventually split into different codebases and then different teams handling them. It's usually the idealist enthusiasts that try to make the same tech work for these clearly different purposes.\r\n\r\n## React for Apps\r\n\r\nReact has been open sourced for 7 years now. It is used in production at the biggest companies and sites in the world from Apple to Twitter to Amazon to Airbnb to Uber. It has been the most cited technology in Hacker News job postings for [at least 36 straight months](https://www.hntrends.com/2020/may-big-drop-developer-job-postings.html). There are [between 3-9m React developers](https://twitter.com/swyx/status/1190088019707154432?s=20), growing [at least >50% annually](https://twitter.com/swyx/status/1024974678337703937?s=20). The [third party ecosystem is vast](https://youtu.be/Qox56z4xH6o) and attracting instructors, developers, companies and hundreds of millions in corporate and venture funding.\r\n\r\nBased on that *alone* it is a good tech choice to base your app on already. But these are contingent facts that don't really have anything fundamental to do with React's merits. This is offensive to [first principles thinkers](https://www.swyx.io/first-principles-approach/). So let me offer some *core* reasons why React is a great choice for apps:\r\n\r\n- React Native looked troubled in 2018, but [the current team](https://www.reactiflux.com/transcripts/react-native-team-2) seems to be executing well (as far as an outsider like me can tell). [Flutter may yet give it a run for its money](https://twitter.com/swyx/status/1301103950066671616?s=20) someday, but has the Dart and Google hurdles to overcome. **React Native is the best cross platform (mobile+web+desktop) \"Write mostly once, run mostly anywhere\" solution** in tech today. If you have the resources to hire platform specialists, [you won't find this useful](https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a). However, if, like the vast majority of companies, you can't afford a dedicated team of specialists per platform, React Native is your best bet.\r\n- React has by far the most experience in abstraction design. **Where React leads, other frameworks follow** (Both Vue's [Composition API](https://composition-api.vuejs.org/) and [Svelte 3's $: API](https://www.youtube.com/watch?v=AdNJ3fydeao) directly credit React for inspiration, as do Swift UI and Jetpack Compose). This isn't to say they always get it right (*pop quiz: how many Context APIs are there in React?*) but when [Concurrent Mode](https://reactjs.org/docs/concurrent-mode-intro.html) and [React Flight](https://twitter.com/brian_d_vaughn/status/1308438105616191496?s=20) are released, I expect it to be deeply informed by production usage at the biggest websites in the world. Suspense for Data Fetching, still not yet released, has [been in production at Facebook](https://engineering.fb.com/web/facebook-redesign/) for over a year. I want to stress how unusual this is - typically in open source, you release something and then hope it gets picked up by a BigCo and tested at scale. With React, Facebook **dogfoods it at scale** before releasing to the general developer community, with [many](https://github.com/facebook/react/issues/15257) [ideas](https://github.com/facebook/prepack/wiki/react-compiler) [killed](https://cdb.reacttraining.com/react-call-return-what-and-why-7e7761f81843) before they are publicly blessed, because flaws were found. Judge React as much on what it doesn't ship as you do on what it does ship.\r\n- That brings me to governance. It's not perfect (many people have issues with Facebook, for one thing), but I think **React is one of the best run open source projects in the world**. Normally mundane things like [versioning policy](https://reactjs.org/docs/faq-versioning.html) to [error messages](https://reactjs.org/docs/error-decoder.html/) to [release channels](https://reactjs.org/blog/2019/10/22/react-release-channels.html) to [gradual upgrades](https://reactjs.org/blog/2020/10/20/react-v17.html#gradual-upgrades) matter at the scale of React. The team also does a lot of informal collaboration with key ecosystem partners like Gatsby, Apollo and Next.js, including at the browser level with Chrome and the language level with TC39. The team not only deeply cares about technical governance, but also fostering an inclusive and diverse community. \r\n- I hesitated to mention this last point because it technically has to do with adoption, but I cannot separate it from React's merits: it seems to have **the best thinkers on accessibility and interaction design** right now. No other ecosystem has projects like Adobe and Devon Govett's [React Aria](https://react-spectrum.adobe.com/react-aria/index.html) that has extensively thought through and tested for WAI-ARIA so you don't have to. Ditto [Segun Adebayo's Chakra UI](https://www.smashingmagazine.com/2020/07/accessible-front-end-application-chakra-ui-nuxtjs/). Or listen to [Rick Hanlon on the Touchable Web](https://www.youtube.com/watch?v=LhKglxQT4sU) and realize how much web apps need to improve for the open web to reverse [its alarming decline vs. mobile walled gardens](https://vimeo.com/364402896). \r\n \r\n - Let me be clear - is the React community ACTUALLY good at these things today? Hell to the no. Most of them are still debating whether or not to learn hooks vs class components. BUT React has the best shot because it has the best abstractions that enable the best thinkers to create the web application standard library we all want.\r\n- [Selective](https://github.com/facebook/react/pull/17004) and [Progressive Hydration](https://twitter.com/dan_abramov/status/1200111677833973760?s=20) are particularly interesting results of the Fiber rewrite. Together with a \"full stack\" future of React that lets the developer [easily move code and execution between client and server](https://twitter.com/dan_abramov/status/1259615888438935556?s=20), the hope for making apps that feel fast without compromising on developer or user experience is extremely strong.\r\n\r\nYou can, of course, use React to make sites. Gatsby and Next.js (and the upcoming [Remix](https://remix.run/)) are great static and serverless rendering options (The \"greatness\" of Gatsby [is disputed](https://dev.to/richharris/in-defense-of-the-modern-web-2nia)). [Docusaurus](https://docusaurus.io/) is great for docs sites. If you are making sites and are worried about JS weight, you can usually [swap Preact for React in a few lines of code](https://twitter.com/swyx/status/1316540904761520129?s=20) because you will usually not be running into any of [Preact's compromises](https://preactjs.com/guide/v8/differences-to-react/) if you are just making a site.\r\n\r\nSo why do I advocate using a different framework for sites?\r\n\r\n## Svelte for Sites\r\n\r\n> Specifically, Svelte for *Interactive* Sites\r\n\r\nSvelte is [used in production](https://twitter.com/SvelteSociety/status/1260209026563858432?s=20) \r\nfrom the NY Times (of course) to Square Enix to Apple to Spotify to Google Arts to Alaska Airlines and [hundreds more](https://github.com/sveltejs/community/tree/master/whos-using-svelte), with other big dev platforms like Amazon and Microsoft also increasingly featuring it in their content. It has a lively community with the first podcasts, YouTube channels, schools, conferences and newsletters emerging. Svelte 3 has been wildly successful and yet it is still early days. \r\n\r\nI'm going to let you in on a little secret: [Svelte and React aren't that different](https://twitter.com/buildsghost/status/1255936971265826816?s=20). Take a look [under the hood of Svelte compiled output](https://lihautan.com/compile-svelte-in-your-head-part-1/#compile-svelte-in-your-head):\r\n\r\n```js\r\nfunction create_fragment(ctx) {\r\n // redacted\r\n}\r\n\r\nexport default class App extends SvelteComponent {\r\n constructor(options) {\r\n super();\r\n init(this, options, null, create_fragment, safe_not_equal, {});\r\n }\r\n}\r\n```\r\n\r\nWtf? `class App extends SvelteComponent`?? That looks like React??\r\n\r\nYes. Wait til you realize that [`=` basically compiles to `setState`](https://lihautan.com/compile-svelte-in-your-head-part-1/#updating-data), or that yes, it does actually [ship a runtime](https://github.com/sveltejs/svelte/tree/master/src/runtime), or that yes, it actually has [a scheduler](https://github.com/sveltejs/svelte/blob/ec0f79c5af3113bedf0a5e9ae1f5f521328fcd30/src/runtime/internal/scheduler.ts) too. Like I said, where React leads, other frameworks follow. React proved Components are the right way to go.\r\n\r\nThis also means that [most React developers can learn Svelte in *hours*](https://youtu.be/xgER1OutVvU) so the switching cost is low.\r\n\r\nThe differences are large enough, though, in everything else:\r\n\r\n- **JS Weight**. Your site might get green Lighthouse scores, but hopefully you agree that you ideally only ship JS that you use, for your users' sake. Svelte sites are often single digit kilobytes. React+React DOM is ~120kb uncompressed. You can of course slash this severely if you can switch to Preact. But Svelte offers [the smallest measured runtime footprint](https://twitter.com/SvelteSociety/status/1314255119555338241). We used to worry about the compiler output overhead exceeding the size of React components (smaller runtime = more boilerplate), but [recent studies have debunked this concern completely](https://twitter.com/SvelteSociety/status/1297548737091264518?s=20).\r\n \r\n - But my consideration of JS weight extends beyond just the framework. Anecdotally, the kind of people that are drawn to Svelte seem to be more performance-minded than those in React (see everything that [lukeed](https://github.com/lukeed/) makes). This comes from the top - where React devs often import heavy dependencies as long as they kinda fit the usecase, Rich Harris is the kind of stubborn developer that makes his own version of everything because he just needs it to do a smaller job. But also, Svelte is most people's *second* framework, so they come to it with more of a performance mindset. Collectively, the dependency choices encouraged by the framework's culture also impact the end result of JS weight.\r\n \r\n - I am even encouraged by the emerging JAMstack culture in Svelte, where [Nick Reese](https://twitter.com/nickreese) has made an excellent implementation of [Jason Miller's Islands Architecture](https://jasonformat.com/islands-architecture/) with [Elder.js](https://elderguide.com/tech/elderjs/). (*TL;DR - typical [Gen-2 SSG's](https://www.youtube.com/watch?v=DD6KTAGrj3E) send JS to rehydrate the entire page, even the content that doesn't change, whereas Islands Architecture sites only send JS to hydrate dynamic parts of the page and leave the rest untouched.*)\r\n- **Scoped styles**. Need I say more? The way Rich Harris puts it, goes something like this (poor phrasing is my fault): \"In my opinion, a frontend framework should give you a styling solution\" (fun aside: [watch the React Core Team debate styling solutions](https://twitter.com/rachelnabors/status/1320474510143967235?s=20)! They feel the pain). Not just styling, but transitions and animations too. Ask any React developer what styling/animation solution to use, and watch them squirm or give you a PhD length dissertation of 5 subtly different alternatives. I say this with some irony, because I myself use [Tailwind with Svelte](http://swyx.io/why-tailwind).\r\n- **Full Sitemaking Toolkit**. It's not just styles and animations. State management? Head management? Class toggling? Tween/Spring effects? (soon) Routing? All are one import away. Because of Svelte's design, you can use as much or as little as you like, but at least there is a first party option for everything.\r\n \r\n - React takes pride in its [minimal surface area](https://www.youtube.com/watch?v=4anAwXYqLG8) and relies on its ecosystem to fill in the gaps. Choice is good and a big part of React's popularity and longevity. \r\n \r\n - But I've lived with the ambient anxiety of having to stay informed and choose and set up every goddamn part of my frontend stack for years at this point, and it really is not productive. Look, maybe I just suck at this. Or maybe I just need a more productive stack that aligns with my preferences.\r\n- **Svelte is a superset of HTML**. Svelte is actually not just a toolkit, [it is also a language](https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934) designed to make the web developer more productive. That means that SVG \"just works\". That means that you can work with `class`es. That you can [work nicely with Web Components](https://custom-elements-everywhere.com/) (both exporting and importing). A lot of little things you make apologies for with React and JSX.\r\n- **Svelte's downsides matter less** when making sites. Svelte has a much smaller ecosystem and community, but that matters less when you're making sites, since you're going to be mostly making your own designs and interactions anyway. This is certainly how Rich uses it at the New York Times - not relying on the ecosystem. The smaller hiring pool is also less of a concern since you typically wouldn't be hiring the same size team you'd need to maintain an app.\r\n \r\n > By the way, we are working on building out the Svelte ecosystem by helping to grow the Svelte community - [Svelte Society](https://twitter.com/SvelteSociety) was [started a year ago in a dinky little Microsoft room](https://twitter.com/swyx/status/1179261731304022017?s=20) - check out [Svelte Summit](https://sveltesummit.com/) if you are reading this on 18 Oct 2020!\r\n- If you STILL needed to ship features in React, you could mount it atop of a Svelte app if you wished. It would make less sense (because you'd already be paying the library footprint size) to do the opposite, so it just makes sense to have Svelte as the baseline.\r\n\r\n> Aside on Render Performance and Virtual DOM: The importance of a \"Virtual DOM\" is a big bone of contention between React and Svelte (Tech Twitter folks will remember [the 3d \"benchmarks\" from last year](https://twitter.com/Rich_Harris/status/1200807516529147904?s=20))) but to be quite honest the kind of pedestrian sites and apps that you and I write don't even run into that kind of perf demands, so I don't count it.\r\n\r\nI've written more thoughts on [Why I Enjoy Svelte](https://www.swyx.io/svelte-why/), but these are the two salient points that lead me to pick Svelte over React for my own interactive sites.\r\n\r\n### Why use frameworks at all?\r\n\r\nOf course, webdev being webdev, we aren't done discussing the full complexity of this sort of tech stack choice. The *other* concern people have comes from the opposite direction - if you're just making a site (interactive or otherwise), why use a framework at all?\r\n\r\nIt's a valid question - after all, perfectly good, fast, battle tested solutions exist from [Hugo, Jekyll, Eleventy](https://jamstack.org/generators/), and so on. They generate zero JS by default, and then let you \"sprinkle on JS\" as needed. \r\n\r\nMy current answer here is more about mental model. I want to code using components, and I want an easy upgrade path to add interactivity to something that wasn't previously interactive. None of those more traditional site generators let me do that. I'm not sure that this line of argument is convincing to the \"no frameworks\" crowd, but it is true for me.\r\n\r\n## The Philosophical Big Picture\r\n\r\nI want to share with you a deep realization I had, that is going to sound extremely underwhelming at first:\r\n\r\n**[Tools-designed-to-make-small-things should work very differently from tools-designed-to-make-big-things.](https://twitter.com/swyx/status/1278665379544350720)**\r\n\r\nWell, duh, right? At the surface, this is just a restatement of the tired \"Use the right tool for the job\" cop-out, which [I have my problems with](https://www.swyx.io/hammers/). \r\n\r\nBut no, this is subtly different. I am insisting that what *looks* like the same job, at two different scales, are actually *different* jobs. Different enough to justify using different tools.\r\n\r\nFurther, when we ignore this and try to make the tool do everything, we make the tool *worse* for everyone - more confusing to learn, more API to remember, and often a degraded end user experience from making too many tradeoffs. \r\n\r\n**In the rush to satisfy everyone, we delight no one.**\r\n\r\n> Aside: The reasons we do this are complex. Sometimes devtool companies do it because they feel they need it to grow. Other times hackers just do it just to show that they can. I pass no judgment here, it is always worth trying to push limits.\r\n\r\nThis is the high level takeaway I have in the React vs Svelte debate. It's exposed most clearly in the public statements that the React team have been making (**PLEASE DO NOT CROSS EXAMINE THEM ON THIS, THESE ARE MERELY OFF THE CUFF STATEMENTS ON PERSONAL SOCIAL MEDIA**):\r\n\r\n- [Dan Abramov](https://twitter.com/dan_abramov/status/1259618524751958016?s=20): \"A “disappearing framework” is certainly cool and worth striving for. But it doesn’t help much when the framework is 5% of your code. Say “disappearing app” and I’m listening.\"\r\n- [Seb Markbage](https://twitter.com/sebmarkbage/status/1201251406604197888?s=20): \"This is from an internal perf investigation I did. We also see similar numbers in all real significant apps. This is the percentage of all JS time and about 5% is the time spent creating the actual DOM nodes so it’s inherent. The framework code is about 8%. We could optimize those 8% and use various other tradeoffs. To save maybe 7% of JS execution... However that hides 87% of the JS executed in actual apps. That’s what we need to focus on.\"\r\n- [Dan again](https://twitter.com/dan_abramov/status/1316838048223694851?s=20): \"I think overall it's true that we're a lot more focused on optimizing the application size over the library size. Because the library size is relatively constant, whereas the application size keeps growing. lazy() is an example of that, but there is a lot more we need to do.\"\r\n\r\nThe thing is... React's library size is 120kb (uncompressed). What size of app are you targeting for React to be 5-13% of total JS? 1mb-2.5mb. Is your site/app anywhere close to that?\r\n\r\nThe ground facts are these:\r\n\r\n- React is without question the best framework for making apps and getting better\r\n- the React team is more focused on apps than sites\r\n- While they really care about community, React is made for Facebook needs first and foremost\r\n- You Are Not Facebook\r\n- Your site is most definitely Not Facebook\r\n- You probably don't use all the features React ships\r\n- Even if you use Preact instead, the P/React ecosystem doesn't give you enough out of the box to be productive\r\n- There should exist a better and different toolkit for making interactive sites. \r\n- The best langauge for that today is Svelte.\r\n\r\nSvelte for Sites, React for Apps. Q.E.D.\r\n\r\n\r\n> P.S. for the apoplectic Svelte fans: yes of course you can use Svelte to write Apps too. Let people realize that on their own. Make the case where you can indisputably win, where adoption is easy and lower cost, rather than fight every battle on every front even where circumstantial facts weaken your case.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/svelte-for-sites-react-for-apps-2o8h","devToReactions":588,"devToReadingTime":14,"devToPublishedAt":"2020-10-18T01:08:02.366Z","devToViewsCount":19772,"title":"Svelte for Sites, React for Apps","published":true,"description":"Why we should stop trying to use the same tool for different jobs.","tags":"Svelte, React, Webdev","slug":"svelte-sites-react-apps","canonical_url":"https://www.swyx.io/svelte-sites-react-apps","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/tc1icmvqblxg6wl5y61p.jpg"},"title":"Svelte for Sites, React for Apps","description":"Why we should stop trying to use the same tool for different jobs. ","category":"note","tags":["svelte","react","webdev"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/tc1icmvqblxg6wl5y61p.jpg","canonical":"https://www.swyx.io/svelte-sites-react-apps","slug":"svelte-sites-react-apps","date":"2020-10-18T01:08:02.366Z","readingTime":"14 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/200","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/200/comments","title":"Svelte for Sites, React for Apps","created_at":"2022-01-17T23:13:46Z","updated_at":"2024-01-09T19:50:09Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/200/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"The Coding Career Handbook on the React Podcast","slug":"react-podcast-2020","tags":["Careers"],"venues":"React Podcast","date":"2020-10-15T00:00:00.000Z","url":"https://www.listennotes.com/podcasts/react-podcast/114-shawn-swyx-wang-on-the-8flz1q2hHM4/","description":"swyx and Chantastic talk the state of React and the Coding Career Handbook.","category":"podcast"},{"title":"The Coding Career Handbook on React Podcast","slug":"coding-career-react-podcast","tags":["Careers"],"venues":"React Podcast","date":"2020-10-15T00:00:00.000Z","url":"https://reactpodcast.com/episodes/114/","description":"Shawn Swyx Wang opens up about his new book The Coding Career Handbook - His book shines a spotlight on career patterns and practices that many had to learn the hard way — you know, up hill in the snow both ways!","category":"podcast"},{"title":"Intro to AWS Amplify and AppSync","slug":"intro-to-aws-amplify-and-appsync","categories":["AWS"],"description":"A General intro to AWS Amplify and AppSync","instances":[{"venue":"Singapore Serverless","date":"2020-10-14","video":"https://www.youtube.com/watch?v=YwpInifIO8o"}],"category":"talk","date":"2020-10-14T00:00:00.000Z"},{"type":"blog","content":"\nWith Amplify Storage, it is very easy to add file storage capability to any web or mobile app. Here's a quick demo!\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/94xwh0o7wv8f2ovesmgs.gif)\n\n## What's Amplify?\n\n[AWS Amplify](https://www.swyx.io/writing/hello-aws/) is an open source toolset that helps you get up and running on AWS faster:\n\n- [A CLI](https://docs.amplify.aws/cli) that lets you add storage functionality and provision it in the cloud\n- [JS libraries](https://docs.amplify.aws/lib) (or iOS or Android or Flutter) that lets you call simple functions to execute all these capabilities\n- Premade [UI Components](https://docs.amplify.aws/ui/) that we won't be using today.\n\nFor app developers, Amplify offers easier access to curated AWS services in each \"Category\" - ranging from [GraphQL](https://docs.amplify.aws/cli/graphql-transformer/overview), [Authentication](https://docs.amplify.aws/cli/auth/overview), [Analytics](https://docs.amplify.aws/lib/analytics/getting-started/q/platform/js), and even [pretrained Machine Learning models](https://docs.amplify.aws/lib/predictions/intro/q/platform/js). However today we'll be exploring the [Storage](https://docs.amplify.aws/lib/storage/getting-started/q/platform/js) category, which uploads files to [Amazon S3](https://aws.amazon.com/s3/).\n\n## Demo\n\nYou can clone my demo on GitHub here: https://github.com/sw-yx/demo-amplify-storage-file-upload\n\nOr you could try out the one click deploy from Amplify:\n\n[![amplifybutton](https://oneclick.amplifyapp.com/button.svg)](https://console.aws.amazon.com/amplify/home#/deploy?repo=https://github.com/sw-yx/demo-amplify-storage-file-upload)\n\nThe demo is built with [Tailwind UI](https://tailwindui.com/) and [Svelte](https://dev.to/swyx/how-to-set-up-svelte-with-tailwind-css-4fg5), but Amplify is framework agnostic and you can use this toolchain with anything you like. I won't bore you with the step-by-step, since it would mostly duplicate the docs (that I also have updated), but here are the features demonstrated:\n\n- Upload file with progress bar\n- List files (with metadata)\n- Delete files\n- Download files\n- Create folder\n- Toast success/failure\n\n>⚠️ Note that this demo is designed explicitly for educational purposes around Amplify Storage - you still need to [add authentication](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js) if you are to release it for broader production use. You can also run `amplify delete` when you are done to remove all resources provisioned.\n\n## 6 minute Codebase Walkthrough\n\nYou can see my 6 minute codebase walkthrough here:\n\n{% youtube Be0hmfNMdxI %}\n\n## Help me share this\n\nIf you liked this demo, you can help me [share it on Twitter](https://twitter.com/swyx/status/1315695498032902144?s=20) or [signup to my YouTube](https://youtu.be/Be0hmfNMdxI)!\n\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/amplibox-a-self-hosted-file-storage-app-with-aws-amplify-1f6g","devToReactions":66,"devToReadingTime":2,"devToPublishedAt":"2020-10-12T15:35:04.990Z","devToViewsCount":1967,"title":"AmpliBox - a Self Hosted File Storage App with AWS Amplify","published":true,"description":"A demo using AWS S3 (Simple Storage Service) using Amplify Storage, Svelte, and Tailwind CSS","tags":"Tutorials, AWS, Svelte, Tailwind","slug":"amplify-storage-demo","canonical_url":"https://www.swyx.io/amplify-storage-demo","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/igg11wp4zrxios48582f.png"},"title":"AmpliBox - a Self Hosted File Storage App with AWS Amplify","description":"A demo using AWS S3 (Simple Storage Service) using Amplify Storage, Svelte, and Tailwind CSS ","category":"note","tags":["tutorials","aws","svelte","tailwind"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/igg11wp4zrxios48582f.png","canonical":"https://www.swyx.io/amplify-storage-demo","slug":"amplify-storage-demo","date":"2020-10-12T15:35:04.990Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/201","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/201/comments","title":"AmpliBox - a Self Hosted File Storage App with AWS Amplify","created_at":"2022-01-17T23:13:48Z","updated_at":"2022-04-10T09:35:28Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/201/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nIn 2007, just after his cancer diagnosis, Carnegie Mellon professor Randy Pausch gave [a well received lecture on Time Management](https://www.youtube.com/watch?v=oTugjssqOT0). These are my notes ([slides here](http://www.cs.virginia.edu/~robins/Randy/RandyPauschTimeManagement2007.pdf), [transcript here](https://jamesclear.com/great-speeches/time-management-by-randy-pausch)).\n\n> Side note - he is better known for his Last Lecture on [Achieving Your Childhood Dreams](https://www.youtube.com/watch?v=ji5_MqicxSo) - ironically given *before* this Time Management talk.\n\n{% youtube oTugjssqOT0 %}\n\n## Money vs Time\n\n- We are very good at dealing with money, but very bad at dealing with time. Having an idea of how much your time costs helps you start making tradeoffs better. \n- We have to manage our time better than we manage our money. We have money budgets, what about time budgets?\n- We are in a \"Time Famine\" - nobody says they have \"too much time\". Yet The typical office worker wastes almost 2 hrs a day at work, and 28 hours a week on TV. This isn't just a one-off problem - you can't solve it one week and then go back to normal - it's systemic and requries change in fundamental processes to address this once and for all.\n- The goal is to have fun, be happier, lead a more meaningful life. If you're not going to have fun, why do it?\n- Being successful doesn't make you manage your time well. Managing your time well does make you successful.\n- Turn money into time - Hire someone to do chores. Esp if you have kids.\n\n## Goals, Priorities, Planning\n\n- Always ask: Why am I doing this, What is the goal? Why will I succeed? What will happen if I don't do it?\n- **It's more important to do the right things, rather than do things right.**\n- Pareto Principle, 80/20 rule. Focus on the high value/impact things.\n- People asked Walt how he built Disneyland in 366 days. His reply: \"We used every one of them.\"\n- **Planning is impt**. Failing to plan = planning to fail. Have a plan for day/week/quarter.\n- You can still be fluid - plans can change.\n- **Todos** - Break things down into small steps. \"Get tenure\" is not a todo. Eat your frog - do the ugliest thing first.\n- **Prioritization** (MOST IMPORTANT) Covey/Eisenhower Matrix\n - urgent + important\n - not urgent + important\n - urgent + unimportant\n - not urgent + unimportant\n - the trick is to not do unimportant things, and to tackle important things **before** they become urgent.\n\n ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ixrb0xwdka2kb2coycb7.png)\n- Keep your desk clear - have 1 thing on your desk\n- Touch each piece of paper, email once. **Inbox is not your todo list**. File the email away and put it on your todo list.\n- A filing system is absolutely essential. Have one place in the house where any piece of paper goes. (Ditto in the cloud/computer)\n- **Have at least two, maybe three monitors.** Using just one \"is like eating off the airplane tray.\"\n- Productivity Stack:\n - Todolist\n - Inbox\n - Calendar. Dont use your brain to remember your appointments.\n- Standing during phone calls - will be much faster. Don't get comfortable. \"I'd love to keep talking with you but I have students waiting.\"\n- Exercise on bike - can be spent on phone if you have a headset\n- Write a Thank You note. Tangible way of telling someone you appreciated something. It makes you rare, they remember you well.\n- The dog - reminds you you have better things to do\n- Chair - make your office comfortable for you, optionally comfortable for others (eg folding chair).\n- **You do not find time to do something, you make time.** And you make time by electing not to do something else.\n- **Learn to say no.** Opportunity cost is real. \"Gentle no\" = \"I'll be your backup\". \"If you need an 8th person I'll be there.\"\n- Find your creative time and defend it ruthlessly. It varies for people - could be 10pm-Midnight.\n- Find your dead time and do stuff where you don't need to be at your best.\n- **Interruption** takes 6-9mins, but recovery takes 4-5mins. Got to find ways to reduce frequency of interruptions. Turn phone calls into emails. Batch interactions with other people.\n- Giving hints to cut meetings short: Get up, walk to the door, thank them, shake their hand. Walk them out of the room.\n- **Time journals** - monitor and update thru the day. [Fred Brooks had actual time clocks](http://www.cs.unc.edu/Events/News/VirtuousReality/).\n- Look at open blocks where you know you are going to be wasting time, as gaps between blocks - make up a fake class.\n- Delegate.\n- \"How am I wasting other people's time?\"\n- You become more efficient at work so you can leave on time and spend it with the people you love. Once you have kids the stakes are real.\n\n## Procrastination\n\n- Sometimes you get lucky - if you wait long enough you may not have to do it\n- Sometimes you want to avoid Parkinson's Law - Work expands to fill the time available for it.\n- But key realization - doing things at the last minute is very expensive. If you push things up to the deadline that's where all the stress comes from\n- Make a fake deadline and pretend it is real.\n- Identify why you're procrastinating - afraid you are going to fail? scared to ask somebody for something? Sometimes you just have to ask.\n\n## Delegation\n\n- Grant Authority + Responsibility\n- Delegate but always do the ugliest job yourself, so it is very clear you are willing to do what you ask\n- Treat your people well, esp staff/secretaries\n- Don't be vague: \n - Give specific thing to do\n - Specific date/time\n - Specific penalty/reward\n- Challenge people: delegate until they complain\n- Communication has to be CLEAR - and written\n- Don't tell them HOW to do it - tell them what you need done, let them come up with solutions. This is how to work with people smarter than you.\n- Offer relative importance - so people know what order to do them in\n- Beware upward delegation - step back.\n- Carrots > Sticks. Reinforce behavior you like. \"Thank you I really appreciate you did a good job.\"\n\n## Meetings\n\n- Take everybody's phones in a meeting. Be present.\n- A scribe should take One minute minutes at the end. What decisions got made, and who is responsible for what.\n\n## Tools\n\n- \"Computers are faster, they just take longer.\"\n- Technology has to make your life better, end to end. eg. if it changes workflow. \"Just a little bit faster\" is not good enough.\n\n## Email\n\n- don't delete email\n- If you want something done, don't send it to 5 people. Send it to ONE person. use alf weaver specificity rules.\n- If person has not responded in 48 hours, nag them, bc their response rate will be zero\n- It's not a vacation if you're reading email\n\n## Reporting Up\n\n- Ask when is next meeting, what you want by then, who to turn to for help\n\n## Life Advice\n\n- Kill your television. Average American spends 28 hrs/wk on TV.\n- Eat, sleep, exercise. \n- Never break a promise, but re-negotiate them if need be. \n- If you haven’t got time to do it right, you don’t have time to do it wrong. \n- Recognize that most things are pass/fail. Good Enough is good enough.\n- Feedback loops: ask in confidence.\n\n## Call to Action\n\n- Put your TODO list in priority order\n- Do a time journal or count hours of TV you watch\n- Make a note to revisit this in 30 days and ask \"What Have I Changed?\"\n\n## Style Notes\n\n- He often uses humor - noting the optimistic side of his very grim situation, giving some relief to his audience while also reminding them of the importance of his message.\n- He is also extremely respectful - being humble to specific members of the audience (\"Gabe is REALLY in good shape\", \"I am NOT smarter than Jim Calhoun\", \"Am I giving a talk with Alf Weaver in the audience?\"), as well as the venue/general audience itself (\"there aren't many better PhD programs in history than this one\").\n- He brings in personal stories and examples, often involving his wife, and they are usually relatable and funny. His slides use photos from his own life living the things he talks about.\n- The anecdotes also inject some variety - 40 minutes in he breaks for a tangent about his dog and a tiny debate he had with his wife.\n- Vocal variation - 53 minutes in he screams \"PUT THE CIGARETTE OUT MOM\" and that is a nice spike in decibels.\n- Ending is really good: He ends with actionable things to do, and a nice reminder of why this is important: \n\n > \"If I haven't changed anything, then we still had a pleasant hour together. If you have changed things, then you'll probably have a lot more time to spend with the ones you love. And that's important, time is all we have. And you may find one day, you have less than you think.\"","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/notes-on-time-management-from-a-dying-man-49fb","devToReactions":393,"devToReadingTime":6,"devToPublishedAt":"2020-10-12T00:10:32.036Z","devToViewsCount":7109,"title":"Notes on Time Management from a Dying Professor","published":true,"description":"Notes on Randy Pausch's lecture on Time Management","tags":"Notes, Speeches","slug":"time-management-randy-pausch","canonical_url":"https://www.swyx.io/time-management-randy-pausch"},"title":"Notes on Time Management from a Dying Professor","description":"Notes on Randy Pausch's lecture on Time Management ","category":"note","tags":["notes","speeches"],"canonical":"https://www.swyx.io/time-management-randy-pausch","slug":"time-management-randy-pausch","date":"2020-10-12T00:10:32.036Z","readingTime":"7 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/202","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/202/comments","title":"Notes on Time Management from a Dying Professor","created_at":"2022-01-17T23:13:50Z","updated_at":"2022-01-17T23:45:29Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/202/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nIn their book [Nudge: Improving Decisions about Health, Wealth, and Happiness](https://en.wikipedia.org/wiki/Nudge_(book)), Richard Thaler and Cass Sunstein coined the term [Choice Architecture](https://en.wikipedia.org/wiki/Choice_architecture) to describe how the way you present choices to consumers can heavily affect their decisionmaking. It's been used for everything from encouraging people to save more for retirement or registering for organ donations, with dozens of governments setting up dedicated [\"Nudge Units\"](https://en.wikipedia.org/wiki/Behavioural_Insights_Team).\n\nThaler later [won the Economics Nobel](https://theconversation.com/why-richard-thaler-won-the-2017-economics-nobel-prize-85404) for his contributions to behavioral economics, but it occurred to me today that this pinnacle achievement of choice architecture must seem absolutely elementary to its master practitioners: \n\n**Gyms and Startups**.\n\n## Selling like a Gym\n\nI signed up for a gym recently and it was a surprisingly convoluted experience.\n\nGo on to the [Anytime Fitness website](https://www.anytimefitness.sg/) and try to figure out how much membership costs.\n\nI'll save you some time - you won't find it. You need to schedule a free trial, go down, tour the facilities, work out, and then at the end, their \"membership consultant\" will sit you down at a nice table with a refreshing drink to tell you about their options. [Reciprocity at its finest](https://www.influenceatwork.com/principles-of-persuasion/). But we're not here to talk about Influence - let's look at the choices offered:\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hhcrq7vo3lf6jv32ykdu.jpg)\n\nThis is how it works out: \n\n- For the base membership price, a commitment of 6 months will cost you $128 per month (a 1 month commitment would be $148). \n- On top of the base membership, there's an \"Admin\" fee of $105, together with a \"Key\" fee of $75. \n- During this special period, they are running a promotion - they will waive the Admin fee if you sign up for personal training, and you can book 5-30 sessions at the cost of $450-$2,100.\n- However if you sign up RIGHT THIS SECOND you can get a special deal of 3 sessions of personal training at $160.50! What a deal!\n\nGot all that? I went in wanting to sign up for a gym, I came out with a complex financial plan.\n\nOrdinarily, you might consider the Admin fee of $105 exorbitant compared to the monthly membership of $128. But you are immediately bombarded with this special \"promotion\" that offers something of value for more money. Now, the $160.50 in personal training doesn't look so bad! Among the barrage of dollars and choices, you hopefully have also forgotten that they're also charging $75 to set up a keycard for you.\n\nThis is choice architecture.\n\n## Startups\n\nHaving been involved in a few job offer discussions at Silicon Valley companies now, I noticed they all use the same playbook:\n\n- You start interviewing with them, with no idea what they pay\n- After 1-2 months you finish the interview process, you're tired (you've been interviewing with others too, as you should) and want it to be over, they tell you you are the best thing since sliced bread\n- You've absorbed enough advice to know that you should [never name the first number](http://blog.interviewing.io/exactly-what-to-say-when-recruiters-ask-you-to-name-the-first-number/) (more thoughts collected in [my book](https://www.learninpublic.org/toc))... and your recruiter knows that too\n- So they happily name TWO numbers:\n - Offer A with X cash and Y options\n - Offer B with (X minus a bit) cash and (Y plus a bit) options\n\nAnd now you have the power to choose your compensation according to how much you believe in the company! How generous, right?\n\nThis, too, is choice architecture.\n\nRelevant [XKCD](https://xkcd.com/1801/)?\n\n![https://imgs.xkcd.com/comics/decision_paralysis_2x.png](https://imgs.xkcd.com/comics/decision_paralysis_2x.png)\n\nTo be clear, I don't mean that there's anything malicious going on. It's an extremely standard playbook at this point. I've taken this deal myself, twice. It's just that giving you that choice focuses you on the options they give you, rather than all the other options available to you which could include higher total compensation. It also establishes an extremely tight \"range\" - a low end and a high end, and if the company is extra savvy, the tradeoff between cash and stock will be at a much higher valuation than their last investment. All fair game.\n\nBut you see how presenting this choice is better than presenting one offer without a choice? It hands limited \"agency\" back to the prospective hire, within predetermined bounds, and the hire will have to fight extra hard to justify something much higher (basically a higher offer from a close peer or that you are completely misleveled). After all, you gave them a choice in how much cash they want! By the way those options are simultaneously worth nothing and worth millions.\n\nYou have the choice to not accept these choices, and to propose different rules and different structures. Of course, the likelihood of acceptance decreases dramatically as you go outside the company playbook. I'm not smart enough to offer you a menu of what those other choices are - but some in-demand people like Daniel Vassallo are experimenting with [1/4 time employment](https://twitter.com/shl/status/1300848723182776322). I've known others to work contract jobs for only half the year, and spend the other half surfing around the world. Or you could start an agency or company building the tool or service you would've been working on anyway, sell it in lieu of employment and maybe get acquihired. Lots of choices that are not Offer A nor Offer B.\n\n## Choice Architecture in the Wild\n\nI want to reiterate that there's nothing inherently malicious about Choice Architecture. [Kasey Speakman raised a very great point](https://dev.to/kspeakman/comment/16kla) that parents also do it for their children. It's just that most of the time it's done, it's done with the benefit of the choice-giver in mind, rather than the choice-taker. It respects agency but puts down extremely tight boundaries around what you're allowed to do. Most of the time that's just how the game is played, and you can just go along with it. But every now and then it'll be used for something truly exploitative and you'll want to know how to spot it and reject it out of hand before being manipulated into a bad deal.\n\nYou often also see (un?)intentionally bad choice architecture in surveys and opinion polls - a leading question like [Do you think buying the latest smartphone is a waste of money?](https://news.ycombinator.com/item?id=24738206) may get a lot of yeses but fail to reflect actual behavior. This is why experienced data analysts always ask to see the original question alongside the interpreted survey results.\n\nTwo last examples I'll leave you with so you can see this in the wild: indie book makers love choice architecture.\n\n- Wes Bos is pretty open about how he does it. Check out [Mastering Gatsby](https://mastergatsby.com/): as of time of writing and in my country, the Starter Course with 6 Modules costs $82, whereas the Master Package with 13 Modules costs $97. Who's going to buy the Starter course?\n- Adam Wathan likes the \"shitty version/full version\" model too - [Refactoring UI](https://refactoringui.com/book/) charges $79 for just the book, and $149 for the book plus a bunch of extras. He also is very open that this pricing model is pretty much designed to set levels so that it appeals to people who would normally flinch at paying $79 for a PDF.\n\nIn pricing for my book, I used the [Ryan Delk pricing formula from Joel Hooks](https://twitter.com/jhooks/status/1261687440588210177?s=20). It hasn't worked that well - I suspect mainly because I haven't done a good enough job articulating the value in the 3 choices, which is more work compared to the 2 choice model. Still, nothing malicious meant. When you are putting infinitely replicable zero margin stuff up for sale, there is no marginal \"cost of goods sold\", so it is \"monkey see, monkey do\" when it comes to giving Choices.\n\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/choice-architecture-mld","devToReactions":25,"devToReadingTime":6,"devToPublishedAt":"2020-10-10T16:29:19.454Z","devToViewsCount":394,"title":"Choice Architecture","subtitle":"How Companies Offer Choice to Reduce Choice","published":true,"description":"Reflection on how both gyms and startups do choice architecture and how we can be more conscious of this","tags":"Reflections","slug":"choice-architecture","canonical_url":"https://www.swyx.io/choice-architecture"},"title":"Choice Architecture","subtitle":"How Companies Offer Choice to Reduce Choice","description":"Reflection on how both gyms and startups do choice architecture and how we can be more conscious of this ","category":"note","tags":["reflections"],"canonical":"https://www.swyx.io/choice-architecture","slug":"choice-architecture","date":"2020-10-10T16:29:19.454Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/203","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/203/comments","title":"Choice Architecture","created_at":"2022-01-17T23:13:52Z","updated_at":"2022-01-17T23:45:30Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/203/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n## TL;DR\n\n**Service as a Service** is an idea I coined in [my recent book](https://www.learninpublic.org/toc) to describe what software founders should do before they create a \"Software as a Service\" (SaaS) business. \n\nIt is a nice shorthand for both:\n\n- how Indie Hackers should offer productized services before SaaS in the [stairstep](https://robwalling.com/2015/03/26/the-stairstep-approach-to-bootstrapping/) or [ladder](https://nathanbarry.com/wealth-creation/) model\n- how Y Combinator startups should [Do Things That Don't Scale](http://paulgraham.com/ds.html) before they do things that do.\n\nIt is also nicely aligned with the current conventional wisdom of how companies can be built by serving an [audience first](https://medium.com/@rrhoover/building-a-startup-build-an-audience-first-9fbba4f1fa15). \n\n## Context\n\nIn the context of a software startup, **Services** mean writing custom software tailored to the needs of each individual customer, and **Products** mean writing one set of software that all customers use.\n\nProducts are more scalable, because every feature added is immediately useful to all customers (including future ones), whereas Services are more sellable, because you are directly addressing the needs of each user. Products (especially digital products) have higher profit margins and can generate recurring revenue indefinitely, whereas Services always have expensive humans involved, and customers churn much more frequently.\n\nA lot of people get caught up in the idea that products are better than services, because they only want to do things that scale (and a pure Services business is basically a consulting shop that refuses to admit it - this is the heart of [the debate on Palantir's valuation](https://www.theinformation.com/articles/investor-question-how-to-define-palantir?shared=01870c)).\n\nThe truth is that most tech companies are a mix of both. At the largest scale, every enterprise sale involves custom integration work done by \"Forward Deployed\" or \"Implementation\" or \"Success\" engineers. At the smallest scales, startups have to balance their long term vision with short term \"just for me\" feature requests from their early design partner customers.\n\n## Product Core, Services Shell\n\nPerforming Services gets revenue in the door earlier, while making sure you are *hyper* attuned to customer needs. Instead of being off in your own world building product nobody wants, you can make money serving your desired customer first, then build your product internally to serve your needs, and then eventually let the “Services Facade” fade away and users can use your product directly. \n\nThe Services to Product transition can take a long time and will never quite go away: Chetan Puttagunta, a notable software startup investor, [notes that](https://twitter.com/chetanp/status/1201540828096679940) at $60m in revenue, half the revenue of software startups are services, but even at $800m, services revenue is still at 20%. \n\n<img src=\"https://dev-to-uploads.s3.amazonaws.com/i/p2znatkx5uq49mu9uv55.png\" width=400 />\n\nIn the vein of Gary Bernhardt's [Functional Core, Imperative Shell](https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell), you could frame this phenomenon as **Product Core, Services Shell**.\n\nOnce you see it, it's hard to deny that for entrepreneurs still seeking product market fit, offering \"Service as a Service\" before investing in \"Software as a Service\" can lead to a higher probability of success, and that though the Product component may grow over time, the Services component may never quite fall away.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/service-as-a-service-3ene","devToReactions":36,"devToReadingTime":3,"devToPublishedAt":"2020-10-07T17:16:35.868Z","devToViewsCount":336,"title":"Service as a Service","published":true,"description":"Before you start offering Software as a Service, perhaps just offer a Service.","tags":"Ideas","slug":"service-as-a-service","canonical_url":"https://www.swyx.io/service-as-a-service"},"title":"Service as a Service","description":"Before you start offering Software as a Service, perhaps just offer a Service. ","category":"note","tags":["ideas"],"canonical":"https://www.swyx.io/service-as-a-service","slug":"service-as-a-service","date":"2020-10-07T17:16:35.868Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/204","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/204/comments","title":"Service as a Service","created_at":"2022-01-17T23:13:54Z","updated_at":"2022-01-17T23:45:30Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/204/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n> \"You’d be surprised how far you’ll get by just doing what you say you’ll do.\" - [Sahil Lavingia](https://twitter.com/shl/status/1311235651795214336)\r\n\r\n## Follow up\r\n\r\nTo dramatically improve the probability of feedback, level up fast, and become a partner and then a peer to people you look up to, [**Pick Up What They Put Down**](https://www.swyx.io/learn-in-public-hack/). Even if it is to say you appreciate what they do. [It](https://twitter.com/swyx/status/1275220693307674624?s=20) [never](https://twitter.com/wesbos/status/927966276261171201?s=20) [gets](https://twitter.com/jjacobs22/status/1286396277194985484?s=20) [old](https://twitter.com/ashleydavis75/status/1275262643817734144?s=20).\r\n\r\n## Follow up more\r\n\r\nWant a job? Want to raise money? Want to hire someone? [Cold emailing](https://paigefinndoherty.com/2020/03/25/a-cold-outreach-workshop/) is inevitable. Because it's cold, you may get ignored. **Follow up**. Some in-demand people automatically ignore all first emails as a desire filter. Others are busy or don't have their shit together. Judge them all you like. \r\n\r\nIn all cases, following up improves your chances of getting what you want.\r\n\r\n## Follow Through\r\n\r\n**Following Through is just Following Up on your past self.**\r\n\r\nMany [Obligers](https://lifegoalsmag.com/how-to-say-no-as-an-obliger-personality/), like me, try not to let others down, but let ourselves down way too easily. \r\n\r\nYou fall in love with ideas, you underestimate difficulty, you find it hard to say no to other people's hopes and expectations, you get lazy and change your mind. You write a check your future self can't cash. Then you [build an identity of someone who doesn't follow through](https://jamesclear.com/identity-votes). This becomes self-fulfilling.\r\n\r\nLess promising. More doing.\r\n\r\n## Don't Flake\r\n\r\nThe old adage is \"[If you want something done, give it to a busy person](https://quoteinvestigator.com/2018/01/30/busy/)\". \r\n\r\nThat's too indirect. \r\n\r\n**If you want something done, give it to a person who gets things done.** Guess what kind of people get more opportunities?\r\n\r\n> \"If you want to stand out, set yourself apart in the world: When you say you're gonna do something, do it. **Don't flake and I will bring you business for the rest of my life.**\" - [Jerod Santo](https://twitter.com/swyx/status/1193466435177082880)\r\n\r\n## So What\r\n\r\nYou have good [reasons to not follow up](https://twitter.com/swyx/status/1313364849095655425). Health. Family. [Fear of looking spammy](https://twitter.com/latviancoder/status/1313430624624095235?s=20). Distractions. Anxiety. Lack of confidence. Cynicism. Fatalism. [Resistance](https://en.wikipedia.org/wiki/Resistance_(creativity)).\r\n\r\nSo do people who follow up. Many had more privilege than you. Some had less. They overcame it. The difference? \r\n\r\nThey understood the value of following up.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/follow-up-2do2","devToReactions":10,"devToReadingTime":2,"devToPublishedAt":"2020-10-06T10:29:38.329Z","devToViewsCount":65,"title":"Follow Up","published":true,"description":"Following up and following through is a well known formula for success. Yet people don't do it. Why?","category":"essay","tags":"Reflections, Advice","slug":"follow-up"},"title":"Follow Up","description":"Following up and following through is a well known formula for success. Yet people don't do it. Why? ","category":"essay","tags":["reflections","advice"],"slug":"follow-up","date":"2020-10-06T10:29:38.329Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/205","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/205/comments","title":"Follow Up","created_at":"2022-01-17T23:13:56Z","updated_at":"2022-01-17T23:46:59Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/205/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n*Translations: [中文](https://nextfe.com/why-tailwind-css/), [Português](https://codigofonte.com.br/artigos/por-que-usar-tailwind-css)*\r\n\r\nI'm not a Tailwind shill. I'm a [Guo Lai Ren](https://www.swyx.io/guo-lai-ren/) - someone who has changed their mind on it recently and am a happy user despite acknowledged tradeoffs. \"Crossover people\" can often be more persuasive to skeptics than born-and-bred believers. So I hope to contribute my perspective to the discussion, if you are open to it.\r\n\r\nA while ago Adam Wathan [asked](https://twitter.com/tailwindcss/status/1303740401967390720?s=20): \"Did you think Tailwind was a horrible idea until you actually built something with it?\"\r\n\r\nI [replied](https://twitter.com/swyx/status/1303769383278268416):\r\n\r\n> I once complained to @samselikoff that Tailwind caused ugly unreadable classname soup and said zero-runtime CSS-in-JS could do more with a lower learning curve.\r\n>\r\n> I was wrong on 2 counts: Tailwind is easier to learn than I thought, and CSSinJS's flexibility can be a *negative*.\r\n\r\nAfter shipping a few projects (including my [personal site](https://www.swyx.io/) and [book site](https://www.learninpublic.org/)) with [Tailwind](https://tailwindcss.com/) now, I feel I should probably jot down my thoughts on what I like about it. Since Tailwind is the predominant Utility CSS framework and the only one I've tried, I'll make no effort to distinguish the points below from the general benefits of Utility CSS (but [here's a list of others](https://css-tricks.com/need-css-utility-library/)).\r\n\r\n## TL;DR\r\n\r\n- **\"System\" Values reduce Magic Numbers**: Decrease hardcoded values, Increase consistency.\r\n- **Responsive Design in the Browser**: Prototype in browser, copy and paste to codebase, using consistent system values.\r\n- **Inlining Styles Optimizes for Change**: Make code easy to delete and move, by eliminating all reliance on the cascade.\r\n- **Inlining Styles reduces Naming**: Ship faster by solving one of the known hard problems in Computer Science!\r\n- **Zero JS & Sublinear Scaling of CSS**: Scale at O(log N), not O(N).\r\n- **Utility-First, not Utility-Only**: Respect the Principle of Least Power, use CSS-in-JS only when warranted.\r\n\r\nI also cover popular objections to Tailwind at the end with links to their arguments so you can decide for yourself.\r\n\r\n## The Utility-First Canon\r\n\r\nBefore you listen to me, you may wish to check out the most influential pieces on the \"utility classes\" revolution in CSS right now:\r\n\r\n- Adam Wathan's blogpost on [CSS Utility Classes and \"Separation of Concerns\"](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/)\r\n- Simon Vrachilotis' talk on [A Real Life Journey into the Opinionated World of Utility-First CSS](https://twitter.com/simonswiss/status/1057078025118871552?s=20) (see also: [Sarah Dayan's talk](https://www.youtube.com/watch?v=R50q4NES6Iw))\r\n\r\nI am heavily influenced by these people and others, so if I repeat some points poorly below, the fault is mine. At least I gave you the canonical sources first.\r\n\r\n## \"System\" Values reduce Magic Numbers\r\n\r\nCSS is extremely flexible, which makes it powerful, but also gives you a lot of footguns to shoot yourself with. Constraints are needed, or else we sprinkle \"magic numbers\" all over our codebase.\r\n\r\n[Magic Numbers in CSS are a bad thing](https://css-tricks.com/magic-numbers-in-css/), says Chris Coyier. He defines it to mean \"*values which “work” under some circumstances but are frail and prone to break when those circumstances change*\", but honestly any hardcoded number, like `px` in margins and media queries, or color variants, is difficult to manage well at scale. The temptation to break rules just to ship a fix is there, and the difficulty of refactoring when design requirements change is too high. If you are working by yourself, there is nothing enforcing that you stick to a consistent set of well designed number scales, which can lead to bad-looking design.\r\n\r\nThe solution, of course, is to draw only from a preset range of number values, which I call a \"system\" (note that I don't call this a \"Design System\", a debate I have no interest in getting into). Tailwind comes with a good set of font and color systems by default. Again, you could try to roll your own system with CSS variables, but the syntax for that is verbose and you still have to come up with names for classes and for variables, and you end up with a custom system that doesn't transfer across projects and probably isn't well documented. Might as well adopt a good default system by importing [Steve Schoger](https://www.steveschoger.com/speaking/) on your team.\r\n\r\n> Alternatives exist: [Styled-System](https://styled-system.com/) and [Theme UI](https://theme-ui.com) from the [jxnblk](https://jxnblk.com/)-verse are the basis for this in CSS-in-JS land.\r\n\r\n## Responsive Design in the Browser\r\n\r\n> 2021 Edit: Tailwind's new JIT mode now negates this point :( [Our discussion here](https://twitter.com/swyx/status/1371519369113649153)\r\n\r\nThis point is most relevant to developers-who-do-design: the best development workflow is to preview your site on `localhost`, make adjustments in the browser until you are happy with it, and then copy-and-paste your changes **straight into your codebase**. Let's call this the **Design in Browser** workflow.\r\n\r\nIf you want this workflow, you rule out using React's inline styling (which make you use object syntax). But let's say you do use some form of \"Write Real CSS\"™ solution like Styled-Components or Vue or Svelte scoped styles, where design-in-browser is possible. What else does Tailwind offer you?\r\n\r\n1. You can pull directly from preset \"system\" values (elaborated above) while prototyping in browser\r\n2. You can do responsive and pseudo-class design while in browser too - e.g. to apply styles at different breakpoints, or on hover or focus, you can just prefix inline, e.g. for a link, `text-green-400 hover:text-green-300 md:text-blue-400`.\r\n\r\nI did a demo of this in a recent video:\r\n\r\n{% youtube 1LYoYBeig6g %}\r\n\r\nDesigning in the Browser is not quite Bret-Victor-style [Inventing on Principle](https://www.youtube.com/watch?v=PUv66718DII), but you are getting at least closer to being able to \"play\" in context by reducing the cognitive distance yet again. With Tailwind, you can even add [transitions](https://tailwindcss.com/docs/transition-property#app) and [animations](https://tailwindcss.com/docs/animation#app) inline while you play. This is extremely underrated - we developers might offer more movement in our apps if only it were easier to prototype and add them.\r\n\r\n## Inlining Styles Optimizes for Change\r\n\r\n> IMPORTANT note: [Utility classes are NOT the same as inline styles](https://frontstuff.io/no-utility-classes-arent-the-same-as-inline-styles) - I am using \"Inlining Styles\" as a shorthand, but the reality is more nuanced and VERY in favor of utility classes.\r\n\r\nA lot of production CSS is [append only](https://css-tricks.com/oh-no-stylesheet-grows-grows-grows-append-stylesheet-problem/). This is because the **cognitive distance** between the CSS and the markup it affects is often far - sometimes in a different folder, different file, or same file but dozens of lines away. On top of that, you have to remember the CSS cascade and run every element against every matching rule, in your head. \r\n\r\nPretty soon, you have a codebase you are scared to even open! Developer velocity slows down, and eventually you back yourself into a corner where nothing less than a full rewrite will do.\r\n\r\nBy design, CSS is easy to extend. Just add specificity! But [it is not easy to delete](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to). This adds complexity, in [the best Rich Hickey sense of the word](https://www.infoq.com/presentations/Simple-Made-Easy/) (because position matters in CSS, you now have to remember all positions). It's easy to build up the house of cards, but take one thing out and the whole edifice may fall apart, and you WON'T KNOW until you check for visual regressions or emulate the browser in your head. \r\n\r\nYou can use tooling (CSS modules, static CSS in JS, Vue or Svelte [scoped styles](https://svelte.dev/blog/the-zen-of-just-writing-css)) or naming conventions (BEM, etc) to control specificity, but that reduces the cognitive distance rather than eliminates it. The only option with zero \"spooky action at a distance\" is inline styling. Inline styling [optimizes for change](https://overreacted.io/optimized-for-change/).\r\n\r\n\"Galaxy Brain\" time: Tailwind offers the developer velocity benefits of inline styles without its downsides.\r\n\r\n> Alternatives exist: Other solutions like Emotion's `css` prop and `styled-jsx` offer similar benefits of inline styles, but they run into the standard CSS in JS downsides\r\n\r\n[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hyqokn1sf7yur7t48j73.jpg)](https://www.infoq.com/presentations/Simple-Made-Easy/)\r\n\r\n## Inlining Styles reduces Naming\r\n\r\n[Naming Things](https://www.swyx.io/how-to-name-things/) is a known hard problem. We waste a lot of time bickering over naming classes. With Styled-Components, you often write a bunch of intermediate styled components you have to name. With [BEM](http://getbem.com/naming/), we replace one naming problem with three and a half naming problems (I've had PRs held up on whether I should've used `--` or `__` - what a total waste of time). How many millions in developer-hours do we waste every year bickering over names?\r\n\r\nWith utility CSS we significantly reduce the total number of names in our codebase, and perhaps more importantly, the number of names we have to independently invent and remember. This feels minor until you've worked on a codebase where it isn't. What price are you willing to pay to eliminate one of the known known hard problems? I'm not kidding - this is a conversation worth having. Names don't matter to machines but they matter to humans.\r\n\r\nThe tradeoff is you have to learn the names from the utility CSS framework. `-mb-5` and `space-x-reverse` aren't parseable without docs. The difference is that traditional CSS naming is bespoke per project, whereas you learn Tailwind once and can use them in every project. Yes, you could try to roll your own utilities, but Tailwind's naming is probably more thoughtfully designed than whatever you come up with.\r\n\r\n> Alternatives exist: Emotion's `css` prop and `styled-jsx` also let you skip naming.\r\n\r\n## Zero JS & Sublinear Scaling of CSS\r\n\r\nA lot of ink has been spilled about the performance tradeoffs of using CSS in JS, and their mitigating factors. You can check my [What's New in React talk](https://www.youtube.com/watch?v=Qox56z4xH6o) for more, but rest assured it is hotly debated with passionate, intelligent people on both sides. But we all agree that the less JS you ship, the better, and we also agree that byte-for-byte, shipping 1kb of JS has a far bigger performance impact than 1kb of CSS. Those are well understood.\r\n\r\nThe point I'm keen on exploring here is that many CSS and CSS in JS solutions scale linearly with the number of components in your app. Because CSS scopes each declaration to your identifier, you have to repeat it everywhere you want to apply it. This is how we ended up with >50 declarations of `font-weight: bold` at a previous workplace. Individually, these don't matter, but in bulk, they add up.\r\n\r\n> \"On our old site, we were loading more than 400 KB of compressed CSS (2 MB uncompressed)... We didn’t start out with that much CSS; it just grew over time and rarely decreased. This happened in part because every new feature meant adding new CSS.\" - [Facebook Engineering](https://engineering.fb.com/web/facebook-redesign/)\r\n\r\nYou can defer this problem with code-splitting, but eventually people ship and implement hacky workarounds to the point where the CSS gets out of control again (particularly if it is append-only!). \r\n\r\nThe solution here is (arguably!) to ship \"atomic\" CSS, so that your CSS scales by `O(log N)` instead of `O(N)` (where `N` is your number of components). [Facebook's unreleased stylex library](https://twitter.com/wongmjane/status/1187411809667436550) lets you write CSS in JS and generates atomic CSS for you, but you could also just choose to hand-write atomic CSS, which is what utility frameworks like Tailwind guide you do.\r\n\r\nTo be fair, I put this point at the bottom, because it is unlikely that most apps get to the scale where this really starts to matter, especially when taking [gzip](https://en.wikipedia.org/wiki/Gzip) into account. However, like with all optimizations, these things are premature until they are not.\r\n\r\n## Utility-First, not Utility-Only\r\n\r\nOn top of all the above benefits, you can STILL use those other solutions for benefits you need. For example, nothing is truly as powerful as CSS in JS, where you can dynamically change out media query values and entire rulesets based on arbitrary JavaScript. \r\n\r\nHowever, the real life usecases in which you *actually* need to do this are limited, and the costs (in JS weight, for example) dominate when you just use it for static styling. Going utility-*first* respects the [Principle of Least Power](https://en.wikipedia.org/wiki/Rule_of_least_power) here.\r\n\r\nNon-CSS-in-JS solutions are often also easier to debug. \"Easy\" here is of course subjective. But when things go wrong with CSS in JS solutions, I have often found myself getting to a point where I had to look up docs, then GitHub issues, then diving into `node_modules`, which is a lot of yak shaving away from what I really want to be doing. When things go wrong with Tailwind, I know that I'm either generating the classname I expected, or I am not. There are much fewer points of variance. But it stands to reason that you should use the easier-to-debug solution most of the time if you can.\r\n\r\n## The Bad Parts\r\n\r\nIs Tailwind perfect? No, of course not. But the good outweighs the bad:\r\n\r\n- Setting up Tailwind means fiddling with build tooling. [This is getting easier](https://dev.to/swyx/how-to-set-up-svelte-with-tailwind-css-4fg5/), and is comparable with tooling required for similar performance with other solutions, but is unacceptable to some.\r\n- The Tailwind API surface area is big and [constantly growing](https://www.youtube.com/channel/UCOe-8z68tgw9ioqVvYM4ddQ). It's understandable (it has to map all of CSS!) but also can be tiring to learn and keep up with. The end result is you pay some upfront learning cost for hopeful long term productivity gain. Nice, but it isn't a pure win.\r\n- The classnames do get rather verbose. It'd be nice to have shorthands like `md:hover:(text-green-300 underline border-5)`, but then that'd just add API surface area. (**Edit from the future: [this is now implemented in `twind`](https://github.com/tw-in-js/twind)** - the CSS in JS interpretation of tailwind!) Perhaps use of `@apply` is warranted, or just some smart [typography](https://github.com/tailwindlabs/tailwindcss-typography). But overall I find that the ease of editing things inline overrides superficial aesthetic concerns. Users certainly don't care.\r\n- CSS abstraction leak - Tailwind let's you use classes like inline styles, but they are NOT inline styles in one critical respect - what happens when they clash. Eg with 'm-4 m-2', the \"m-4\" takes precedence. The order of classes generated by Tailwind matters, even though it is invisible to you. This is an abstraction leak. If you are trying to build reusable components for an in-house design system, this runs counter to that. You may wish to explore Chakra UI instead. \r\n- Project governance owned by Tailwind Labs - they are of course the project originators and great stewards for now, but it isn't an egalitarian process with established conduct like the [CSSWG](https://en.wikipedia.org/wiki/CSS_Working_Group). As with all BDFL relationships, it's fine until the day you disagree with them.\r\n- (minor) The VS Code extension still isn't as robust as it could be - requiring a space to initiate and often just not working. But [Brad Cornes](https://blog.tailwindcss.com/welcoming-brad-cornes-to-the-tailwind-team) is on it!\r\n\r\n\r\n## Conclusion: The Goldilocks Styling Solution\r\n\r\nAbove all I think choosing Tailwind is a matter of personal preference rather than being the objective right answer. There is a wide spectrum of styling solutions from super opinionated to not. This is [how I put it recently](https://twitter.com/swyx/status/1253303455961079810/):\r\n\r\n- Premade Component Libraries are too restrictive, Vanilla CSS is too permissive\r\n- CSS in JS is too heavy, inline CSS is too underpowered\r\n- We want design system constraints, but the way we tap into design systems have been very heavy handed (bound to framework)\r\n- [Ben Holmes](https://twitter.com/BHolmesDev/status/1314036040697610241?s=20): \"a solid in-between for designers that want freedom and devs that want structure\". \r\n\r\nTailwind is for those who desire a styling solution that is \"not too hot, but not too cold\".\r\n\r\nThe Goldilocks solution.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/l49w2xqe9pakqt4153vs.png)\r\n\r\n## Appendix: Opposite Perspectives\r\n\r\n- Max Stoiber: [Why I Write CSS in JavaScript](https://mxstbr.com/thoughts/css-in-js)\r\n- Johan Ronsse: [Why you’ll probably regret using Tailwind](https://johanronsse.be/2020/07/08/why-youll-probably-regret-using-tailwind/)\r\n- Aleksandr Hovhannisyan: [Why I Don't Like Tailwind CSS](https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/) - [my responses here](https://news.ycombinator.com/item?id=26428678)\r\n- Jared White: [Why Tailwind CSS isn't for Me](https://dev.to/jaredcwhite/why-tailwind-isn-t-for-me-5c90)\r\n- If you have a notable \"Why Not to Use Tailwind\" or \"Why I use something else despite knowing about Tailwind\" post, let me know and I'll include it here\r\n- [On a recent Svelte Radio](https://twitter.com/SvelteSociety/status/1311700640939175936?s=20) (52mins in), [Kev](https://twitter.com/kevmodrome) mentioned that people are having tooling integration difficulties. [This will be better documented over time.](https://twitter.com/swyx/status/1303383805776949249?s=20)\r\n\r\n\r\n## Addressing Objections (Jan 2021 edit)\r\n\r\n- **But the HTML is super ugly**: code aesthetics should take a backseat to development velocity and ability to ship better UX.\r\n- **But CSS Variables Exist!**: yes, but you don't get the uninterrupted workflow of inline styles. `margin-bottom: var(--spacing-8)` is not equivalent to `class=\"mb-8\"`. \r\n- **But Web Components Exist!**: Of course you can use both together, but how much of your app is made up of web components, really? Tailwind is a great choice of base for those who are working on apps that aren't majority WC's.\r\n- **I don't like `@apply`**: Good, you're not supposed to use it too much anyway. But downleveling `@apply` to its constituent CSS is a trivial task.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/why-tailwind-css-2o8f","devToReactions":350,"devToReadingTime":12,"devToPublishedAt":"2020-10-04T02:48:22.841Z","devToViewsCount":15444,"title":"Why Tailwind CSS","published":true,"description":"Why I changed my mind on Tailwind CSS, and why I now consider it the Goldilocks Styling Solution","category":"essay","tags":"Tech, CSS, Tailwind, Reflections","slug":"why-tailwind","canonical_url":"https://www.swyx.io/why-tailwind","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/ubgj091em2q1ri9mmwth.png"},"title":"Why Tailwind CSS","description":"Why I changed my mind on Tailwind CSS, and why I now consider it the Goldilocks Styling Solution ","category":"essay","tags":["tech","css","tailwind","reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/ubgj091em2q1ri9mmwth.png","canonical":"https://www.swyx.io/why-tailwind","slug":"why-tailwind","date":"2020-10-04T02:48:22.841Z","readingTime":"12 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/206","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/206/comments","title":"Why Tailwind CSS","created_at":"2022-01-17T23:13:58Z","updated_at":"2022-11-12T20:39:29Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/206/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n[The Fallacy of Composition](https://en.wikipedia.org/wiki/Fallacy_of_composition) happens when you assume something that is true for one person, is also true for the entire population. \r\n\r\nA trivial example looks like this: If someone stands up out of their seat at a football game, they can see better. The Fallacy would conclude that if everyone stood up, they would **all** be able to see better.\r\n\r\n\r\n<a href=\"https://i1.wp.com/marketbusinessnews.com/wp-content/uploads/2018/05/Fallacy-of-Composition-example.jpg?fit=731%2C641&ssl=1\"><img src=\"https://i1.wp.com/marketbusinessnews.com/wp-content/uploads/2018/05/Fallacy-of-Composition-example.jpg?fit=731%2C641&ssl=1\" width=400></a>\r\n\r\nThis is taught in every introductory macroeconomics class as the general form of the [paradox of thrift](https://en.wikipedia.org/wiki/Paradox_of_thrift) (*when there is a recession, you should save more to conserve your finances, but if everyone saves more, it deepens the recession*). But not everyone learns economics, and not every economics student understands it deeply enough to realize: **this is more common sense than it is economics**.\r\n\r\n> Aside: Yes, common sense should be taught in schools, dont @ me!\r\n\r\n## Programming Languages\r\n\r\nDevelopers might be more familiar with the famous [Bjarne Stroustrup on managing the growth of C++](https://www.stroustrup.com/P0977-remember-the-vasa.pdf): \r\n\r\n> \"Individually, many (most?) proposals make sense. Together they are insanity to the point of endangering the future of C++.\"\r\n\r\nIf you are a fan of Guy Steele's talk on \"Growing a Language\" ([my notes here](https://www.swyx.io/notes-on-growing-a-language-by-guy-steele-5501/)), this may sound familiar. Java has a number type, but there are reasonable requests to add other important number types: complex numbers, rational numbers, intervals, vectors, matrices, and so on. He concludes:\r\n\r\n> \"I might say “yes” to each one of these, but it is clear that I must say “no” to all of them!\"\r\n\r\n## It's Everywhere\r\n\r\nThe Fallacy of Composition isn't just limited to language design:\r\n\r\n- You commit it when you [apply linear intuition to exponential growth](https://twitter.com/swyx/status/1308472657097027584?s=20). \r\n- You commit it when you apply overly reductionist techniques like [the 5 Why's](https://news.ycombinator.com/item?id=19625754) to complex systems, failing to understand [necessary but only jointly sufficient](https://www.kitchensoap.com/2012/02/10/each-necessary-but-only-jointly-sufficient/) causal dependencies. \r\n- You commit it [when you find a local performance optimization](https://twitter.com/search?q=react%20purecomponent%20why&src=typed_query) and demand that it be applied at the language or framework level for the whole app.\r\n- You commit it when you take a tangential indication of product traction and scale it up only to find it doesn't work. \r\n- You commit the opposite when you float a shitty MVP and abandon a great idea because the shitty MVP was shitty.\r\n\r\nBy the way, a lot of TED Talk style speaking works this way - tell a personal anecdote, make that analogy to the problem you're trying to solve, introduce the first bit of halfway credible research that supports the story, applause. Ted Talks churn out Fallacies of Composition at industrial scale. If they were all true we would have achieved Nirvana by now. \r\n\r\nSimilar quotes:\r\n\r\n> \"Mathematics requires a small dose, not of genius, but of an imaginative freedom which, in a larger dose, would be insanity.\" - *[Angus Rogers](https://news.ycombinator.com/item?id=8534918), via Grant Sanderson of ThreeBlue1Brown*\r\n\r\nThe other day I made an offhand comment to my friend [Joe](https://twitter.com/jsjoeio) about how the recent trend of Indie Maker group challenges (like [his](https://twitter.com/jsjoeio/status/1296637530024980480?s=20)) can be counterproductive. He didn't get it right away, so I had to write this post. I think, if you took a better look at the things you believe and advise people to do, you'll find many, many more examples of the Fallacy of Composition.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/beware-the-fallacy-of-composition-2fmn","devToReactions":55,"devToReadingTime":3,"devToPublishedAt":"2020-10-01T05:48:50.890Z","devToViewsCount":694,"title":"Beware The Fallacy of Composition","published":true,"date":"2020-10-01T00:00:00.000Z","description":"Many things that make sense individually don't make sense as a group.","slug":"composition-fallacy","category":"essay","tags":["Principles","Advice","Mental Models"]},"title":"Beware The Fallacy of Composition","description":"Many things that make sense individually don't make sense as a group. ","category":"essay","tags":["principles","advice","mental models"],"slug":"composition-fallacy","date":"2020-10-01T00:00:00.000Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/207","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/207/comments","title":"Beware The Fallacy of Composition","created_at":"2022-01-17T23:13:59Z","updated_at":"2022-01-17T23:51:25Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/207/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Lessons and Regrets from Shipping My $50000 Coronavirus Side Project","slug":"lessons-and-regrets-50k","categories":["CodingCareer"],"description":"This talk is about my personal journey shipping my side project, LearnInPublic.org, from April to July this year. It involves both technical and nontechnical takeaways, from coding and designing the landing page and ecommerce fulfilment, to writing and marketing the book, all as a solo dev. Shipping side projects for money is a dream for many dev and I wanted to share what I learned doing mine.","instances":[{"venue":"JS.LA","date":"2020-09-29","video":"https://www.youtube.com/watch?v=LJCyS8bFY80"}],"category":"talk","date":"2020-09-29T00:00:00.000Z"},{"title":"SWYX on Shoptalk Show Podcast","slug":"coding-career-shoptalk-show","tags":["Careers"],"venues":"Shoptalk Show Podcast","date":"2020-09-28T00:00:00.000Z","url":"https://shoptalkshow.com/432/","description":"Shawn Wang, known as Swyx, talks with Dave and Chris about his career path from finance to coding, and now in developer experience. They chat about serverless functions, React, getting a broad sense of technology, Wang's Coding Career Handbook, what's next for SSR, checking out Vite, and what exactly is DevX / developer experience?","category":"podcast"},{"type":"blog","content":"\r\nI started reading [Node.js Design Patterns](https://www.nodejsdesignpatterns.com/) this week. I got the Third Edition, and have not spent any time looking into what's changed from prior editions. The first 6 chapters cover fundamental knowledge, before getting into the meaty named Design Patterns, so these notes are from that first \"half\" of the book.\r\n\r\n## 1. `libuv` and the Reactor Pattern\r\n\r\n`libuv` is something I've often heard about as a low level Node.js library, but now I have a glimpse of what it does for us. As the book says:\r\n\r\n> Libuv represents the low-level I/O engine of Node.js and is probably the most important component that Node.js is built on. Other than abstracting the underlying system calls, libuv also implements **the reactor pattern**, thus providing an API for creating event loops, managing the event queue, running asynchronous I/O operations, and queuing other types of task.\r\n\r\nThe [Reactor pattern](https://en.wikipedia.org/wiki/Reactor_pattern), together with demultiplexing, [event queues and the event loop](https://www.youtube.com/watch?v=8aGhZQkoFbQ), is core to how this works - a tightly coordinated dance of feeding async events into a single queue, executing them as resources free up, and then popping them off the event queue to call callbacks given by user code.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/mj0r6gwfwiv5nqcfhkn5.png)\r\n\r\n## 2. Module Design Patterns\r\n\r\nI am superficially familiar with the differences between CommonJS modules and ES Modules. But I liked the explicit elaboration of 5 module definition patterns in CommonJS:\r\n\r\n- Named exports: `exports.foo = () => {}`\r\n- Exporting a function: `module.exports = () => {}`\r\n- Exporting a class: `module.exports = class Foo() {}`\r\n- Exporting an instance: `module.exports = new Foo()` which is *like* a singleton, except when it is not because of multiple instances of the same module.\r\n- Monkey patching other modules (useful for [nock](https://github.com/nock/nock))\r\n\r\nIn ES Modules, I enjoyed the explanation of \"read-only live bindings\", which will look weird to anyone who has never seen it and has always treated modules as stateless chunks of code:\r\n\r\n```js\r\n// counter.js\r\nexport let count = 0\r\nexport function increment () {\r\n count++ \r\n}\r\n\r\n// main.js\r\nimport { count, increment } from './counter.js'\r\nconsole.log(count) // prints 0\r\nincrement()\r\nconsole.log(count) // prints 1\r\ncount++ // TypeError: Assignment to constant variable!\r\n```\r\n\r\nThis mutable module internal state pattern is endemic in [Svelte and Rich Harris' work](https://twitter.com/swyx/status/1221586490674696193?s=20) and I enjoy how simple it makes code look. I don't know if there are scalability issues with this pattern but so far it seems to work fine for ES Modules people.\r\n\r\nThe last important topic I enjoyed was ESM and CJS interop issues. `ESM` doesn't offer `require`, `__filename` or `__dirname`, so you have to reconstruct them if needed:\r\n\r\n```js\r\nimport { fileURLToPath } from 'url'\r\nimport { dirname } from 'path'\r\nconst __filename = fileURLToPath(import.meta.url) \r\nconst __dirname = dirname(__filename)\r\n\r\nimport { createRequire } from 'module'\r\nconst require = createRequire(import.meta.url)\r\n```\r\n\r\nESM also cannot natively import JSON, as of the time of writing, whereas CJS does. You can work around this with the `require` function from above:\r\n\r\n```js\r\nimport { createRequire } from 'module'\r\nconst require = createRequire(import.meta.url) \r\nconst data = require('./data.json') \r\nconsole.log(data)\r\n```\r\n\r\nDid you know that? I didn't!\r\n\r\n> In semi-related news - [Node v14.13 will allow named imports from CJS modules](https://twitter.com/MylesBorins/status/1311033983824793601?s=20) - probably the last step in ESM \"just working\" in Node.js\r\n\r\n## 3. Unleashing Zalgo\r\n\r\nAPIs are usually either sync or async in Node.js, but TIL you can design APIs that are *both*:\r\n\r\n```js\r\nfunction createFileReader (filename) { \r\n const listeners = [] \r\n inconsistentRead(filename, value => {\r\n listeners.forEach(listener => listener(value)) \r\n })\r\n return {\r\n onDataReady: listener => listeners.push(listener) \r\n }\r\n}\r\n```\r\n\r\nThis looks innocent enough, except when you use it as async and then sync:\r\n\r\n```js\r\nconst reader1 = createFileReader('data.txt') // async\r\nreader1.onDataReady(data => {\r\n console.log(`First call: ${data}`)\r\n const reader2 = createFileReader('data.txt') // sync\r\n reader2.onDataReady(data => {\r\n console.log(`Second call: ${data}`) \r\n })\r\n})\r\n// only outputs First call - never outputs Second call\r\n```\r\n\r\nThis is because module caching in Node makes the first call async and the second call sync. [izs famously called this \"releasing Zalgo\"](https://blog.izs.me/2013/08/designing-apis-for-asynchrony) in a blogpost.\r\n\r\nYou can keep Zalgo caged up by:\r\n\r\n- using direct style functions for synchronous APIs (instead of [Continuation Passing Style](https://en.wikipedia.org/wiki/Continuation-passing_style))\r\n- make I/O purely async by only using async APIs, using CPS, and deferring synchronous memory reads by using `process.nextTick()`\r\n\r\nThe same line of thinking can also be done for EventEmitter Observers as it is for Callbacks.\r\n\r\n> Callbacks should be used when a result must be returned in an asynchronous way, while events should be used when there is a need to communicate that something has happened.\r\n\r\nYou can combine both the Observer and Callback patterns, for example with the [`glob` package](https://www.npmjs.com/package/glob) which takes both a callback for its simplier, critical functionality and a `.on` for advanced events.\r\n\r\nA note on ticks and microtasks:\r\n\r\n- `process.nextTick` sets up a microtask, which executes just after the current operation and before any other I/O\r\n- whereas `setImmediate` runs after ALL I/O events have been processed. \r\n- `process.nextTick` executes earlier, but runs the risk of I/O [starvation] (https://en.wikipedia.org/wiki/Starvation_(computer_science)) if takes too long.\r\n- `setTimeout(callback, 0)` is yet another phase behind `setImmediate`.\r\n\r\n## 4. Managing Async and Limiting Concurrency with `async`\r\n\r\nIt's easy to spawn race conditions and accidentally launch unlimited parallel execution bringing down the server, with Node.js. The [Async](https://github.com/caolan/async) library gives battle tested utilities for defining and executing these issues, in particular, queues that offer limited concurrency.\r\n\r\nThe book steps you through 4 versions of a simple web spider program to develop the motivations for requiring managing async processes and describe the subtle issues that present themselves at scale. I honestly cant do it justice, I didn't want to just copy out all the versions and discussions of the web spider project as that is a significant chunk of the book, you're just gonna have to read thru these chapters yourself. \r\n\r\n## 5. Streams\r\n\r\nI've often commented that [Streams are the best worst kept secret of Node.js](https://twitter.com/swyx/status/1201528574236217345). Time to learn them. Streams are more memory and CPU efficient than full buffers, but they are also more *composable*.\r\n\r\nEach stream is an instance of `EventEmitter`, streaming either binary chunks or discrete objects. Node offers [4 base abstract stream classes](https://nodejs.org/api/stream.html#stream_api_for_stream_consumers):\r\n\r\n- `Readable` (where you can read in [flowing (push) or paused (pull) mode](https://nodejs.org/api/stream.html#stream_two_reading_modes))\r\n- `Writable` - you're probably familiar with `res.write()` from Node's `http` module\r\n- `Duplex`: both readable and writable\r\n- `Transform`: a special duplex stream with two other methods: `_transform` and `_flush`, for data transformation\r\n- `PassThrough`: a `Transform` stream that doesnt do any transformation - useful for observability or to implement late piping and lazy stream patterns.\r\n\r\n```js\r\nimport { PassThrough } from 'stream'\r\nlet bytesWritten = 0\r\nconst monitor = new PassThrough() \r\nmonitor.on('data', (chunk) => {\r\n bytesWritten += chunk.length \r\n})\r\nmonitor.on('finish', () => { \r\n console.log(`${bytesWritten} bytes written`)\r\n})\r\nmonitor.write('Hello!') monitor.end()\r\n\r\n// usage\r\ncreateReadStream(filename)\r\n .pipe(createGzip())\r\n .pipe(monitor) // passthrough stream!\r\n .pipe(createWriteStream(`${filename}.gz`))\r\n```\r\n\r\nizs recommends [minipass](https://www.npmjs.com/package/minipass) which implement a PassThrough stream with some better features. Other useful stream utils:\r\n\r\n- https://github.com/maxogden/mississippi\r\n- https://www.npmjs.com/package/streamx\r\n- You can make streams lazy (create proxies for streams, so the stream instance isn't until some piece of code is consuming) with [lazystream](https://www.npmjs.com/package/lazystream). \r\n\r\nAlthough the authors do recommend that piping and error handling be best organized with the native [stream.pipeline](https://nodejs.org/api/stream.html#stream_stream_pipeline_source_transforms_destination_callback) function.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/5-tils-about-node-js-fundamentals-from-the-node-js-design-patterns-book-4dh2","devToReactions":164,"devToReadingTime":5,"devToPublishedAt":"2020-09-27T08:48:33.316Z","devToViewsCount":8282,"title":"5 TILs about Node.js Fundamentals from the Node.js Design Patterns Book","published":true,"description":"5 Things I Learned about Node.js Fundamentals from the Node.js Design Patterns Book","category":"snippet","tags":"Tech, TIL, Nodejs, JavaScript, Design Patterns","slug":"til-node-fundamentals-design-patterns-book","canonical_url":"https://swyx.io/til-node-fundamentals-design-patterns-book"},"title":"5 TILs about Node.js Fundamentals from the Node.js Design Patterns Book","description":"5 Things I Learned about Node.js Fundamentals from the Node.js Design Patterns Book ","category":"snippet","tags":["tech","til","nodejs","javascript","design patterns"],"canonical":"https://swyx.io/til-node-fundamentals-design-patterns-book","slug":"til-node-fundamentals-design-patterns-book","date":"2020-09-27T08:48:33.316Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/208","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/208/comments","title":"5 TILs about Node.js Fundamentals from the Node.js Design Patterns Book","created_at":"2022-01-17T23:14:02Z","updated_at":"2022-01-17T23:44:52Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/208/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"The Operating System of You","slug":"operating-system-of-you","categories":["Careers"],"description":"Developers are mostly humans that run the same \"hardware\". Therefore most performance differences, especially the ones we can control, are down to our \"OS\" - our conscious prioritization and processing - and \"firmware\" - our unconscious personality and reactions. What can we do to better take care of our \"hardware\", and what does running better \"software\" look like?","instances":[{"venue":"CascadiaJS","description":"the truncated 20 min one that actually ran for the conference","url":"https://2020.cascadiajs.com/speakers/shawn-wang","video":"https://www.youtube.com/watch?v=KBi_LZTCrgU","date":"2020-09-24"},{"venue":"CascadiaJS","description":"my full length, 25 min recording.","slides":"https://docs.google.com/presentation/d/1z43axgETtWGqPFlRDmqU11gb3aJnEH0y3MgSV5fchpM/edit?usp=sharing","url":"https://2020.cascadiajs.com/speakers/shawn-wang","video":"https://www.youtube.com/watch?v=D-Sj6jo4o1I","date":"2020-09-01"},{"venue":"BelgiumJS","video":"https://www.youtube.com/watch?v=IzK4IxHv3W0","slides":"https://docs.google.com/presentation/d/1iHi3tULjAWeMpfjzpKtix-vzRItRSC4P_Osl0hkm_aY/edit?usp=sharing","date":"2020-06-23"}],"category":"talk","date":"2020-09-24T00:00:00.000Z"},{"type":"blog","content":"\nA lightning fast overview of everything you need to know to set up a REST endpoint with full CRUD capability with AWS Lambda, DynamoDB and AWS Amplify in 2 minutes.\n\nDev.to embed: {% youtube 8-wJilYucnI %}\n\n- YouTube: https://youtu.be/8-wJilYucnI\n- Github: https://github.com/sw-yx/amplifycrud-demo\n- Guide: https://docs.amplify.aws/guides/api-rest/form-api-with-dynamodb-and-lambda/q/platform/js\n\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/rest-endpoint-crud-with-aws-lambda-and-dynamodb-in-2-minutes-2ldm","devToReactions":20,"devToReadingTime":1,"devToPublishedAt":"2020-09-23T14:31:01.229Z","devToViewsCount":267,"title":"REST Endpoint + CRUD with AWS Lambda and DynamoDB in 2 minutes","published":true,"description":"A lightning fast overview of everything you need to know to set up a REST endpoint with full CRUD capability with AWS Lambda, DynamoDB and AWS Amplify in 2 minutes.","tags":"AWS","slug":"amplify_rest_crud","canonical_url":"https://www.swyx.io/writing/amplify_rest_crud"},"title":"REST Endpoint + CRUD with AWS Lambda and DynamoDB in 2 minutes","description":"A lightning fast overview of everything you need to know to set up a REST endpoint with full CRUD capability with AWS Lambda, DynamoDB and AWS Amplify in 2 minutes. ","category":"note","tags":["aws"],"canonical":"https://www.swyx.io/writing/amplify_rest_crud","slug":"amplify_rest_crud","date":"2020-09-23T14:31:01.229Z","readingTime":"1 minute","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/209","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/209/comments","title":"REST Endpoint + CRUD with AWS Lambda and DynamoDB in 2 minutes","created_at":"2022-01-17T23:14:04Z","updated_at":"2022-01-17T23:45:30Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/209/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"React Podcast","slug":"reactpodcast2020","categories":["React"],"description":"swyx and Chantastic talk the state of React and the Coding Career Handbook.","instances":[{"venue":"React Podcast","date":"2020-09-17","video":"https://www.youtube.com/watch?v=GSl2CbF77GM"}],"category":"talk","date":"2020-09-17T00:00:00.000Z"},{"title":"Typesafe, Fullstack React","slug":"aws-typesafe-fullstack-react","categories":["AWS"],"description":"A live coding talk given at React Global Summit 2020, with React, TypeScript GraphQL with an AWS Amplify backend.","instances":[{"venue":"React Summit","date":"2020-09-17","tweet":"https://twitter.com/swyx/status/1305994389362106370?s=20","video":"https://www.youtube.com/watch?v=ja6meOLHjIg"},{"venue":"Reactathon","date":"2020-12-08","video":"https://www.youtube.com/watch?v=KgTW0xfyr9A&t=17107s"}],"category":"talk","date":"2020-09-17T00:00:00.000Z"},{"type":"blog","content":"\na16z recently dropped a podcast that every developer relations professional needs to digest: \"[a16z Podcast: Measuring & Managing Community Orgs, Developer Relations and Beyond](https://a16z.com/2020/08/30/community-developer-relations-measurement-leadership-alignment-best-practices-success/)\". \n\n\n2021 Update: this is now given as a talk on GitHub's OCTO speaker series:\n\n{% youtube ycKPJ_27cYo %}\n\nThis is audio from a workshop held in 2018 - no video is available, but I was able to obtain a copy of slides from Amir Shevat, the presenter. Amir formerly was the VP of Product and Developer Experience at Twitch and former Director of Developer Relations at Slack, and he was previously an evangelist at Microsoft and Google. So... quite a resume.\n\n## TLDR\n\nTop takes for the TL;DR crowd:\n\n- Most startups don't need devrel - but that can change once you start doing integrations\n- Product feedback is the most impt job - put devrel in product org, triage top 3 issues EVERY WEEK\n- Decide on Breadth vs Depth and hire accordingly\n\nGrowing Dev Community:\n\n- Offer fun, growth, belonging\n- People want recognition - put their names in badges and release notes and make it fun\n- Dinner with community leaders EVERY MONTH\n- Swag works\n\nMake docs/site easy to contribute to, create a pipeline to grow contributors.\n\n## Notes\n\n- When should Startups start Devrel?\n - Only do it if you HAVE to. Startups need to save their budget for engineering hires.\n - Devrel is expensive, it is a one-way door. \n - More than 90% of startups don't need devrel.\n - It IS required when you are building a developer platform, when they are your users.\n - You also want it when developers drive value for the core audience: Slack started without Devrel, but quickly opened one when they discovered that users' top favorite thing about Slack was the integrations - built by developers.\n- How to Devrel?\n - Advocacy: 1 to many. Create dev tools/experience/awareness.\n - Partnership: 1 to 1. Create great partners releasing on your platform. \n - Enterprise Architects: Post sales support.\n - Content Writers: Docs. Measure this team by \"mean time to hello world\".\n - Voice of Developers: The job of a devrel is to inspire devs (sell the reason), educate them (tutorial), enable (tools, sdks, api, devtools), but the most important thing is **feedback**. Evangelists don't take feedback. Never hire evangelists, hire advocates to give bidirectional flow of info.\n- Developer Engagement\n - Dev Funnel: Interested -> Trying -> Testing -> Prod -> Paying\n - Nail 2 things: Measurement (how people move thru your funnel), and Levers (what activities you can do to move them thru).\n - People often measure the wrong things:\n - Developers \"engaged/touched\". Who cares? If it doesn't move anything it is an empty metric.\n - Developers registered. Who cares? Hackable. You'll turn devrel into salespeople. Devs don't want to talk to sales people.\n - Right metric: Weekly active developers, and % of paying customers who are using the platform. You also want diversification of integration usage as well.\n - Decide on breadth vs depth - few high value partners or broad? Choose partners who can be your \"lighthouse wins\" - your partners who can tell your story - esp if they make money with your platform.\n- Where in the org to put Devrel?\n - Put it under product - gives the feedback loop\n - if put under engineering - will compete against engineers\n - if under sales - becomes sales\n - if budget comes from marketing - devrel becomes marketing\n- The future is Streaming? Devs want to see another dev at work, live\n \n\n## Q&A with Amir and Mikeal Rogers\n\n- Be careful about paying for developer interactions - \"best way to ruin a marriage is to pay for sex\". Can backfire really hard. Devs want belonging, fun, growth - tie it into overall vision.\n- Who to hire first? Depends on breadth vs depth.\n - Breadth: Content Writers and Advocates\n - Depth: Partner Engs\n- Interview: build on the platform, describe how the platform sucks. Seek empathy, willingness to admit room for improvement.\n- How to choose between easy to measure but less effective things vs hard to measure but potentially more impactful things? Do the right things over the easy to measure things. Sometimes it can take >6 months for developers to try you out after first hearing about you.\n- Swag and dinner expenses are worth it. Slack socks worked great. **Creates belonging**.\n- Devrel know how to message to developers, have the most empathy. If you don't build the feedback loop to product, will create a lot of frustration. **At Slack, every week both support and devrel can bring 3 issues to product, and product HAS to triage them.** Every week there is a PM accountable.\n- KPI to describe health of community: If a community leader leaves, how likely is the community to disperse? A community lead needs to have an apprentice, a second in command. **Dinner with community leaders every month** - to engage them.\n- Big Partners are great for initial launch - beta program before launch is high value, low cost. Bring developers to the office to do what you ask them to do - it's humbling to watch the confusion. Cost $50 of amazon vouchers.\n- How to trust your team? Tie them to a single metric: Twitter reactions -> blogposts -> landing on dev sites. \"Show growth of 20% week on week\" (!!!?!) \n- https://devstats.cncf.io/\n - amount of time to get a response in an issue\n - how long does an issue take to get resolved\n - connecting open source to a service - can measure that\n- Application devrel vs Core devrel\n - People contribute to your OSS because they want recognition, some incentives on your platform. \n - Don't assume devs are going to show up with all the skills they need to contribute - need to build a pipeline to get there\n - Make docs and website very easy to contribute to. \n - Most people show up to fix 1 thing, but they stick around bc of community. It's not even about external recognition - internal recognition can be enough, if they did something hard that is recognized by core devs.\n - **People like to see their names pop up in badges.**\n- Developer as customer vs Developer as community member - there is a lot of overlap\n - As Customer: it's about value exchange, e.g. Twilio, Stripe\n - As Community Members: it's like \"miniemployees\" - they are kind of working for you - it's about fun, growth, and belonging. \n- **Create release notes that are really funny**, helps to make feeling that you aren't \"managing\" the community, you're a **member** of the community. You can't \"manage\" a community from the outside - you have to be a part of it.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/notes-from-amir-shevat-on-measuring-managing-developer-relations-4geo","devToReactions":30,"devToReadingTime":4,"devToPublishedAt":"2020-09-16T18:40:08.582Z","devToViewsCount":404,"title":"Notes from Amir Shevat on Measuring & Managing Developer Relations","published":true,"description":"Notes from an a16z podcast about developer relations that I thought was valuable","tags":"DevRel","slug":"a16z_devrel_amir_shevat","canonical_url":"https://www.swyx.io/writing/a16z_devrel_amir_shevat"},"title":"Notes from Amir Shevat on Measuring & Managing Developer Relations","description":"Notes from an a16z podcast about developer relations that I thought was valuable ","category":"note","tags":["devrel"],"canonical":"https://www.swyx.io/writing/a16z_devrel_amir_shevat","slug":"a16z_devrel_amir_shevat","date":"2020-09-16T18:40:08.582Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/210","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/210/comments","title":"Notes from Amir Shevat on Measuring & Managing Developer Relations","created_at":"2022-01-17T23:14:06Z","updated_at":"2022-01-17T23:45:31Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/210/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n*This is the blog form of a talk I gave at React Summit and Reactathon 2020*\r\n\r\n{% youtube ja6meOLHjIg %}\r\n\r\n## Resources\r\n\r\nI am going to skim over [the slides, which are available here.](https://docs.google.com/presentation/d/1wU2VCAgdNk67EtxokcKUPMWyHJ5e0wVqcrOjqGLUyqg/edit?usp=sharing)\r\n\r\nGitHub Repo for this demo: https://github.com/sw-yx/talk-typesafe-fullstack-react-demo-cms\r\n\r\nI will also assume you already have the [AWS Amplify CLI setup and configured](https://docs.amplify.aws/cli).\r\n\r\n## Livecode Demo Script\r\n\r\nFirst we clone our premade React + TypeScript app and initialize it as an AWS Amplify project:\r\n\r\n```bash\r\ngit clone https://github.com/sw-yx/talk-typesafe-fullstack-react-demo-cms\r\ncd talk-typesafe-fullstack-react-demo-cms\r\nyarn\r\namplify init # select defaults for everything\r\n```\r\n\r\nAt this point we have our simple app with some mock data:\r\n\r\n![https://user-images.githubusercontent.com/6764957/93261590-7c13f980-f7d5-11ea-9fda-b482ac1abdac.png](https://user-images.githubusercontent.com/6764957/93261590-7c13f980-f7d5-11ea-9fda-b482ac1abdac.png)\r\n\r\nThis gives us a strongly typed frontend with React and TypeScript! If you wish to learn how to wield React and TypeScript well, check out the [React and TypeScript cheatsheet](https://react-typescript-cheatsheet.netlify.app/) I have been maintaining for [over two years](https://twitter.com/swyx/status/1002776892154445826)!\r\n\r\n### Adding a GraphQL Database\r\n\r\nWe will now add a strongly typed backend to complement the frontend, using Amplify and AWS AppSync:\r\n\r\n```bash\r\namplify add api\r\n\r\n# choose the graphql option and defaults for the rest\r\n\r\n? Please select from one of the below mentioned services: GraphQL\r\n? Provide API name: myapiname\r\n? Choose the default authorization type for the API API key\r\n? Enter a description for the API key: \r\n? After how many days from now the API key should expire (1-365): 7\r\n? Do you want to configure advanced settings for the GraphQL API No, I am do\r\nne.\r\n? Do you have an annotated GraphQL schema? No\r\n? Choose a schema template: Single object with fields (e.g., “Todo” with ID,\r\n name, description)\r\n\r\nThe following types do not have '@auth' enabled. Consider using @auth with @model\r\n - Todo\r\nLearn more about @auth here: https://docs.amplify.aws/cli/graphql-transformer/directives#auth\r\n\r\n\r\nGraphQL schema compiled successfully.\r\n\r\n? Do you want to edit the schema now? Yes\r\n```\r\n\r\nWe'll use GraphQL SDL to define our database schema:\r\n\r\n```graphql\r\n# amplify/backend/api/myapiname/schema.graphql\r\ntype Blog @model {\r\n id: ID!\r\n title: String!\r\n image: String!\r\n body: String!\r\n}\r\n```\r\n\r\nThat `@model` there is a special GraphQL directive, which AppSync uses to provision infrastructure for you alongside your GraphQL model via a library called [GraphQL Transform](https://docs.amplify.aws/cli/graphql-transformer/directives). It has loads more goodies you can explore on your own, like `@auth`, `@searchable`, `@function` and `@predictions`, that you can add to your backend.\r\n\r\nProvisioning this infrastructure in AWS takes a long time, so we'll kick it off in the background while we work on the rest of the app:\r\n\r\n```bash\r\namplify push -y # skips the yes check\r\n```\r\n\r\n### Wiring up Backend to Frontend\r\n\r\nWe're in the home stretch. We'll need the `aws-amplify` library for interacting from the frontend:\r\n\r\n```bash\r\nyarn add -D aws-amplify\r\n```\r\n\r\nNotice that during `amplify init` an `aws-exports.js` file was generated in your `src` folder, with some non-secret information for your backend. We'll use this to wire up our app with AWS Amplify:\r\n\r\n```tsx\r\n// // src/index.tsx\r\n\r\n// the other imports\r\nimport Amplify from 'aws-amplify';\r\nimport awsconfig from './aws-exports';\r\nAmplify.configure(awsconfig);\r\n\r\n// rest of the app\r\n```\r\n\r\nYou also notice that during `amplify push` there was an autogenerated folder in `src/graphql` with a bunch of GraphQL queries. We will use this in our app!\r\n\r\nOptional step first - we can configure the codegen to generate typescript, so that types and auto imports work:\r\n\r\n```bash\r\namplify codegen configure\r\n\r\n? Choose the code generation language target typescript\r\n? Enter the file name pattern of graphql queries, mutations and subscriptions src/\r\ngraphql/**/*.ts\r\n? Enter the file name for the generated code src/API.ts\r\n? Enter maximum statement depth [increase from default if your schema is deeply nested] 2\r\n```\r\n\r\nThen we will use the `listBlogs` query in our app!\r\n\r\n```tsx\r\n// src/App.tsx\r\nimport { API } from 'aws-amplify'; // new\r\nimport { listBlogs } from \"./graphql/queries\"; // new\r\n// other imports here\r\n\r\nfunction App() {\r\n \r\n // new\r\n React.useEffect(fetchBlogs);\r\n function fetchBlogs() {\r\n const query = API.graphql({ query: listBlogs }) as Promise<any>\r\n query.then(\r\n ({\r\n data: {\r\n listBlogs: { items },\r\n },\r\n }) => setBlogs(items)\r\n );\r\n }\r\n // etc\r\n}\r\n```\r\n\r\nThis sets up the blog items to refresh from backend whenever the app rerenders.\r\n\r\nThen we'll also do the same for adding and updating blogs:\r\n\r\n```tsx\r\n// make sure to import createBlog and updateBlog\r\n\r\n async function addBlog(values: Blog) {\r\n const timestamp = new Date();\r\n const newBlog: Blog = {\r\n ...values,\r\n id: uuidv4(),\r\n createdAt: timestamp,\r\n updatedAt: timestamp,\r\n };\r\n setBlogs([...blogs, newBlog]);\r\n await API.graphql({query: createBlog, variables: {input: values}}) // NEW!\r\n }\r\n function _updateBlog(oldValues: Blog) {\r\n return async function (newValues: Blog) {\r\n const timestamp = new Date();\r\n const newBlog: Blog = {\r\n ...newValues,\r\n createdAt: oldValues.createdAt,\r\n updatedAt: timestamp,\r\n };\r\n setBlogs([...blogs.filter((x) => x.id !== oldValues.id), newBlog]);\r\n\r\n const { createdAt, updatedAt, ...input } = newBlog; // NEW!\r\n await API.graphql({ query: updateBlog, variables: { input } }); // NEW!\r\n };\r\n }\r\n```\r\n\r\nAnd there you have it! The basics of an end to end typed app!\r\n\r\nYou got stuck you can see the completed version of the app here https://github.com/sw-yx/talk-react-summit-demo-cms/blob/withAWS/src/App.tsx and the slides are [here](https://docs.google.com/presentation/d/1wU2VCAgdNk67EtxokcKUPMWyHJ5e0wVqcrOjqGLUyqg/edit?usp=sharing).\r\n\r\n[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1hfx0h8s4cb9lmot9c4m.png)](https://docs.google.com/presentation/d/1wU2VCAgdNk67EtxokcKUPMWyHJ5e0wVqcrOjqGLUyqg/edit?usp=sharing)\r\n\r\nI'm sure you have questions - let's hear them!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/typesafe-fullstack-react-graphql-with-aws-amplify-b3a","devToReactions":33,"devToReadingTime":4,"devToPublishedAt":"2020-09-15T21:23:42.704Z","devToViewsCount":454,"title":"Typesafe, Fullstack React & GraphQL with AWS Amplify","published":true,"description":"This is the blog version of a talk I am giving at React Summit 2020","category":"tutorial","tags":"React, GraphQL, AWS","slug":"aws_typesafe_fullstack_react","canonical_url":"https://www.swyx.io/writing/aws_typesafe_fullstack_react","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/1hfx0h8s4cb9lmot9c4m.png"},"title":"Typesafe, Fullstack React & GraphQL with AWS Amplify","description":"This is the blog version of a talk I am giving at React Summit 2020 ","category":"tutorial","tags":["react","graphql","aws"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/1hfx0h8s4cb9lmot9c4m.png","canonical":"https://www.swyx.io/writing/aws_typesafe_fullstack_react","slug":"aws_typesafe_fullstack_react","date":"2020-09-15T21:23:42.704Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/211","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/211/comments","title":"Typesafe, Fullstack React & GraphQL with AWS Amplify","created_at":"2022-01-17T23:14:08Z","updated_at":"2022-01-24T07:39:41Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/211/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nI've just finished the audiobook of [Shoe Dog](https://amzn.to/32tjm8d) by Phil Knight, the founder of Nike. Here are quick stream of consciousness notes from what I can recall, while I still recall it.\r\n\r\n- The book is in two parts. Part One covers 1962-1975, telling the story of Knight's journey post college wandering the world, then setting up Blue Ribbon Sports as an importer of [Onitsuka Tigers](https://en.wikipedia.org/wiki/Onitsuka_Tiger), and ultimately the betrayal and founding of Nike. \r\n- Part Two covers 1975-1980, telling of Nike's early and constant struggles with financing, manufacturing, competition, apparel, the law, and eventual IPO. \r\n- The closing chapter, Night, contrasts Knight's tremendous financial success with personal tragedy.\r\n\r\nI approached this simply to enjoy a great true story, nothing more. It's an autobiography, more than a business textbook. It's not designed to offer specific lessons, it just tells Knight's side of the story. But he did turn an initial $500 investment into a $25 billion fortune, so of course there is a fascinating business story running through the entire book.\r\n\r\n## Favorite moments and anecdotes\r\n\r\n- Knight made the initial deal with Onitsuka not having even set up Blue Ribbon yet, he just made it up on the spot when asked.\r\n- The nervous early days of wiring money to Japan and waiting months for delivery of shoes, constantly late\r\n- meeting and dating Penny, his wife\r\n- telling about how important [Steve \"Pre\" Prefontaine](https://en.wikipedia.org/wiki/Steve_Prefontaine) was to Blue Ribbon and how Pre's death devastated everyone at the company\r\n- The love and then hate dance with [Shoji Kitami from Onitsuka visiting the US](https://www.shortform.com/blog/kitami-onitsuka-nike/) planning to cheat on Blue Ribbon, the corporate espionage, and the betrayal that ultimately led to the parting of ways\r\n- The Nike name was literally a last minute idea - [Knight almost went with \"Dimension Six\"](https://www.businessinsider.com/how-nike-got-its-name-2016-1), which EVERYBODY hated. He [paid $35 for the logo](https://www.financialexpress.com/jobs/excerpts-shoe-dog-a-memoir-by-the-creator-of-nike-in-his-shoes/250447/).\r\n- Nike is the greek goddess of victory. Knight's early brushes with this happened during the world tour of his youth. The obvious one was in Greece, visiting the Parthenon, however I appreciated more the second mention, when he encountered Winston Churchill's \"[Blood, Toil, Tears, and Sweat](https://winstonchurchill.org/resources/speeches/1940-the-finest-hour/blood-toil-tears-and-sweat-2/)\" speech in London at the brink of World War 2: \r\n\r\n > You ask, what is our aim? I can answer in one word: It is victory, victory at all costs, victory in spite of all terror, victory, however long and hard the road may be; for without victory, there is no survival. \r\n- They almost rejected the [\"Air soles\"](https://www.businessinsider.com/nike-air-soles-almost-never-launched-phil-knight-shoe-dog-2019-5) idea that eventually became the classic Air Jordans in 1985.\r\n- Their initial head of apparel had a terrible dress sense and it took Knight way, way too long to fire him. \r\n- [Bob Woodell](https://www.shortform.com/blog/bob-woodell-nike-phil-knight/), the \"fixer\" and Nike's first COO, seemed capable of doing anything - get you a Woodell in anything that you do!\r\n- [The perverse abuse of obscure US Customs law by Nike competitors to try to destroy Nike with $25m in customs duties](https://www.oregonlive.com/playbooks-profits/2014/06/post_40.html) - the entirety of Nike annual sales at the time. Coopting the unilateral power of government as a competitive tactic particularly rankled me, for some reason. \r\n- You can hear Knight [read an extremely abbreviated version of his story at the 2014 Stanford GSB commencement](https://www.youtube.com/watch?v=nRN9FwWQY8w) (including the US Customs story 13 minutes in). Dev.to embed: {% youtube nRN9FwWQY8w %}\r\n\r\n## The Writing\r\n\r\nIt's also just incredibly well written. I mean, just read this:\r\n\r\n> \"Sept 7th, 1962. Carter and I piled into his battered old Chevy and drove at warp speed down I-5, through the Willamette Valley, out the wooded bottom of Oregon, which felt like plunging through the roots of a tree. We sped into the piney tip of California, up and over tall green mountain passes, then down, down, until long after midnight we swept into fog-cloaked San Francisco. For several days we stayed with some friends, sleeping on their floor, and then we swung by Stanford and fetched a few of Carter’s things out of storage. Finally we stopped at a liquor store and bought two discounted tickets on Standard Airlines to Honolulu. One-way, eighty bucks.\r\n> \r\n> It felt like only minutes later that Carter and I were stepping onto the sandy tarmac of Oahu Airport. We wheeled and looked at the sky and thought: That is not the sky back home.\r\n> \r\n> A line of beautiful girls came toward us. Soft-eyed, olive-skinned, barefoot, they had double-jointed hips, with which they twitched and swished their grass skirts in our faces. Carter and I looked at each other and slowly grinned.\r\n> \r\n> We took a cab to Waikiki Beach and checked into a motel directly across the street from the sea. In one motion we dropped our bags and pulled on our swim trunks. Race you to the water!\"\r\n\r\nYou could play the movie in your head.\r\n\r\nThe audiobook is competently narrated - I don't have a lot of experience to judge this, but it's a pleasant enough male voice and easy to follow.\r\n\r\n## Closing Thoughts\r\n\r\nI briefly covered Nike's stock in my hedge fund career, at the start of it's big \"direct to consumer\" drive. I confess I never really understood the company - never understood [American sneakerhead culture](https://en.wikipedia.org/wiki/Sneaker_collecting), never watched basketball, never knew how to evaluate the importance of Nike's offline and then online retail operations. But I did know that Phil Knight is a phenomenal businessman. \r\n\r\nIn particular this book has been repeatedly mentioned (by the likes of no less than [Bill Gates](https://www.gatesnotes.com/Books/Shoe-Dog)) as one of the best business autobiographies ever. \r\n\r\nAnd so it is.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/book-review-shoe-dog-by-phil-knight-52d3","devToReactions":7,"devToReadingTime":4,"devToPublishedAt":"2020-09-14T03:30:30.624Z","devToViewsCount":163,"title":"Book Review - Shoe Dog by Phil Knight","published":true,"description":"One of the greatest autobiographies by a business icon and great writer","tags":"Reflections, Review, Business","category":"essay","slug":"shoe-dog","canonical_url":"https://www.swyx.io/writing/shoe-dog","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/67l94sr9okh8d46scojj.jpg"},"title":"Book Review - Shoe Dog by Phil Knight","description":"One of the greatest autobiographies by a business icon and great writer ","category":"essay","tags":["reflections","review","business"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/67l94sr9okh8d46scojj.jpg","canonical":"https://www.swyx.io/writing/shoe-dog","slug":"shoe-dog","date":"2020-09-14T03:30:30.624Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/212","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/212/comments","title":"Book Review - Shoe Dog by Phil Knight","created_at":"2022-01-17T23:14:10Z","updated_at":"2022-01-17T23:44:53Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/212/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nI just caught up on Seth Godin's podcast on [Adversarial Interoperability](https://play.acast.com/s/akimbo/adversarialinteroperability), and it reminded me of a [great YC podcast episode with Cory Doctorow](https://www.ycombinator.com/library/6c-cory-doctorow-on-adversarial-interoperability) on the same topic. Cory himself has written reams of blogposts on [how Adversarial Interoperability has been applied repeatedly over tech history](https://www.eff.org/deeplinks/2019/10/adversarial-interoperability). \r\n\r\nThe way to frame this is that there are two types of actors: \r\n\r\n- a (bigger) **core platform**, sometimes controlled by a single company, or sometimes a public commons\r\n- a group of (smaller) **third parties**, which want to connect to or use the core platform for their own benefit and the benefit of users\r\n\r\nBased on these basic desires, we have three types of interop:\r\n\r\n- **Cooperative Interoperability** is when the platform explicitly works with third parties to enable them, mostly because the platform sees the benefits of adding capability without paying to develop it (in fact, it could be their primary revenue stream, as with Stripe or anything else in [the API economy](https://a16z.com/tag/the-api-economy/)). We may be familiar with these as an \"API marketplace\" or \"plugin ecosystem\", but also this happens on a \"spec\" level with major languages, protocols, and file formats.\r\n- **Adversarial Interoperability** is when the platform does NOT explicitly want third parties to connect for whatever reason, whether it is about control of data or of revenues or of content available on a platform, BUT, crucially, third parties are **still able to interop with it anyway**. [Plaid, the fintech unicorn](https://qz.com/1784765/the-seeds-of-visas-5-3-billion-acquisition-of-plaid-were-planted-more-than-a-year-ago/) still mostly operates via [screen-scraping](https://searchdatacenter.techtarget.com/definition/screen-scraping), as do [Mint and Quicken](https://www.scrapehero.com/mint-com-and-quicken-data-scraping-blocked-by-bank-websites/).\r\n- **Indifferent Interoperability** is when the platform doesn't care, e.g. a fridge maker doesn't care what magnets you put on the door. Usually platforms here claim they are \"unopinionated\", but I don't think this attitude lasts forever.\r\n\r\nThe star of the show is of course Adversarial Interoperability. It means that if users are not being served well, someone else (often a technically proficient user themselves) can come along and make some sort of hack to fix that problem (analogous to the [Right to Repair](https://thecounter.org/right-to-repair-elizabeth-warren-john-deere/)). Open Source is itself an inherent promise that adversarial interoperability will always be possible - anyone can fork a project if their priorities diverge from the maintainers.\r\n\r\nYou can make a lot of money via Adversarial Interoperability - and this has at least some legal protection thanks to [hiQ vs LinkedIn](https://www.eff.org/deeplinks/2019/09/victory-ruling-hiq-v-linkedin-protects-scraping-public-data), a landmark court ruling that even made it *illegal* for platforms to *try* to prevent screen scrapers from getting already-public data. In fact, one could argue that every new social network should be bootstrapped off existing ones, since it's legal anyway.\r\n\r\nIn tech, progress is fastest with cooperative interop, as all interests are aligned. But progress is also *possible* with indifferent and adversarial interop. \r\n\r\nThe problem arises when technology **prevents** adversarial interop, which helps monopolistic platforms keep a stranglehold on their users. This is most prevalent in closed ecosystems like with Apple's iOS.\r\n\r\nI think this is an incredibly important idea in [tech strategy](https://www.swyx.io/writing/dev-guide-to-tech-strategy/) - I've forgotten it before, so I wanted to take this occasion to note it down.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/notes-on-adversarial-interoperability-bgg","devToReactions":5,"devToReadingTime":3,"devToPublishedAt":"2020-09-13T23:37:49.620Z","devToViewsCount":134,"title":"Notes on Adversarial Interoperability","published":true,"description":"Summarizing thoughts from Seth Godin and Cory Doctorow on Interoperability","tags":"Reflections, Tech, Strategy","slug":"adversarial_interoperability","canonical_url":"https://www.swyx.io/writing/adversarial_interoperability"},"title":"Notes on Adversarial Interoperability","description":"Summarizing thoughts from Seth Godin and Cory Doctorow on Interoperability ","category":"note","tags":["reflections","tech","strategy"],"canonical":"https://www.swyx.io/writing/adversarial_interoperability","slug":"adversarial_interoperability","date":"2020-09-13T23:37:49.620Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/324","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/324/comments","title":"Notes on Adversarial Interoperability","created_at":"2022-01-18T00:15:09Z","updated_at":"2022-06-18T17:47:17Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/324/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nI'm about to rewrite my personal site (for hopefully the last time for a long while - UPDATE: [2022 rewrite blogpost here](https://www.swyx.io/rewrite-2022)). I have been paralyzed more than I should be about what I'm calling \"URL Architecture\". Because I care about [Cool URIs](https://www.w3.org/Provider/Style/URI), this is ideally not a reversible decision.\r\n\r\nAfter some agonizing I think I have decided on a URL Architecture I like. In true fashion, I'm blogging about it.\r\n\r\n\"URL Architecture\" (I don't know the proper word for this, if there is one pls correct me) is how you set up your URLs for each page of your site. For example, `netlify.com` has these:\r\n\r\n- `netlify.com`: generic landing page\r\n- `netlify.com/blog`: index of blogs\r\n- `netlify.com/blog/year/month/day/slug`: individual posts\r\n- other pages\r\n\r\n\r\nI call that `/blog` a **namespace**. The reason you do this is simple: it GREATLY reduces the risk of clashing with any other page you could possibly put on your site. It is \"future proof\".\r\n\r\n> Note: There is some debate about whether or not putting year/month/day in the URL impacts SEO. Some think it doesn't matter, some think it's a mild negative, some like it because you avoid clashes at the *slug* level.\r\n\r\nPersonal sites of frequent speakers often opt for TWO namespaces: `/writing` and `/speaking`. My current site (as of Sept 2020) uses this, but I have grown to dislike it: I will often speak about what I write, and write about related things I speak about. Why separate them? It is more effort to make my talks discoverable to my readers and vice versa.\r\n\r\nThe other thing that bothers me about my current setup is that it makes for ugly URLs. [My most popular essay ever](https://www.swyx.io/writing/learn-in-public) regularly gets linked to in Slacks, Discords, YouTube chats, Tweets and presentation slides. It weighs in at 43 characters all told.\r\n\r\nIf I shortened it to the shortcode that I set up for myself, `swyx.io/LIP`, it is only 11 characters. This looks much better.\r\n\r\nI've noticed that a lot of prolific bloggers don't namespace:\r\n\r\n- CSS Tricks: https://css-tricks.com/how-css-perspective-works/\r\n- Derek Sivers: https://sive.rs/cons\r\n- Paul Graham: http://www.paulgraham.com/good.html\r\n\r\nThese people have blogged for *decades* and somehow managed to find their way around possible URL clashes. Why can't I?","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/against-namespacing-personal-sites-23h2","devToReactions":32,"devToReadingTime":2,"devToPublishedAt":"2020-09-09T22:15:08.065Z","devToViewsCount":1358,"title":"Against Namespacing Personal Sites","published":true,"description":"I care a lot about creating Cool URIs so I have been paralyzed more than I should be about what I'm calling \"URL Architecture\". In true fashion, I'm blogging about it.","category":"tutorial","tags":"Reflections, Advice, Meta","slug":"namespacing-sites","canonical_url":"https://www.swyx.io/writing/namespacing-sites"},"title":"Against Namespacing Personal Sites","description":"I care a lot about creating Cool URIs so I have been paralyzed more than I should be about what I'm calling \"URL Architecture\". In true fashion, I'm blogging about it. ","category":"tutorial","tags":["reflections","advice","meta"],"canonical":"https://www.swyx.io/writing/namespacing-sites","slug":"namespacing-sites","date":"2020-09-09T22:15:08.065Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/325","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/325/comments","title":"Against Namespacing Personal Sites","created_at":"2022-01-18T00:20:53Z","updated_at":"2022-08-29T07:06:52Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/325/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Coding Career Tactics on ML Engineered Podcast","slug":"coding-career-mle-podcast-2","tags":["Careers"],"venues":"ML Engineered Podcast","date":"2020-09-09T00:00:00.000Z","url":"https://www.mlengineered.com/episode/swyx2","description":"I returned to the MLE podcast to continue our conversation. Charlie is one of the best interviewers I have ever worked with and it was a pleasure to join him again.","category":"podcast"},{"title":"Coding Career Strategy on ML Engineered Podcast","slug":"coding-career-mle-podcast","tags":["Careers"],"venues":"ML Engineered Podcast","date":"2020-09-09T00:00:00.000Z","url":"https://www.mlengineered.com/episode/swyx","description":"Shawn Wang formerly worked in finance as a derivatives trader and equity analyst before burning out and pivoting towards tech. He's a prolific blogger who goes under the pseudonym \"swyx\" and recently published the excellent Coding Career Handbook. He's a graduate of Free Code Camp and Full Stack Academy now working at AWS as a Senior Developer Advocate.","category":"podcast"},{"type":"blog","content":"\n> Jun 2021 update: This guide has been completely updated for SvelteKit@next.113 + Tailwind JIT! You can also see [this guide](https://jsco.dev/blog/how-to-set-up-tailwindcss-with-svelte-kit)\n\n> Aug 2021 update: try this first:\n>\n> ```bash\n> npm init svelte@next\n> npx svelte-add@latest tailwindcss\n> npm install\n> ```\n\n## Prerequisites\n\nI'm going to skip the preamble. You can read:\n\n- Why Svelte\n - [Why I Enjoy Svelte](https://www.swyx.io/svelte-why/)\n - [Svelte for Sites, React for Apps](https://www.swyx.io/svelte-sites-react-apps/)\n- [Why Tailwind CSS](https://www.swyx.io/why-tailwind/)\n\nI will also assume you have SvelteKit set up:\n\n```bash\nnpm init svelte@next my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nI strongly recommend picking at least the ESLint and Prettier options.\n\n## Step 1: Install deps\n\n```bash\nnpm install -D svelte-preprocess tailwindcss autoprefixer postcss\n\n# optional tailwind ui plugin\nnpm install @tailwindcss/ui\n```\n\n### Step 2: Setup Config Files\n\nAdd a `tailwind.config.cjs` file at the project root. (we use `.cjs` for now, or else the tailwind vs code extension complains it uses `require` when the rest of the project is in ESM).\n\n```js\n// tailwind.config.cjs\nmodule.exports = {\n mode: 'jit',\n // you dont need `purge: enabled: production` because you are using jit\n purge: [ \n \"./src/**/*.svelte\",\n // may also want to include HTML files\n \"./src/**/*.html\"\n ],\n darkMode: 'class',\n theme: {\n extend: {},\n },\n variants: {},\n plugins: [],\n }\n```\n\n## Step 2A: Svelte Config with inline PostCSS\n\nAnd now set it up inside of your Svelte bundler config as well:\n\n```js\n// svelte.config.js\nimport preprocess from 'svelte-preprocess';\nimport tailwind from 'tailwindcss'\nimport autoprefixer from 'autoprefixer'\n\n/** @type {import('@sveltejs/kit').Config} */\nconst config = {\n\t// Consult https://github.com/sveltejs/svelte-preprocess\n\t// for more information about preprocessors\n\tpreprocess: preprocess({\n\t\tpostcss: {\n\t\t\tplugins: [\n\t\t\t\ttailwind, \n\t\t\t\tautoprefixer\n\t\t\t]\n\t\t}\n\t}),\n\n\tkit: {\n\t\t// hydrate the <div id=\"svelte\"> element in src/app.html\n\t\ttarget: '#svelte'\n\t}\n};\n\nexport default config;\n```\n\n## Step 2B: Svelte Config with separate PostCSS for PostCSS nesting\n\n**ALTERNATIVELY** you can also set up your `postcss.config.js` in a separate file (this seems to be better for the postcss nesting plugin to run).\n\nWe use PostCSS 7, not 8 (latest) for now, because... [JavaScript](https://stackoverflow.com/questions/64057023/error-postcss-plugin-autoprefixer-requires-postcss-8-update-postcss-or-downgra). I've added in postcss-nesting because I like it - feel free to remove of course.\n\n- `npm i -D postcss-load-config postcss@7 postcss-nesting@7`\n- `svelte.config.js`:\n ```js\n\tpreprocess: preprocess({\n\t\tdefaults: {\n\t\t\tstyle: 'postcss',\n\t\t},\n\t\tpostcss: true,\n\t}),\n ```\n- `postcss.config.js`\n\n```js\n\nimport tailwind from 'tailwindcss'\nimport autoprefixer from 'autoprefixer'\nimport nesting from 'postcss-nesting'\n\nexport default {\n\tsyntax: 'postcss-scss',\n\tplugins: [\n\t\t// Some plugins, like postcss-nested, need to run before Tailwind\n\t\tnesting(),\n\t\ttailwind(),\n\n\t\t// But others, like autoprefixer, need to run after\n\n\t\tautoprefixer(),\n\t\t// !dev &&\n\t\t// \tcssnano({\n\t\t// \t\tpreset: 'default',\n\t\t// \t}),\n\t],\n};\n```\n\nHowever, this setup is still buggy when you actually try to nest CSS. I haven't figured it out yet and would like some help here if you are reading this.\n\n### Step 3: Add the Tailwind includes to your Svelte App\n\nCreate `src/routes/__layout.svelte` and add this:\n\n```html\n<style global lang=\"postcss\">\n\t@tailwind base;\n\t@tailwind components;\n\t@tailwind utilities;\n</style>\n\n<slot></slot>\n```\n\nAnd that's it!\n\n## Optional: Dark Mode\n\nI like using Dark mode with classes so you can let the user toggle it:\n\nPut this in your `app.html`:\n\n```html\n<!DOCTYPE html>\n<html lang=\"en\">\n\t<head>\n\t\t<meta charset=\"utf-8\" />\n\t\t<link rel=\"icon\" href=\"/favicon.png\" />\n\t\t<meta name=\"viewport\" content=\"width=device-width, initial-scale=1\" />\n\t\t<link href=\"https://fonts.googleapis.com/css2?family=Varela+Round&display=swap\" rel=\"stylesheet\">\n\t\t<script>\n\t\t\t// On page load or when changing themes, best to add inline in `head` to avoid FOUC\n\t\t\tif (localStorage.theme === 'dark' || (!('theme' in localStorage) && window.matchMedia('(prefers-color-scheme: dark)').matches)) {\n\t\t\tdocument.documentElement.classList.add('dark')\n\t\t\t} else {\n\t\t\tdocument.documentElement.classList.remove('dark')\n\t\t\t}\n\t\t</script>\n\t\t%svelte.head%\n\t</head>\n\t<body class=\"dark:bg-gray-900 dark:text-gray-100\">\n\t\t<div id=\"svelte\">%svelte.body%</div>\n\t</body>\n</html>\n```\n\n## What about Svelte classes!\n\nSvelte has a `class:` binding syntax that [didn't used to be supported by Tailwind](https://github.com/tailwindlabs/tailwindcss/discussions/1731). With Tailwind JIT, it has now been supported [as of 2021](https://github.com/tailwindlabs/tailwindcss-jit/pull/183)!\n\n## What versions are you working with?!?\n\n```js\n \"devDependencies\": {\n \"@sveltejs/adapter-netlify\": \"^1.0.0-next.17\",\n \"@sveltejs/kit\": \"^1.0.0-next.113\",\n \"@typescript-eslint/eslint-plugin\": \"^4.19.0\",\n \"@typescript-eslint/parser\": \"^4.19.0\",\n \"autoprefixer\": \"^9.8.6\",\n \"eslint\": \"^7.22.0\",\n \"eslint-config-prettier\": \"^8.1.0\",\n \"eslint-plugin-svelte3\": \"^3.2.0\",\n \"postcss\": \"^8.3.0\",\n \"postcss-load-config\": \"^3.0.1\",\n \"prettier\": \"~2.2.1\",\n \"prettier-plugin-svelte\": \"^2.2.0\",\n \"svelte\": \"^3.34.0\",\n \"svelte-check\": \"^2.0.0\",\n \"svelte-preprocess\": \"^4.7.3\",\n \"tailwindcss\": \"^2.1.4\",\n \"tslib\": \"^2.0.0\",\n \"typescript\": \"^4.0.0\"\n },\n```\n\n## Reference Repos\n\nMore practical repos you can reference and run\n\n- https://github.com/sw-yx/swyxkit\n- https://github.com/navneetsharmaui/sveltekit-starter\n- https://github.com/Dan1ve/Sveltekit-Typescript-TailwindCSS-Jit\n\nYou are supposed to be able to run [`npx svelte-add tailwindcss --jit`](https://github.com/svelte-add/tailwindcss) - but as of time of writing it is very buggy and doesn't work.\n\n\n---\n\n## Appendix: Prior content (Old outdated content)\n\n> Mar 2021 update: SvelteKit and Tailwind JIT were released this month and completely changed the game. Both are still in beta but strongly recommend checking out these templates and tools: \n\n- https://github.com/navneetsharmaui/sveltekit-starter\n- https://github.com/Dan1ve/Sveltekit-Typescript-TailwindCSS-Jit\n- more integrations here: https://github.com/sveltejs/integrations#sveltekit-templates\n- `npx svelte-add tailwindcss --jit` \n https://github.com/svelte-add/tailwindcss\n\n> Jan 2021 update: minor update of config for Tailwind 2.0. I've also added alternative approaches at the bottom, scroll down\n\n> Sep 2020 update: Chris has shown a much easier way to do this than I originally outlined, so I have replaced my original notes with notes from [his sample repo](https://github.com/chrisdhanaraj/test-svelte-tailwind). There's a build speed tradeoff, I discuss alternatives at bottom. \n\n\nOn [the latest Toolsday](https://spec.fm/podcasts/toolsday/o2XubpwD), [Chris Dhanaraj](https://twitter.com/chrisdhanaraj) said he had trouble finding documentation for adding [Tailwind](https://tailwindcss.com/) to [Svelte](https://svelte.dev/). \n\nToday I also needed to add Tailwind to a Svelte project, so I am writing this as a reference for myself. Setting up PostCSS with Svelte is something I have documented on [the new Svelte Society site](https://sveltesociety.dev/recipes/build-setup/using-postcss-with-svelte), but of course it could be better and more specifically tailored to Tailwind (which after all is \"just\" a PostCSS plugin).\n\nSo I am writing this for him and for me.\n\n> A quick aside on **WHY Use Tailwind with Svelte**, since Svelte offers scoped CSS by default: Tailwind offers a nicely constrained \"design system\" so you don't overuse [Magic Numbers](https://css-tricks.com/magic-numbers-in-css) and it's easy to add responsive styling with [Tailwind breakpoints](https://tailwindcss.com/docs/breakpoints). Because Tailwind has the developer experience of \"inline styles\", I also find it easier to delete and move HTML around without having to go back for the styling. I also like [not having to name classes](https://www.swyx.io/writing/how-to-name-things/#not-naming-things-aug-2019-edit). I discuss more on [Why Tailwind in general](https://dev.to/swyx/why-tailwind-css-2o8f) in a separate post. \n\n I will assume you have a standard existing Svelte or Sapper project with no PostCSS/Tailwind set up. I'll also add in `autoprefixer` and [`postcss-nesting`](https://tailwindcss.com/docs/using-with-preprocessors#nesting) since I like to work with those, but of course feel free to remove as needed.\n\n\n> Note: this section used to involve messing with `package.json` scripts to run `postcss-cli`, but Chris realized that you didn't need to do any of this since Svelte already has a way to inject CSS and `svelte-preprocess` already runs on every Svelte file.\n\nPlease see:\n\n- [Chris' sample Svelte repo](https://github.com/chrisdhanaraj/test-svelte-tailwind)\n- [Chris' Sapper side project](https://github.com/chrisdhanaraj/tier-list/)\n\nTo see this working in action.\n\n\n## Alternative Approaches\n\nThis method outlined above is simple to get running, but does end up running thousands of lines of Tailwind's CSS through the Svelte compiler. This may cause performance issues (primarily, every time you change the entry point file). Alternative approaches may be more appropriate depending on your preferences:\n\n- David Parker's video on [Adding TailwindCSS to a Sapper / Svelte App](https://www.youtube.com/watch?v=Dvm25Wgoh8Q)\n- Jacob Babich: \"I'm moving to https://github.com/babichjacob/sapper-postcss-template/tree/main running the global css builder in parallel with a reimplementation of postcss-cli (just so I can have source maps controlled by a variable in rollup.config.js) but without getting that extreme you can just use [npm-run-all](http://npm.im/npm-run-all) with [postcss-cli](https://www.npmjs.com/package/postcss-cli)\"\n- dominikg: \"The easiest way to setup tailwind with svelte: `npx svite create -t postcss-tailwind my-svelte-tailwind-project`\"\n- https://github.com/sarioglu/sapper-tailwindcss-template\n- https://github.com/sarioglu/svelte-tailwindcss-template\n- https://github.com/breadthe/svelte-tailwind2-starter\n- https://codechips.me/sapper-with-postcss-and-tailwind/","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/how-to-set-up-svelte-with-tailwind-css-4fg5","devToReactions":137,"devToReadingTime":6,"devToPublishedAt":"2020-09-08T16:30:58.850Z","devToViewsCount":28145,"title":"How to Set Up SvelteKit with Tailwind CSS","published":true,"description":"A quick 3 step guide for myself on how to set up Svelte with Tailwind CSS","tags":"Svelte, TailwindCSS, JavaScript","slug":"svelte_tailwind_setup","canonical_url":"https://www.swyx.io/writing/svelte_tailwind_setup"},"title":"How to Set Up SvelteKit with Tailwind CSS","description":"A quick 3 step guide for myself on how to set up Svelte with Tailwind CSS ","category":"note","tags":["svelte","tailwindcss","javascript"],"canonical":"https://www.swyx.io/writing/svelte_tailwind_setup","slug":"svelte_tailwind_setup","date":"2020-09-08T16:30:58.850Z","readingTime":"6 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/326","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/326/comments","title":"How to Set Up SvelteKit with Tailwind CSS","created_at":"2022-01-18T00:20:54Z","updated_at":"2022-06-18T17:47:17Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/326/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n## The Why\n\nMakers love spending all their time making their core product, and not enough time thinking about how to market and sell. \"*Build it and they will come*\", right?\n\n**Wrong.**\n\nThe average landing page conversion rate is **2.35%**, meaning **over 97% of people never even see what you made**.\n\nWe've all been warned not to judge a book by it's cover, but let's face it - we all do it.\n\nOne of my biggest stress points in [launching my own book](https://www.swyx.io/writing/coding-career-launch/) was leaving the landing page to the final week before launch, and realizing that I was totally out of my depth. After a certain point, one additional hour spent on the nth proofreading of the book was nowhere near as valuable to me as spending it on *the landing page*. \n\n[A top quartile landing page converts 5.31%, and the top decile converts 11.45%.](https://www.wordstream.com/blog/ws/2014/03/17/what-is-a-good-conversion-rate) That means **you can 2x-5x your sales** just working on your landing page rather than your product!!! \n\n> And that's assuming you can even make an average-performing landing page, especially on your first try!\n\nSo hopefully you can see why I think landing pages are important. If you're thinking \"but I'm a developer, this isn't my job!\", I'd say you're *almost* right. You took on this job the day you decided to sell something - your book, your business, your app, your *self* - online.\n\nYou're also right in that almost nobody - not even many marketers I have worked with - specializes in landing pages. It's *almost* nobody's job.\n\nIt is Rob Hope's.\n\n## The Book\n\n[![https://onepagelove.com/wp-content/themes/onepagelove/frontend/img/pages/hottips/cover.png](https://onepagelove.com/wp-content/themes/onepagelove/frontend/img/pages/hottips/cover.png)](https://onepagelove.com/go/swyx)\n\nFor over 12 years, Rob has [made a career](https://robhope.com/) out of studying one page websites. One Page sites embrace their titular constraint - within one page, they must drive the visitor to purchase or sign up or whatever action it is designed to do.\n\nI've just finished going through Rob Hope's new [Landing Page Hot Tips](https://onepagelove.com/go/swyx) book. It distils the best of Rob's experience from curating [tens of thousands of one page sites](https://onepagelove.com/inspiration) and of course working on his own. You can see a short sample of all 100 tips from [his hugely popular tweet thread here](https://twitter.com/robhope/status/1265278107088347136?s=20) - Dev.to Embed: {% twitter 1265278107088347136 %}\n\nIt's a quick read - just 100 short tips (1-2 page each) on everything from Design to Development to Pricing to Testimonials. \n\n> Side note: It's very un-like my style - where I like to explore every idea in detail, spell out every sub point (My book is 100k words even after editing!), Rob clearly likes to trim all the fat and just leave you with the core essence. There's a place for both, but I suspect Rob's approach is by far the more popular!\n\nThe book goes into more detail on each item and offers further links and 200+ resources to use to help achieve these things. Each tip is also delightfully narrated for an audiobook version, [with sound effects (!)](https://twitter.com/robhope/status/1299361913751601152?s=20).\n\nPart of the value of the book comes from it being available in so many formats, from PDF to HTML to audio, so that you retain better by spaced repetition, but probably my favorite feature is the categorized checklists.\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/08aafsw0f732arkbzohc.png)\n\nI will literally use these for every landing page I have to do for the rest of my life. That's worth the price of admission to me.\n\nRob didn't pay me to write this, I just think it's a great book and am writing it up as per my usual M.O. I did sign up for the affiliate thingy though - If you decide to get the book, I get a small kickback if you **[use my link](https://onepagelove.com/go/swyx)**, at no cost to you. It's $10 off for the month of September. You can also book a personal critique of your landing page, worth $179!\n\n> ‎”I fear not the man who has practiced 10,000 kicks once, but **I fear the man who has practiced one kick 10,000 times.**” - Bruce Lee","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/if-you-sell-anything-online-this-book-will-make-you-money-5830","devToReactions":74,"devToReadingTime":3,"devToPublishedAt":"2020-09-07T19:16:56.604Z","devToViewsCount":970,"title":"If You Sell Anything Online, This Book Will Make You Money","published":true,"description":"My glowing review of Rob Hope's Landing Page Hot Tips Book","tags":"Reviews","slug":"rob_hope_hot_tips","canonical_url":"https://www.swyx.io/writing/rob_hope_hot_tips","cover_image":"https://static-2.gumroad.com/res/gumroad/3228741675464/asset_previews/739f1e1c7b3c9feebc8adc814a7d1558/retina/Gumroad-Cover.png"},"title":"If You Sell Anything Online, This Book Will Make You Money","description":"My glowing review of Rob Hope's Landing Page Hot Tips Book ","category":"note","tags":["reviews"],"image":"https://static-2.gumroad.com/res/gumroad/3228741675464/asset_previews/739f1e1c7b3c9feebc8adc814a7d1558/retina/Gumroad-Cover.png","canonical":"https://www.swyx.io/writing/rob_hope_hot_tips","slug":"rob_hope_hot_tips","date":"2020-09-07T19:16:56.604Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/327","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/327/comments","title":"If You Sell Anything Online, This Book Will Make You Money","created_at":"2022-01-18T00:20:57Z","updated_at":"2022-06-18T17:47:18Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/327/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n_Translations: [Español](https://blog.rauljimenez.info/es/c%C3%B3mo-crear-suerte), [Francais](https://www.ncartron.org/comment-provoquer-la-chance.html), [Arabic](https://youdo.blog/2023/10/16/swyx-io/). Discussions on [Hacker News](https://hn.algolia.com/?q=https%3A%2F%2Fwww.swyx.io%2Fcreate-luck%2F)._\r\n\r\nMy entire worldview changed when I realized that **luck can be created**. \r\n\r\nMore precisely, you can actively **create optimal conditions for lucky things to happen to you**. The more I looked into this, the more I realized that this is not only *not* a new insight, but successful people have studied this for *decades* and I am just late to the party.\r\n\r\nIn this post we'll briefly review the \"Literature of Luck\", and then I'll end with some personal thoughts on how it could be extended.\r\n\r\n## Binary Luck\r\n\r\nMost people have a binary view of luck:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kgd335km9x3ujfmhxnz7.png)\r\n\r\nThis is true enough. Some people are born into privilege, some people just win some literal or figurative lottery or other.\r\n\r\nThe closing question of every episode of Guy Raz's [How I Built This](https://www.npr.org/podcasts/510313/how-i-built-this) podcast asks successful people: *\"How much of your success is due to skill, and how much is due to luck?\"*\r\n\r\nThose who believe in their own agency answer the former. Others - who've seen people smarter and harder working than them fail - answer the latter. Those who are politically correct cop-out with the half-and-half.\r\n\r\nIt can be comforting to subscribe to the binary luck model. If you just got a bad roll of the dice, there's nothing you could do. Your lack of success is not your fault. \r\n\r\nBut what if I told you **there are people who have skill at creating luck** for themselves?\r\n\r\n## Luck Surface Area\r\n\r\nJason Roberts coined the term \"[Luck Surface Area](https://www.codusoperandi.com/posts/increasing-your-luck-surface-area)\", and it was expanded by [Sean Murphy](https://www.skmurphy.com/blog/2019/04/03/increase-your-luck-surface-area-to-get-more-customers/) and popularized by [Patrick McKenzie](https://www.perell.com/podcast/patrick-mckenzie-internet-famous). \r\n\r\nI liken this model of luckiness to a \"catchment area\" ([a term from urban and hydrological geography](https://en.wikipedia.org/wiki/Catchment_area)). Luck is still randomly occurring, but you can position yourself in a way that captures more of it:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ogbkk8weenqb9nltrl34.png)\r\n\r\nJason has a really simple model of how to grow your LSA - do more things, and tell more people about it. **Doing and Telling**. Already this embodies a more active attitude toward how you can orient your life for more positive random events. It's \"[Fixed vs Growth mindset](https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/)\" adapted for luck.\r\n\r\n> 2021 update: a reader [visualized the LSA concept with this fancy video](https://twitter.com/elzr/status/1381105950602461189)!\r\n\r\n## Four Kinds of Luck\r\n\r\nA parallel, older school of thought dates back to James Austin in 1978 and was repopularized by [Marc Andreesen](https://pmarchive.com/luck_and_the_entrepreneur.html) in 2007, then [Naval and Nivi](https://twitter.com/nivi/status/1094940675353784320?lang=en) a decade later.\r\n\r\nHere, there are no helpful visuals. James Austin just gives a list of types, and Marc quotes verbatim. [Naval summarizes](https://twitter.com/naval/status/1093981014920052736) the 4 kinds of luck as such:\r\n\r\n> 1. Hope luck finds you.\r\n> \r\n> 2. Hustle until you stumble into it.\r\n> \r\n> 3. Prepare the mind and be sensitive to chances others miss.\r\n> \r\n> 4. Become the best at what you do. Refine what you do until this is true. Opportunity will seek you out. Luck becomes your destiny.\r\n\r\nI've quoted this many times to friends and always had trouble remembering what the 4 types are. I gave it some thought and visualized/organized it as such:\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/5ycsicfgoxsvxoyys5ip.png)\r\n\r\n1. **🌱 Accidental Luck**: You have the same luck as a plant. A plant does not move. Whether or not a plant does well pretty much just depends on where it's seed lands. It's not very interesting since by definition you can't do anything about it, but ofc privilege plays a huge part.\r\n2. **🏃🏽‍♀️ Active Luck**: The luck you get from constantly moving around. There's no particular direction in mind, but you're more likely to find something good if you move around and explore instead of stay put and hope. You're more likely to roll a 6 if you roll more dice.\r\n \r\n > \"I have never heard of anyone stumbling on something sitting down.\" - [Charles Kettering](https://due.com/blog/keep-going-charles-f-kettering/)\r\n \r\n > \"You don’t get extreme results without extreme actions.\" - [Derek Sivers](https://sive.rs/extremex)\r\n3. **💊 Prepared Luck**: The luck you get from noticing that something lucky has happened, that most would miss. The canonical story on this is Alexander Fleming's discovery of penicillin, which was a huge medical breakthrough. The discovery was a total accident (some mold happened to fall in the right spot + Fleming happened to see it + he had a similar experience that was a nonevent 9 years ago), but Fleming was not only \"uniquely equipped to observe it\" by his background, he took action to confirm the observation.\r\n \r\n > \"Luck is what happens when preparation meets opportunity.\" - Seneca\r\n \r\n > \"Chance favors the prepared mind.\" - Louis Pasteur\r\n \r\n > \"Richard Feynman was fond of giving the following advice on how to be a genius. You have to keep a dozen of your favorite problems constantly present in your mind, although by and large they will lay in a dormant state. Every time you hear or read a new trick or a new result, test it against each of your twelve problems to see whether it helps. Every once in a while there will be a hit, and people will say: “How did he do it? He must be a genius!”\" - [Gian-Carlo Rota](http://themattheweffect.org/tag/richard-feynman/)\r\n4. **🧲 Magnetic Luck**: *\"Chance IV comes to you, unsought, because of who you are and how you behave.\"* All sources call it \"individualized action\" but I've renamed it \"magnetic luck\" to emphasize the end result rather than how you get there. I'm quite familiar with this as [the \"Miner\" gear of my Learning Gears](https://www.swyx.io/writing/learning-gears/#miner) terminology (since updated to 4 gears in [my book](https://learninpublic.org/)). This was already a thing pre-Internet, but search and social media have given tremendous reach and influence to the oddballs and obsessives that become the spiritual leaders of every idea and purpose both big and niche.\r\n\r\nI find the 4 of these hard to remember, so I've organized them along two axes - **active vs passive**, and **general vs individual**. The first axis is the same realization as \"Luck Surface Area\" - you actually have the power to do things to create more luck than you were given.\r\n\r\nThe second axis is the insight - that there are forms of luck that apply to everyone, and there are forms of luck that are available only to someone in your unique position. There is a you-shaped hole in the universe and you can either passively occupy it or you can become a beacon for some idea or purpose.\r\n\r\n## Habits and Strategy\r\n\r\nI of course find the Four Kinds of Luck very appealing, since I've quoted it so much to friends that I'm writing this post at all. But upon closer reading I think there's a *slightly* different direction that is unaddressed by the Four Kinds (I originally thought this was embedded in the Four Kinds, only to discover that it wasn't in the source material and I had completely read my own thinking into it). \r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/poue5zg9homy1eo4ml05.png)\r\n\r\nThis model differs in two ways. It treats both axes as a spectrum rather than a 2x2. It also focuses more on **actions** (you can take) rather than **classification** (which are a little more abstract). I've also swapped out \"Active vs Passive\" for \"Active Habits\" and \"Individual vs General\" for \"Good Strategy\". So my version is more about HOW you get more lucky. It's not very actionable to be \"more magnetic\", but you can Claim a Domain or Hustle and have a good sense of what those things entail.\r\n\r\nI've written about a few of these ideas in prior posts so I won't elaborate:\r\n\r\n- [Claiming a Domain, Personal Branding](https://www.swyx.io/writing/marketing-yourself/)\r\n- \"Copywork\" I wrote about in the \"Clone Open Source Apps\" chapter of the book\r\n\r\nI think **Exploring** and **Prospecting** are worth elaborating here.\r\n\r\n**Exploring** (and to a lesser extent Grinding and Copywork) are **Actively Habitual, non Strategic** activities. But this doesn't mean it is bad. I think this is what you do when you take in general life and career advice and apply them to yourself. You know there are a list of **Principles** which are just generally good things to do in life, and trust that you will do well if you do those things (e.g. [Learn in Public](https://www.swyx.io/writing/learn-in-public/)). Keep doing the \"right\" things, and \"trust the process\".\r\n\r\n**Prospecting** is a term I've [borrowed from the oil exploration industry](https://en.wikipedia.org/wiki/Prospecting). **Prospecting is a highly Active habit, and highly Strategic.** These days, when you look for oil, there is a whole science to handicapping whether or not a plot of land is likely to have oil. You don't know it for a fact, all you're doing is estimating probabilities. Not to get too tautological, but you will be luckier if you can consistently assess and move towards areas where you are more likely to be \"lucky\". It might look like luck to others, but the motion and intention you invested to get yourself in a position to be lucky was far from random. I've also written many times about how I think strategic [manoeuvring for \"Megatrends\"](https://www.google.com/search?&q=swyx.io+%22megatrends%22&oq=swyx.io+%22megatrends%22) is a good idea.\r\n\r\n## In Summary\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/5075sq79y4pstxpp4pdk.png)\r\n\r\nThis is the state of my thinking on luck right now. That last bit you just read is pretty fresh, I might come back and change this in a couple years when I have refined my thoughts. I welcome any and all feedback.\r\n\r\nBut overall, the message I really want to leave you with is this: **you can create luck**. That's it. I don't care how you do it, what mental model you use, who you quote. I just care *that* you do it. **Go make yourself more lucky.**\r\n\r\n> Ordinarily I'd wish you good luck, but now you have something better than a mere wish 😂\r\n\r\n## Related Reads\r\n\r\n- The Serendipity Mindset: The Art and Science of Creating Good Luck ([Book](https://www.amazon.com/gp/product/B0818ZH58R/ref=as_li_tl), [Podcast](https://www.artofmanliness.com/articles/podcast-662-the-art-and-science-of-creating-good-luck/))\r\n- [How To Get Lucky](https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-get-lucky) in the Alamanack of Naval Ravikant\r\n- [How to Maximize Serendipity](https://www.perell.com/blog/serendipity) by David Perell\r\n- [Richard Meadows - Optionality: How To Make Your Own Luck In Life](https://modernwisdom.libsyn.com/269-richard-meadows-optionality-how-to-make-your-own-luck-in-life)\r\n- GitHub ReadME project: [Publishing your work increases your luck](https://github.com/readme/guides/publishing-your-work) (see [HN comments](https://news.ycombinator.com/item?id=32071137))\r\n- Richard Wiseman's [4 precursors of Luck](https://www.youtube.com/watch?v=lKxFDqP1Yw4) (Open to Opportunities, Intuition, Optimists, Resilient)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/how-to-create-luck-2jl1","devToReactions":160,"devToReadingTime":7,"devToPublishedAt":"2020-08-29T21:23:06.846Z","devToViewsCount":4161,"title":"How to Create Luck","published":true,"description":"Your entire worldview changes when you realize you can *create luck*.","tags":"Luck, Advice","slug":"create-luck","canonical_url":"https://www.swyx.io/writing/create-luck","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/5075sq79y4pstxpp4pdk.png"},"title":"How to Create Luck","description":"Your entire worldview changes when you realize you can *create luck*. ","category":"note","tags":["luck","advice"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/5075sq79y4pstxpp4pdk.png","canonical":"https://www.swyx.io/writing/create-luck","slug":"create-luck","date":"2020-08-29T21:23:06.846Z","readingTime":"8 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/328","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/328/comments","title":"How to Create Luck","created_at":"2022-01-18T00:20:59Z","updated_at":"2023-10-25T21:09:35Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/328/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nToday [I joined John Lindquist's Twitch stream to learn Karabiner Elements](https://www.twitch.tv/videos/723328200)! \n\nMy interest stems from 2 directions:\n\n- [my recent RSI explorations](https://dev.to/swyx/notes-on-rsi-for-developers-who-don-t-have-it-yet-239n)\n- a general interest in productivity and automation - I have heard a great deal from folks like Wes Bos how much TextExpander and Alfred help them in productivity, and I suspect I am not taking as full advantage of these tools as I should be.\n\nFriends like [Brandon Bayer](https://twitter.com/flybayer/status/1288610907367514113) use Karabiner to prevent bad (for RSI) key combinations, and both John and [Vadim](https://twitter.com/swyx/status/1274054230911803392) use it to do \"Home Row Computing\".\n\n## What is Karabiner Elements?\n\n[On its website](https://karabiner-elements.pqrs.org/), it describes itself as \"A powerful and stable keyboard customizer for macOS\". It is [free and open source](https://github.com/pqrs-org/Karabiner-Elements). \n\nI have also heard it called a \"key remapper\", but I don't think that describes the full range of what it does, because \"map from A to B\" is just the bare minimum of the possibility.\n\n## Setting up Karabiner and Goku\n\nAfter [downloading](https://karabiner-elements.pqrs.org/), the next move was to set up [Goku](https://github.com/yqrashawn/GokuRakuJoudo). Karabiner has a verbose JSON DSL - Goku lets you write a terser Clojure based EDN format that compiles to that JSON.\n\n```bash\nbrew install yqrashawn/goku/goku\ncd /Users/yourusername/.config\ntouch karabiner/karabiner.json\ntouch karabiner.edn\n# prepopulate the edn with something from https://github.com/yqrashawn/GokuRakuJoudo/blob/master/tutorial.md\ngoku\n```\n\nThis will give you something to start with.\n\n## The EDN language\n\nEDN is a dialect of Clojure. This is basic EDN:\n\n```clojure\n{:main [\n {:des \"hello world\"\n ; comments use semicolons\n :rules [\n [:a :b] ; map a key to b key\n ]}\n]}\n```\n\nWe didnt find the EDN VSCode Extension formatter to be very good, so we just manually formatted the file ourselves.\n\nThe array syntax is good for setting up multiple rules:\n\n```clojure\n{:main [\n {:des \"mapping some keys to the other\"\n :rules [\n [:a :b] \n [:c :d] \n [:e :f] \n [:g :h] \n ]}\n {:des \"combination keys\"\n :rules [\n ; map \"shift+spacebar\" to \" = \"\n [{:key :spacebar :modi :left_shift} [:spacebar :equal_sign :spacebar]]\n ]}\n]}\n```\n\nYou can create layers to put Karabiner into modes:\n\n```clojure\n{\n :layers {\n ; implement caps lock mode\n :caps_mode {:key :caps_lock :alone {:key :escape}}}\n ; implement vs code mode\n :applications {\n :code [\"com.microsoft.VSCode\"]\n } \n :main [\n {:des \"capslock layer\"\n :rules [\n :caps_mode\n ; VIM MODE - hold caps and AJKL\n ; home row computing\n [:##h :left_arrow] ; even with f, still do left arrow\n [:##k :up_arrow]\n [:##j :down_arrow]\n [:##l :right_arrow]\n [:##f :left_option]\n [:##d :left_shift]\n ]}\n {:des \"these only work when you are inside vscode\"\n :rules [ \n :code\n [:p :m] ; remap p to m INSIDE VSCODE\n ]}\n ]\n}\n```\n\nYou can even enable a [multitouch extension](https://karabiner-elements.pqrs.org/docs/manual/misc/multitouch-extension/) to switch modes based on how many fingers you have on the touchpad!\n\n```clojure\n{:des \"trackpad2\"\n:rules [ \n ; 2 fingers down\n [:condi [\"multitouch_extension_finger_count_total\" 2]]\n [:f :button2] ; \n [:v [:button1 :!Cv]] ; go around and paste\n ; idea: g for cmd + click\n]}\n```\n\n## More\n\nTo see an expert's edn file, see:\n\n- https://github.com/nikitavoloboev/dotfiles/blob/master/karabiner/karabiner.edn\n- search github: https://github.com/search?l=&q=filename%3Akarabiner.edn&type=Code\n\nother ideas for things you can do:\n\n- https://stevelosh.com/blog/2012/10/a-modern-space-cadet/#s15-better-shifting\n- http://vadimpleshkov.me/notes/all/remapping-arrows/\n- [ensure consistent keyboard shortcuts in different apps](https://twitter.com/johnlindquist/status/1298317208435585024?s=20)\n\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/notes-on-karabiner-elements-from-john-lindquist-4cmo","devToReactions":8,"devToReadingTime":3,"devToPublishedAt":"2020-08-28T02:10:46.835Z","devToViewsCount":602,"title":"Putting your Keyboard on Steroids with Karabiner Elements","published":true,"description":"I did a livestream with John Lindquist from Egghead.io today, and he blew my mind on how much mileage you can get out of your keyboard!","tags":"Automation","slug":"karabiner_lindquist","canonical_url":"https://www.swyx.io/writing/karabiner_lindquist"},"title":"Putting your Keyboard on Steroids with Karabiner Elements","description":"I did a livestream with John Lindquist from Egghead.io today, and he blew my mind on how much mileage you can get out of your keyboard! ","category":"note","tags":["automation"],"canonical":"https://www.swyx.io/writing/karabiner_lindquist","slug":"karabiner_lindquist","date":"2020-08-28T02:10:46.835Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/329","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/329/comments","title":"Putting your Keyboard on Steroids with Karabiner Elements","created_at":"2022-01-18T00:21:01Z","updated_at":"2022-06-18T17:47:18Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/329/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n[Flutter](https://flutter.dev/) is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase, and is one of the fastest growing mobile frameworks in 2020. [AWS Amplify recently announced Flutter support](https://aws.amazon.com/blogs/mobile/announcing-aws-amplify-flutter-developer-preview/) in Developer Preview, meaning it's not officially launched yet, but we can start trying it out now.\r\n\r\nHere's my log from getting a simple Photo-Sharing app going with Authentication and Storage (example is in Android, but should work for iOS and web too).\r\n\r\n## Explained In 100 Seconds\r\n\r\n- YouTube: https://youtu.be/0NgR-Qa5GPE\r\n- Twitter: https://twitter.com/swyx/status/1298349861696282625?s=20\r\n- Dev.to Embed: {% youtube 0NgR-Qa5GPE %}\r\n\r\n## Start a new Flutter App\r\n\r\nAssuming you've [set up all the prerequisites for Flutter](https://flutter.dev/setup) (including setting up an [Android Virtual Device](https://developer.android.com/studio/run/managing-avds) and [accepting the Android SDK licenses](https://stackoverflow.com/questions/39760172/you-have-not-accepted-the-license-agreements-of-the-following-sdk-components), you can head to **File -> New -> New Flutter Project** and pick the basic Flutter Application starter.\r\n\r\nWe'll need to add the new Amplify flutter libraries, so be sure to add them in `pubspec.yaml` and `Pub get` to download:\r\n\r\n```yaml\r\ndependencies:\r\n flutter:\r\n sdk: flutter\r\n\r\n\r\n # new\r\n amplify_core: '<1.0.0'\r\n amplify_auth_cognito: '<1.0.0'\r\n amplify_storage_s3: '<1.0.0'\r\n\r\n # we happen to also use this in our demo\r\n file_picker: ^1.13.3\r\n\r\n ## this is also available if you want analytics but not covered in this post\r\n # amplify_analytics_pinpoint: '<1.0.0'\r\n```\r\n\r\n## Initialize an Amplify project\r\n\r\nNote: If you're reading this in late August 2020, be aware that you'll need a special version of the CLI because it is still in developer preview:\r\n\r\n```bash\r\nnpm i -g @aws-amplify/cli@4.26.1-flutter-preview.0\r\n```\r\n\r\nWe then follow the standard Amplify setup instructions (assuming [CLI is installed and configured](https://docs.amplify.aws/lib/project-setup/prereq/q/platform/flutter)). \r\n\r\n```bash\r\n# command\r\namplify init\r\n\r\n# prompts\r\n? Enter a name for the environment\r\n `dev`\r\n? Choose your default editor:\r\n `IntelliJ IDEA`\r\n? Choose the type of app that you're building: \r\n 'flutter'\r\n⚠️ Flutter project support in the Amplify CLI is in DEVELOPER PREVIEW.\r\nOnly the following categories are supported:\r\n * Auth\r\n * Analytics\r\n * Storage\r\n? Where do you want to store your configuration file? \r\n ./lib/\r\n? Do you want to use an AWS profile?\r\n `Yes`\r\n? Please choose the profile you want to use\r\n `default`\r\n```\r\n\r\nNotice that you will see a configuration file created in `./lib/` called `amplifyconfiguration.dart`. This is a static file you can import that holds all your public facing Amplify data, but most people will only use it in `amplify.configure(amplifyconfig)`.\r\n\r\nWe're going to want to set up storage for our photo app, which requires authentication. Fortunately the CLI sets up both at once for us:\r\n\r\n\r\n```bash\r\n# command\r\namplify add storage\r\n\r\n# prompts\r\n? Please select from one of the below mentioned services:\r\n `Content (Images, audio, video, etc.)`\r\n? You need to add auth (Amazon Cognito) to your project in order to add storage for user files. Do you want to add auth now?\r\n `Yes`\r\n? Do you want to use the default authentication and security configuration?\r\n `Default configuration`\r\n? How do you want users to be able to sign in?\r\n `Username`\r\n? Do you want to configure advanced settings?\r\n `No, I am done.`\r\n? Please provide a friendly name for your resource that will be used to label this category in the project:\r\n `S3friendlyName`\r\n? Please provide bucket name:\r\n `storagebucketname`\r\n? Who should have access:\r\n `Auth and guest users`\r\n? What kind of access do you want for Authenticated users?\r\n `create/update, read, delete`\r\n? What kind of access do you want for Guest users?\r\n `create/update, read, delete`\r\n? Do you want to add a Lambda Trigger for your S3 Bucket?\r\n `No`\r\n```\r\n\r\nWhen you've set up whatever else you might need, you can push to the cloud to kick off the provisioning:\r\n\r\n```bash\r\namplify push --y\r\n```\r\n\r\nThis process takes a while to provision all the resources for you, so while that's going we can set up our code first.\r\n\r\n## Diving into Flutter code\r\n\r\nInside of `./lib/main.dart`, we can import everything we will need:\r\n\r\n```dart\r\nimport 'package:amplify_auth_cognito/amplify_auth_cognito.dart';\r\nimport 'package:amplify_core/amplify_core.dart';\r\nimport 'package:amplify_storage_s3/amplify_storage_s3.dart';\r\nimport 'amplifyconfiguration.dart';\r\n// etc\r\n```\r\n\r\nThen inside of our main page we can write the Amplify config code:\r\n\r\n```dart\r\n// inside of some class for the page\r\n Amplify amplify = Amplify();\r\n bool _isAmplifyConfigured = false;\r\n\r\n @override\r\n initState() {\r\n super.initState();\r\n _initAmplifyFlutter();\r\n }\r\n\r\n void _initAmplifyFlutter() async {\r\n AmplifyAuthCognito auth = AmplifyAuthCognito();\r\n AmplifyStorageS3 storage = AmplifyStorageS3();\r\n amplify.addPlugin(\r\n authPlugins: [auth],\r\n storagePlugins: [storage],\r\n );\r\n await amplify.configure(amplifyconfig);\r\n\r\n setState(() {\r\n _isAmplifyConfigured = true;\r\n });\r\n }\r\n```\r\n\r\nThis way we are able to add a little loading screen based on `_isAmplifyConfigured` if we wish.\r\n\r\nFor the rest of the app, you will have to write up the Flutter UI experience yourself, but the hard part is over from writing Amplify code.\r\n\r\n### Using Amplify Auth in a Widget\r\n\r\nCall the appropriate functions ([docs here](https://docs.amplify.aws/lib/auth/signin/q/platform/flutter)) as needed. Here's how we sign a user in:\r\n\r\n```dart\r\nimport 'package:amplify_auth_cognito/amplify_auth_cognito.dart';\r\nimport 'package:amplify_core/amplify_core.dart';\r\nimport 'package:flutter/material.dart';\r\n\r\nclass SignInView extends StatefulWidget {\r\n @override\r\n _SignInViewState createState() => _SignInViewState();\r\n}\r\n\r\nclass _SignInViewState extends State<SignInView> {\r\n final usernameController = TextEditingController();\r\n final passwordController = TextEditingController();\r\n\r\n String _signUpError = \"\";\r\n List<String> _signUpExceptions = [];\r\n\r\n @override\r\n void initState() {\r\n super.initState();\r\n }\r\n\r\n void _signIn() async {\r\n // Sign out before in case a user is already signed in\r\n // If a user is already signed in - Amplify.Auth.signIn will throw an exception\r\n try {\r\n await Amplify.Auth.signOut();\r\n } on AuthError catch (e) {\r\n print(e);\r\n }\r\n\r\n try {\r\n SignInResult res = await Amplify.Auth.signIn(\r\n username: usernameController.text.trim(),\r\n password: passwordController.text.trim());\r\n Navigator.pop(context, true);\r\n } on AuthError catch (e) {\r\n setState(() {\r\n _signUpError = e.cause;\r\n _signUpExceptions.clear();\r\n e.exceptionList.forEach((el) {\r\n _signUpExceptions.add(el.exception);\r\n });\r\n });\r\n }\r\n }\r\n\r\n// etc for the Widget build\r\n```\r\n\r\n### Using Amplify Storage in a Widget\r\n\r\n\r\nCall the appropriate functions ([docs here](https://docs.amplify.aws/lib/storage/overview/q/platform/flutter)) as needed. Here's how we upload a new picture:\r\n\r\n```dart\r\nimport 'package:flutter/material.dart';\r\nimport 'dart:io';\r\nimport 'package:file_picker/file_picker.dart';\r\nimport 'package:amplify_core/amplify_core.dart';\r\nimport 'package:amplify_storage_s3/amplify_storage_s3.dart';\r\n\r\nclass ImageUploader extends StatelessWidget {\r\n void _upload(BuildContext context) async {\r\n try {\r\n print('In upload');\r\n // Uploading the file with options\r\n File local = await FilePicker.getFile(type: FileType.image);\r\n local.existsSync();\r\n final key = new DateTime.now().toString();\r\n Map<String, String> metadata = <String, String>{};\r\n metadata['name'] = 'filename';\r\n metadata['desc'] = 'A test file';\r\n S3UploadFileOptions options = S3UploadFileOptions(\r\n accessLevel: StorageAccessLevel.guest, metadata: metadata);\r\n UploadFileResult result = await Amplify.Storage.uploadFile(\r\n key: key, local: local, options: options);\r\n\r\n print('File uploaded. Key: ' + result.key);\r\n Navigator.pop(context, result.key);\r\n } catch (e) {\r\n print('UploadFile Err: ' + e.toString());\r\n }\r\n }\r\n\r\n @override\r\n Widget build(BuildContext context) {\r\n return Column(children: [\r\n RaisedButton(\r\n child: Text(\"Upload Image\"),\r\n onPressed: () {\r\n _upload(context);\r\n },\r\n )\r\n ]);\r\n }\r\n}\r\n```\r\n\r\n## Full Demo App\r\n\r\nIf you would like to see a demo app with all this setup, head to the `amplify-flutter` example repo: https://github.com/aws-amplify/amplify-flutter/tree/master/example\r\n\r\n(and give it a ⭐ - it really helps!)\r\n\r\n## What's Next?\r\n\r\nBeing a new SDK, the Flutter Developer Preview is definitely lacking feature parity with the JS/Android/iOS SDK's. Here's what's coming in the next few months:\r\n\r\n- API (REST/GraphQL): The API category provides an interface for retrieving and persisting your data, using GraphQL backed by AWS AppSync or REST APIs and handlers using Amazon API Gateway and AWS Lambda.\r\n- DataStore: Amplify DataStore provides a programming model for leveraging shared and distributed data without writing additional code for offline and online scenarios, which makes working with distributed, cross-user data just as simple as working with local-only data.\r\n- Predictions: The Predictions category enables AI/ML use cases on the frontend such as translating text, converting text to speech, and recognizing text, labels and faces in images.\r\n- Auth: We will extend the Auth category with social sign in with Web UI\r\n- Storage: We will extend the Storage category with the ability to track Upload and Download Progress\r\n- Escape Hatches: We will add support for ‘escape hatches’, enabling developers to more easily use the low-level generated iOS and Android AWS Mobile SDKs for additional use cases.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/first-look-at-aws-amplify-flutter-developer-preview-2jbh","devToReactions":51,"devToReadingTime":5,"devToPublishedAt":"2020-08-25T18:25:14.871Z","devToViewsCount":3036,"title":"First Look at AWS Amplify Flutter (Developer Preview)","published":true,"description":"AWS Amplify launched a Flutter Integration, so I thought I would record a quick video and blogpost","category":"Tutorial","tags":"AWS, Flutter","slug":"amplify-flutter","cover_image":"https://d2908q01vomqb2.cloudfront.net/0a57cb53ba59c46fc4b692527a38a87c78d84028/2020/08/19/flutter_preview2-1078x630.jpg"},"title":"First Look at AWS Amplify Flutter (Developer Preview)","description":"AWS Amplify launched a Flutter Integration, so I thought I would record a quick video and blogpost ","category":"tutorial","tags":["aws","flutter"],"image":"https://d2908q01vomqb2.cloudfront.net/0a57cb53ba59c46fc4b692527a38a87c78d84028/2020/08/19/flutter_preview2-1078x630.jpg","slug":"amplify-flutter","date":"2020-08-25T18:25:14.871Z","readingTime":"7 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/330","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/330/comments","title":"First Look at AWS Amplify Flutter (Developer Preview)","created_at":"2022-01-18T00:21:03Z","updated_at":"2022-06-18T17:46:26Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/330/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\n*[Share on Twitter](https://twitter.com/swyx/status/1296829223051526152?s=20)*\n\nFor my own reference, and anyone else interested in moving primary git branch from `master` to `main`. \n\n> I'm not interested in discussing [reasons to do this](https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx) here, it has been rehashed thousands of times already.\n\nTL;DR: \n\n![Cheatsheet for Master to Main](https://dev-to-uploads.s3.amazonaws.com/i/6wqq892i53i8fn19kcg3.png)\n\n## Move Existing Projects\n\n### 1. Rename branches\n\n```bash\ngit branch -m master main # history unchanged\ngit push origin HEAD\ngit branch -u origin/main main\n```\n\n### 2. retarget existing PRs \n\nYou can use https://github.com/ethomson/retarget_prs to do it.\n\n### 3. set default branch\n\nMake sure you've pushed your `main` branch, then head to `https://github.com/USERNAME/REPONAME/settings/branches` - [docs here](https://docs.github.com/en/github/administering-a-repository/setting-the-default-branch)\n\n### 4. update local clones (if applicable)\n\nThis is handy if you are working on local forks of OSS - Thanks to https://twitter.com/xunit/status/1269881005877256192\n\n```bash\n$ git branch --unset-upstream\n$ git branch -u origin/main\n```\n\n## Set Default For New Projects\n\nYou can set new projects created on your machine to start with `main` branch as well.\n\n```bash\n## Git 2.28+\ngit config --global init.defaultBranch main\n## Git 2.27-\ngit config --global alias.new '!git init && git symbolic-ref HEAD refs/heads/main'\n```\n\nIf you're on a Mac like me, you can `brew upgrade git` or [download Git](https://git-scm.com/downloads) to update the version. Recent versions also include [sparse-checkout](https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/), in case you needed more incentive to upgrade.\n\nThis is for new projects *on your local machine* - unfortunately GitHub hasn't made a new setting for setting the default `main` branch for new repos created on GitHub yet.\n\n> Edit: now it has! head to https://github.com/settings/repositories to set it\n\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rs27j4f09wle6cn6h1a3.png)\n\n## Set Bash Aliases\n\nLastly, you can setup [bash aliases](https://opensource.com/article/19/7/bash-aliases) that tries `main` first and then `master` so you get to use the same alias no matter what you work with:\n\n```bash\nalias gpom=\"git push origin main 2> /dev/null || git push origin master\"\n```\n\n## GitHub's Plans\n\nIf the GitHub process seem rather manual, don't worry. I have hundreds of repos on GitHub. GitHub has plans to release automated tooling to help you manage this.\n\nPlans: https://github.com/github/renaming\n\n- ✅ Jul 17 - redirects of deleted branches\n- ✅ Aug 1 - [GitHub Pages work from any branch](https://github.blog/changelog/2020-07-31-build-and-deploy-github-pages-from-any-branch-beta/)\n- ✅ Aug 26 - [Be able to change default branch in Github](https://github.blog/changelog/2020-08-26-set-the-default-branch-for-newly-created-repositories/) \n- ✅ Oct 1 - Default branch AUTOMATICALLY changes to `main` on GitHub\n- ☑ Summer - Configurable default for new repos\n- ☑ EoY 2020 - Retargeting PRs/Releases/Pages for existing repos (https://twitter.com/swyx/status/1351772911082762240?s=20) \n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/move-primary-git-branch-from-master-to-main-m7c","devToReactions":115,"devToReadingTime":2,"devToPublishedAt":"2020-08-21T03:04:51.077Z","devToViewsCount":3081,"title":"Cheatsheet for moving from Master to Main","published":true,"description":"Notes I have collected on how to renaming the Git default/primary branch","tags":"Tech","slug":"master_to_main","canonical_url":"https://www.swyx.io/writing/master_to_main","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/6wqq892i53i8fn19kcg3.png"},"title":"Cheatsheet for moving from Master to Main","description":"Notes I have collected on how to renaming the Git default/primary branch ","category":"note","tags":["tech"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/6wqq892i53i8fn19kcg3.png","canonical":"https://www.swyx.io/writing/master_to_main","slug":"master_to_main","date":"2020-08-21T03:04:51.077Z","readingTime":"2 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/331","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/331/comments","title":"Cheatsheet for moving from Master to Main","created_at":"2022-01-18T00:21:05Z","updated_at":"2022-06-18T17:47:19Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/331/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"The Coding Career Handbook on Zhia Chong YouTube","slug":"coding-career-zhia-chong","tags":["Careers"],"venues":"Zhia Chong","date":"2020-08-20T00:00:00.000Z","url":"https://www.youtube.com/watch?v=flaAZQ3meQI","description":"A quick interview on Zhia Chong's YouTube channel!","category":"podcast"},{"type":"blog","content":"\r\n**2023 update**: check out [the screencasting course](https://screencasting.com/) for people serious about screencasting\r\n\r\n**2022 update**: much better camera tips here by Kevin who runs [a zoom setup business](https://dreamstudiocourse.com/#pricing)! Or try the \"[90% good enough](https://twitter.com/girdley/status/1606277214231674880?s=20)\" solution from Michael Girdley that [includes a teleprompter](https://twitter.com/girdley/status/1606277321555554304/photo/2).\r\n\r\n{% twitter https://twitter.com/theKevinShen/status/1613190967615524866 %}\r\n\r\n**2021 Edit**: Now given as a talk for Global Diversity CFP Day!\r\n\r\n{% youtube Tz1Fotm-hnk %}\r\n\r\n---\r\n\r\nI've just given my 5th or 6th prerecorded talk this year, [at React Rally 2020](https://www.swyx.io/speaking/react-rally-metalanguage). Prerecorded talks are an increasingly popular way to do virtual conferences, because they reduce a host of conference organizer risks. However, they also present new challenges and opportunities to speakers.\r\n\r\nA lot of folks start off doing prerecorded talks exactly the same way they do in-person conference talks. This is fine, but misses the opportunity to fully take advantage of the medium.\r\n\r\nI'm no expert, but I realized I may have some ideas from my experiences that others may want to steal. Here they are.\r\n\r\n## Recording Yourself\r\n\r\n- **Write a script**. It's BETTER to have a script when prerecording. I rarely have a script when speaking live - it is more natural to be able to improvise and command attention when not scripted. But the prerecording restriction takes ALL the benefit out of speaking off script. Here, the expensive thing is now recording and editing. You should try as much as possible to reduce the amount of editing you need to do - and that means trying out words and phrases in writing first, instead of taking a million cuts and improvising. Writing a script may feel like extra work, but trust me that it saves rather than adds time.\r\n - You can still improvise!! Just have a script first.\r\n - **Front-load value**. People have a FAR shorter attention span online than in person. They could be deciding whether or not to listen to your 30 minute talk based on the first 30 seconds. They could be playing you in the background while working on something else. If you start out flat and monotone, I'm going to tune out. **Grab attention. Use pauses, videos, cliffhanger stories, whatever you can think of to get them to actually watch**.\r\n - You can [set up a teleprompter for yourself](https://mobile.twitter.com/QuinnyPig/status/1291597180021559296) (some use [Glide Gear](https://www.amazon.sg/Glide-Gear-Laptop-Smartphone-Teleprompter/dp/B07X9VSZMM)) if you feel you must look at the camera at all times, but honestly nobody minds if you look away every now and then, especially when your face is not the focus of attention\r\n- **Good Lighting**: You want your face to be lighted up nicely. This doesn't mean you have to shine a [ring light](https://spectrum-brand.com/blogs/news/what-is-a-ring-light) directly in your eyes. I use a regular LED lamp and shine it at white paper taped on to the wall in front of my desk, so it bounces off the paper and *then* onto my face. Multiple lights will help you avoid shadows.\r\n - If you want to go beyond amateur, check this [advice for youtubers](https://www.youtube.com/watch?v=IXe3rEWrDVg) covering fill light/rim light/practical light and [this one](https://www.youtube.com/watch?v=0wqUWYx3UrY) covering white balance and colors\r\n- **Interesting background**: plain white is a little too plain. no Zoom backgrounds please. A good background tells a little about your personality, but isn't too distracting. Books, vases, plants, guitars, toys, paintings, shelves. You can take some inspiration from [Jason Lengstorf, Sarah Drasner](https://www.learnwithjason.dev/make-animations-feel-pro), [Michael Liendo](https://www.youtube.com/watch?v=ZQyiYifmwfg) or [Simona Cotin](https://www.youtube.com/watch?v=kVA6EfClvlg) or [Scott Tolinski](https://www.youtube.com/c/LevelUpTuts/videos). (More [here](https://twitter.com/ShaanVP/status/1428015172203937794?s=20))\r\n- you can take a look at https://dreamstudiocourse.com/p/home if this is worth $1500 to you\r\n- **Camera**: Many laptops skimp on cameras, so the quality isn't that great. A lot of serious folks buy mirrorless DSLRs just for livestreaming, but if you are in the market for a cheaper option, I use a Logitech C9250-ish webcam. I elevate the camera with a few books so it is at eye level.\r\n - 2021 Update: I'm now getting a [Sony a5100](https://twitter.com/jessejanderson/status/1387059854930501634) DSLR which only cost me $400.\r\n- **Microphone**: A good microphone is important here - you can watch video with bad camera quality, but bad sound quality is unwatchable. Turn the gain down and stick the microphone close to your face. I use [the standard issue eggheadio mic](https://howtoegghead.com/instructor/screencasting/audio-equipment/), I've carried it across 4 continents.\r\n - 2021 update: I now use a Blue Yeti (given to me for free by GitHub). I don't use a pop filter, but I like the idea that you can just [aim the microphone at your mouth rather than aim your mouth at the microphone](https://www.youtube.com/watch?v=amWbTkjfhDk) to avoid pops.\r\n - 2022 update: https://dontbuyayeti.com/ has swayed me - I am looking to replace it with a supercardoid mic soon.\r\n - If you have unavoidable background noise, like construction, you can remove it with https://krisp.ai/ (which has a free tier)\r\n- **Misc**: Watch what you are wearing - you are home, but you don't have to dress too \"homely\". Don't wear the same color as your background. Try to lean forward to prevent double chin.\r\n\r\nI'm a relative cheapskate when it comes to recording setups. Here are people who have invested way more:\r\n\r\n- Jason Lengstorf https://lengstorf.com/uses/\r\n- Ben Thompson https://monkbent.net/the-ultimate-home-office/\r\n- Van Nguyen ($400 to $11k) https://medium.com/@askvan/in-depth-guide-on-how-to-greatly-boost-video-chat-quality-ff5d44921ed3\r\n\t- especially https://www.notion.so/5ad8f062d9594ef0b5c851a2d08c5e4c?v=9f6f1cd1978242f8a40b17c9f1c0656f\r\n- Quinn Slack https://slack.org/high-resolution-video-calls\r\n- Jason Toff (head of youtube) https://medium.com/@toff/new-home-office-8514acf5ea39 \r\n- Emma Bostian https://web.archive.org/web/20201101134657/https://compiled.blog/blog/my-tech-setup\r\n\r\nCheck my [video on Growing a Meta-Language](https://www.youtube.com/watch?v=18F5v1diO_A) for an example of how this all comes together:\r\n\r\n{% youtube 18F5v1diO_A %}\r\n\r\n## Recording Your Screen\r\n\r\n- **MAKE. EVERYTHING. BIGGER.** Statistically, half your audience will be watching on their phones. Even if they watch on desktop, your video may be shrunk down for any number of reasons (livestream banners). Make everything as big as possible without having to scroll too much every second. It also just forces you to get rid of everything not immediately relevant on your screen. \r\n- **Clear Your Screen**: this is worth a standalone point. Remove everything not relevant to your talk. This includes stray browser tabs and chrome extensions. You can use a clean [Chrome Profile](https://www.bettercloud.com/monitor/the-academy/how-to-create-switch-profiles-in-chrome/) to do this (more from [Dave Ceddia](https://daveceddia.com/setup-chrome-for-screencasting/)). Hide the activity bar and file explorer in your IDE when not relevant. Hide the Mac OS menubar unless you actually need it. This isn't just about reducing clutter for aesthetic purposes - reducing points of variance can help you record video with time skips so it can be easier to edit seamlessly later.\r\n\r\n> 2021 Edit: Evyatar from Svelte Society recommends using the [Colibri browser](https://colibri.opqr.co/) and these VSCode settings to have maximize code on screen and minimize distraction:\r\n>\r\n> ```js\r\n> \"workbench.activityBar.visible\": false,\r\n> \"workbench.statusBar.visible\": false,\r\n> \"editor.fontSize\": 52,\r\n> \"window.zoomLevel\": -4,\r\n> \"editor.accessibilityPageSize\": 17,\r\n> \"editor.lineNumbers\": \"off\",\r\n> ```\r\n\r\n- **Make It Obvious**: If your software supports it (i use Screenflow) add an indicator for when you have clicked something on screen (usually concentric circles). [Make your mouse cursor bigger](https://www.lifewire.com/make-mac-mouse-pointer-bigger-2260808) so it is easier to track. Speak what you are typing and doing on screen if it is something you are trying teach. \"I cut this command here and paste it over there.\" \"I search and replace all instances of this variable.\"\r\n- Be wary of recording the keyboard sound when you type and speak at the same time. This is why using a separate mic helps reduce that noise. You can also choose to record your screen first with some narration, throw away the audio, then record voiceover without any typing.\r\n- Think about where you are placing your face later when you edit these things together. If you are doing anything in the bottom right, be aware that you may have to move your face awkwardly. Also good practice in general to leave a healthy margin in all directions and don't do anything too close to the corner of any side of the screen.\r\n- Slides can be nice, but you need slides less than in live talks. Since you are prerecording, you can easily \"live code\" and never be at any risk of mistakes. Likewise, you can bring people around on websites and apps to demonstrate what you are trying to say and what things will actually look like, instead of having each thing be merely a bullet point. **Show, don't tell**.\r\n\r\nCheck my [video on Vite + React for an example](https://www.youtube.com/watch?v=oJd9XzNIHzQ). Dev.to Embed: {% youtube oJd9XzNIHzQ %}\r\n\r\n## Editing Opportunities\r\n\r\n- I use [Screenflow](http://www.telestream.net/screenflow/store.asp). Free alternatives exist, like [Kdenlive](https://kdenlive.org/en/).\r\n- **Try different layouts**. Most people have their screen take up the full size of the video, and their camera/face floating/overlaid on the bottom right. It's fine, but it's boring. You can invert that - have your face/camera take the full video, and inset the screen. Alternatively, you can **move your face around** as a replacement of laser pointer, to specifically indicate what part of the screen you are talking about. Don't overdo it!\r\n- Transition scenes with quick fades instead of having hard cuts.\r\n- You can cut and speed up routine tasks in video so your audience don't have to wait for you, but you also don't have to take the cognitive loss of a jump cut.\r\n- You aren't limited to what's on your screen, or what's on your slides. You can superimpose even more content on your final video - more images to quickly reference what you are talking about, and even video and charts to illustrate your point. Don't throw too much or it will feel very chaotic, but adding good visuals atop audio can do a lot to break up the monotony of talking through a single slide for a whole minute. One every 10-20 seconds feels right. Examples:\r\n - [Veritasium presenting a slide deck](https://www.youtube.com/watch?v=S2xHZPH5Sng) - using a projector and a ladder! or a [hand drawn flip chart](https://www.youtube.com/watch?v=fHsa9DqmId8)\r\n - [Rich Harris drawing a chart with his finger](https://www.youtube.com/watch?v=luM5uobewhA&t=665s) and adding in post\r\n- Consider what the title frame/screenshot will be. This will be what most people see in YouTube before they decide to watch your video. make it good.\r\n- Since you're not live, take advantage of it to make your video AS CLEAR AS POSSIBLE. For example, if you have a 30 minute talk, with 3 parts of 10 minutes each, you could show a little overlay with text or diagrams as a visual reminder of where you are in the talk. This helps people follow along when you transition and change to the next point, as well as people on YouTube when they are scrubbing and skipping ahead.\r\n- Consider the final call to action - this is a VERY good chance to send people to related talks you have done and/or your personal blog/site/twitter for leaving comments on the talk.\r\n\r\nYou can see a very good example of editing in [Rich Harris' Svelte Society talk](https://www.youtube.com/watch?v=luM5uobewhA). Dev.to Embed: {% youtube luM5uobewhA %}\r\n\r\n## During the Talk\r\n\r\nFinally you can relax! You've done all the hard work! But this is the last benefit from going prerecorded - you can still talk while you talk!\r\n\r\n- Provide onscreen links in the conference chat so that people can click to follow through\r\n- Respond to questions as they come in\r\n- Discuss other things you didn't have time to cover but point people in the right direction if they\r\n- Director's commentary - talk about the behind the scenes of what's going on in the video and tell stories what you had to do to get there\r\n- I also share my script and slides for people who want to read along. It doesnt have to be 100% faithful\r\n- Heckle yourself - have some fun with it!\r\n\r\n---\r\n\r\n## Other resources\r\n\r\n- https://medium.com/shiftconf/how-to-prep-for-speaking-at-a-virtual-conference-2bb4ecfc0d30\r\n- Video setup: https://www.youtube.com/watch?v=WedG8LKO6ks\r\n- Lights: https://www.amazon.com/dp/B07K8GGX48/?coliid=I2Z6KLAW1XNOCD&colid=2VU9TEDIL0L6V&psc=1&ref_=lv_ov_lig_dp_it\r\n- use iphone for camera https://reincubate.com/camo/\r\n- [Adam Wathan Screencasting tips](https://fullstackradio.com/150)\r\n- [Craigery Dennis' Speaker Studio recommendations](https://thespeakerlab.com/craigery-dennis/)\r\n- MDS' equipment http://mds.is/recording/\r\n\r\n## Your Turn\r\n\r\n**What other great tips from prerecorded talks have you observed?**\r\n","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/tips-for-speakers-prerecording-talks-for-online-conferences-4ic9","devToReactions":35,"devToReadingTime":8,"devToPublishedAt":"2020-08-17T23:26:34.045Z","devToViewsCount":527,"title":"Prerecording Talks for Online Conferences","published":true,"description":"Tips for Speakers Prerecording Talks for Online Conferences","tags":"Reflections","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/2tqpqf58ztigjf3ucl3c.png","slug":"prerecording-talks","canonical_url":"https://www.swyx.io/prerecording-talks"},"title":"Prerecording Talks for Online Conferences","description":"Tips for Speakers Prerecording Talks for Online Conferences ","category":"note","tags":["reflections"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/2tqpqf58ztigjf3ucl3c.png","canonical":"https://www.swyx.io/prerecording-talks","slug":"prerecording-talks","date":"2020-08-17T23:26:34.045Z","readingTime":"9 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/332","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/332/comments","title":"Prerecording Talks for Online Conferences","created_at":"2022-01-18T00:21:08Z","updated_at":"2024-06-18T16:05:35Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/332/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nWe need to have some real talk around what we are calling Developer Experience (DX) at developer-focused companies. \r\n\r\nIt's not well defined, although [Chris Coyier has done a good survey](https://css-tricks.com/what-is-developer-experience-dx/) of what people think of when they hear the term, and others try to define [Developer Enablement](https://devbizops.substack.com/p/from-developer-experience-to-enablement). It's a differentiator among devtools, so of course it is professionalizing, and creeping into job titles (my last job title was \"Developer Experience Engineer\", whatever that actually means). I fully expect this to develop into a fullblown sub-industry, with conferences and thoughtleaders and gatekeepers and the like (right down to \"[Dev Advocate Cofounder](https://twitter.com/terronk/status/1286774559274725376?s=20)\").\r\n\r\n## \"Developer Experience\"\r\n\r\nHere are some things that companies traditionally work on when they \"work on DX\":\r\n\r\n- **Replacing many with few**: Replacing many lines of code with few lines of code. Replacing many logos with one logo. Replacing many steps with one click (signup, deploy). [Generating code](https://www.swyx.io/writing/write-my-code-for-me/) so you don't have to handwrite it. Providing great value and plenty of functionality as a first-party, out of the box, or with zero config.\r\n- **Extensive Documentation**: Getting Started. Example Demos. Interactive Examples. Full API Docs. Guides and Recipes. Good Search. Versioning. (appropriate to [project maturity](https://www.swyx.io/writing/documentation-levels/))\r\n- **More tooling**: CLIs, Editor Extensions, Code Snippets, Playgrounds, Language Servers.\r\n\r\nI'm not at all saying these things aren't important. They're even hard to do well, and fully deserve specialists in their own right. These foundational pieces of developer experience should also be *fast* and intuitive to the point of [guessable](https://johno.com/guessable).\r\n\r\n## \"Developer Exceptions\"\r\n\r\nBut I'm also saying that developers, when they use our products, experience *many* other things which aren't traditionally the domain of \"DX people\", because they have to do with core engineering and product promises:\r\n\r\n- **Downtime**: When your service goes down, does your status page lie? Do you refrain from tweeting about it for fear of scaring off customers you don't yet have, rather than reassuring those you do? Do you post prompt, no-bullshit [post-mortems](https://github.com/danluu/post-mortems)? Do you provide good fallback options for when your service is down? Do you practice disaster recovery?\r\n- **Response times**: Are you not just meeting your SLAs, but actually clearly answering customer questions? What are you doing for users not yet covered by SLAs? For your open source footprint, do users have confidence that their issues will be addressed and appropriate PRs reviewed, or are you asking people to do free work for you that you then ignore?\r\n- **Missing/Incomplete Features**: No product launches feature complete. Nobody expects you to. **The true test is whether you address it up front or hide it like a dirty secret.** As developers explore your offering, they will find things they want, that you don't have, and will tell you about it. How long do you make developers dig to find known holes in your product? Do developers have confidence you will ship or reject these features promptly, or are they for a \"v2\" that will never come?\r\n- **Uncertainty over roadmap**: Do your most avid users know what's coming so they can plan around your plan? If that's too high a bar, do your *own employees* know what's coming so they can coordinate nicely? Do you have \"perma-beta\" products? How do you communicate when users ask if they should use \"orphan\" products? (don't be ashamed, everyone has them)\r\n- **Uncertainty over costs**: Is your pricing predictable or do your users need a spreadsheet to figure out what you are going to charge them? If charges are unexpectedly high, can developers use your software to figure out why or do they have to beg for help? Are good defaults in place to get advance warning? Have your employees ever paid for your own product (or had to justify doing so to their own employers)?\r\n- **Deprecation/Lock-in/Portability**: Do you [constantly deprecate APIs and products](https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc), causing additional work for no gain? Some amount of lock-in is unavoidable, but are you conscious of how much proprietary API you are foisting on your user? Should your user want to leave someday for whatever reason, have you documented that and made that easy, or are they on their own? \r\n- **Debugging**: Are your errors informative or scary? Have you designed them to be searchable or do they only make sense to maintainers? When things go wrong, how quickly does your service surface common issues and offer resolution steps? What about enabling users to answer [questions they don't yet know they have](https://www.swyx.io/writing/frontend-observability/)? If developers are constantly making mistakes and \"[holding the phone wrong](https://www.engadget.com/2010-06-24-apple-responds-over-iphone-4-reception-issues-youre-holding-th.html)\", is it their fault or yours?\r\n- **Audit Logs & Access Control**: Many products start life in single-player mode, and then execute a very clumsy transition to multi-player when they start serving teams and enterprise. When something that shouldn't have been done has been done, do you offer trustworthy sources of truth, and ways to prevent repeats (or, of course, make them impossible in the first place)?\r\n- **Error Messages**: Are your errors helpful or cryptic? [Don't make me think](https://dev.to/temporalio/write-errors-that-don-t-make-me-think-24hg)!\r\n\r\n## Causes\r\n\r\nOf course, none of these are new problems, and well known to product management. The problem is mostly organizational - as \"developer advocacy\" as a discipline evolved from \"developer evangelism\" (going from a \"1 way street\" to a \"2 way street\"), it is now evolving to \"developer experience\". I see a troubling organizational limitation of DX folks, defining DX to the stuff that focuses on increasing \"top of funnel\" growth (reducing friction, growing awareness, an endless parade of copycat short term growth hacks) - and having comparatively a lot less impact on the \"bottom of funnel\" stuff (logo churn, satisfaction scores, account expansion/customer success). **There's little sense making more rain when faced with a leaky bucket**.\r\n\r\nConway's Law is an [eponymous law](https://www.swyx.io/writing/eponymous-laws/) that states that \"organizations design systems that mirror their own communication structure\". Steven Sinofsky's snappier definition is \"[don't ship your org chart](https://medium.com/@donorem/shipping-the-org-chart-3319181be9bd)\". We need to be careful about the consequences of letting Conway's Law apply to Developer Experience.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/87bsgzkj9jrftxhgxil9.png)\r\n\r\n## Engineering for Developer Exceptions\r\n\r\nTo be clear, I don't really know how to do this yet. I am just thinking out loud. But my intuition is that in order to design exceptional developer experiences, we should pay more attention to developer exceptions. As DX people, we've focused a lot on `try`, perhaps we should take a good look at `catch`.\r\n\r\nThe first thing to fix is organizational incentives. DX work must not just feel welcome, it must be demanded and good results rewarded. Nobody wants to feel like they are adding weight onto an already overloaded backlog. Most orgs are set up in a way that lack of feedback isn't noticed when it isn't given, and feedback when given feels like additional burden. This is, unsurprisingly, not conducive to feedback.\r\n\r\nThe second thing is to establish invariants around your core developer experience and automate monitoring and reporting of these to the fullest extent possible. [Tools that hold the line are incredibly powerful](https://twitter.com/sebmarkbage/status/1063585097545220096). To progress, you need to first stop regressing.\r\n\r\nMy last thought is around helping PMs and EMs create DX, rather than taking primary responsibility. If you're sending in PRs and design docs yourself, you are probably doing too much of someone else's job and will be ineffective and/or resented. Better to provide them the information they need to make decisions and be available for opinions and instant feedback since you represent the end user. It is common for there to be an infinite list of small things to do - and that is very hard to sell internally - so how can you bundle these up into thematic projects, motivate engineers, and carefully communicate progress to the wider world?\r\n\r\nIt's time we look beyond the easy questions in developer experience, and start addressing the uncomfortable ones.\r\n\r\n> Note: This is my own thinking sparked by a third party conversation, and I am not speaking on behalf of my current employer.\r\n\r\n## More on this\r\n\r\n- https://css-tricks.com/dx-to-whom/\r\n- https://www.swyx.io/write-errors-that-don-t-make-me-think-24hg/\r\n- https://lethain.com/platform-product-fit/\r\n\r\n > The diverging results of these approaches are perhaps most easily seen in the evolution of their respective Identity and Access Management offering. Google’s IAM historically offered an elegant interface but limited support for common usecases like sub-bucket object permissioning. Amazon’s IAM skewed towards extreme flexibility, gleefully sacrificing comprehensibility for completeness. In my opinion. Google’s platform has become much easier to start on and equipped with better defaults for new projects, but remains difficult-to-impossible to operate on as a scaled enterprise user. (Results are also measurable in quarterly earnings.)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/developer-exception-engineering-4jfo","devToReactions":60,"devToReadingTime":6,"devToPublishedAt":"2020-08-15T17:20:15.608Z","devToViewsCount":1467,"title":"Developer Exception Engineering","subtitle":"Managing Developer Experience off the Happy Path","published":true,"description":"It's time we look beyond the easy questions in developer experience, and start addressing the uncomfortable ones.","tags":"DX","slug":"developer-exception","canonical_url":"https://www.swyx.io/writing/developer-exception","cover_image":"https://dev-to-uploads.s3.amazonaws.com/i/87bsgzkj9jrftxhgxil9.png"},"title":"Developer Exception Engineering","subtitle":"Managing Developer Experience off the Happy Path","description":"It's time we look beyond the easy questions in developer experience, and start addressing the uncomfortable ones. ","category":"note","tags":["dx"],"image":"https://dev-to-uploads.s3.amazonaws.com/i/87bsgzkj9jrftxhgxil9.png","canonical":"https://www.swyx.io/writing/developer-exception","slug":"developer-exception","date":"2020-08-15T17:20:15.608Z","readingTime":"7 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/333","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/333/comments","title":"Developer Exception Engineering","created_at":"2022-01-18T00:21:10Z","updated_at":"2022-03-29T17:28:05Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/333/reactions","total_count":1,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":1,"rocket":0,"eyes":0}}},{"title":"Growing a Meta-Language","slug":"reactrally2020","categories":["React"],"description":"7 years after release, React reaches millions of developers and billions of users. Its ideas have influenced other frameworks, even those in other languages like Swift UI and Jetpack Compose. What’s next? The community has been hard at work innovating in React formats, metaframeworks, and developer tooling. This fits an established pattern of how developer languages grow, and likely forms a roadmap for React in the Third Age of JavaScript.","instances":[{"venue":"Swyx YouTube","date":"2020-08-15","video":"https://www.youtube.com/watch?v=18F5v1diO_A"},{"venue":"React Rally","date":"2021-04-01","video":"https://www.youtube.com/watch?v=Dz4q_bNDqfo"}],"category":"talk","date":"2020-08-15T00:00:00.000Z"},{"slug":"react-rally-metalanguage","title":"Growing a Meta-Language","categories":["React"],"desc":"My React Rally 2020 talk on Dialects, Distros, Devtools, and the React SFC idea","description":"7 years after release, React reaches millions of developers and billions of users. Its ideas have influenced other frameworks, even those in other languages like Swift UI and Jetpack Compose. What’s next? The community has been hard at work innovating in React formats, metaframeworks, and developer tooling. This fits an established pattern of how developer languages grow, and likely forms a roadmap for React in the Third Age of JavaScript.","instances":[{"venue":"ReactRally","github":"https://gist.github.com/swyxio/dedf23e25e6955d29968b5eecd7d749e","url":"https://www.reactrally.com/speakers","date":"2020-08-15","video":"https://www.youtube.com/watch?v=18F5v1diO_A","slides":"https://docs.google.com/presentation/d/1sBb7KjhSOiONML61fnYwkVI-7yzJCoP-Zgs6E37T-nY/edit?usp=sharing"}],"category":"talk","date":"2020-08-15T00:00:00.000Z"},{"type":"blog","content":"\r\n[Amplify DataStore](https://docs.amplify.aws/lib/datastore/getting-started/q/platform/js#option-1-platform-integration) provides a persistent on-device storage repository for you to write, read, and observe changes to data if you are online or offline, and seamlessly sync to the cloud as well as across devices.\r\n\r\nIt is free, open source, and supported by the [AWS Amplify](https://amplify.aws/) team, and I wanted to show you how easy it is to use it to add realtime, offline first CRUD features to your app! We'll use React in this example, but you can easily use this guide for adding realtime, offline-first CRUD to an app built with any framework.\r\n\r\n## 100 Second Video Version\r\n\r\nYoutube: https://youtu.be/pSSfTWqSXbU\r\n\r\nDev.to Embed: {% youtube pSSfTWqSXbU %}\r\n\r\n## Text Based Version - 3 Steps\r\n\r\nThe stuff below is the script for the video above, so you can copy/paste!\r\n\r\n### Step 1: Setup the React Chat App\r\n\r\nAssuming you have [setup the Amplify CLI](https://docs.amplify.aws/start/getting-started/installation/q/integration/react), we're going to spin up a standard React app and install a special demo Chat component I've prepared under [the `react-demos` package](http://npm.im/react-demos):\r\n\r\n```bash\r\nnpx create react-app amplifychatapp\r\ncd amplifychatapp\r\nyarn add react-demos # or npm install react-demos\r\n```\r\n\r\nLet's try out this demo component to get familiar with it!\r\n\r\n```js\r\n// src/App.js\r\nimport React from 'react'\r\nimport { Chat, useChatLocalState } from 'react-demos'\r\n\r\nexport default function App() {\r\n const {\r\n currentUser,\r\n sendMessage,\r\n loginUser,\r\n messages,\r\n usersOnline,\r\n } = useChatLocalState()\r\n return (\r\n <div>\r\n <Chat\r\n {...{\r\n currentUser,\r\n sendMessage,\r\n loginUser,\r\n messages,\r\n usersOnline,\r\n }}\r\n />\r\n </div>\r\n )\r\n}\r\n```\r\n\r\nNow we can start up our app with `npm run start` and it works! This data isn't stored or shared though - when you reload that page or load it in an incognito browser, the messages start over from scratch. Not much of a chat app!\r\n\r\n### Step 2: Setup the Amplify DataStore\r\n\r\nWe'll init a new Amplify project and `amplify add api`, making sure to enable \"Conflict Resolution\" (which enables the Amplify DataStore):\r\n\r\n```bash\r\nyarn add aws-amplify @aws-amplify/datastore \r\n# or use npm install\r\n\r\namplify init \r\n# go with all default answers... and when you are done...\r\n\r\namplify add api\r\n? Please select from one of the below mentioned services: GraphQL\r\n? Provide API name: # Any Name Is Fine\r\n? Choose the default authorization type for the API API key\r\n? Enter a description for the API key: # Any Description Is Fine\r\n? After how many days from now the API key should expire (1-365): 7\r\n? Do you want to configure advanced settings for the GraphQL API Yes, I want to make some additional changes.\r\n? Configure additional auth types? No\r\n? Configure conflict detection? Yes # IMPORTANT\r\n? Select the default resolution strategy Auto Merge\r\n? Do you have an annotated GraphQL schema? No\r\n? Choose a schema template: Single object with fields (e.g., “Todo” with ID, name, description)\r\n# some instructions here...\r\n? Do you want to edit the schema now? Yes\r\n```\r\n\r\nThis will open up your editor where we can specify the GraphQL schema for the DataStore (it is exactly the same schema definition language as [GraphQL Transform for AWS AppSync](https://docs.amplify.aws/cli/graphql-transformer/overview)). We'll paste in this very simple schema:\r\n\r\n```graphql\r\n# /amplify/backend/api/YOURAPINAME/schema.graphql\r\ntype User @model {\r\n id: ID!\r\n name: String\r\n}\r\n\r\ntype Message @model {\r\n id: ID!\r\n user: String\r\n text: String\r\n}\r\n```\r\n\r\nSave the file and `amplify push --y` to kick off provisioning the AWS backend!\r\n\r\nWhile that's going, we will run `amplify codegen models` to [generate the DataStore models](https://docs.amplify.aws/lib/datastore/getting-started/q/platform/js#code-generation-amplify-cli) we will use in our React app.\r\n\r\n### Step 3: Wire up DataStore with React\r\n\r\nNow let's put it into use:\r\n\r\n```js\r\n\r\nimport React from \"react\";\r\nimport { DataStore } from \"@aws-amplify/datastore\";\r\nimport { User, Message } from \"./models\";\r\nimport { Chat } from \"react-demos\";\r\nimport Amplify from 'aws-amplify';\r\nimport awsconfig from './aws-exports';\r\nAmplify.configure(awsconfig); // will not sync if you forget this\r\n\r\nfunction App() {\r\n const [currentUser, setCurrentUser] = React.useState(null);\r\n const [usersOnline, setUsersOnline] = React.useState([]);\r\n const [messages, setMessages] = React.useState([]);\r\n\r\n React.useEffect(() => {\r\n fetchMessage();\r\n DataStore.observe(Message).subscribe(fetchMessage);\r\n }, []);\r\n React.useEffect(() => {\r\n fetchMessage();\r\n DataStore.observe(User).subscribe(() => \r\n DataStore.query(User).then(setUsersOnline)\r\n );\r\n }, []);\r\n async function fetchMessage() {\r\n const _Messages = await DataStore.query(Message);\r\n setMessages(_Messages);\r\n }\r\n\r\n async function loginUser(name) {\r\n const user = await DataStore.save(new User({ name }));\r\n setCurrentUser(user);\r\n }\r\n async function sendMessage(text) {\r\n await DataStore.save(\r\n new Message({\r\n user: currentUser.name,\r\n text,\r\n })\r\n );\r\n }\r\n\r\n return (\r\n <div>\r\n <Chat\r\n {...{\r\n currentUser,\r\n sendMessage,\r\n loginUser,\r\n messages,\r\n usersOnline,\r\n }}\r\n />\r\n </div>\r\n );\r\n}\r\n\r\nexport default App;\r\n```\r\n\r\nAnd there you have it - a realtime, offline persisting chat app with Amplify DataStore!\r\n\r\n## Conclusion\r\n\r\nNow you've had a taste, be sure to [head to the docs](https://docs.amplify.aws/lib/datastore/getting-started/q/platform/js) to get a fuller understanding, or [watch Richard Threlkeld's Re:Invent 2019 talk where Amplify DataStore was first introduced!](https://www.youtube.com/watch?v=KcYl6_We0EU&feature=emb_title)\r\n\r\n> P.S. if you are worried about incurring AWS charges following this guide, just run `amplify delete` at the end to delete everything you just set up in one command! The Amplify DataStore itself carries no charge to use, but it uses [AWS AppSync for storage](https://aws.amazon.com/appsync/pricing/) so you should check that pricing as you plan for production usage.\r\n\r\n## Share\r\n\r\nLiked this format/tutorial/video? Got requests for more? Please comment and share it with a [Tweet](https://twitter.com/swyx/status/1293676684747526144?s=20) or [subscribe to my YouTube](https://youtube.com/swyxTV)!","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/realtime-offline-first-chat-app-in-100-seconds-with-amplify-datastore-react-and-graphql-47d4","devToReactions":110,"devToReadingTime":4,"devToPublishedAt":"2020-08-12T22:27:32.821Z","devToViewsCount":3347,"title":"Realtime Offline-First Chat App in 100 Seconds","subtitle":"with Amplify DataStore, React, and GraphQL","published":true,"description":"A quick demo of how easy it is to add realtime, offline persistence to an app with Amplify DataStore","category":"tutorial","tags":"AWS, React, GraphQL","cover_image":"https://docs.amplify.aws/images/sync.png"},"title":"Realtime Offline-First Chat App in 100 Seconds","subtitle":"with Amplify DataStore, React, and GraphQL","description":"A quick demo of how easy it is to add realtime, offline persistence to an app with Amplify DataStore ","category":"tutorial","tags":["aws","react","graphql"],"image":"https://docs.amplify.aws/images/sync.png","slug":"realtime-offline-first-chat-app-in-100-seconds-with-amplify-datastore-react-and-graphql-47d4","date":"2020-08-12T22:27:32.821Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/334","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/334/comments","title":"Realtime Offline-First Chat App in 100 Seconds ","created_at":"2022-01-18T00:21:12Z","updated_at":"2022-06-18T17:45:00Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/334/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n_Note: this doc has continued to be updated up til 2022._\r\n\r\nSomeone in the [Coding Career Community](https://www.learninpublic.org/#community) asked:\r\n\r\n> Is there a good guide out there to familiarize oneself with the structures and lingo of startups? I mean knowing about seed fundraising, equity rounds... don't be afraid to go really basic on it. Startups for Dummmies.\r\n\r\nI realize that the lingo can be pretty scary for new developers and the tech news media never really stops to explain some basics. So here is a quick brain dump of thoughts at least from a US-biased perspective. This is a living document, please feel free to add in comments and I will edit.\r\n\r\n## Important Caveats and Disclaimers\r\n\r\nI'm just a developer with a former finance background and an interest in this stuff. But I'm no expert or VC. I have never personally raised any startup money. but I do keep tabs on the US startup ecosystem and have worked at a couple startups, most recently from [Series B to C](https://dev.to/swyx/working-at-a-startup-from-series-b-to-c-445p) (Update: I posted an update on working from [Series A to B here](https://www.swyx.io/temporal-centicorn).)\r\n\r\nJust sharing what I know, developer to developer, not trying to come across as an authoritative source or anything. \r\n\r\n## Why Fundraise At All\r\n\r\nWe should probably start with why you even want to raise funds, when most \"normal\" (non tech) businesses start with a bank loan or a \"rich uncle\".\r\n\r\nThis happens because of the economics of scale. If you're just starting a mom 'n pop shop, you don't need a lot to get started, and you can (hopefully) recoup what you invest in a short amount of time. \r\n\r\nBut if you're building a $1b factory to make $200 computer chips or hiring a bunch of $200,000/yr engineers to write $10/month software, you need a lot of money upfront, and patience to grow sales up to the point where your overall profits start to cover the upfront cost you incur.\r\n\r\nMany startups don't start with their full economics worked out yet. The assumption is that if you can get a bunch of users first, you can figure out how to monetize them later. So modern startups can often run with negligible revenue for years (think: GIPHY, Reddit, Facebook, but also open source developer tooling companies like Gatsby) while having a **burn rate** (contractually obliged spending, like employee payroll or office rental) of hundreds of thousands a month. This is especially important if the goal is to spread virally, or to form a sticky habit.\r\n\r\nOften, aggressive companies will even use the money they raise to subsidize their customers, just to grow the customer base and build the habit (think: Uber/Lyft, Postmates/Doordash). They will literally *make a loss on every transaction*, something you can only do if you have deep pockets. So you go *deeper* in the #red the *faster* you grow. As you might imagine, this is high risk, high reward. Giving money to customers to get customers sounds like a terrible business, but it worked very well for Paypal.\r\n\r\n> Pop culture reference: You saw this happen on [HBO's Silicon Valley where Richard Hendricks \"bankrupts\" Sliceline](https://www.youtube.com/watch?v=Txl90NEl92U) in order to acquihire the company, by buying a bunch of pizzas from them. In reality this is very unlikely to happen due to the expense, but it's a TV show 🤷‍♂️\r\n\r\nMoney is often also bundled with advice and network. You may not NEED the money, but if you are building a social network, you might well want to raise money from Reid Hoffman or Peter Thiel just to get their advice. If you are selling to developer enterprises, you may want to raise money from Y Combinator just to get your foot in the door to sell to all Y Combinator alumni companies. Do note that the actual value of these non-monetary aspects of fundraising is heavily disputed. \r\n\r\n## Fundraising Economics\r\n\r\nThere are two main ways of financing any business venture: **Equity and Debt**. There's a thousand tiny variations of combinations of them (see \"Nuances\" section next) but you should understand the big picture first.\r\n\r\n- **Debt** is what you might be familiar from taking on a mortgage for a house - I lend you a sum of money, and you agree to pay it back to me in future, with some amount of interest due every year for my trouble. \r\n\t- If your business valuation grows, I take no benefit from that, I merely continue to receive my interest payments. \r\n\t- If your business goes bankrupt, you don't owe me anything (more accurately, I take possession of your remaining assets) - thats the risk I took in exchange for those interest payments. \r\n\t- Since most startups fail, most startups are not able to get lenders to take this risk (aka, raise debt capital). \"*Venture Debt*\" does exist though, for the small category of [startups who can raise it](https://wistia.com/learn/culture/taking-on-debt-to-grow-our-own-way).\r\n- Most fundraising takes the form of sale of **Equity**. This is a straightforward exchange of cash for a partial ownership in the company. \r\n\t- The math gets a little circular, because the value of the company goes up when the money goes in, which then affects what % of the company you actually own. So the startup community has adopted a simple terminology. You have a **\"pre-money valuation\"** and a **\"post-money valuation\"**. The \"money\" here is the amount invested/raised. So say I give you a $45m pre money valuation and I invest $5m. Your post money valuation is $50m, and I now own a 10% stake in your company (5 divided by 50). In practice this lingo can be shortened in various ways: \"I raised 5 on 50\", \"I'll take 10% on a 50 post\", so on. The lingo differs but the math is the same.\r\n\t- Most valuations quoted are post-money, because it is the bigger and easier number to do math with. If you are given $1m in equity of a company valued at $1b, it means you have 0.10% of the company (important nuances apply w.r.t. dilution, vesting, and preference stack)\r\n\r\n## Important Nuances on Equity\r\n\r\nEarly stages of startups often have a hybrid between debt and equity. This is often used to deal with the fact that trying to place a valuation on an early stage company with no revenues is meaningless, but standard debt is unattractive for the investor, so we improve the upside for them by letting the debt convert into equity at some future point. This has a few names, and is known as **convertible debt** in the public markets, but in startups the popular version of this is the [Simple Agreement for Future Equity or SAFE](https://www.ycombinator.com/documents/) ([explainer here](https://joshephraim.medium.com/complete-guide-to-understanding-safes-how-we-invest-at-dorm-room-fund-bbb37855ec4e), [UpCounsel explainer here](https://www.upcounsel.com/safe-notes)), introduced by Y Combinator in 2013. SAFEs recognize the futility of placing a valuation number on an early stage, and only convert to equity in a future **priced round**. \r\n\r\n> Technically if you raise SAFEs and then never raise a priced round, your investors and employees never get anything back. [Toptal founder Taso du Val is accused of doing this](https://www.theinformation.com/articles/at-booming-toptal-no-stock-for-employees-or-investors). \r\n> \r\n> also, if you raise MULTIPLE SAFEs, do note [the antidilutive properties of post money SAFEs](https://twitter.com/jayyeh/status/1512061954734510088).\r\n\r\nAnother way startup investors sweeten the deal is to include special terms in the contract. There are a wide range of these:\r\n\r\n- An option to invest further money in future funding rounds\r\n- Some sort of \"preference\" or \"preferred\" status in the investment, where, if the business gets sold, they get paid back first ahead of other investors\r\n- Anti-dilution terms to defend against **dilution** from future fundraising (I'll explain below)\r\n- Board seats (which lets investors have a say in company strategy and hire/fire senior management including founders - routine for lead investors of each stage to have, but also where [they turn from fans to your boss](https://reactionwheel.net/2021/11/your-boards-of-directors-is-probably-going-to-fire-you.html).)\r\n- Jason Calacanis likes to attach side letters to [SAFEs](https://thisweekinstartups.com/understanding-financing-structures-safes-convertibles-notes-priced-rounds-more-with-becki-degraw-wilson-sonsini-startup-legal-basics/) \r\n- and more I cant think of and don't know about (*what other major terms should i add?*)\r\n\r\n**Dilution** is what happens when startups issue new shares to raise subsequent rounds of funding and you aren't involved. This happens because nobody ACTUALLY sells \"10% of a company\". You create, out of thin air, 1 million shares, and give me 100,000 of them. Then, for the purpose of simple math, when you raise your next round, you create 1 million more shares, and I for whatever reason don't invest more money, my 10% goes down to 5% (because I now own 100,000 shares out of a shareholder base of 2 million shares).\r\n\r\nTypical dilution by stage [from Index Ventures](https://www.indexventures.com/optionplan/#expected_funding_rounds_pre_exit=series-b-and-c&employee_country=us&mode=seed):\r\n\r\n- Series A: 20%\r\n- Series A+B: 33%\r\n- Series A+B+C: 41%\r\n- Series A+B+C+D: 47%\r\n\r\nYou most famously saw dilution dramatized in [The Social Network](https://www.youtube.com/watch?v=xdiFzcpmmJc), when Eduardo Saverin was diluted out of his ownership of Facebook. This happens to cofounders, employees, and unsophisticated investors if they aren't careful ([ugly wipeout example here](https://blocksandfiles.com/2020/10/12/actifio-reverse-stock-split-employees-hit/)). Therefore anti-dilution terms are used to protect investments. Some go overboard and become genuinely predatory, eating up more of the company when it is not doing well, like the dreaded **[full ratchet](https://www.cooleygo.com/glossary/full-ratchet/)**.\r\n\r\n[![image](https://user-images.githubusercontent.com/6764957/156240391-816295ef-93fc-4904-9b4e-9854f1058aa5.png)](https://carta.com/blog/state-of-private-markets-report-q4-2021/)\r\n\r\nFundraising Terms are deals with the devil. You of course get better valuation and more money with these terms, but they make it more complicated for you down the line as well as for everyone else on your **\"cap table\"** (the list of people who invested with you). If you wish to be acquired some day, you ideally want to have \"**clean terms**\". Of course this is the domain of lawyers and much negotiation.\r\n\r\nNow that you know what **dilution** is, you can also learn the difference between **primary** and **secondary** share sales. **Primary** fundraising happen when you create new shares out of thin air and sell them to investors. **Secondary** sales happen when you transfer ownership of existing shares to investors. Most fundraising is primary. However, you often see some secondary sales as well bundled alongside the primary sales, especially in later stages. This allows founders and employees to \"take some money off the table\", and is usually not a sign of lack of faith in the company. Instead, secondary sales are mostly simple pragmatism in that founders and early employees may sit on paper wealth worth millions which might go to 0 someday, so it is prudent to cash in some of it in. Basecamp founders Jason Fried and DHH are famously criticized for \"raising money\" from Jeff Bezos, but this [was a secondary sale](https://m.signalvnoise.com/the-deal-jeff-bezos-got-on-basecamp/) that gave them the financial security to build for the long term.\r\n\r\nAn extreme version of secondary sale is VC's buying out other VC's. Chris Sacca [became a billionaire by buying up 10% of Twitter](https://techcrunch.com/2011/02/27/jp-morgan-twitter-chris-sacca-10-percent-secondary/) from other shareholders who weren't as optimistic as he was. VC's have also been known to stalk departing employees to snap up their shares in a hot company. \r\n\r\nMost employees do not get outright grants of equity. They get **options** to buy equity. They also don't get these options right away - they **vest** over time to ensure that you can't just join for 1 month and leave with the whole amount (Founders vest too). If they leave the company, they get to \"buy in\" to the company they helped to build. If the company gets acquired, all employee options convert to shares. For more details on the employee perspective, see the [Holloway Guide to Equity Compensation](https://www.holloway.com/g/equity-compensation).\r\n\r\nIn the US, it is generally illegal to openly solicit funds for your startup. To protect the average Joe from losing money to some get-rich-quick scheme, you can only raise in private from accredited investors (read: rich people). Of course, this could also have the downside of reserving opportunities to get rich only to the already rich. Exceptions to this rule are opening up, between [the JOBS act](https://www.investopedia.com/terms/j/jumpstart-our-business-startups-act-jobs.asp) and [Reg 506(c) for rolling venture funds](https://techcrunch.com/2020/08/05/gumroad-founder-sahil-lavingia-launches-new-seed-fund-in-collaboration-with-angellist/).\r\n\r\n## Fundraising Stages\r\n\r\nIn the course of their life as a private startup, startups often raise anywhere from $5m to $5b, between their founding to their **Exit**.\r\n\r\n[![https://assets-global.website-files.com/5f3e7f710351ee0491efb21b/60f1adf608217849e9ec7bad_JQLsOCpuBmIKY4aTJYBAWUbcwBbpNR9N2dwyrkG-czh6KREcDS8jZq9m7YLr_ovV6qgCWEQrnCsIlCcCFld1_8Qxm4kuDwuXydfil0UgedCxOWjAdDRQCe0NvKffkkcwinmeWYGf.png](https://assets-global.website-files.com/5f3e7f710351ee0491efb21b/60f1adf608217849e9ec7bad_JQLsOCpuBmIKY4aTJYBAWUbcwBbpNR9N2dwyrkG-czh6KREcDS8jZq9m7YLr_ovV6qgCWEQrnCsIlCcCFld1_8Qxm4kuDwuXydfil0UgedCxOWjAdDRQCe0NvKffkkcwinmeWYGf.png)](https://www.angellist.com/blog/angellist-unicorn-rate)\r\n\r\nAn \"exit\" is VC lingo for either an Initial Public Offering or an Acquisition. In both cases, the VC gets paid back on their investment either in public company stock or in cash and are said to have \"exited\" their investment - although in reality many VC's often hold on to their stock after IPO, sometimes for years, because they continue to believe in the company as an investment.\r\n\r\nWhen you hear a company do a successful exit, it can be common to assume that the founders are billionaires. This is often far from the truth, though they certainly won't have to work again. Typical founder ownership percentages by exit range from 5-20%. It's much more likely that \r\nVC's have more ownership than founders and therefore make more from the exit (and are financially more incentivized to push for an earlier exit than founders). If that sounds like a bum deal, it can be. Someone running a $100m bootstrapped company can be wealthier than someone running a $10b unicorn. So of course, putting off fundraising can be very beneficial for founders, at the expense of speed of growth. the Atlassian founders [owned 60% of the company](https://www.businessinsider.com.au/atlassian-files-for-ipo-2015-11) at IPO, but took 15 years to get there. \r\n\r\nMost professional VCs are not investing money out of their own pockets. VC firms take a partnership format and raise funds in vintages like wine. They raise money from institutions, which range from pension funds to university endowments to family offices (read: \"rich people\"), who form their **\"Limited Partners\"** (LP's). The principal VC investors are thus **\"General Partners\"** (GP's) of those partnerships. Now you know what it means when VC's talk about their \"fiduciary duty to LPs\". The compensation model is usually some variant of \"2 and 20\" - speaking VERY VERY loosely, VC's earn 2% of funds invested per year, and 20% of realized profits over some pre-agreed hurdle on exit. This varies WILDLY, and I want to be extra clear that I have only very third-hand knowledge of the actual terms here.\r\n\r\nBut the point is this - **funds are raised for a specific purpose to serve a specific clientele with desired risk profile and investment mandate.** Some LPs are comfortable with the risks of early stage investment. Some only want to invest in proven later stage companies. Money is NOT the same shade of green everywhere. It is completely reasonable and natural to have different profiles of investors along the lifetime of a journey. Further, these investors expect a return on their investment within a reasonable timeframe, say, 10 years (the commonly cited amount of time between starting and exiting a \"unicorn\" startup - though this has gotten longer recently as more and more financing moves to private markets).\r\n\r\nThere are no hard and fast rules with fundraising stages, but there is an informal norm with many exceptions. As a rule of thumb, 10-30% of post money equity is sold at every stage, and you need to reach some proof points before you get the next stage. The other way to think about stages is that given your projected **burn rate** (contractually obliged spending, like employee payroll or office rental), you want to raise about 1.5-2 years worth of funds at each stage (burn typically does a quantum step up at every stage, you see a flurry of hiring in order to meet aggressive growth targets).\r\n\r\nFunding rounds also tend to inflate over time - $20m raised in 2010 is much much more than $20m in 2020.\r\n\r\n![image](https://user-images.githubusercontent.com/6764957/158273390-8e8cf700-c649-4db8-8922-03ffd3fd0f62.png)\r\n\r\n> 2023 edit: we now have data that says [series A/B/C are the highest expected value stages](https://twitter.com/GallagherBilly/status/1719750729600991352) from 2015\r\n\r\nHere is a very rough, illustrative guide:\r\n\r\n- **Angel/Pre-seed round**: the \"first money in\" to any company. Usually these are former entrepreneurs looking to \"give back\" to the next generation of entrepreneurs. There are legends and self made billionaires in this space alone - [Chris Sacca angel-invested in Uber, Kickstarter, Twitter, Instagram, and Facebook and returned 250x his investors' money](https://observer.com/2017/08/the-strange-question-chris-sacca-used-to-build-the-greatest-angel-portfolio-ever-investing-venture-capital/). Jason Calacanis has written a [notable book](https://www.goodreads.com/book/show/32600757-angel) on this and Naval Ravikant started [AngelList](http://angel.co/) to help angel investors find you. The size of this round is very small, from 50k to 500k. You're not expected to have much here beyond an idea and a passionate pitch. Some startup accelerators like YCombinator (Pitch guide [here](https://www.actiondesk.io/blog/small-guide-to-preparing-y-combinator-in-person-interview) and [from pg](http://paulgraham.com/ace.html)) or Launch or TechStars will have a packaged deal for you of ~100k for ~7% of the company and then everyone else who follows on invests with SAFEs. \r\n - The difference between seed and preseed is arbitrary. You're telling a story - [narrative](https://twitter.com/gokulr/status/1380741338191126530) can make the same company worth 2x more.\r\n- **Seed round**: the first \"institutional\" money in from **incubators** and **seed stage VCs**. The amount raised is anywhere from $0.5m to $5m at valuations from $2-20m. Some \"celebrity investors\" can come in for just tiny checks of $5-50k, just lending their prestige to the startup. (\"we are backed by the founders of X, Y, and Z\"). Here you may have a working proof of concept, or a [minimal viable product](https://en.wikipedia.org/wiki/Minimum_viable_product), and hopefully [a business plan](https://www.sequoiacap.com/article/writing-a-business-plan). See [Airbyte's seed round deck advice](https://airbyte.com/blog/the-deck-we-used-to-raise-our-seed-with-accel-in-13-days). Here is extensive detail on [a real life seed round from Freshpaint](https://www.freshpaint.io/blog/anatomy-of-a-seed-round-during-covid-19), right down to check size of each investor. Looker ($2.6bn exit) raised their seed with a [216 word email](https://review.firstround.com/the-inside-story-of-how-this-startup-turned-a-216-word-pitch-email-into-a-2-6-billion-acquisition). Sample [Series Seed term sheet here](https://github.com/CooleyLLP/seriesseed) - (old versions [here](https://www.seriesseed.com/posts/financing-documents/)).\r\n - [2.5% of seed stage startups make it to unicorn status](https://www.angellist.com/blog/angellist-unicorn-rate)\r\n - https://pioneer.app/codex/fundraising\r\n - https://venturehacks.com/deck (2007: one of the OG references)\r\n - some startups go up to [$100m valuation](https://avc.com/2021/11/seed-rounds-at-100mm-post-money/)\r\n - Airbyte's [Seed deck](https://airbyte.com/blog/the-deck-we-used-to-raise-our-seed-with-accel-in-13-days) \r\n- The Seed to Series A gap is a big discontinuity/milestone. Seed Extensions are common - [note the math](https://twitter.com/lpolovets/status/1560063089822773249?s=20&t=yAV89kcQeDytKka_nELD3g) on who invests in extensions.\r\n- **Series A**: this is where things get serious and you start to be on the \"VC clock\". [It is possible](https://sahillavingia.com/reflecting), but very rare, to get off the VC track once you are on. Please note that ([as Greylock mention](https://greylock.com/greymatter/from-seed-to-series-a/)) none of the following are hard and fast rules: You have a working product, 10-20 employees, a small base of loyal users, and a plan to get to Series B in the next 2-3 years. Revenue should be [growing 2, 7, 16, 34, 70, 144](https://twitter.com/sytses/status/1209504876109221895?s=20&t=z6O9ynhV6sNtKll0rKvK9A). Your mandate is to grow this userbase and potentially build out your platform. You might also start to monetize, but it is not super important right now. Amount raised from $10-$25m, with exceptions on either end (this goes for everything in this post). Here's [Standard Treasury's Series A Deck](http://blog.zactownsend.com/standard-treasurys-series-a-pitch-deck) and [YCs guide to series A decks](https://www.ycombinator.com/library/8d-how-to-build-a-great-series-a-pitch-and-deck), [Airbyte's A](https://airbyte.com/blog/how-airbyte-raised-its-series-a-round-2-months-after-its-seed) and [Emergence Capital's guide](https://www.emcap.com/thoughts/the-5m's-how-emergence-evaluates-series-a-pitches/) \r\n\t- More deck advice: https://andrewchen.com/investor-metrics-deck/\r\n- **Series B**: this is where you start to really pour fuel onto the fire. By this stage you might be regarded to have [\"product-market fit\"](https://en.wikipedia.org/wiki/Product/market_fit), a clear business model, 40-50 employees and a clear story around how 1 additional dollar of funds raised turns into 5 or more dollars of customer lifetime value. **Cash is the limiting business factor.** Amount raised $15-$50m. Check out [LinkedIn's Series B Pitch Deck](https://www.reidhoffman.org/linkedin-pitch-to-greylock/) and more recently [Airbyte's Series B](https://airbyte.com/blog/the-deck-we-used-to-raise-our-150m-series-b). It has been called [the hardest round to raise](http://tomtunguz.com/hardest-round-raise-2017/). If you are doing really well your B may look more like a C, as with [Mixpanel raising 65 on 865m](https://mixpanel.com/blog/open-sourcing-our-pitch-deck-that-helped-us-get-our-865m-valuation/)\r\n- **Series C**: Your business model is working! You've built out your 2nd or 3rd product and they're also doing well! You’re at 100-150 employees and starting to not know who everybody is. You've reached the proof points needed to unlock the MASSIVE growth stage! Amount raised $30-$100m. [Here's Front's Series C Pitch Deck](https://medium.com/@collinmathilde/front-series-c-deck-11773b30b272).\r\n- Round about here you hopefully become a **unicorn** (valued at $1b or more)\r\n- **Series D-G**: You are on the path to becoming a **decacorn** (10b or more) and/or you are burning a lot of money and don't want to IPO to get it.\r\n\r\nHere's is a list of some popular names of investors that specialize in each stage: https://www.fundz.net/what-is-series-a-funding-series-b-funding-and-more\r\n\r\nThese numbers are merely illustrative and there are lots of great reasons why an individual company might not meet those situations. After all, the nomenclature of \"Series A B or C\" only depends on the order of fundraises. Jason Calacanis has coined the term of **\"Pegasus\"** for companies that normally would've raised a round at a particular stage, but don't because they didn't need the money, therefore they \"fly\" over a particular stage. Webflow is one example of a Pegasus that [raised an abnormal $72m \"Series A\"](https://news.crunchbase.com/news/webflow-raises-72m-series-a-continuing-the-trend-of-outsized-early-stage-rounds/) (not at all a standard Series A by any metric).\r\n\r\nOf course there are other reasons to reach abnormal valuation at any given stage - serial founders with proven track records, or just abnormal business results, like with [Rippling's $145m Series B](https://www.rippling.com/blog/entrepreneurship/pitching-vcs-heres-the-deck-we-used-to-raise-145m/).\r\n\r\nThe most aggressive VCs and high potential startups do **\"pre-emptive\" rounds** - meaning they get the money they would have received for a stage, despite not having yet met the traditional metrics needed for that stage. Pre-emptive A's and B's are common.\r\n\r\nOn the other end of the spectrum, if startups need a little more time to hit their metrics, they often get intermediate rounds of funding. This can be called a number of things, from \"bridge\" to \"extension\"\r\n\r\nGiven how every case is special, funding dynamics are always very difficult to generalize. You can find collated data in [Crunchbase](https://en.wikipedia.org/wiki/Crunchbase) and [Pitchbook](https://pitchbook.com/). They also change over time. The amounts and valuations of each stage has almost doubled over time compared to where they were 10 years ago.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/u3a0e9h31x7b5bt0vqsh.png)\r\n\r\nIt will likely shrink and grow together with the economy. The exits of one generation of entrepreneurs also frees up money to invest in the next, so investing can happen in waves.\r\n\r\n![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/2f9vjk0bflp3gaiblieu.png)\r\n\r\nIf you are wondering how fundraising has been affected by Covid, [here's some data for you](https://tomtunguz.com/fundraising-market-corona-two-quarters-in/) - investment sizes have gone UP, numbers have gone DOWN. Massive concentration in companies that are doing well.\r\n\r\n## To be continued?\r\n\r\nPhew that was a lot. Let me know if there are still unanswered questions and I'd be happy to add to this.\r\n\r\n## More Resources\r\n\r\n- read [Paul Graham's 2007 Hacker's Guide to Investors](http://www.paulgraham.com/guidetoinvestors.html)\r\n- some people do help to fundraise, like [Foundersuite.com](https://seedtoharvest.buzzsprout.com/1902723/11182231-nathan-beckord-ceo-of-foundersuite-com-on-how-to-create-proactive-investor-updates-his-passion-for-sailing-and-giving-a-memorable-pitch-to-investors-seed-to-harvest-ep-27)\r\n- setting up a “data room” for investors https://future.com/insiders-guide-to-data-rooms-fundraising/\r\n\t- beware the VC backchannel: https://twitter.com/dunkhippo33/status/1564339076035055617?s=21&t=2OIXIDKKhEFDr07BOrBRpQ \r\n- Professional slides agency https://www.zacht.studio/ https://www.presentation.design/\r\n- Paige Finn's guide - [Seed to Harvest: A Simple Explanation of Venture Capital](https://www.amazon.com/dp/0578906457)\r\n- IVP's [SaaS Fundraising Handbook](https://www.ivp.com/saas-fundraising-handbook/)\r\n- How much to pay yourself: https://kruzeconsulting.com/blog/post/startup-ceo-salary-report/\r\n- Rahul Vohra fundraise advice https://techcrunch.com/2021/11/16/superhuman-ceo-rahul-vohras-5-essential-rules-for-your-first-fundraise/\r\n- Tom advice https://tomblomfield.com/post/662033487432466432/how-to-raise-investment\r\n- Jason Calacanis advice https://www.youtube.com/watch?v=Dr1Gh4uo2qQ\r\n- Spencer Kimball advice https://www.youtube.com/watch?v=3kvBIplSrI4\r\n- Legal and Accounting: https://pioneer.app/codex/legal\r\n- Glossary: https://pioneer.app/codex/glossary\r\n- [Guide to the 409a valuation process](https://www.founderscircle.com/startup-409a-valuation-process/)\r\n- It's interesting to learn how _VC's themselves_ raise funds - see their slide decks: https://www.signatureblock.co/p/vc-fund-decks-that-close-lps","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/brief-guide-to-startup-fundraising-terminology-7k2","devToReactions":61,"devToReadingTime":15,"devToPublishedAt":"2020-08-12T00:21:55.990Z","devToViewsCount":1035,"title":"A Developer's Guide to Startup Fundraising","published":true,"description":"A Brief Guide to Startup Fundraising Terminology for Beginners","cover_image":"https://res.cloudinary.com/practicaldev/image/fetch/s--6RF62X89--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/2f9vjk0bflp3gaiblieu.png","canonical_url":"https://www.swyx.io/brief-guide-to-startup-fundraising-terminology-7k2","category":"essay","tags":"Startups, Fundraising, Money"},"title":"A Developer's Guide to Startup Fundraising","description":"A Brief Guide to Startup Fundraising Terminology for Beginners ","category":"essay","tags":["startups","fundraising","money"],"image":"https://res.cloudinary.com/practicaldev/image/fetch/s--6RF62X89--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/2f9vjk0bflp3gaiblieu.png","canonical":"https://www.swyx.io/brief-guide-to-startup-fundraising-terminology-7k2","slug":"brief-guide-to-startup-fundraising-terminology-7k2","date":"2020-08-12T00:21:55.990Z","readingTime":"17 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/335","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/335/comments","title":"A Developer's Guide to Startup Fundraising","created_at":"2022-01-18T00:21:14Z","updated_at":"2024-03-02T08:43:23Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/335/reactions","total_count":1,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":1,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nFrom [April to July 2020](https://www.swyx.io/writing/coding-career-launch) I made >$45k writing and selling [the Coding Career Handbook](https://www.learninpublic.org/) and the related Community and Creator packages to over 1k individual developers, teams, and bootcamps.\n\n> Before you get too excited, know that it was over 600 hours of work, and probably took me 2-3 years of relationship building, career experience, and blogging before that to build up to this. I was exhausted afterward. I will NOT be able to repeat this strategy or topic again for a while, this was at best a once-every-couple-years effort.\n\nToday I got some questions from [Jess Eddy](https://twitter.com/jesseddy/status/1292969688083755009?s=20), who is planning to write her first book (also a career advice book, but different industry). \n\nI'm answering in public!\n\n---\n\n## 1. Did you test the contents of your book while writing it?\n\nYes! It served two purposes - marketing the book as well as getting feedback from readers.\n\nMy first attempt at this went EXTRAORDINARILY well. I wrote and published [How To Market Yourself](https://twitter.com/swyx/status/1249793388037025797?s=20) 3 days after deciding to write the book. This was explicitly marked as a chapter in the book.\n\nI knew it would be a popular topic, but there was some risk in that, if the chapter turned out bad, I would lose credibility (if I can't market a blogpost, can't market a book, how can I teach others to market themselves?). I took the risk.\n\nFortunately, it did not fail. It is probably my 3rd or 4th most popular piece of writing ever. It also immediately got me booked on 3 different podcasts ([like this](https://www.productionreadypod.com/episodes/marketing-yourself-your-products-by-learning-in-public-w-shawn-wang) and [this](https://www.youtube.com/watch?v=QFHO2-8fGtM) and [this](https://aquestionofcode.com/71-how-should-developers-market-themselves-shawn-wang/)). So publishing the chapter helped market the book and helped me produce even more free collateral for the site! Wonderful stuff.\n\nI also livestreamed 5 hours of this writing process. After launch, I took down the livestream and made the video part of my \"Creators package\" (which helps teach others to \"get paid to learn in public\", aka create their first products). Might as well reuse valuable work, eh?\n\nIn case you think I know what I'm doing, my second and third attempts did not fare as well. \n\nThe second attempt was my Intro to Tech Strategy chapter - first released as a [screenshot](https://twitter.com/swyx/status/1250837183264522242?s=20), and then [as a blogpost](https://twitter.com/swyx/status/1253009793448460288?s=20). I think the topic choice was a mismatch between how important I *know* it is to developers, but how much developers are inherently interested in it. Fortunately, I believed in this topic strongly enough to not care that it didn't do well. I also got some valuable feedback in a couple of interactions.\n\nThe third attempt [did not do much better](https://twitter.com/Coding_Career/status/1258070398605774848). I knew \"Junior Developer vs Senior Developer\" was a hot topic. I wrote up a whole chapter, but only published some core quotes. I chose a different format here - tweet thread from book account, not main account. It has a smaller following of course. I'm not sure how I could have done this better.\n\nI also livestreamed writing my chapter on Why You Should Write. Very meta, but it [didn't really do well](https://twitter.com/swyx/status/1259186402907967488?s=20).\n\nat this point i just abandoned public testing and just went heads down writing until the book was done, then when i was 99% done I started sending out to early reviewers for both testimonials and feedback on things that could be problematic (HUGELY important for a soft skills book like this one with a massive attack surface I can be criticized on)\n\nThroughout the writing process I kept tweeting behind the scenes from both my personal account and my book account. I also presold the book, so I was able to send periodic updates to presale buyers, which serves as a form of marketing.\n\n---\n\n## 2. What publishing methods have been most fruitful for you (Kindle, Gumroad, etc.)?\n\nThere are two questions here. Publishing format and publishing platform.\n\nI think the format you pick will depend on the kind of experience you aim to deliver. If you have a graphics/design heavy book, for example, then go PDF-only. If you have a text-heavy book like mine, then be aware that the market is [exactly split a third each between EPUB, MOBI and PDF](https://twitter.com/swyx/status/1265301477049790464?s=20), and your publishing tool will ideally want to support all of them (this is annoyingly hard to achieve AND have other requirements met like having autogenerated Table of Contents - which the professional writing app Ulysses has had \"on the roadmap\" [for 7 straight years](https://twitter.com/ulyssesapp/status/1252593635125792772?s=20)). I used Michael Hartl's [Softcover](https://www.softcover.io/) which does the job, but requires you to learn some LaTeX to typeset to acceptable quality. (more on typesetting in a future post, lmk what qtns you have here)\n\nChoice of Platform is a smaller field of choices.\n\n- Kindle Direct Publishing takes a HUGE cut. They take 30% if you charge under $9.99, and 70% if you want a higher priced book. You also of course don't have the option to sell packages.\n- Gumroad is well known in this space, mainly bc of the founder's marketign ability. They charge 3.5% + 30c with a $100/yr Creator account. They have a trusted brand and can take PayPal, which is good in some circles. They also serve as a \"Merchant of Record\" which helps US/Canada residents not worry about state/VAT tax nonsense. Their landing page is spartan and serviceable, but buggy (not terminal). And their couponing/affiliate system is easy to use. Analytics are good. Their \"marketplace\" can bring enough sales to cover the cost of a Creator account.\n- Podia is the other big player here. Where Gumroad focuses on ebooks, Podia is more generalist on ebooks + video courses + webinars + email marketing. They don't charge transaction fees, but cost $390-790/yr depending on plan. I've made back the $790 on affiliates alone. Do the math as to how much you expect to sell vs the feature set. Their landing page is better designed but still kinda ugly. Analytics nonexistent. And their external embed widget is buggy. However, their support for memberships/video/webinars/email made me switch from Gumroad to them. They also offer live chat with your customers, which people ACTUALLY use, surprisingly.\n- both founders of Gumroad and Podia are cocky and annoying and sometimes problematic. idk if that matters to you. it's pissed me off sometimes.\n- Quite honestly, you can't go wrong picking either Gumroad or Podia. both aren't perfect but they do similar jobs in slightly different ways. If you end up using Podia you can toss me a few coins using my podia referral https://www.podia.com/?via=shawn-wang at no cost to you.\n- Paddle is another big player but mostly seems to be used by Europeans. They can sell ebooks but also do packaged software (e.g. little utilities)\n- Other smaller players are out there, like Sellfy, Happeno, Payhip and the newly launched Converkit Commerce. No exp with them.\n\n---\n\n## 3. How did you figure out pricing and did it change over the course of time?\n\nI honestly wasn't very scientific about pricing.\n\nI started out wanting to presell, so I picked a $19 price point on the day of the presale and said it was 50% off, making my \"actual\" price $39. This was back when I intended to make it a 2 week writing effort.\n\nAs I wrote and wrote and my scope grew, I decided I wanted to write a bigger book. So as 2 weeks became 2 months I kept selling it at $19, but I knew I'd be asking more at the end.\n\nIn the leadup to launch I kind of reverse engineered everything from $39. I knew I wanted the launch price of the book to be $39. Assuming a launch discount of $20, that means full price of the book is $59. from there, I then priced the Community package at $99 (just under buying another book, with the promise that you get more out of it if you join the community. Along with an audiobook version, which people are used to paying extra for and did take a ton of extra work) and the Creators package at $249 (with extra workshops and the livestream). I set these with a quick call for advice from [Joel Hooks of Egghead](https://twitter.com/jhooks/status/1278357145411399680?s=20).\n\nThe 20% launch sale lasted through all of July. Now the sale has expired, people are still buying $200-300 of book daily. I don't know how much more I would get if I had priced the book at a more normal $39 instead of $59. But I'm happy making $6-9k a month while this lasts.\n\nIf the goal was to maximize revenue, I might do more pricing experiments. But instead, I wanted to write an aspirational book and I stand by the value of the book. A higher list price also leaves me room to do sales in future.\n\nNeither Podia or Gumroad have capability to adjust prices for purchasing power, so I don't explicitly offer it, but I have reserved some coupons for countries with obviously lower income.\n\n---\n\n## 4. How do you market your book?\n\nheheh. See #1.\n\nI haven't done much marketing post-launch. The occasional tweet, that's about it. I've offered an affiliate program to friends so that has helped some but I think mostly it's word of mouth from here on out.\n\nI'm thinking of trying out [Acadium](https://app.acadium.com/). I don't really know. seems like a lot of work, and I have a day job. Ideally I'd like to pair up with a marketing partner and split things 50-50.\n\n---\n\n## 5. Is there anything else you think is worth sharing?\n\nAdvice from Robert Kiyosaki: \"They're called best SELLING authors, not best WRITING authors.\" You may feel like writing is the most important thing you can do as an author, but it's probably equal parts selling as it is writing. I'm still learning this. a HUGE part of it is the landing page for the book pretty much sets the expectation for the user driving their purchase decision. Have a look at [Rob Hope's teardown of mine](https://dev.to/swyx/8-landing-page-tips-from-rob-hope-338l) and [Mahmoud Abdelwahab](https://twitter.com/thisismahmoud_/status/1286683701322055680?s=20)'s refactor of my shitty initial page. Landing page is really that impt. Check Rob Hope's [epic thread of advice](https://twitter.com/robhope/status/1265278107088347136) and [use my link](https://t.co/6PElS7Iaa9?amp=1) if you want his book. If you are great at designing your own, you can even do [$40k presale like Emma](https://compiled.blog/blog/how-i-made-40000-dollars-on-a-book).\n\nIf you have no audience and no authority you can bootstrap it by interviewing a bunch of folks like [Philip Kiely](https://philipkiely.com/wfsd/) did. I don't know how the commercial terms for these things work and suspect it worked for him bc he is a college kid. But doing interviews are an easy content+marketing package.\n\nDon't forget to make a team licence. I've made about 2k like this.\n\nDon't worry about DRM/piracy.\n\nFor specific launch sequences and to study comparable launches, please check out my **[launch cheatsheet](https://github.com/sw-yx/launch-cheatsheet/blob/master/README.md)**. Contributions VERY welcome, including of your own reflections.\n\n**It doesn't end with the launch, and it doesn't end with the book either.**\n\nYou can keep putting out new versions, continue to add value to the higher tiers. And when you launch your NEXT thing, be it a course or book, you can bundle this book together with it to add extra value. When you launch you will feel like this is the most precious thing in the world, because you worked so hard on it, but with the passing of time it'll be emotionally easier to give the book away for other gains.\n\nIf you have a plan to \"win\" whether or not the book sells well, whether it becomes:\n\n- part of your overall personal brand (*\"hey, she wrote the book on X, she must know what she's talking about even if I havent read the book\"*), \n- or your future course offerings (*\"i'll even throw in a free copy of X valued at $99!\"*)\n\nThen you cannot fail.\n\nGood luck and enjoy the ride! ","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/5-q-a-s-on-writing-and-selling-my-first-book-18d1","devToReactions":49,"devToReadingTime":8,"devToPublishedAt":"2020-08-10T23:24:57.944Z","devToViewsCount":496,"title":"5 Q&A's on Writing and Selling My First Book","published":true,"description":"I answered some questions from someone planning to write their first book","tags":"Reflections"},"title":"5 Q&A's on Writing and Selling My First Book","description":"I answered some questions from someone planning to write their first book ","category":"note","tags":["reflections"],"slug":"5-q-a-s-on-writing-and-selling-my-first-book-18d1","date":"2020-08-10T23:24:57.944Z","readingTime":"9 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/336","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/336/comments","title":"5 Q&A's on Writing and Selling My First Book","created_at":"2022-01-18T00:21:16Z","updated_at":"2022-06-18T17:47:19Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/336/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"title":"Coding Careers on the Junior to Senior Podcast","slug":"jr-to-sr-podcast","tags":["Careers"],"venues":"JrToSr","date":"2020-08-03T00:00:00.000Z","url":"https://juniortosenior.io/3","description":"I spoke with David Guttman, who does a lot of mentoring and runs the AMAZING JS.LA community, on the Coding Career Handbook.","category":"podcast"},{"type":"blog","content":"\r\nOne of the talks in my Lindy Library (from the [Lindy effect](https://en.wikipedia.org/wiki/Lindy_effect) which I discussed in [my book](https://learninpublic.org/)) is \"Growing a Language\", by Guy Steele:\r\n\r\n- [Youtube Link](https://www.youtube.com/watch?v=_ahvzDzKdB0)\r\n- [The full text of the talk with some diagrams is here](https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf)\r\n\r\nIf you care enough about programming languages (and every framework, every library has aspects of a language), you come to care intensely about programming language **design**. This is one of the few accessible, entertaining talks that tackles this head on.\r\n\r\nI'm watching it again in preparation for an upcoming talk so here are my public notes.\r\n\r\n## Core Points\r\n\r\n- You should design languages to start small and then grow.\r\n- You should design languages so that users help you grow them easily.\r\n- The solution to the Cathedral vs Bazaar is let everyone play but have a BDFL decide what to take in/out. Have a Shopping Mall of good ideas.\r\n- It is good for you and your users, to give them a chance to buy in and pitch in.\r\n- If you design a small number of useful patterns, you can say no to a lot more things that not everybody uses, while letting them define things they will use.\r\n- Generic Types and Operator Overloading are 2 such patterns that let users solve all sorts of problems.\r\n- Going meta: We should now think of a language design as a pattern for language designs, a tool for making more tools of the same kind.\r\n- Use simple words in real life too.\r\n\r\n## Raw Notes\r\n\r\n> ⚠️ Note - a lot of these are lifted verbatim from the transcript as I am just doing a first pass of notes right now.\r\n\r\n- A language that is too small is hard to use. You can't say much at all until you take the time to define at least a few new terms.\r\n- If you want to get far at all with a small language, you must first add to the small language to make a language that is more large.\r\n- **I need to design a language that can grow.** I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time. \r\n- We have known for some time that huge programs can not be coded from scratch all at once. There has to be a plan for growth. What we must think on now is the fact that languages have now reached that large size where they can not be designed all at once, much less built all at once.\r\n- At times we think of C as a small language designed from whole cloth. But it grew out of a smaller language called B, and has since grown to be a larger language called C plus plus. **A language as large as C plus plus could not have spread so wide if it had been foisted on the world all at once.**\r\n- [Worse is Better](https://en.wikipedia.org/wiki/Worse_is_better): The gist of it is that the best way to get a language used by many persons is not to design and build 'The Right Thing,' because that will take too long. In a race, a small language with warts will beat a well designed language because users will not wait for the right thing; they will use the language that is quick and cheap, and put up with the warts. Once a small language fills a niche, it is hard to take its place.\r\n- Languages must do a lot more things than they used to:\r\n\r\n > They need to paint bits, lines, and boxes on the screen in hues bright and wild; they need to talk to printers and servers through the net; they need to load code on the fly; they need their programs to work with other code they don’t trust; they need to run code in many threads and on many machines; they need to deal with text and sayings in all the world’s languages. A small programming language just won’t cut it.\r\n\r\n- So a small language can not do the job right and a large language takes too long to get off the ground. Are we doomed to use small languages with many warts because that is the sole kind of design that can make it in the world?\r\n- No. Start small, then grow.\r\n- If one person does all the work, then growth will be slow. But if one lets the users help do the work, growth can be quick. If many persons work side by side, and the best work is added with care and good taste, a great deal can be added in a short time.\r\n- Let the user define new words in a way that they look like primitives. In this way the user can build a larger language to meet his needs. (Hooks pass this test). \r\n- In APL, new words don't look like primitives. To add to APL, it takes a lot of work - this has stopped users from helping to grow the language. To adopt userland code into the language takes a total rewrite.\r\n- In Lisp, new words defined by the user look like primitives and, what is more, all primitives look like words defined by the user. In other words, if a user has good taste in defining new words, what comes out is a larger language that has no seams. The designer in charge can grow the language with close to no work on his part, just by choosing with care from the work of many users.\r\n- So Lisp grew much faster than APL did, because many users could try things out and put their best code out there for other users to use and to add to the language.\r\n- **A main goal in designing a language should be to plan for growth.** The language must start small, and the language must grow as the set of users grows.\r\n\r\n > I, as a language designer helping out with the Java programming language, need to ask not 'Should the Java programming language grow?' but 'How should the Java programming language grow?'\r\n\r\n- if the goal is to be quick and yet to do good work, one mode may be better by far than all other modes.\r\n- There are two kinds of growth in a language. One can change the vocabulary, or one can change the rules that say what a string of words means.\r\n- A library is a vocabulary designed to be added to a programming language to make its vocabulary larger. A true library does not change the rules of meaning for the language; it just adds new words. The key point is that the new words defined by a library should look just like the primitives of the language.\r\n- It may be good as well to have a way to add to the rules of meaning for a language.\r\n\r\n### Cathedral vs Bazaar \r\n\r\n- There are 2 ways to do the growing - One person-or a small group-to be in charge and to take in, test, judge, and add the work done by other persons. The other way is to just put all the source code out there, once things start to work, and let each person do as he wills. To have a person in charge can slow things down, but to have no one in charge makes it harder to add up the work of many persons.\r\n- The way that I think is faster and better than all others does both. Put the source code out there and let all persons play with it. Have a person in charge who is a quick judge of good work and who will take it in and shove it back out fast. You don’t have to use what he ships, and you don’t have to give back your work, but he gives all persons a fast way to spread new code to those who want it.\r\n- As for the role of programmer in charge, Eric Raymond says that it is fine to come up with good thoughts, but much better to know them when you see them in the works of other persons.\r\n- The key point is that in the bazaar style of building a program or designing a language or what you will, the plan can change in real time to meet the needs of those who are working on it.\r\n- This tends to make users stay with it as time goes by; they will take joy in working hard and helping out if they know that their wants and needs have some weight and their hard work can change the plan for the better.\r\n\r\n### HIGH POINT OF THE TALK: The Importance of Patterns\r\n\r\n- Christopher Alexander says: Master plans have two additional unhealthy characteristics. To begin with, the existence of a master plan alienates the users. After all, the very existence of a master plan means, by definition, that the members of the community can have little impact on the future shape of their community, because most of the important decisions have already been made. In a sense, under a master plan people are living with a frozen future, able to affect only relatively trivial details. When people lose the sense of responsibility for the environment they live in, and realize that they are merely cogs in someone else’s machine, how can they feel any sense of identification with the community, or any sense of purpose there?\r\n- Does this mean, then, that it is of no use to design? Not at all. But in stead of designing a thing, you need to design a way of doing.\r\n- A pattern is a plan that has some number of parts and shows you how each part turns a face to the other parts, how each joins with the others or stands off, how each part does what it does and how the other parts aid it or drag it down, and how all the parts may be grasped as a whole and made to serve as one thing, for some higher goal or as part of a larger pattern. A pattern should give hints or clues as to when and where it is best put to use. What is more, some of the parts of a pattern may be holes, or slots, in which other things may be placed later.\r\n- A generic type is a map from one or more types to types. Put another way, a generic type is a pattern for building types.\r\n- A word is said to be overloaded if it is made to mean two or more things and the hearer has to choose the meaning based on the rest of what is said. For example, using the rules defined near the start of this talk, a verb form such as 'painted' might be a past tense or a past participle, and it is up to you, the hearer, to make the call as to which I mean when I say it. Just as a user can code methods in just the same way as methods that are built in, the user ought to have a way to define operators for user defined classes that can be used in just the same way as operators that are built in.\r\n- If we grow the language in these few ways, then I think we will not need to grow it in a hundred other ways; the users can take on the rest of the task. (Examples with number types - cannot add all of them at once even tho each individually may have a good usecase)\r\n- Some parts of the programming vocabulary are fit for all programmers to use, but other parts are just for their own niches. It would not be fair to weigh down all programmers with the need to have or to learn all the words for every niche used.\r\n- We should not make the Java programming language a cathedral, but a plain bazaar might be too loose. What we need is more like a shopping mall, where there are not quite as many choices but most of the goods are well designed and sellers stand up and back what they sell.\r\n- When a language gives you the right tools, such classes can be coded by a few and then put up as libraries for other users to use, or not, as they choose; but they don’t have to be built in as part of the base language. If you give a person a fish, he can eat for a day. If you teach a person to fish, he can eat his whole life long. If you give a person tools, he can make a fishing pole—and lots of other tools! In this way he can help other persons to catch fish.\r\n\r\n### Going Meta\r\n\r\n- Meta means that you step back from your own place. What you used to do is now what you see. What you were is now what you act on. Verbs turn to nouns. What you used to think of as a pattern is now treated as a thing to put in the slot of an other pattern.\r\n- We should now think of a language design as a pattern for language designs, a tool for making more tools of the same kind. A language design can no longer be a thing. It must be a pattern—a pattern for growth—a pattern for growing the pattern for defining the patterns that programmers can use for their real work and their main goal.\r\n- In the course of giving this talk, because I started with a small language, I have had to define fifty or more new words or phrases and sixteen names of persons or things; and I laid out six rules for making new words from old ones.\r\n- It should give no one pause to note that the writing of a program a million lines of code in length might need many, many hundreds of new words—that is to say, a new language built up on the base language.\r\n- Language design is not at all the same kind of work it was thirty years ago, or twenty years ago. Back then, you could set out to design a whole language and then build it by your own self, or with a small team, because it was small and because what you would then do with it was small. Now programs are big messes with many needs. A small language won’t do the job.\r\n- It would be great if there were some small programming language that felt large, the way Basic English is small but feels large in some ways. But I don’t know how to do it and I have good cause to doubt that it can be done at all. \r\n- So I think the sole way to win is to plan for growth.\r\n- Parts of the language must be designed to help the task of growth- of growing the language.\r\n\r\n### Plan for Warts\r\n\r\n- You may find that you need to add warts as part of the design, so that you can get it out the door fast, with the goal of taking out the warts at a later time.\r\n- With care, one can design a wart so that it will not be too hard to take out or patch up later on.\r\n- Some warts are not bad things you put in, but good things you leave out. Have a plan to add those good things at a later time, if you should choose to do so, and make sure that other parts of your design don’t cut you off from adding those good things when the time is right.\r\n\r\n### Natural Languages\r\n\r\n- If we add hundreds of new things to the Java brand programming language, we will have a huge language, but it will take a long time to get there. But if we add a few things— just the right things- generic types, operator overloading, user defined types of light weight, for use as numbers and small vectors and such— and some other things- that are designed to let users make and add things for their own use, I think we can go a long way, and much faster. We need to put tools for language growth in the hands of the users.\r\n- I hope that we can, in this way or some other way, design a programming language where we don’t seem to spend most of our time talking and writing in words of just one syllable.\r\n- (In designing this talk) there was this choice for each new word: is it worth the work to define it, or should I just stick with the words I have?\r\n- I learned in my youth, from the books of such great teachers of writing as Strunk and White, that it is better to choose short words when I can. I should not choose long, hard words just to make other persons think that I know a lot. I should try to make my thoughts clear; if they are clear and right, then other persons can judge my work as it ought to be judged.\r\n- Short words work well, if we choose them well. \r\n- All in all, I think it might be a good thing if those who rule our lives—those in high places who do the work of state, those who judge what we do, and most of all those who make the laws—were made to define their terms and to say all else that they say in words of one syllable. For I have found that this mode of speech makes it hard to hedge. It takes work, and great care, and some skill, to find just the right way to say what you want to say, but in the end you seem to have no choice but to talk straight. If you do not veer wide of the truth, you are forced to hit it dead on.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/notes-on-growing-a-language-by-guy-steele-5501","devToReactions":13,"devToReadingTime":12,"devToPublishedAt":"2020-07-28T20:50:13.238Z","devToViewsCount":520,"title":"Notes on \"Growing a Language\"","published":true,"description":"Revisiting one of my favorite talks ever, on designing programming languages for user extensibility and collaboration","canonical_url":"https://www.swyx.io/notes-on-growing-a-language-by-guy-steele-5501/","cover_image":"http://i3.ytimg.com/vi/_ahvzDzKdB0/hqdefault.jpg","tags":"Reflections"},"title":"Notes on \"Growing a Language\"","description":"Revisiting one of my favorite talks ever, on designing programming languages for user extensibility and collaboration ","category":"note","tags":["reflections"],"image":"http://i3.ytimg.com/vi/_ahvzDzKdB0/hqdefault.jpg","canonical":"https://www.swyx.io/notes-on-growing-a-language-by-guy-steele-5501/","slug":"notes-on-growing-a-language-by-guy-steele-5501","date":"2020-07-28T20:50:13.238Z","readingTime":"14 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/337","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/337/comments","title":"Notes on \"Growing a Language\"","created_at":"2022-01-18T00:21:19Z","updated_at":"2024-03-13T16:06:01Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/337/reactions","total_count":1,"+1":0,"-1":0,"laugh":0,"hooray":1,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nI first encountered MongoDB as part of the FreeCodeCamp curriculum, then as part of the MeteorJS stack, finally attending a talk at my bootcamp given by it's lead developer, Val Karpov (who, by the way, also coined [the MEAN stack](https://www.mongodb.com/blog/post/the-mean-stack-mongodb-expressjs-angularjs-and)!). \r\n\r\nMost resources, including my bootcamp, kind of treat Mongoose as a thin interface to MongoDB, which is a shame given how powerful it really is and how central your mastery of your database stack can be for an app's speed and scale. So it was of course exciting to hear that Val has finally written the definitive guide on Mongoose: [Mastering Mongoose](https://masteringjs.io/ebooks/mastering-mongoose)!\r\n\r\nI'm going to jot down 4 things I learned. **Note** - I haven't used Mongoose in about 3 years, so this is mostly very introductory level.\r\n\r\n## 1. Change Tracking for Minimal Updates\r\n\r\nWhen you load a document from the database using a query and then modify it after, change tracking means Mongoose can determine the minimal update to send to MongoDB and avoid wasting network bandwidth.\r\n\r\n```js\r\n// Mongoose loads the document from MongoDB and then _hydrates_ it\r\n// into a full Mongoose document.\r\nconst doc = await MyModel.findOne();\r\ndoc.name; // \"Jean Valjean\"\r\ndoc.name = 'Monsieur Leblanc';\r\ndoc.modifiedPaths(); // ['name']\r\n// `save()` only sends updated paths to MongoDB. Mongoose doesn't\r\n// send `age`.\r\nawait doc.save();\r\n```\r\n\r\nThis is very nice out of the box for performance and I don't have to do a thing!\r\n\r\n## 2. Multiple Connections\r\n\r\nMost apps only need one connection to MongoDB. However, Mongoose supports multiple connections:\r\n\r\n```js\r\nconst mongoose = require('mongoose');\r\nconst conn1 = mongoose.createConnection('mongodb://localhost:27017/db1',\r\n { useNewUrlParser: true });\r\nconst conn2 = mongoose.createConnection('mongodb://localhost:27017/db2',\r\n { useNewUrlParser: true });\r\n// Will store data in the 'db1' database's 'tests' collection\r\nconst Model1 = conn1.model('Test', mongoose.Schema({ name: String }));\r\n// Will store data in the 'db2' database's 'tests' collection\r\nconst Model2 = conn2.model('Test', mongoose.Schema({ name: String }));\r\n```\r\n\r\nThis is helpful when:\r\n\r\n- Your app needs to access data stored in multiple databases\r\n- Your app has some slow operations and you don't want them to cause performance issues on fast queries. A MongoDB server can only execute a single operation on a given socket at a\r\ntime, and the number of concurrent operations is limited by the `poolSize` of sockets. So to deal with slow connections, you can increase `poolSize` past the default of 5 - however, too many connections can hit OS-level performance issues and limits! Val uses `poolSize = 10` for his production apps. Beyond that, you can't add more sockets. So it's better to just put slow operations on a separate connection.\r\n\r\n## 3. Mongoose uses its own Middleware\r\n\r\nIn Mongoose, middleware lets you attach your own custom logic to built-in Mongoose functions. You can run `pre` and `post` any function:\r\n\r\n- Document Middleware\r\n - `validate()`\r\n - `save()`\r\n - `remove()`\r\n - `updateOne()`\r\n - `deleteOne()`\r\n- Model Middleware\r\n - `insertMany()`\r\n- Aggregation Middleware\r\n - `aggregate()` - you can do fancy stuff here with modifying the [aggregation pipeline](https://docs.mongodb.com/manual/core/aggregation-pipeline/)\r\n- Query Middleware\r\n - `find()`\r\n - `count()`\r\n - `countDocuments()`\r\n - `deleteOne()`\r\n - `deleteMany()`\r\n - `distinct()`\r\n - `estimatedDocumentCount()`\r\n - `find()`\r\n - `findOne()`\r\n - `findOneAndDelete()`\r\n - `findOneAndRemove()`\r\n - `findOneAndReplace()`\r\n - `findOneAndUpdate()`\r\n - `remove()`\r\n - `replaceOne()`\r\n - `update()`\r\n - `updateMany()`\r\n - `updateOne()`\r\n\r\nThis is a powerful pluggable system that reminds me of similar things in the [npm scripts](https://docs.npmjs.com/misc/scripts) and [Netlify Build](https://github.com/netlify/build) system. \r\n\r\nMongoose uses its own system internally - Mongoose attaches a `pre('save')` middleware to all models that calls\r\n`validate()`. That means `save()` triggers `validate()` middleware, which is why `save()` works the way it does.\r\n\r\n\r\n## 4. Principle of Least Cardinality\r\n\r\nWith relational databases it is best to normalise data per schema. The third normal form is something like:\r\n\r\n> \"Every non-key must provide a fact about the key, the whole key, and nothing but the key.\"\r\n\r\nYou can do this in Mongoose with `populate()`, but that goes against the grain of how NoSQL schemas should be setup. The common recommendation is to `denormalize` - a document should store all the properties you want to query by (\"The Princple of Denormalization\"), and, data that is referenced together, belongs together (\"The Principle of Data Locality\"). However, taken literally, this can lead to monster documents that can take forever to load.\r\n\r\nThe Principle of Least Cardinality states:\r\n\r\n> Store relationships in a way that minimizes the size of individual documents.\r\n\r\nThis helps make the correct tradeoff as far as Val is concerned. The other very good reason to do this is the fact that MongoDB limits documents to 16MB in size, of course - but primarily, the Principle of Least Cardinality is about conserving bandwidth when loading documents.\r\n\r\n## Conclusion\r\n\r\nThe book offers 4 sample apps built with Websockets, React, and Vue, and even ends with a great discussion about recommended app structure at the directory and app level! These polishing touches and the accessible and well thought through examples on every page make this a great reference point for anyone using Mongoose.js.","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/4-things-i-learned-from-mastering-mongoose-js-25e","devToReactions":68,"devToReadingTime":4,"devToPublishedAt":"2020-07-26T09:53:19.203Z","devToViewsCount":1720,"title":"4 Things I Learned from Mastering Mongoose.js","published":true,"description":"A quick book review of the new Mongoose.js book from Val Karpov","category":"note","tags":"Reflections, Review, JavaScript, MongoDB","cover_image":"https://mastering-mongoose.netlify.app/images/mastering-mongoose.jpg"},"title":"4 Things I Learned from Mastering Mongoose.js","description":"A quick book review of the new Mongoose.js book from Val Karpov ","category":"note","tags":["reflections","review","javascript","mongodb"],"image":"https://mastering-mongoose.netlify.app/images/mastering-mongoose.jpg","slug":"4-things-i-learned-from-mastering-mongoose-js-25e","date":"2020-07-26T09:53:19.203Z","readingTime":"4 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/338","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/338/comments","title":"4 Things I Learned from Mastering Mongoose.js","created_at":"2022-01-18T00:21:20Z","updated_at":"2022-06-18T17:45:01Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/338/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\nI submitted [my book's landing page](https://learninpublic.org/) for [Rob Hope's review](https://twitter.com/swyx/status/1284487504670806018) and he obliged! Brutal feedback incoming. I respect Rob's opinion mainly because this is [literally his thing](http://onepagelove.com/) and he is writing THE BOOK on this (if you do get it, [my affiliate link is here](https://gumroad.com/l/hottips?offer_code=swyx)!) .\n\n[As a first time maker](https://www.swyx.io/writing/launching-coding-career) I have a lot to learn, so I expect that there will be a lot of issues. Rob gave me a 5 min review which was just PACKED with insight and I am excited to internalize this and improve.\n\n## 1. Erroring Checkout\n\nIf you try to buy on the page in Incognito mode, it errors because Podia (the backend I use)'s widget uses cookies, and cross-site cookies are blocked by default in Chrome.\n\n![image](https://user-images.githubusercontent.com/6764957/88324929-fcc6f400-cd56-11ea-948e-a855205cbdf3.png)\n\nThe only way to fix this is to move off Podia, which I'm not very keen on, or to drop the Podia widget altogether and just directly link to the Podia sales page (slightly worse experience for the majority of visitors, in exchange for better experience for the small percentage that uses Incognito). \n\n## 2. Communicating Launch Sale\n\n![image](https://user-images.githubusercontent.com/6764957/88325284-7a8aff80-cd57-11ea-8cbc-3858a84ef5f4.png)\n\nI launched on Jul 1 and ended launch sales on Jul 14. After some people DMed me saying they missed the launch sale, I held out for a while and eventually relented by extending it to Aug 1. I didn't spend a lot of time on this but basically the objection is that the high number of hours hurts my credibility. \n\nI definitely don't intend to do a permasale as that is unethical, however, I do want to figure out the best price that the market pays for my book while still having most customers feel like they got value for money (I care about total revenue more than I care about per-unit prices - I tried to market like an upmarket brand that deserves a premium for a while, but unfortunately I don't think I know how to do that well).\n\nRecommmendation: go with days instead of long countdown timer.\n\n## 3. Duck Branding\n\nUse it more! everyone likes it!\n\nHis recommendations:\n\n- put duck near book reviews\n- and at footer\n- cheeky angle\n\nAdds personality!\n\n![image](https://user-images.githubusercontent.com/6764957/88326452-a35fc480-cd58-11ea-89e6-cc9f819fd269.png)\n\nMore Yellow Page inspo on his site: https://onepagelove.com/tag/yellow-color\n\n## 4. Hero Section \n\nBook Cover Too Small. Squinting to read the subtitle. Make it bigger.\n\n\"The Missing Manual\" text is more appealing than \"Build an Exceptional Career\".\n\nMove Login to top of the page, See Sample instead -> don't put you on Newsletter at all - send sample with friendly email.\n\nRemove Product Hunt widget.\n\nMake entire Hero section yellow?\n\nAdd 1 testimonial here.\n\n![image](https://user-images.githubusercontent.com/6764957/88344541-63a7d580-cd76-11ea-8125-bed042417511.png)\n\n\n\n## 5. What's in the book? section\n\nText hierarchy is \"out\" - headers should be darker than body text, I have the inverse when it comes to my bolded text.\n\nMake sample chapter links into buttons, more \"actionable\".\n\n![image](https://user-images.githubusercontent.com/6764957/88343291-ab792d80-cd73-11ea-802d-9614503a88a0.png)\n\n## 6. Book Reviews \n\nToo many!\n\nNeed to be more specific. Address doubts and features. 4-6 slam dunk ones.\n\nBring 1 testimonial up under the Hero section.\n\n![image](https://user-images.githubusercontent.com/6764957/88343759-b2547000-cd74-11ea-824d-d1b2367f00a3.png)\n\n## 7. Pricing section\n\ncreate left-to-right flow\n\n![image](https://user-images.githubusercontent.com/6764957/88343891-02333700-cd75-11ea-94b0-18745249587b.png)\n\n\n## 8. About the Author\n\nSAY WHY YOU WROTE THE BOOK\n\n![image](https://user-images.githubusercontent.com/6764957/88343990-3c9cd400-cd75-11ea-829b-286563e51448.png)\n\n---\n\nlots to chew on, as you can see! I figured I would transcribe the lessons here so I can save them for my future self. I'll be working on making recommended changes as I go. You're welcome to give more critiques of my page too!\n\n\nIf you enjoyed this you should probably buy his book prelaunch like I already have - [my affiliate link here](https://gumroad.com/a/942240883). :)","frontmatter":{"source":"devto","devToUrl":"https://dev.to/swyx/8-landing-page-tips-from-rob-hope-338l","devToReactions":46,"devToReadingTime":3,"devToPublishedAt":"2020-07-23T22:19:19.084Z","devToViewsCount":1130,"title":"8 Landing Page Tips from Rob Hope","published":true,"description":"I submitted my book's landing page for Rob Hope's review and he obliged! Brutal feedback incoming.","tags":"Reflections","cover_image":"https://user-images.githubusercontent.com/6764957/88344541-63a7d580-cd76-11ea-8125-bed042417511.png"},"title":"8 Landing Page Tips from Rob Hope","description":"I submitted my book's landing page for Rob Hope's review and he obliged! Brutal feedback incoming. ","category":"note","tags":["reflections"],"image":"https://user-images.githubusercontent.com/6764957/88344541-63a7d580-cd76-11ea-8125-bed042417511.png","slug":"8-landing-page-tips-from-rob-hope-338l","date":"2020-07-23T22:19:19.084Z","readingTime":"3 minutes","ghMetadata":{"issueUrl":"https://github.com/swyxio/swyxdotio/issues/340","commentsUrl":"https://api.github.com/repos/swyxio/swyxdotio/issues/340/comments","title":"8 Landing Page Tips from Rob Hope","created_at":"2022-01-18T00:21:24Z","updated_at":"2022-06-18T17:47:20Z","reactions":{"url":"https://api.github.com/repos/swyxio/swyxdotio/issues/340/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\nThis week I did a Q&A for Fullstack Academy's (FSA) [Bootcamp Prep](https://www.fullstackacademy.com/bootcamp-prep) students - copying out my answers here! This was [the bootcamp I went through 3 years ago](https://medium.com/hackernoon/no-zero-days-my-path-from-code-newbie-to-full-stack-developer-in-12-months-214122a8948f) so I'm always happy to give some time back to people going through the same career change I did.\r\n\r\n\r\n## Table of Contents\r\n\r\n- [What made you want to start writing a book about coding careers?](#what-made-you-want-to-start-writing-a-book-about-coding-careers)\r\n- [What is something you wish you knew during the bootcamp and right after graduation (while looking for a first job)?](#what-is-something-you-wish-you-knew-during-the-bootcamp-and-right-after-graduation-while-looking-for-a-first-job)\r\n- [Are there any podcasts/coding talks that you recommend listening to for beginners?](#are-there-any-podcastscoding-talks-that-you-recommend-listening-to-for-beginners)\r\n- [What was your (career) background before joining FSA? what made you choose FSA?](#what-was-your-career-background-before-joining-fsa-what-made-you-choose-fsa)\r\n- [In addition to the coursework at FSA, did you have to learn anything else (programming language, framework etc) to secure your first job at a programmer?](#in-addition-to-the-coursework-at-fsa--did-you-have-to-learn-anything-else--programming-language--framework-etc--to-secure-your-first-job-at-a-programmer)\r\n- [I understand you graduated from FSA in 2017? In last 3 years with increase in bootcamps and bootcamp grads, do you think industry's outlook towards bootcamps have changed?](#i-understand-you-graduated-from-fsa-in-2017-in-last-3-years-with-increase-in-bootcamps-and-bootcamp-grads-do-you-think-industrys-outlook-towards-bootcamps-have-changed)\r\n- [I was wondering what drew you in to apply for a job at AWS, what certs did you get and/or study tools did you use before applying, and how was the interview process?](#i-was-wondering-what-drew-you-in-to-apply-for-a-job-at-aws-what-certs-did-you-get-andor-study-tools-did-you-use-before-applying-and-how-was-the-interview-process)\r\n- [I really do want to work remotely, do you have any insights / recommendations for that route ?](#i-really-do-want-to-work-remotely-do-you-have-any-insights-recommendations-for-that-route-)\r\n\r\n---\r\n\r\n## Q&A\r\n\r\n### What made you want to start writing [a book about coding careers](https://learninpublic.org/)?\r\n\r\nIt was a couple of factors - i had 2 months off between jobs before i was going to join AWS, and then my most successful writing to date had been a career advice essay, so I went where my readers pointed me to go!\r\n\r\n---\r\n\r\n### What is something you wish you knew during the bootcamp and right after graduation (while looking for a first job)?\r\n\r\n- take it easy on algorithms, even Google doesnt have time to test you on writing heap sorts in their technical interview. Most of Cracking the Coding Career is not tested (at least at our level)\r\n- social pressure is helpful when jobhunting - there is a huge “Cliff” after graudation when people tend to slack off and veg out and dont know how to get into the grind of the job search. organize weekly standups with friends and report what you did and what you will do.\r\n- read technical books like YDKJS and go thru workshops like frontendmasters/eggheadio. solidify your fundamentals, there was a lot of rushing during the bootcamp\r\n- more: https://github.com/sw-yx/ama/issues/1\r\n\r\n---\r\n\r\n### Are there any podcasts/coding talks that you recommend listening to for beginners?\r\n\r\nYes: https://www.swyx.io/writing/fave-podcasts/#tech-webdevjs\r\n\r\nIn particular, check out the BaseCS and CodeNewbie podcasts - just go thru the back catalog! lots of good stuff! for career transition stories i liked the Freecodecamp and Breaking Into Startups podcasts as well.\r\n\r\n---\r\n\r\n### What was your (career) background before joining FSA? what made you choose FSA?\r\n\r\nI was in finance before FSA. I chose FSA by applying to a bunch of bootcamps (flatiron, hackreactor, GA) and picking the one with the hardest entrance exam. theory is, if the exam is hard, everyone i study with will also be high quality. also i think “exam” is the wrong word. more like a short technical interview.\r\n\r\n---\r\n\r\n### In addition to the coursework at FSA, did you have to learn anything else (programming language, framework etc) to secure your first job at a programmer?\r\n\r\nNo. plain and simple. i only needed to know html/js/css. i got my job from the very first person i sat down with at FSA’s hiring day. probably got lucky lol\r\n\r\n---\r\n\r\n### I understand you graduated from FSA in 2017? In last 3 years with increase in bootcamps and bootcamp grads, do you think industry's outlook towards bootcamps have changed?\r\n\r\nNo the industry’s outlook hasnt changed. if anything, its better, bc many bootcamp grads are sr devs now. i would say that the covid recession has made the post bootcamp job search a bit harder. but i still see jr devs getting first jobs all the time so its not 0.\r\n\r\n---\r\n\r\n### I was wondering what drew you in to apply for a job at AWS, what certs did you get and/or study tools did you use before applying, and how was the interview process?\r\n\r\nI applied for AWS because i knew my now-manager for 2 years and i wanted to experience the BigCo life. I didn’t get any certs, at all. interview process was mostly alright, except the final onsite day! a lot of tough questions. if you get there i’ll be happy to coach you thru it!\r\n\r\nfor more on my AWS story https://www.swyx.io/writing/hello-aws/#personal-note\r\n\r\n---\r\n\r\n### I really do want to work remotely, do you have any insights / recommendations for that route ?\r\n\r\nYes - contribute to open source, write a lot. when you work remotely, people have to trust that you can be self motivated (more than the average in-office worker) and that you can communicate very well (since you have to replace hallway/watercooler/casual meeting chats with slack/github/internal memos)\r\n\r\nIn particular contributing to open source demonstrates ability to take issues, clarify requirements, and execute independently, in a code setting.\r\n\r\nWhen you apply for these kinds of jobs with proof that you can already work well under a simulated “remote” setting then its much easier to say yes!\r\n\r\nas an example - this is something i just did for work, today https://github.com/aws-amplify/amplif</article></body></html>

Idea Showcase