Coming back to Mapzen has been incredibly fulfilling. Last summer I was an intern on the product team, where I got my first taste of maps and open source. I started as a complete stranger to the command line and I left with Git, React, and Docker in my toolbox.
This summer, I joined Pelias, the team behind Mapzen Search. Everything I learned last year made the learning curve less steep. Having worked with Node.js before, I had no trouble diving in and setting up a local instance of Pelias, complete with Elasticsearch, Libpostal and the API.
As a newcomer to the project, my fresh pair of eyes helped illuminate points of confusion in the documentation. For instance, I installed a version of Elasticsearch that Pelias does not support and wondered for a while why the schema could not be created. Once someone on the team was able to point me in the right direction, I watched the hundred of thousands records pour into Elasticsearch. From this first task, I uncovered that box on a map with a magnifying glass icon, and revealed five importers, three microservices, and hundreds of Node modules. I was in awe.
The more familiar I became with the Pelias API, the more I realized how many regional variations the geocoder text parser needed to consider. Depending on the country, the order of house number and street name varies, as do the order of the region and the zipcode. In some countries, such as Mexico, addresses include the neighborhood or settlement to distinguish streets of the same name but in different parts of the city. Some apartment complex buildings share the same address.
My second project was to create acceptance tests for international addresses. I drew examples from a list of US Embassy around the world and compared my expectations to the API results. Failing tests were valuable because they mark and push for better coverage. For instance, one class of issues is alternative names. We would love to search for “Serrano Street, Madrid” and get same point as “Calle de Serrano, Madrid”. However, right now we can only find street names in one language. Prior to joining Pelias, I took all this complexity for granted in a geocoder.
A new part of my workflow was formal code review. Every pull request was blocked from merging until someone on the team approved the changes. I liked this process quite a bit because I got frequent feedback on my code. In school, the feedback cycle is slow and there is no chance for revision. A code assignment could take two weeks to be graded. By then, I only have vague memories of what I did. Code reviews were also places where discussions sprouted and neatly documented. I could see what everyone else was working on and keep up to date with all the changes in the codebase. For an intern like me, every pull request I didn’t make was a chance to see how good code is written. My standard for writing unit tests came from looking at existing tests.
While a big part of a tech internship is strengthening programming skills, an equally great component is the social skills of team collaboration. Every day begins with a standup meeting, where each person updates the team on what they are working on. Because the Pelias team is semi-remote, this is an important time to connect and bring up questions that are hard to express in written words. I might share my screen and talk through code that I was stuck on or error logs I struggled to decipher. This practice helped me articulate code into words. Very often, I walk away with a good idea how to resolve my problem. Other times, someone may ask for support trying a new tool that another member has expertise on. During these sessions, I have picked up on techniques in asking and providing guidance, as well as generating productive discussion.
Thank you to Diana, Julian, Peter, and Stephen for taking me into the team. I have enjoyed every minute of being at Mapzen and I cannot quantify how much I’ve learned and grown.
