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.
You can follow swyx on Twitter, GitHub and YouTube
TL;DR Highlights:
- Why swyx doesn’t like the term “self-taught”
- Tips for a great engineering culture
- Swyx’s ideal stack
- An epic fail he’s seen, and what we can learn from it
- The difference between internal and external developer experience, and how to improve both
- Why swyx is a fan of monorepos
- The risks and opportunities facing FE devs
- How 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
