How to code like a FAANG Software Engineer - Follow this one pattern!

[@sudo_garrett]

i love these higher level/conceptual videos. understanding engineering workflows from other FAANG companies offers really valuable perspective.

[@Sammi_Kristiansen]

Thanks for making a video that are useful for other big tech companies too! Could you make the part 2 of your working in USA vs working in UK/Europe video? Thank you!

[@crackfaang]

Not sure what I would discuss to be honest. I think I covered all of my talking points in the first video

[@Sammi_Kristiansen]

@@crackfaang In that video, you said that you'd make a follow up with about the pros and cons of working in the UK, what you like and you don't like. I'm sure many people would love to hear your thoughts! Thank you again!

[@HamidrezaFarhidzadeh]

Thanks for sharing this, informative!

[@fadsa342]

I enjoyed the video but have a couple of questions...I was a little confused when you talked about B1 -> B2. If the developer uses smaller PRs do they get integrated into the main branch? Or do you end up with B3 being a feature branch with all the smaller changes that still needs to be merged and maybe reviewed? Also, do you find that developers are idle while waiting for PR feedback? Or do you they switch to the next small chunk?

[@crackfaang]

So you have the option of landing your code as soon as it's accepted or you can land a stack of 2+ diffs all at once. I'm not sure how the CI exactly does it but eventually all the diffs will be merged into master. Though in rare cases due to our continuous release pipeline you can have the case where some code is actually caught waiting for the next push to happen, but that's rare. In terms of waiting for diff review, it's usually pretty fast if the diffs are small and manageable. The slowdown usually comes from overly complex diffs or ones where team members don't have context or are not familiar in that programming language. Most people will move on to the next diff while waiting for reviews lower in the stack

[@fadsa342]

@@crackfaang thanks I'm going to try this on my team

[@asiancrypto]

If the pr could have been smaller pr's then the coder would not have resorted to having multiple diffs in the first place. The requirement for pr's is that they need to have "impact" to the user. So a pr that "gets data from API" does not qualify has a pr because there is no impact to the user.

[@bigboyshassen59]

Seems like a potential feature gap in github. Because you're totally right, once you grow past 1 or 2 dependent branches, it's painful and not worth the effort (unless each PR is like 5k lines). Do any github alternatives do the auto updating dependent branches thing?

[@crackfaang]

Meta open sourced something called Sapling which aims to imitate our internal version of Mercurial and is probably the closest thing to what we use at Meta. It has some wrappers on top of Github but I'm not entirely sure about the auto-updating of PRs. I think there might be open source vs code extensions which can do it for you though

[@AdpYTExplorer]

I liked this idea, just a question: would the Code reviewer be annoyed that I’m asking them to review multiple PRs/Diffs for a single feature? Would they just be like “just do the entire thing and then call me for review?”… cuz then I need to convince them breaking this into multiple code reviews is better (and probably link this video)

[@crackfaang]

Well it depends on the culture of the company. At somewhere like Meta where working with stacked diffs is the norms, a reviewer will be annoyed that a diff is too large. Whereas at other companies where this practice is not adhered to, then reviewers may indeed question your decision to do this. But ultimately it makes a reviewers life easier to review smaller PRs than one big one. Though merging these stacked PRs in GitHub is admittedly not the simplest. You have to merge & rebase PRs until you hit the last one in the stack and then do a Squash & Merge. It's really annoying and I'm not a fan of it but that's just how the architecture is set up. At Meta we use Mercurial and things are different with the structure of the version control system. I know Google also does stacked PRs though using their own custom code tooling

[@LJLJ-m1j]

Is it common for META to push changes directly to PROD without deploying to lower envs first ?

[@crackfaang]

Not sure how it is for all repositories but yes at least for the main codebase, it's straight to production. Though it happens in 3 phases: employees => small % of production traffic => 100% of production traffic. You can read more about it here: engineering.fb.com/2017/08/31/web/rapid-release-at-massive-scale/ Maybe I'll make a separate video on this as well!

[@LJLJ-m1j]

@@crackfaang Thanks.That's a really great article.I know Google does it this way too in most teams.I just get used that at my job everything is deployed in 3 lower envs with all sorts of testing before adding everything to PROD.That's a bit annoying sometimes :)

[@asiancrypto]

If this is a common problem for new people at FAANG, then a simple remedy would be to say before they start coding "hey new people, make sure to use stacked diffs. Inquire more if you are not sure what we are taking about."

[@crackfaang]

Due to lack of external tooling, it's very difficult to operate the same way. Plus we use a forked version of mercurial and that's not available externally so you can't even practice. But it's not something you need to have learned before joining. It's very easy to pick up and people in code reviews will tell you when your diff(s) are too big and should have been split up to separate out concerns. The general principle is 1 idea = 1 diff.

[@catmaxi2599]

Yeah isnt there a multi werk bootcamp? I bet they teach it there

[@asiancrypto]

For the people using git at startups, what are tools or methods we could use to have stacked diffs?

[@sudo_garrett]

what program do you use to draw/diagram? is that gimp?

[@crackfaang]

Excalidraw

[@sudo_garrett]

@@crackfaang thanks homie

[@syedhassan7052]

Subbed! Also joined your discord. Excited to contribute to the community