Tip 17: On the Shoulders of Giants
An excerpt from The Passionate Programmer — by Chad Fowler
As a jazz musician, I spent a lot of time listening to music. I didn’t just play music in the background while I was reading or driving. I would really listen to the music. If jazz improvisation is all about playing what you hear over the chords of a song, then actually listening to music is a critical source of inspiration and knowledge of what works and what doesn’t. What sounds great and what just sits there.
The vast history of jazz recordings serves as an incredible body of knowledge, there for the taking by anyone with the skill to hear it. Listening to music, therefore, is not a passive activity for a jazz musician. It is study. Furthermore, the ability to understand what you’re hearing is a skill that you develop over time. My circle of musician friends actually did this kind of listening explicitly. We would have listening parties, where a bunch of jazz musician geeks would sit around listening to music and then discussing it. Sometimes we would play name that improviser where one of us would play a recording of an improvised solo and the rest of us would have to figure out, based on style, who the recorded improviser was.
We in the jazz world weren’t special, of course. Classical composers do the same thing. So do novelists and poets. So do sculptors and painters. Studying the work of masters is an essential part of becoming a master.
When listening to jazz recordings, we would discuss the musical devices that improvisers would use to communicate their musical points. “Wow! Did you hear the way he started sidestepping at the end of the form?” or “That was really strange the way he was playing behind the beat on the bridge.” These discussions would help us all distill and discover tricks that we could take with us to our next improvisation session to try.
Software design and programming have a lot in common with the arts in this way. We can mine a huge body of existing code for patterns and tricks. The design patterns movement (see Design Patterns: Elements of Reusable Object-Oriented Software [GHJV95]) is focused on the discovery and documentation of reusable solutions to common software development problems. Design patterns have formalized the study of existing code, making the practice accessible to a great number of software professionals. Still, design patterns address only a small subset of the kinds of learning we can enjoy through code reading.
How do other programmers solve particular problems algorithmically? How do others strategically use variable, function, and structure naming? If I wanted to implement the Jabber instant messaging protocol in a new language, how might I do it? What creative ways can I find to handle interprocess communication between UNIX and Windows systems? These are the type of questions you can answer through the study of existing code.
Even more important than finding solutions to specific problems is the use of existing code as a magnifying mirror to inspect our own style and capabilities. Just as listening to a John Coltrane recording always reminded me of where I stood on the skill ladder as a saxophonist, reading the work of a great software developer has a similarly humbling effect. Nevertheless, it’s not just about being humbled. As you’re reading through code, you will find things that you would have never done. You will find things you might have never even thought of. Why? What was the developer thinking? What were his or her motivations? You can even learn from bad code with this kind of critical, self-aware exploration of an existing work.
The act of learning from the work that came before you works well in the arts world, because there is no hidden source code for a painting or a piece of music. If you can hear the music or see the piece of art, you can learn from it. Thankfully, as software developers we have access to a practically infinite array of existing software in the form of open source software.
Enough open source software is available that it would be impossible to ever actually read all of it. There are definitely some bad open source projects, but there are also quite a few great ones. There is open source code available implementing almost any task that can be done with software in almost every available programming language.
As you look at this code with a critical eye, you will start to develop your own tastes, just as you would for music, art, or literature. Various styles and devices will amuse you, amaze you, anger you, and (I hope) challenge you. If you’re really looking for them, you’ll find everything from tricks that make you more productive to design paradigms that completely change the way you approach a class of problems. Just as in the arts, by studying and learning from the habits of others you will develop your own distinctive style of software development.
A positive side effect of reading code is that you will learn more about what already exists. When you have a new problem that needs solving, you might remember that “Oh, I saw a library that implements MIME type handling in such and such project.” If the licensing terms are right, you may save yourself a lot of time and your company a lot of money by becoming more aware of what’s already out there for the taking. You might be amazed to realize just how much money we waste in the software industry by reimplementing the wheel (invention would be too generous a word) over and over again.
Sir Isaac Newton said, “If I have seen further, it is by standing on the shoulders of giants.” Smart guys like Isaac know that there is much to be learned from those who came before us. Be like Isaac.
Act on It!
- Pick a project, and read it like a book. Make notes. Outline the good and the bad. Write a critique, and publish it. Find at least one trick or pattern that you can use from it. Find at least one bad thing that you observed that you will add to your “What not to do” checklist when you’re developing software.
- Find a group of like-minded people, and meet once a month. Each session have someone nominate some code to study — 2 lines to 200 lines. Break it down. Discuss what’s behind it. Think of the decisions that went into it. Ponder the code that isn’t there.
We hope you enjoyed this excerpt. You can continue reading The Passionate Programmer directly on Medium:
Or purchase the book directly from The Pragmatic Bookshelf. As part of our 2023 Spring sale, you can save 50 percent on this book by using code GROW2023 through midnight ET on April 17th, 2023.
For a print copy, visit bookshop.org.
