Pair Programming is my favorite part of software development.
What makes it so great?
Two people working together on a single challenge get more done than two separate people working on separate challenges.
It is a fantastic exercise in communicating ideas and developing the team-skills that drive large projects.
It's just plain social! You learn so much and you have fun doing it. Each developer gets to share what they know and the whole process is much less cold, scary and in-human.
(I know, I know. Pairing is supposed to be a pair of devs, not three. But life happened. And besides, we made it work.)
Anyway, the challenge was small, but good for us. I had been working on a static map website for FullStackLA that listed and displayed all the local meetups our FullStackianados also like.
The site was built from the markdown of a GitHub issue, converted into HTML and Styled.
It still wasn't ready. The map data displayed the locations of LA's neighborhood councils, not our local meetups.
To do that, I made a googlesheet of the local meetups, their addresses and coordinates, and combined them with a script from Mapbox that ran on the googlesheet to convert it into a geoJSON file. I stuck that file in along side the original neighborhood council file. Changed the path in the JS to point at it and there you have it.
Except for one problem. That's where Tim and Casey come in.
The little dots show this when they're clicked on.
So the three of us sat down to solve the problem. How do we make
undefined become the meetup's name and address?
I explained that the reason this is happening is the way mapbox created the geoJSON file. It created a bare-bones file where each object only had values for the coordinates, not the name or address. So when the JS goes to search for the key, it doesn't find it. what JS returns when it can't find the thing is
Luckily, Tim happened to have spent a lot of time working with spreadsheets and JSON files. So we determined that what we needed was a one-time use script to take a .csv of our googlesheet, and use it to add the values to our geoJSON. Once we had our more fleshed-out geoJSON file, we could safely throw the script-scaffolding away. We'd have the functionality we wanted.
So this whole time Casey is in the driver's seat. He's learning about Git, gitHub, Clones, Commits, Pushes, Pull Requests, The Terminal, Vim and Atom. He already has a pretty good understanding of JS, but neither he nor I have written a script like this before. So Tim is navigating.
We're being slow and methodical. Casey writes a line of code, then we sanity test it. Once that's good, he writes the next line of code and sanity tests that. This is very good because of what happens next.
We get to say the third line of code where we use
JSON.parse() to get the data from our geoJSON file, and we all notice that there is an
id key with the value that has the name of the meetup.
It's not supposed to have a value like that. It shouldn't exist.
So we go back to the JS source and change the name of the key called from
id. And suddenly, our page has
undefined on it.
After some brief celebrating, we go back to the geoJSON file and discover that there is a key called
And then we realized that we could have saved ourselves a whole lot of trouble.
Had I not assumed the reason for
undefined was because no value was there, had we simply verified that assumption by opening up the geoJSON file in the first place, we would have seen the solution was a whole lot simpler than having to download a .csv and write a script to parse and include new keys.
In the end, all we needed to do was change the names in the JS to the new keys in the new geoJSON.
"Having the right name is like 40% of being a developer."
It was a fantastic session, anyway. learning happened, and productivity happened. We made a pull request and it was accepted. Casey learned about git, I learned about not making assumptions, and Tim learned not to blindly trust the documentation. (Me.)
"Trust, but verify."