3rd November 2017, 6:00 pm
This AMA is over!Thank the host
You're welcome! Thanks for the question.
Netflix has been the best company I've worked for, by far. Above all I enjoy the freedom they give us. Freedom to make positive decisions as well as freedom to make mistakes without fear of retribution or shame. Very little bureaucracy. Want to use the new hot framework? Your call, do what's best for the company. Same thing for vacation and so many other things. It's not for everyone though: some people don't do well in an environment where they don't have guard rails. For a lot of roles here, the onus is on you to set priorities, make tech decisions, etc. There are no distinct engineering leads or architects. All engineers are flat, same level. This is so exciting and refreshing when working on projects. From a technical experience, I love love love this. At the same time it's probably my least favorite thing from a totally selfish perspective, as you won't ever get that title "promotion" to Level VI or whatevs, but you definitely still get paid top of personal market. Title's aren't nearly as important to me though as it might have been early in my career.
I highly recommend our culture doc, which was crafted/edited/debated collectively by everyone here and does a great job of representing: https://jobs.netflix.com/culture
Love this question!! (I'm obsessed with WebAssembly) It's pretty bleeding edge stuff, but it's progressing much faster than most probably think!
The v1 of wasm was designed around the C/C++ use case, so it's pretty low-level stuff. However, there's a very active and quickly moving proposal for exposing a built-in Garbage Collector, which is going to be one of the most important building blocks to have high-level languages target wasm and interop with JS objects and the DOM APIs. This is very exciting. Languages like Reason and Elm will be prime examples.
Webpack is actively working on first-class support for wasm modules, as well as eventual things like a cpp-loader, reason-loader, etc which will transparently abstract away nearly all wasm stuff so we can just focus on writing code in our preferred language.
Such an exciting future!
I try not to make distinctions between "developer" and "engineer" as titles, but I'm thinking your question is rooted less about the titles themselves and more about the abilities/mindset.
If that's the case, I think the number one thing you can do is keep yourself challenged. If you feel your abilities are stagnate at your job, try to find another more challenging. Not everyone can switch jobs though, so in those cases try and find more challenging work that fits within your existing role. Having a side project is great too, time permitting. I've grown the most in my skills from the side projects I've done, most of which I never release publicly. It didn't matter though because it was super challenging and I learned so much.
Getting noticed is mostly being more social and having a consistent presence. Being active on Twitter, having an opinion and sharing your passions with others. Giving talks at meetups and conferences helps too, but it takes quite a lot of time, effort, and nerves. In the end, being noticed might get your foot in the door for better jobs but some are surprised to learn companies still make you go through the same interview process and still pass on you for technical reasons. e.g. the guy who made Homebrew interviewing at Google 😆 https://twitter.com/mxcl/status/608682016205344768
I work on Developer Experience rather than customer UX stuff, so I didn't know the answer to this but I found out! We’re constantly A/B testing and improving things; in fact, if you go to netflix.com when you are signed out and watch a trailer, you'll see the video player has the click to pause/play toggle behavior! https://www.netflix.com/title/80057281
So this is definitely on our radar as a possibility. Keep an eye out!
We're love the JVM and have a huge amount of Java and Groovy. There's more and more teams using Kotlin, but I actually haven't seen a major shift across the board. We also have a ton of Groovy, which is slowly going to be superseded by Node.js microservices in a lot of cases; but we’ll continue to use Java indefinitely.
Here are some my favorites:
There's not much specific to Node.js, but it will be helpful to learn how to create custom Observables so you can wrap more imperative APIs or make utilities. Ben's article above will definitely be the best resource for that.
While you're learning, keep an eye out for v4 vs v5 documentation and libraries as some things changed between those versions and people often get tripped up trying to use v4 code or APIs with rxjs v5. Hopefully this shakes out as time goes on. There are still some active efforts to mitigate this.
Netflix definitely has a unique way of doing things. Pretty much everything revolves around the idea of getting every engineer the same freedom as well as responsibility. Avoiding rules as much as possible. This philosophy drives our engineering efforts too: teams decide what technologies they want to use, what they want to work on, etc. Now, certainly some roads are paved more than others, but no one is going to tell you no. It's not all chaos though, as engineers collectively realize being aligned, when possible, helps everyone.
So we do a lot of collaboration and you'll definitely see trends, like our heavy usage of Java and React. But I think it's really important to know that Netflix has the whole gamut of things. Ember, Angular 1/2/3/4, Polymer, Backbone, Vue, Groovy, Scala, Kotlin, Haskell, Python, Ruby, PHP, etc. Some of the most complex UI apps at this big companies are internal and not written in React. They have to deal with very unique scaling issues as well as a user-base who's highly technical and often make mission critical decisions.
That said, I'm pretty confident that most templating languages have the potential to beat the pants off JSX-style virtual DOM because they can better statically analyze them and do all sorts of optimizations. Ember's Glimmer is actually leading the way in this right now IMO but like the browser wars the UI libs seem to take turns becoming the perf leader of the year. There's also still a lot of optimizations you can do to JSX, and even more if you're OK with sometimes deoptimizing certain edge cases that are ambiguous. A great example is automatically extracting ports of your JSX that never changes: https://babeljs.io/docs/plugins/transform-react-constant-elements/
While I’ve used Ember and Angular pretty extensively, my actual experience with Vue so far as mostly been playing around, as well as helping others who just happened to be using Vue. So definitely my opinions are skewed. Vue also has a much more first-class experience with Observables, which I’ve been keeping a close eye on.
Mostly comes down to push vs pull.
Observables are push-based, and perfect for modeling data in which you cannot (or don't want to) control the rate in which data is provided. Easiest example is a user's keyboard events, we can't control the user, they type when they want to. Most UI stuff is modelled best as push, but elsewhere backpressure can become an issue: data can flow faster than you can handle it, so you have to either buffer or drop it. Both backpressure strategies have issues that might make it impractical.
AysncIterables are pull-based, so they're great for things in which you can, and want to, control the rate. You ask for the next event and you get a Promise that will resolve when it's ready. It's important that you can actually control the producer, otherwise the producer will have to drop or buffer and then it's the same problem Observables would have. The cost of creating a new Promise every time (and the fact that they have to be async) is a potential thorn, but not usually an issue the average person will run into.
I'm not directly involved with our A/B testing, so I can't speak too much from experience. We A/B a ton, even stuff you might think would obviously be better. Intuition is often wrong, so it's good to have that data to confirm.
If this stuff is interesting we have a great, in-depth post about our A/B testing stuff here: https://medium.com/netflix-techblog/its-all-a-bout-testing-the-netflix-experimentation-platform-4e1ca458c15
We're given a ton of freedom to do what we think is best, so every team can and often does do things differently. Some teams to TDD, others (like mine) don't.
Most teams here use Jenkins for some things, but there's a lot of hardware related testing that goes on that's pretty complicated.
Automation is key 🔑
I'll give it a shot, but keep in mind these are just my opinions lol 🤡
Programmer: a person who can write code, very often relies on others to make decisions; e.g. advice from the lead engineer, or copying and pasting code off StackOverflow. Doesn't knowingly use their own abstractions.
Good Programmer: a person who can make complete solutions. They can go from an idea to a product on their own. They still copy and paste code off StackOverflow sometimes, but less often as usually they understand the solution's code and write their own variant. Uses abstractions, but sometimes prematurely.
Great Programmer: a person who can do all the above, but also enable others to do them too. Much better at not doing premature optimizations/abstractions, but of course still is guilty. Still copy and pastes code off StackOverflow.
I described them as three categories, but really people's paths and abilities vary. So the path to being a Great Programmer is tough to say, but I've found true passion for programming often correlates. Consistently challenging yourself with harder and harder problems that you enjoy is my advice. The saying "if you're the smartest person in the room you're in the wrong room" is very apt as well.
I unfortunately can't accurately speak for those teams. It's entirely possible that they've experimented or even have future plans for RN though. It's pretty sweet, and Netflix has a similar tech called Gibbon we use on our TV UIs https://medium.com/netflix-techblog/crafting-a-high-performance-tv-user-interface-using-react-3350e5a6ad3b
Being consistently challenged. I often see people stagnate in their jobs, not really learning much new. I love being in over my head and dig my way out. Remember it's not about how many years, but rather what things you've done and learned in your career. Side projects can be a great outlet to experiment and challenge yourself, if you have time.
- Can represent zero to an infinite number of values over time. Promises must represent a single value.
- Observables are lazy, so they don't do anything until someone subscribes. This lets you declaratively compose streams in a way that actually is very similar to its own language.
- Built-in cancellation, though the new AbortController kinda sorta makes this one muddy. (e.g. fetch will be cancellable using them)
- Synchronous by default (unless scheduled differently) so you can choose scheduling. Promises are always async, scheduled on a microtask https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/
It's definitely possible for a custom "Promise" libraries to make some of these points moot, which is totes awesome, but then it's not really a Promise 😉
PWA's are great when they're available and work. Many devices/browsers don't support them fully yet though (or in a usable form) and they're still a bit tough to get right for the average dev. I got frustrated for an embarrassingly long time learning ServiceWorkers.
As far as Netflix.com becoming a PWA, it might happen at some point, just not yet. e.g. iOS Safari is DOA because no ServiceWorkers and no Encrypted Media Extensions. Their "save to home" UX isn't yet as seamless as Android's. I'm not on the team responsible, so I don't want to speculate too specifically! :o)
- Additional documentation on top of what's already available for the individual components, and how they work best together
- You don't have to make as many choices, which can get fatiguing and you're more likely to get them wrong
- Sometimes these groupings help with employment and hiring, like what LAMP did.
- I love React.
- I love React.
- Redux being included as part of it contributes to the issue of people bringing in Redux too early and/or in apps that don't need it.
- MongoDB might not be the best choice for every use case. It also hasn't had the best rep recently with the accidental exposure/deletion/ransom of people's DBs.
All in all, I think MERN is a fair guide for those who just want a more complete paved road. To be honest though, I don't know anyone personally who has used the actual MERN stack CLI or boilerplate stuff. They just use the things that happen to be part of the acronym.
Without a doubt, and it's already begun. First it was separate processes per tab, then they started splitting off things like HTML parsing, layout, GC, etc into separate threads. I'm super excited about the innovation that's being made--Mozilla's Quantum and Servo are shining examples of this. If I didn't know better it seems like Mozilla is going to have their cake and eat it too: multithreaded performance while also becoming more memory safe than all the others, thanks in part to Rust. But don't count out the other browsers, this race will continue!
Our docs on testing have definitely been neglected..I had hoped that we'd have time to improve rxjs's testing story in general, since testing in redux-observable should be nearly the same. There's been some movement in that front but not super solid yet.
I most often test my epics these days by calling them directly, without redux/middleware at all. Check out the example here: https://redux-observable.js.org/docs/recipes/InjectingDependenciesIntoEpics.html
Some experiments around marble diagram testing (but still alpha quality):
Oh it's been talked about for sure. I'm not aware of any concrete usage yet, but it's only a matter of time before someone uses it somewhere at Netflix, probably for internal stuff since there are a lot more greenfield projects. I've been playing around and keeping an eye on it, so for me it's still too volatile to commit to. But I have my own language stuff I'm working on so I'm a bit biased :p
I usually advise: 100% don't learn React while also learning Redux. Learn React with
setState and for the average app (which is most) Redux would have just been significantly overcomplicating things.
That said...if you're the curious type it's very cool to learn Redux in your free time to understand the paradigm and get a better idea of what it's good at and more importantly what it's bad at.
This one is tough for me as I don't have any experience building software for kids. But I do have lots of UX experience, so I would probably approach it similarly: start off with a prototype, going with my gut on UX decisions. From there, have some kids use it with as little direction as possible and watch their behavior. What do they click on? Where does their mouse move to? Where do they get confused? What's missing?
It's definitely useful to have them provide feedback as well, but I imagine it's like UX for adults in that often people say one thing but do another. Just keep it in mind and correlate with others too.
There are also data collection laws regarding kids. To be honest, because kids software feels like a whole different realm to me I'd probably bring in someone else to help me, or at the very least do a ton of research into existing studies and observations of others.
The monkeys live! I haven't heard of any new monkeys recently, but we've upgraded Chaos Monkey a number of times and continue to increase our failure injection initiatives. Speaking of which, the Chaos team recently released a free e-book through O'Reilly if this stuff tickles your fancy: http://www.oreilly.com/webops-perf/free/chaos-engineering.csp
I think I really leveled up when I started writing more libraries as well as trying to understand more about how things work. e.g. really understanding prototype inheritance. I'm a armchair compiler nut, so I would also refer to the ECMAScript spec quite often too. One thing that I've found helpful in teaching others is actually reviewing what ES6 -> ES5 compiled code looks like from Babel and understanding the choices it makes, particularly when in spec-compliance mode where the output can be a bit verbose.
I've found egghead.io to be pretty awesome, and they have lots of free content too. I recommend them so much I sometimes wish they had some sort of referral program lol.
Loves code, hates condiments. Jay is a Senior Front End Engineer at Netflix with over a decade of engineering experience. Lover of all things open source, his contributions span across numerous ecosystems.
The all-in-one cloud platform developers & their teams love. Get started free for 60 days.Learn more
6 Reasons to join Hashnode, now!
- Friendly and inclusive
- Ask questions, Read blogs and share news
- Voice your opinion without being judged
- Question everything and quench your curiosity
- Earn appreciations and be the coolest nerd
- Hang out with smart developers from across the world