Getting to Know David Max
LinkedIn wouldn't be the company it is today without the engineers who built it. We have no shortage of talented individuals in technical roles across the company. They are the ones who create, build, and maintain our platform, tools, and features—as well as write posts for this blog. In this series, we feature some of the people and personalities that make LinkedIn great.
David Max is a Senior Software Engineer working on the Content Ingestion team. His team is responsible for scraping and storing metadata about all the external content shared by members on LinkedIn. Their main services are Babylonia and Jhubbub, which provide information like titles and thumbnail images to accompany shared URLs.
Before joining LinkedIn in the New York City office in February 2015, he worked at Google on ad serving for about two years. Before that, he spent about 10 years working in financial technology for various financial firms, such as Barclays and Goldman Sachs. David received his bachelor’s degree in computer science from Caltech and his master’s degree from New York University.
What are your favorite kinds of engineering stories to read on the blog?
My favorite kinds of engineering stories meet the same criteria as a podcast I enjoy listening to called “Tell Me Something I Don’t Know.” It’s a kind of game show hosted by Stephen Dubner where contestants compete by sharing bits of knowledge. The judging criteria are: Is it something I actually didn’t know? Is it really worth knowing? And, is it true?
It’s interesting that you would ask about stories. Why tell stories about engineering? For example, a story might describe an engineering challenge and then the path the engineer took to a solution. When done well, you imagine yourself trying to solve the challenge. When you read about the path they chose, you can experience a bit of the process yourself. What were the tradeoffs? What other solutions were considered, and why did the chosen solution best fit the situation?
Reading about anti-patterns can be equally useful. Learning about why an initially attractive solution turned out to be a big failure is a great lesson, and much safer to learn vicariously.
One thing I love about software engineering is the people it brings you in contact with. People who have a passion for software engineering often share the sense of what Robert F. Smith called “The Joy of Figuring Things Out.” The payoff of a great story about solving an engineering challenge is not just the solution but also the story of the solution. You don’t just want to learn the solution. You want to learn how to think like the solver.
What kinds of engineering problems interest you the most?
Software engineering challenges can be broadly fit into a spectrum. On one end are the kinds of systems where we have built many others like it before, and the design principles are well-understood. On the other end are systems that we could propose building where nothing like them has ever been built before. We might not even know what to build, let alone how to build it. Somewhere in the middle are the kinds of engineering challenges where you can’t quite foresee all the steps it will take to get from where you are now to where you want to go, but you have a couple of good ideas for possible steps you can take that will get you closer.
I find this to be the most interesting kind of engineering problem. Each step you take is a bit of an exploration that reveals more about the problem landscape you are trying to navigate. Sometimes you take a wrong turn and have to backtrack, but it means that each step is a kind of experiment that helps you discover more about where to go next. This kind of approach I’ve since learned is called “design thinking,” and it applies to more than just solving engineering problems.
A couple of years ago, I volunteered for “Hour of Code” to talk to some elementary school students and answer their questions about being a software developer. A fourth-grade girl in Texas asked me, “When you were our age, did you know that this was what you wanted to do when you grew up?” As I thought about it, I realized there was no possible way I could have imagined being a software engineer at LinkedIn when I was in the fourth grade. What I do now didn’t exist back then. The most interesting challenges of today are the ones that were unforeseeable not too long ago. There was no such thing as a “social networking service.” There were no “internet companies.” The way to work on the best engineering challenges is to get comfortable with this process of discovery and incremental steps.
What do you love most about software engineering?
I got this idea for summing up software engineering from one of Grady Booch’s columns in IEEE Software. I can’t quote it exactly, but here is the basic idea, which encapsulates why I love this field.
Think of human language as a medium. When someone listens to what you say, or reads what you write, language is the medium used to convey thoughts that were in your head into the heads of your listeners and readers. Software is also like a medium. When a system executes the code that you’ve written, the software acts as a medium to convert the thoughts and concepts that were in your head into a kind of physical manifestation. In some ways it is similar to how a mechanical engineer can physically manifest a design as a working device, but with software, the relationship is a lot more direct. The mechanical engineer is more constrained by the limits of physical materials and manufacturing processes. An executing program more closely resembles animated concepts than a mechanical device.
That’s the poetic imagery of it. Every now and then you can pull back to appreciate the grand overview of what software engineering represents and just say, “Wow!” But the truth is that what makes me want to come into the office every day is not the abstract concept of what a beautiful thing software is; rather, what I love most about software engineering is the people that I get to work with. It’s not just that I work with nice people, which I do. It’s also about the mindset and culture. Writing code is a way to tell the computer what to do, but it’s simultaneously a way to communicate to our coworkers, future coworkers, and future selves what this code is supposed to do.
Because we spend much more time wrestling with code that has already been written than we do writing new code, we are constantly asking ourselves, “What was this person trying to do here?” Embarrassingly, sometimes the inscrutable code is something you yourself wrote six months ago. I’ve learned from other software engineers, therefore, to appreciate clarity and directness. When we collaborate and work together, we’re not just being nice (not that there’s anything wrong with being nice). I want my colleagues to understand my system, and I want to understand their system and their expectations, because that’s the only way our systems will work well together. We try to be transparent and helpful to each other because that’s what works. It’s also much better to work alongside people who you have some personal connection to and enjoy working with. I constantly learn new things from my colleagues and appreciate the conversations we have.
There’s a self-reinforcing cycle where we all benefit from understanding each other well without every decision or initiative requiring tickets to be filed, documents to be drafted, and approvals to be signed off on.