,
10 tweets,
2 min read
Read on Twitter
1.1/ For today’s installment podcast summary/hot takes, I’m doing my own podcast.: softwareengineeringdaily.com/2019/05/14/fac…
This episode is mostly about evolving large systems and codebase. I call this: “Evolution Means for Revolutionary Ends: The Art of Changing Systems in Place”
This episode is mostly about evolving large systems and codebase. I call this: “Evolution Means for Revolutionary Ends: The Art of Changing Systems in Place”
1.2/ Original post about series is here:
(Note also doing new threading approach. Twitter’s threading seems to totally break down past 25 tweets, so doing this in tranches)
(Note also doing new threading approach. Twitter’s threading seems to totally break down past 25 tweets, so doing this in tranches)
1.3/ When I joined Facebook I was engineer 180 or so. The company was five years old. We were quickly approaching 200 million (not what I said “2 million”!) monthly actives. The number of unit tests in the code base? Zero.
1.4/ I both shocked and amazed by the state of engineering. I was blown away by the velocity. The notion that I was expected to commit code on day 1 and that would be automatically pushed to production at some point was insane.
1.5/ However when I looked at an individual file in the PHP I was pretty appalled. (In podcast I said I lost color in my face and turned into a “scandalized ghoul” lol). Counterintuitively, it was a testament to the engineers there that so much was still getting done.
1.6/ The company realized that this needed to make this shift. Because we were shipping bugs to production and the engineers just knew intuitively that something was wrong. FB was also hiring lots of experienced people whose feedback was “strong, blunt and consistent.”
1.7/ Two additional points I didn’t make in podcast. One: Code quality by that point was harming velocity. Two: Code quality was a *company-level* goal in 2010. It was recognized as a problem from the highest levels.
1.8/ While I noted that I thought FB had let quality slip too far in terms of not setting a baseline (e.g. there should have been unit tests the whole time), most companies build too much infrastructure when they should instead be iterating on product as quickly as possible.
1.9/ Infrastructure is a problem you have to *earn*. What’s the point of building infrastructure for a product that is never used because it is the wrong thing? Engineers often (myself included) naturally want to build infrastructure and you need to check that instinct.
Next tranche:
