‘Looking For’ Application
Do Your Homework Before Taking on a Task.
This week we were tasked with working on a jobs board app as a team of developers. We were allowed to work on issues of our choice with little or no guidance. Per the instruction, I chose an open issue from the issues page in the repo and decided to go full steam ahead. Big mistake!
Make Sure You Read Carefully
I decided I would take on an open issue that, I thought, said AngelList API. And after skimming the description I decided the goal was to have a scraper that pulled in job postings from AngelList’s API. Turns out the title of the issue was “AngelList API ?” and what was asked of whoever took on this task was to look into the viability of using the API to add additional jobs to the board. If it was viable then the owner should take on the task of integrating the API with the app, if it wasn’t the reason should be documented and the issue should be closed so future collaborators won’t waste their time with it.
What Not To Do
Confident in my ability to work with API’s, I immediately started a new branch and began writing and executing the “Most Brilliant Plan Ever”. I figured I could finish this task in two days and go sip Mai Tai’s on the beach(community pool). After writing some excellent and well tested code I came to the realization that I should probably request access to the API so that I could pull in the data needed to add jobs to the board. After skimming AngelList’s API documentation, terms of service, and some other pages I probably didn’t read(see title of prior section), I applied for access to the API. While my request was being processed I continued to pump out my masterpiece of code that would add so many jobs to the board that I would, probably, single handedly end unemployment. As I was getting to a point that I absolutely needed to start actually pulling in data from the API I realized I should make sure I could register the authorization for the API to a Turing based email so it could be maintained upon my inevitable departure. This is where everything fell apart…
I reached out to the project lead to get clarification on how to proceed. This is where everything started to go downhill.
So upon carefully reading the terms of service I realized that not only could the API not be registered to Turing but that the terms of service prohibited users from “scraping and reposting job listings on your own job board”, the very thing we wanted to use the data for. To make matters even worse, the API admin responded by denying my request and also informing me that the endpoint I was interested in hitting would not yield the results I wanted anyway.
“Unfortunately, our /jobs endpoints have changed — we only let you pull jobs that you have access to edit via the API. ”
Basically, I could only add jobs to the job board that I posted on AngelList. Great, I don’t even have a job how am I supposed to be hiring?
After speaking with the project lead in person, she expressed that she was not surprised and she expected that not all the issues were viable for the app. Awesome.
So all the glorious and well tested code I had invested my time into was basically garbage at this point. Instead, I had to begrudgingly choose a new issue to implement with the limited amount of time remaining.
This is a cautionary tale for all new developers that will undoubtedly work in a collaborative environment.
- Make sure you carefully read and understand what a task calls for.
- Do research before starting on the task. Just because something is on a wish list does not always mean it is plausible.
- Document findings of research and next steps for future collaborators.
Sometimes getting results or completing a task seem like the most important thing in a collaborative project. But some of the most valuable input is information and documentation. Having enough of that will make any future progress or improvements to software that much easier to implement and can help give a project direction.
Before rushing head first into code, make sure you are prepared and the results will show.