Sam Azouzi’s hackNY Summer of Good: Discovering best practices for nonprofit Tech Solutions
My Summer of Good
aflow introducing their problems and pain-points to the hackNY fellows.
This summer I was lucky to be a member of the 10th class of hackNY Fellows, a summer long community-building and internship program for computer science students. In recent years, the program has featured a Summer of Good where hackNY Fellows volunteer time outside their internships, partnering with a variety of non-profits to tackle engineering challenges. My social good team paired with aflow to build a messenger bot to make it easier for people to digest and understand current political bills. While we encountered some pretty cool technical challenges, the most rewarding part of this project was working with aflow to streamline software development and develop code sustainability practices.
We worked with aflow to set a scope for the project that would at least organize the development of software and other software-related tips to scale applications. I taught our point of contact (POC), Seth, how the development of software is organized in professional settings and how applications scale. At the time, there was only one person working on the bot. The bot was a big pain point to get up and running due to lack of documentation regarding how to set up the work environment. We also demonstrated the importance of frameworks that scale: Even if software doesn’t immediately reach thousands of people, it is always good to start with great infrastructure to sustain future growth.
Solving difficulties while giving value
Once we decided on how we wanted the infrastructure to look, our team of two focused on organizing development. We made documentation mandatory for each feature to be added. Documentation was not just one comment in the code describing what the feature did, but information regarding who oversaw that feature and what dependencies were necessary to run that feature. Other information included: lines of code this feature represented, what the feature did, etc. This gives better visibility on features and better experiences for new engineers joining the project.
In addition to documentation, we also setup Trello as a ticketing board. We defined categories of tickets (or features). Some examples of categories include: Blocked, Next Sprint, Working, etc. This gives engineers visibility on what is being done, and by whom, making our weekly meetings a lot smoother because we could focus on what was currently blocked by other features or other people, what was expected for that week, what we wanted to be working on for the next, and so forth.
Another valuable piece of information we supplied: How to get the development environment up and running. None of this information was being documented and a lot of digging had to be done by the engineers. The less setup engineers need to do, the more time they have to implement features. We documented how to setup the development environment, which will be very helpful for engineers that work on this project in the future.
What was actually implemented?
We did code a few things for the actual project in addition to all the work we put in for organization and infrastructure:
We implemented a feature that would allow users to be updated on bills for a certain time period, which is set by the user. For example, if the user wanted to be updated on a bill every week, we ran a piece of software that would check the current date and the date of the last update, check to see if there was a week difference, and promptly update the user.
We also redesigned the user document. Originally, the user had a list of bills which they had saved. To optimize the search of these bills we decided to make it a HashMap where the key was the topic of the bills. This gives us a nice logarithmic time complexity rather than linear for search.
We also helped modularize the code by separating functions and constants to files. For example, all authorization code was put into a separate file instead of the main app.py.
In conclusion…
We came out of the social good project with a very happy POC and a lot of knowledge about Messenger bots. It was a great experience, and it showed me how much I like teaching. I basically gave the POC 24/7 access to pick my brain about anything related to the project. As a result, he learned a lot and found the experience very valuable. Engineers can contribute substantially to non-profits and other organizations not just through the code they write but also through the implementation of sustainable project and workflow management. If your organization is a mission-driven org that could benefit from partnering with talented technologists next summer, or if you know a good cause or organization that might be a great hackNY partner, please let us know at info@hackNY.org!