I just finished up a summer internship at Facebook, and I want to reflect on the lessons that I learned there. I consider the whole experience to have been a learning opportunity, as I was not much of a developer before I started. Before this summer, I had never worked on a software project bigger than a few thousand lines of code. Nor had I ever collaborated with others on one. Of course, this changed over the course of my internship. As I worked, I picked up many software engineering skills: unit testing, code review, logging, debugging, testing, profiling, etc. However, the real take-home message for me was the importance of reading source code.
I think that I used to be afraid of code. If I ran
./configure && make && sudo make install and got back an error, well, then I gave up. It was too scary to go digging around in piles of unintelligible C preprocessor directives. If the answer wasn’t in a README or a man page, then I was dealing with uncivilized software, not worthy of my time.
Of course, this attitude wouldn’t have flown at Facebook. At Facebook, stuff is always broken. Facebook prides itself on breaking things. On top of that, documentation is sparse. As a result, during my internship, I was forced to really dig in to source code written by someone other than me. It was tough at first; progress was slow. Others seemed to just “know”, and I didn’t. Interns joked that there was a secret stash of documentation somewhere that the full-timers were hiding from us.
Slowly but surely, I got better at reading source code. I learned to use Eclipse and grep to help me navigate through it. Eventually, I was following call graphs fluidly. I could easily weave through files and pinpoint the best place to make a change. I became more and more productive.
Ever since then, nothing else will do. I approach documentation with a wary eye, even when it is available. It is far too easy for documentation to become outdated and misleading. There are few users and no compiler to keep your documentation honest, unlike source code. In the same vein, diagrams can only go so far. Discussing a solution with colleagues using anything other than source code feels unbearably hand-wavy. Indeed, there are few meetings at Facebook. Most discussions are short-lived because there is an attitude that the code is the proof. In other words, if you think that there is a better way to do something, don’t argue about it, just go away, do it, and show it to people.
Thanks to my internship, I’m no longer scared of source code. In fact, I’m even upset when it’s not available, as is the case with many peer-reviewed articles. I feel handicapped by the lack of it. On the other hand, when it is available, I feel empowered. There is truly no substitute for reading the source. Anything else can give only an incomplete understanding of the nitty-gritty details.