The Dev-X Project is a series of features with industry leaders sharing their developer experience insights. In each âepisodeâ, we ask 10 questions about DX, collect some valuable insights, and share them with you.
In this episode, weâre featuring Shawn âswyxâ Wang. Swyx has worked on React and serverless JavaScript at Two Sigma, Netlify and AWS, and most recently as Head of Developer Experience at Temporal.io and Airbyte. He has started and run communities for hundreds of thousands of developers, like Svelte Society, /r/reactjs, and the React TypeScript Cheatsheet. His nontechnical writing was recently published in the Coding Career Handbook for Junior to Senior developers. He recently launched DX Tips, a newsletter focusing on Developer Tools, Developer Relations, and all things Developer Experience.
Yï»żou can follow swyx on Twitter, GitHub and YouTube
TL;DR Highlights:
- Wï»żhy swyx doesnât like the term âself-taughtâ
- Tï»żips for a great engineering culture
- Sï»żwyxâs ideal stack
- Aï»żn epic fail heâs seen, and what we can learn from it
- Tï»żhe difference between internal and external developer experience, and how to improve both
- Wï»żhy swyx is a fan of monorepos
- Tï»żhe risks and opportunities facing FE devs
- Hï»żow remote dev teams can work better together
When did you decide to become a developer?
I made the decision when I saw that software is eating the world. I was 30 years old and I was a public markets, hedge fund trader. saw that there were a lot of tech companies that were choosing to remain private and the only IPO when they were done growing essentially. So I realized that if I wanted to learn how to create value and continue to make money, I would probably have more fun and make more money in startups. So I decided to learn to code.
I did a bootcamp, and then I did, 6 months of online learning. I donât like the expression âself-taughtâ though, because that diminishes the work of all the people who tried to teach you for free.
What are the key ingredients to a really good engineering culture?
The first thing that comes to mind is #9 on Amazonâs list of 16 leadership principles - âa bias for actionâ.
I feel like thatâs important in this context, because a lot of things donât get done if you donât take proactive ownership over them. So this is really important for a healthy, engineering culture.
 A good documentation or design doc culture is pretty important as well. In other words, before you implement something, you should obviously try to design it and think through the propositions and agree on the high-level stuff with everybody. But a good culture takes this one step further. It means that everybody actually reads the doc when they receive it. And thatâs quite rare. So a good documentation culture means good writing and also good reading so you catch design issues and mismatched expectations sooner rather than later.Â
Finally, when you ship stuff and youâre maintaining things in production, remember that things will always break. So having a blameless post-mortem culture is important too.
Letâs say youâre building something from scratch. What does your ideal stack look like?
It depends on what Iâm building. For most things, I would probably go with some kind of backend as a service. Right now my favorite is Supabase which is an open source version of Firebase from Google, and then you know, front-end stack, Iâll probably choose either react or Svelte. depending on the kind of app Iâm building. If itâs more webby than Svelte, if itâs more mobile cross-platform then React. , And then if I need to take over my own, infrastructure, I might explore other things CDK or Pulumi. I also started to really dive into data pipelines because I feel like that is a form of comparative advantage.
So right now the paradigm that makes the most sense to me is either Apache Airflow or Dexter as a general orchestration layer to do, pipeline work, to kick off jobs and modify databases. I donât even need a data warehouse, especially for smaller projects, but I still need a pipeline. And if I need the operational equivalent of a pipeline, then Iâd use Temporal because I worked there.
Tell us about an epic engineering fail youâve experienced in your career. What did you learn from it?
Hereâs a fail that wasnât mine, but it was a team next to me that I felt like could have done things better.Â
Whenever we rolled out a version of Temporal, we ran a very extensive series of tests. Some of them taking two days to finish. So we thought that we had a really good understanding of how to test these things. Now, the whole premise of offering a managed service to our customers is that we auto-upgrade the service for them, and they donât need to know. And because we test each release so extensively, we had a lot of confidence in our tests. So in one instance, we roll out our tests. Then we roll out a new version, and then things start breaking in production because essentially there was a bug that only showed up at real scale. Meaning our customersâ scale, not our test scale.Â
In this case, it was a deadlock. Meaning that no progress can be made no matter how many resources you throw at it. Ultimately, it resulted in one of our customers having an outage for eight hours and eventually leaving us. And because we didnât give them any advanced warning, it felt like there was a mismatch of control there.Â
Ultimately, what we could have done better was communicate to our customers that we are doing a managed upgrade. We could have picked a time when itâs not the middle of the day at a time when theyâre doing their most traffic. We could have done a weekend upgrade to try and minimize the blast radius and we could have done some kind of rolling upgrade instead of trying to upgrade the whole thing at once. That may have allowed us to test more extensively, but thatâs easier said than done since youâre really always testing only the last thing that went wrong. So thereâs only so much you can do there.
How important is âDeveloper Experienceâ? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
I make a distinction between internal DevX and external DevX. Internal DevX is improving the developer productivity of engineers within your company. And external developer experience is promoting your tools to engineers at other companies, and eventually, improving their productivity as well.Â
Both of them require deep empathy with the customer. (I actually have a, have a longer explanation of this on the infraeng.dev site - feel free to check it out)
Internal developer experience for developer productivity is simple math. If you think that there is room to improve your developer productivity by one percent every quarter, and you have a team of 50 engineers, then it actually makes mathematical sense to hire, at least one or two, engineers whose job is not to work on the product, but just to make everyone else more productive.
The simplest mental model that I found comes from the Netflix developer productivity team. They have 3 stages: âzero to devâ, âdev to prodâ, and then âprod to devâ.
Zero to dev is, scaffolding and onboarding and creating new environments. Dev to prod is CI/CD, which is Spinnaker. And then Prod to dev is telemetry or observability, and that is Atlas. Thatâs one version. Another version would be the Accelerate metrics from Nicole Forsgren. There are specific metrics behind a rollout and specific ways you can measure and improve them. From there, you can try to figure out which part of the process is lacking right now? And once you figure that part of it out, you can work on those pieces and try to improve them.Â
I think that these are solid approaches to improve internal developer productivity, on the monetary side of things.
On the qualitative side of things, you unlock different kinds of development when people can play with their tools. When the feedback loop goes from one hour to one minute or two seconds, you change the nature of the tool of your operations, right? Instead of checking something in, and then waiting for a compilation, if you can hot reload, or if you can see the impact of your changes right away, then you start playing and discovering new things that you might not know about. This is a very well-known concept exemplified by Bret Victor in his talk: âInventing on principleâ where he explained that direct manipulation unlocks a different mode of interaction with your software.
And finally, a lot of people quit jobs for tech stack reasons. They realize: âI donât totally like my companyâs tech stack, and this other company seems to be more of the stuff that I would much rather deal withâ. So from a developer experience perspective, you want to keep your engineers happy so that they donât leave.
And in terms of external developer experience, itâs important to keep in mind that developers donât like to be marketed to by regular marketing people. Regular marketing people are usually terrible at marketing developers because they follow all the typical marketing advice: talk about benefits, not features, you always want the Fire Mario, not the Fire Flower. These approaches to marketing donât apply for developers because we deal in building blocks. So, you have to get developers to talk to fellow developers in terms that they know, cut the marketing BS, and try to explain how things work. We (developers) donât trust magic boxes. Our mindset is - âeverything youâre telling me sounds amazing. So whatâs the catch?â. We need somebody to be honest about the catch.
Letâs take the mono-repo question once and for all - should you âgo monoâ?
Yes. Iâve been converted to mono. I think it takes some training and in my opinion, GitHub is not the best code hosting environment for monorepos. So if you can invest in the tooling that you need - everything from CI/CDÂ to project tracking, to code source searching and all that - then monorepos are better. There used to be a minimum size that you needed to be as a company or as a code base to justify a monorepo. But that âminimum sizeâ has been going down and will continue to go down. Could it go down to as much as one person? Could you feel more productive if you had a monorepo? I think that that is slowly emerging to be the case. Itâs definitely not mainstream yet but the massive trend over the past ten years has been towards smaller and smaller teams benefiting from monorepos. So Iâd much rather be ahead of the curve now.
I wrote a whole blog post on this, so anyone interested in reading more is welcome to check it out.Â
What will be the hottest dev trend/adopted technology in the next 12-24 months?
Aside from monorepos, Iâve talked a lot about the end of localhost. The movement towards cloud development is accelerating. I think that more and more people are embracing the data industry like data pipelines, data replication and analytics and all that jazz. So I think that will become more of a thing.
Something else that comes to mind isnât a near-term trend, but a developing thing, and that is the shifting contract between frontend and backend. Meaning, you either want a smart client or a smart server, and the standard rest server contract is constantly being shift shifted. I really like that because it improves performance and it also improves user experience.Â
The problem is that we havenât really worked out the exact code patterns that are going to become industry standard yet. So weâll wait and see, but eventually, I think that something will emerge that displaces the current, disconnected client-sever model.
Some claim that front-end developers will become irrelevant in the future of no-code tools. Do you see this happening? If so, how soon?
No. I donât think they will become irrelevant. It is possible that no code tools will take up a lot of incremental growth that used to be occupied by having to learn how to code. But I think that is okay. The worldâs demand for software and websites is far greater than our ability to supply them manually. As frontend developers, we should be happy about that because that means weâre not converting Photoshop PSD to HTML or something like that.Â
But frontend developers will never become irrelevant because there will always be demand for custom code and apps, and then we get to work on the interesting UI paradigms rather than the boring commoditized stuff.Â
One risk that I will mention, is that I think frontend developers are constantly stuck in framework wars for which they do not get paid. Theyâre really, theyâre wasting a lot of their time on API design debates that are very, very minor. These donât really move the needle in terms of business, and so frontend devs are wasting their time debating stuff that doesnât really change, compared to backend developers and database developers who are making fabulous amounts of money doing anything else.
Share some tips to help remote teams collaborate better.
Something we do in my company is to meet in person once a quarter. Itâs frequent enough to get the general non-verbal vibes from others on the team. Something like 80 percent of our communication is non verbal so itâs really important to have an opportunity to experience that. Once youâve worked with people for a while you get to the point where you donât have to see each other every week, because then you start to get on each otherâs nerves (which Iâve done). So one week a quarter in person is a good balance. You can take the money that you would spend on an office and fly people out to fun locations and make them have a good time with each other for a week, and then not have to see each other again for a few months.Â
Other things I would suggest are making sure you have a good, writing and reading culture. Ans also make sure to set the expectation that remote work is a trade-off between flexibility on the one hand and lower bandwidth on the other. With remote work, you have to serialize all your thoughts into some slack messages. Some of it will be lost. Some of it will be misinterpreted. Some of it will be ignored because everyone just has too many Slack messages. So a successful distributed team would have an intentional contract for when something gets missed - how do we pick up on that? How do we hold each other accountable in a healthy way? In my company, itâs a weekly roundup every Friday, and then for all of my one on ones with my direct reports and my boss, we have a running sheet of all the commitments that we have, and we check in on each other, throughout the week. So I think this accountability and communication are key to success here.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
Iâm publishing a lot of my developer experience thoughts on dx.tips. So check it out if youâre interested to hear more from me.
Like what you see? Want to get featured? Check out our DevX Project for other great features and to apply to share your own developer experience wisdom
