Career coach, programmer, author, speaker. Former engineer & manager @ Facebook, Wandoujia, Yahoo and Baidu. Career coaching available: https://chen.cat/patreon
I worked at Facebook and I focused on driving down production uncaught error for a while. I would say Flow helped prevent a lot of potential error throwing code from being checked in.
All engineers in Facebook are full stack. That means many of them don’t know much about JavaScript but need to write JavaScript. When thousands of engineers from different teams writing JavaScript in a single repo and all the code interact with each other, bad things happen.
For example, one engineer calling function X expects it to accept nullable argument. He checks X’s implementation and it looks like so. He doesn’t filter out null when passing the argument. Everything works in his dev environment. In production, some branch in X calls function Y and some branch in Y calls function Z. Z doesn’t accept null but the argument is passed all the way from X to Z. A production error is thrown.
Why didn’t anybody realize this before the code was pushed to production? Because the authors of function X, Y and Z are all different engineers. The functions are in different files. The authors are from different teams. They never talk to each other. They happened to find a function in the codebase and it looked like the function can fulfill their need, so they called someone else’s function without checking thoroughly.
Flow helped a lot when you need to reuse someone else’s undocumented code as a blackbox. At least it’s a more reliable blackbox now. If you are building your own project and you only depend on well documented libraries, you might not have the problem Flow aims to solve.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I worked at Facebook and I focused on driving down production uncaught error for a while. I would say Flow helped prevent a lot of potential error throwing code from being checked in.
All engineers in Facebook are full stack. That means many of them don’t know much about JavaScript but need to write JavaScript. When thousands of engineers from different teams writing JavaScript in a single repo and all the code interact with each other, bad things happen.
For example, one engineer calling function X expects it to accept nullable argument. He checks X’s implementation and it looks like so. He doesn’t filter out null when passing the argument. Everything works in his dev environment. In production, some branch in X calls function Y and some branch in Y calls function Z. Z doesn’t accept null but the argument is passed all the way from X to Z. A production error is thrown.
Why didn’t anybody realize this before the code was pushed to production? Because the authors of function X, Y and Z are all different engineers. The functions are in different files. The authors are from different teams. They never talk to each other. They happened to find a function in the codebase and it looked like the function can fulfill their need, so they called someone else’s function without checking thoroughly.
Flow helped a lot when you need to reuse someone else’s undocumented code as a blackbox. At least it’s a more reliable blackbox now. If you are building your own project and you only depend on well documented libraries, you might not have the problem Flow aims to solve.