Last week we had the pleasure of hosting Tom Occhino, Head of React at Facebook at our Culver City campus. We enjoyed a really great conversation ranging from interviewing tips to software architecture and much more.
It would be really hard to summarize the two hours he spent with the 40+ Fellows so instead I will highlight four key points that made an impression on me.
Learn to Code by Focusing on Product DevelopmentWhat’s the best way to learn to code? Ask 10 developers and you might get 20 different answers. In a world where so much subjectivity exists, it is hard to say what is the best way to learn to code but we certainly have an opinion. In fact, I was happy to hear that Tom agrees with our pedagogical approach of building products as a way to learn how to code. Simply diving into a library, framework or language for the sake of just doing that, does not yield very tangible and valuable results. Building software on the other hand produces value very quickly.
Passion in InterviewingIf you are interviewing for a job you have to show a passion for your craft. This seems like it should be common sense but the majority of people you ask, even at Tom’s level, are going to stress the importance of showing passion? Why? Because so many people fail to do so. Perhaps it’s the situation and the stress of interviewing. It would be tough to say with exact certainty but one thing is clear: bring your passion.
Pick the Best Tool for the JobWhat source control provider should you be using? Right now, you may be hard pressed to find someone that does not say GIT. Why? Is it because it is so great? No, not in my opinion. They say GIT because it is the most popular of all the options. But the most popular or in vogue technology is not always the best for your needs. Such is the case at Facebook. At Facebook they use Mercurial, a much less known version control provider. I am not trying to take anything away from GIT or give anything to Mercurial. I just want to point out that the task at hand needs to be considered when pick your tool.
Branching Strategy Kept SimpleOne of my favorite debates among development teams is the debate around the branching strategy employed. Branching is such a popular thing that often times teams will branch simply because they can. And this is where I like to inject into the conversation: “just because we can, does not mean we should”. I have seen a number of different strategies employed and most of them really sucked. One forced a team into a dead standstill while the merging of branches took place. A process that would seemingly take days. Yes, I wrote days. It was a not a typo. This team would dedicated at least 1 resource for a number of days to the merge process. During this time, everyone else could not check in.
This is absurd and very far from any well running development teams like at Facebook. At Facebook, like at one of my previous employers, they run a very simple branching strategy where features are release disabled behind code blocks that keep them off until they are ready. These same switches are used to enable certain features for specific populations. This does involve writing a bit more code and managing the switches but it allows their developers to keep coding, to move fast and maybe break things.