Speaker Spotlight: David Max
We're less than a week out from #NWD2018! Our final speaker spotlight is David Max, who will be sharing a lively tale of two systems in his talk on March 15.
Bio: David Max is a Senior Software Engineer at LinkedIn in New York City where he helps build software systems to connect the world’s professionals and create economic opportunity for every member of the global workforce. He earned his undergraduate degree in Computer Science from the California Institute of Technology, and has a Masters degree in Computer Science from New York University. He has previously worked at Google and in the financial technology field.
Topic: A Tale of Two Systems
Breakdown: In this tale, a software team attempts to build a new system to replace their old system that was failing because of its inability to scale. The system they end up building meets all their criteria for scaling, but they discover that it has broken other criteria in ways that they did not anticipate.
What this team did not take into account is that scalability is only one quality attribute of a system's architecture. Certain quality attributes tend to trade off against each other, so it is often impossible to change just one aspect of a system while expecting all the other attributes to stay the same.
This team could have avoided disaster if they had thought more about their system architecturally by making more explicit their goals and accounting for the ways the attributes they needed to change would trade off against the existing constraints their new system still needed to meet.
Read on to learn more about David, his interesting work with LinkedIn, and his dislike for makefiles.
What is your background in?
My background is in computer science. I started out as a software engineer for a company that made digital oscilloscopes, so I started out writing code in C and C++ on systems that ran almost on the bare metal working hand in hand with some of the electrical engineers who designed the chips.
I’ve spent my career working in technology around New York City. I worked for a few years in an internet startup, and then switched to working for some time as a software developer at various financial institutions. I worked at Google serving ads for publishers, and I started at LinkedIn in 2015.
Can you tell us about your work with LinkedIn? What does a day-to-day look like for you?
LinkedIn’s New York City office is located in the Empire State Building in midtown Manhattan. When I started there three years ago, we had about 25 engineers. That number has grown now to about 90.
I work in the content ingestion team. So, for example, whenever a member pastes a URL into the update box on LinkedIn, our service will go fetch that URL and extract data from the page so that the sharing system can pop up a panel with the title, thumbnail image, and link to the article.
On a typical day, we have a brief standup meeting to go over our current tasks, and we’ll spend most of the day coding, testing, reviewing code, engaging in design discussions, or meeting with stakeholders from other teams.
Can you describe how LinkedIn teams plan and release features? (processes, tools, stages, metrics, etc.)
Every quarter, we put together a list of projects that we want to do. They may be features we want to add, tech debt we want to pay down, or fulfilling requests for new features coming from other teams. We scope the work for each project and come up with the list of highest priority tasks that we can realistically accomplish.
For each two week sprint, we pick out each task to work on and figure out which one of us will work on it. Before we check our code in, we go through a code review process. Once code is checked in, it goes through a series of tests that validate the code, build a new release, test the release, etc. before the new version is rolled out to production.
What is something people would be surprised to know about you?
I am an avid fan of podcasts. They are my favorite thing to listen to while I’m commuting to work or otherwise engaged in some task where my mind is free, but maybe my eyes or hands are busy. Some of my favorites are Radiolab, Freakonomics Radio, Reply All, Science Vs, Hidden Brain, Masters of Scale, LinkedIn’s Work in Progress, and I could list several more that I like to regularly keep up to date on.
Do you any general tips for building and growing successful software teams?
As much as we emphasize aspects like technical skills, craftsmanship, and ownership, often the most important attribute of a successful software team comes down to human relationships. Project Aristotle at Google studied what makes teams effective. Team members need one another to get work done. They plan work, solve problems, make decisions, and review progress together. What they found was that how the team worked together was more significant than who was on the team.
What is your least favorite programming language?
I would have to say that my least favorite programming language is make, as in the build utility that processes makefiles. Every large project I have worked on that uses makefiles ended up with a tangled mess that one had to be very wary of touching.
You could load a file into your text editor, change nothing, save it to disk, and then have a broken makefile because, by the way, shell commands must be indented by a tab character instead of spaces, and your editor was in the mode that replaces tabs with spaces. Some parts of a makefile ignore whitespace, and in other parts, whitespace must be included.
All variables are global. Dependencies between files often have to be updated by hand. If they weren’t exactly right, sometimes you’d resort to cleaning before every build, or running make multiple times until it succeeds. There were multiple versions of make, and a change might work on Solaris, but break under Windows. Open source projects would suggest that you could download the latest source code and then just build by running make. Ha! Good luck!
Check out David's talk at Nowhere Developers Conference on March 15 in Bentonville!