Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
91 lines (66 sloc) 9.46 KB

Hi, I'm swyx

Why read me?

I'm writing this in the hope that we can fast forward through some getting-to-know-you facets of me that we might miss (of course doing so IRL is better, but not always possible).

I am really keen to do great work with/for you and I can be extremely, extraordinarily creative and productive under the right conditions.

I am also very imperfect and I hope that my transparency about them here is not treated as an excuse for my flaws but as a guide for you to know how I might fail. Consider this an open invite for you to call me out and prevent bigger pain down the road.

My role

I'm excited to be a DX Engineer at Netlify! I absolutely love my job description so here it is in full:

  • The DX team is focused on empowering developers (customers & partners) by making it as easy & streamlined as possible for them to build awesome stuff on top of the expanding Netlify Platform.
  • The DX team are the internal dogfooders. They stretch, bend, and break the tools Netlify offer to make things better for the ever expanding group of developers.
  • DX work closely with product, support, docs, users & partners to push the product to new heights, teach users what is possible with the JAMstack, and build tooling/docs/demos to attract people into the Netlify ecosystem.
  • As a DX engineer you will be immersed in a wild range of projects:
    • Building demo applications with bleeding edge tech
    • Coming up with innovative & creative ways to build things on Netlify
    • Working with other SAAS companies and onboarding them as partner integrations
    • Building a world class developer experiences including tooling, CLI
    • Creating content/talks/presentations spreading awareness on what’s truly possible on Netlify
    • Helping close enterprise sales

In other words: this is a growth + engineering role that traverses from top of funnel (awareness and education in talks, podcasts, blogs, seminars and workshops) through on-boarding developers into the product, helping to reduce churn, and improve engagement as well as revenue expansion.

Me in a few words

  • Born and raised in Singapore, family are all still there and I visit at least once a year. My baby sister is the most important person in the world to me and she is learning to be a dentist!
  • Came to the US for college in 2007
  • Started my career trading equities, interest rate, currency, and volatility derivatives in investment banks/hedge funds
  • Made apps for risk management, pricing, and portfolio management in Python and Haskell as part of the job
  • After a brief run in product management decided to make engineering my fulltime job as it's what I enjoy most
  • Went through Fullstack to get up to speed on JS as JS is everywhere
  • Started being active in Dev Twitter, speaking in the NYC tech meetup scene, and moderating /r/reactjs.
  • My full english + chinese name is Shawn Wang Yue Xian, when I was 13 people started calling me "swyx" and it stuck.

What I believe most

  1. Learn in Public: I prefer to share what I learn and work on, after doing my level best, but before it is perfect. This means I will be wrong more often than most people, but I respond very well to people who correct me because I always reserve the right to be wrong. I do not share everything, in particular my political views.
  2. Systems over Goals: There are things I can control and things I can't. Of the things I can control I focus on the items I can work on more frequently that can compound, and get me tangibly closer toward a goal. But the goal isn't the point. The goal doesn't matter. It is the system that sustainably gets me there that is everything, and I welcome the opportunity to periodically take a step back and work on the system instead of working in the system.
  3. Intrinsic Drive over Extrinsic Motivation: Drive is a wake-up call to me. I don't quite know what it means yet in the context of work but I definitely function like this. For Netlify it probably maps closest to the team value of Empowerment. I will come up with (too many) ideas and welcome criticism of them, and in return don't take my criticism of your ideas as a criticism of you.


The general thrust of this is: lets agree upon what we need done and why (I'll always have a suggestion), enable me with resources and knowledge, and check in frequently while I throw myself at it.

  1. Start with Why: I generally (but don't literally) believe in asking 5 Whys and will often question why we are doing a thing as it may not be the best way of achieving our ultimate intended goal.
  2. Frequent, Specific Deliverables: I work best when I know exactly what is expected of me. I'm also a sprinter and will move heaven and earth to deliver something I've signed up to deliver.
  3. Stretch: I have no problem signing up for things slightly out of my comfort zone and knowledge level, in fact I love the challenge and do my best work on the edge.

How I Work

  • How should people set time with you? I may close Slack when in the flow of things, so I may not always be present there. I check email about twice a day. I generally like scheduling video chats with a day's notice. You can also book time on my calendar whenever i'm not free and then send me a note.
  • What's the best way to discuss issues with you? I am extremely open to direct 1 on 1 feedback and don't need a compliment sandwich.
  • How do you define "Done"? My bar for "done" is probably lower than yours (see "Learn in Public", above). But I also expect to work on things after they are "initially done", i.e. I probably see more stages to a task than most. I do not put documentation at the end of my process so much as use it as a planning and support tool while I code, but having good docs are very much part of how I define "Done". Tests are great, but only make sense if there is stability in the API/idea so it is more of a judgment call for me than some who want everything unit tested.
  • When are you available? I am a night owl regardless of time zone, weird but true. I am currently in New York City and typing this at 4am in the morning. I can of course do morning work if it calls for it, but I'm just sharing my weird default.

Personality quirks

  • I am a friendly introvert; I love meeting people in real life in non noisy environments.
  • I love making work fun and adding in emojis and memes to spice up a core message! This can sometimes involve writing song parodies as an outlet - I will sing them for you if under the influence. If I were actually any good at it I'd be a singer-songwriter.
  • I am not a polished speaker (still working on my ums and ahs) but have generally done well speaking from the heart about great ideas and other things I am passionate about.

Known Failure Modes

  • In 2018-19 the top feedback I got in my 360 was that I don't communicate well or enough in some contexts, and often seem distracted. People report that I:
    • move fast and skip steps
    • dont provide enough context in issues or externally
      • In particular, longer explanations to customers, not imperative: do this, do that
      • provide more context in GH repos
    • am not engaged in calls/dont value others contributions to conversations/dont pay attention when others are speaking
    • working on too many things at once
  • I shut down when people are bikeshedding (spending disproportionate time debating small things that they know well while not discussing bigger things that really matter). Yes, what "really matters" is subjective. But I will pick silence over contributing to what I perceive as noise. If it really does matter and you see me shut off, please tell me why it matters (see 5 Whys). I may respond by pointing to the bigger thing that does matter in my view.
  • I've been accused of being too direct with people without context. I don't like small talk and while I respect that there I things I don't know, I often implicitly assume that people will fill me in on what I need to know if they see me assuming things in error. This can be a bad assumption.
  • Because "my bar for done is probably lower than yours" (see above) it can appear like I don't care about details. I care (watch how rarely I make grammatical/spelling mistakes) but I care -more- about getting things out and iterating on the big picture first rather than debating wording on a button. Obviously, a lot more cases in real life are more ambiguous than that. If I make a judgement error and the detail really does matter, please call me out on it and I will work with you.
  • This is a non-exhaustive list; there are definitely more things I can't think of right now.


This idea comes from Manager README's - I'm no manager but I like the idea of READMEs to accelerate getting-to-know-you phases, especially asynchronously. So I'm trying this out.

This is a living document and I hope to update it as I refine my self-knowledge over time. kick me if you think it needs an update.

You can’t perform that action at this time.