What I Learned from Forbidden Research

Earlier this week I had the privilege of attending the Forbidden Research conference with others from Berkman Klein. There the speakers posed the question of “[h]ow can we most effectively harness responsible, ethical disobedience aimed at challenging the norms, rules, or laws that sustain society’s injustices?” This was explored both through panel discussions and also some announcements that were made at the conference. At the end of the conference I felt refreshed and motivated.

The panel that most resonated with me was the panel about the hacks at MIT. There they discussed the process and rules that MIT and its students follow in relation to the famous hacks that involve placing objects on top of the MIT dome. That panel helped me understand that while the students were breaking the rules, there were still a set of norms that governed that rule breaking. Both them and the administration understood it was something that happens and that the students would endeavor to conduct their activities in a responsible and ethical manner despite the fact it was not allowed.

The biggest takeaway I got from the panel is that often it is better to be proactive in reaching out to enforcement agencies than to have egos clash in public later. The other big takeaway is that breaking the rules is often fine if it works, but you can quickly be disavowed if it fails. I think it is fairly evident that we do not have enough space and room for people to experiment and fail in this world, and while I appreciate the idea of the prize that was presented at the conference, I think another good action item would have been to spend time figuring out how we can create more spaces for rule breakers to fail safely and ethically.

Delegation versus Just Doing It

One of the things that I consistently struggle with when I run organizations is deciding when to delegate something versus when to do it myself. A well functioning organization should have lots of people in it that can split the work and get things done without large amounts of intervention. However getting an organization to a point where it is well functioning is a challenge. In a well functioning organization people need the authority, time, and ability to get things done. When new people join an organization they often are still learning how things work. There is a cost to on boarding on both ends.

In my civic technology projects I have two kinds of delegation. The first kind is for all the members of the team that visit every week. I can give one of them a high level task and they know both the history of the project and are able and willing to learn what they need to complete the task. Since they have been there every week I trust them to do it. The other kind of task, which takes more work to put together, are tightly specified micro-tasks designed to allow a coder to participate for the one session they are present. These tasks can take more work to put together. While it might feel like its worth just writing the code once I am done, not doing these tasks saves me real time and provides an opportunity for new community members to engage with the project in a meaningful way.

As a software developer that is now fairly talented at what I do, it is tempting to just write the software I want to create. Removing the management overhead of working on a group project feels like it would make things work faster, and in many ways it would. However the goal of a successful project is not just to have functioning software but to have a functioning community around that software. Communities are resilient and will patch bugs and keep your software up to date. Communities bring more perspective to the project and can take it in directions you did not consider by bringing in new and fresh perspective. In the short term delegation may not feel or be worthwhile, but I believe it is worthwhile in the long term.

What is Automated Software Testing

One of my goals when I started my fellowship at the Berkman Center for Internet and Society was to incorporate auotmated software testing into my workflow. Sections on automated software testing are included in popular tomes like the Rails Tutorial but these tutorials also will suggest that you can skip learning about testing. Many people often do. I think the main reasons people skip testing is that it is a second programming language to learn, and its purpose is not well explained.

If your software is a book of math problems, your tests are the answers at the back of the book. Testing frameworks like RSpec provide a language to describe what your software should do, and also are a way of making sure that it in fact does those things. While automated tests are not a complete replacement for human testing of software, they provide a general sense of what is and is not working in your software by pretending to be a person that uses that software. This can save time when manually testing software would be tedious; for example an automated test can load your site 300 times really quickly to test a rate limiter.

Testing is not without pitfalls. Sometimes a feature will work while testing of that feature fails. This can be due to a mismatch between your understanding of how your testing framework is doing something and how you do it in the real world. It can also be a bug in how the testing framework is executing the steps. Some people will write lots of tests for a model or program and then want to make changes. Extra work is created since for each change the tests also need to be updated to accomodate the change. The upside is tests will force you to be more deliberate in considering how your code works, but the downside is the cost of change increases. That is likely why many developers do not regularly write tests.

Ultimately learning to write tests has benefitted my code and also makes it easier to be confident when integrating changes from others into codebases I maintain. I am not religious about creating tests for every single change, but I believe that having a test suite and including tests with bug fixes is a good practice to prevent regressions and help others understand your program.

Involving Non-Developers in Civic Technology Projects

One of the largest challenges that I think civic technology projects face is involving non-developers. Every single week that I attend Code for Boston I often see groups crying out for people that are not developers to join and help them. There are a lot of skills and areas that developers are quite happy to disclaim or delegate, but actually engaging non-developers to do these things is difficult. I think it is important to talk about these roles and how we can better engage non-developers because it has the potential to help us build more inclusive innovations and engage communities outside the usual groups we work with.

The first important role is that of project manager. While many times developers serve as project managers, there is an advantage to having a non-technical person serve as the owner and manager of the project. A project manager may have subject matter expertise that the developers lack and thus have a better sense of what goals are important to the project. Sometimes developers struggle to translate real world problems into concrete coding tasks, and a skilled project manager can help their developers with this. A skilled project manager can also spend time managing relationships and expectations with project partners and external parties. Finally a good project manager can spend time bringing new team members up to speed and helping those that are struggling. A skilled project manager can make a big difference in the progress of a group.

The second important role is that of a designer. Many developers specifically disclaim the field of design, which includes creating logos, finding or taking photos, and figuring out what your interface looks like and how it should work. When I had a designer spend a couple weeks with the project I was working at Code for Boston it felt like we made more progress in that month than we had in the previous three combined. While there are templates and other ways for developers to get around the lack of a designer, having one can make a project look more professional and help the team see possibilities they otherwise would not consider.

The third important role is that of a content creator. Many projects have components that involve writing copy and doing research to make sure that copy is accurate. The content creator does not always need subject matter expertise, just the ability to research an area and potentially conduct interviews to generate content that is correct and also easy to understand. In the current project I am working for at Code for Boston, it would be beneficial to have a content creator be in charge of the feature that provides users with energy saving tips. Finding new tips, making sure the tips are accurate, and also removing the unpopular tips could lead to a more successful app.

A civic technology project cannot succeed with geeks alone. We need leaders, artists, and poets. Yet this is only the tip of the iceberg. Many civic technology projects have privacy and policy implications that could benefit from the input and help of lawyers. Community organizers, marketers, and data scientists can make the difference between a project that gathers dust and one that catches fire with the public. There is so much that needs to be done and so many projects lack the volunteers that do these things.

How can we better engage with poets and organizers and teach them enough about our technical ways so they want to participate in these projects? What sorts of barriers exist in civic technology projects that make them less appealing to people with these skill sets? Finally how can we make sure that the contributions of these individuals are just as recognized and valued as those that the developers make?

Being Reflective on Programming and Civic Hacking

One of the lessons that I am learning from the other fellows at the Berkman Center for Internet and Society is that in addition to spending time learning it is also important to be reflective. People like Nathan Matias and Jason Griffey do a great job of documenting their work on their blogs. I like the style they both use and I will endeavor to emulate it, but also sprinkle in my own personality.

Why is it important to be reflective? I think that in the academic world we spend a lot of time ingesting lots of information and it is easy to let that information pass us by without synthesizing and internalizing it. Second I believe that many people are probably tackling problems similar to the ones that I am tackling and by putting out what I learn and think, I might be able to help them or they might be able to help me.

Finally I think a blog is a better place to put reflective writing than Facebook because Facebook posts are not easily searched. If I wonder what I thought the solution is to a particular problem a year ago, I am less likely to be able to find it in Facebook than in my blog. Also by being searchable in Google other people who are interested in the same subjects as me will be able to find these posts and comment on them.

Given that most of my independent work over the past year has involved improving my software development skills and leading and mentoring new developers at Code for Boston’s Hack Nights, many of my future posts are going to focus on the lessons I have learned while leading the development of EnerSave, and working on the Lumen Database.

Follow Zagaja.com posts: RSS Feed
This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.