A significant part of the life of a developer is spent gluing other people’s code together rather than writing their own code . This is both a blessing and a curse. On the one hand, we use more robust, more flexible, and maybe even faster software. However, when the honeymoon stops and the library does not work as expected, the time spent debugging might exceed the time we would have spent had we written things ourselves. A major reason for this is that most developers only use libraries, yet don't read them. Reading and understanding other people's code is an important virtue every developer has to obtain. Could Dostoevsky be the author he was had he not read Pushkin? Can we reach for the skies if we don't understand how the giants we are standing on the shoulders of work?
Mortimer Adler, editor for Encyclopædia Britannica, outlined the rules of reading other people's work in his influential book "How to Read a Book". Reading code is different. It is neither as linear nor as polished as the edited version of a book. It seems more like a random walk rather than a guided journey. Can we do any better?
This talk proposes to do what Adler did for prose; outline the principles of reading other people's code, using React.js as an example. We will dive into the internals of this exciting user interface library by Facebook that has transformed how people are doing web applications over the last couple of years.
Sign in to add slides, notes or videos to this session