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.
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?
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.
If you are reading this post on my blog you are one of the few. Currently most of my updates are posted to Facebook and I will tweet interesting things on twitter. I think the reason for this is that the state of the open web regressed after the death of Google Reader. When Google Reader was popular many people used it. They’d stumble upon an interesting blog, add it to their Google Reader, and when you posted an update the magic of RSS sent a swarm of subscribers to your blog. While RSS readers still exist I think that their usage is down overall. This has lead many blogs and online shops to resort to e-mail newsletters as their tool to keep people updated and engaged. Unfortuantely, the quality of my inbox has steadily declined as a result.
So this lead me to wonder what could make blogging useful again. The first thing would be for it to be easy to post to my blog the way it is from Facebook using the share tools on iOS and OS X, both of which I use frequently. The second would be for people to use RSS readers again, or for Facebook to integrate RSS into its newsfeed. Finally it would be great if my Facebook posts could automatically post to Jekyll if they met certain criteria.
Meanwhile I am on the hunt for a good iOS and OS X GitHub Pages/Jekyll client to change some habits since I do not know how long Facebook will last, but I can be fairly certain this blog will.
I am currently in the process of restructuring this website to make it look nicer, since I love playing with HTML and CSS, but also to make this a better portfolio pitstop. I have come to realize that a lot of blogging these days is seen and done on Facebook and so I have been posting my blog type posts there. I will probably still post here but am going to modify the site to better reflect the fact that when people land they’re likely just wondering who I am.