Ever since I returned to academia for my PhD, I have jokingly referred to myself as a "recovering tech bro." I say that to people for laughs, but I'm still a dev at heart. My research is purely computational, so I use the same set of skills and tools, only in a different domain.
One of the benefits of writing software or building models in a place like academia is that I rarely have to think about scale. Before academia, "scale" was a word I heard regularly. How do we take a product and serve it to a billion people? How do we handle the load of a million concurrent users? These are the types of questions you're trained to ask and answer. In fact, your ability to think this way reflects your knowledge of good software and system design patterns.
In the last few years, I have enjoyed the process of making software that can be classified as "hyperlocal software," i.e., software that is local to a group of people and will only be used by them. This type of software only has meaning and utility within the context of small and local groups. Clay Shirky also defined this as "situated software" in 2004.
When you create this type of software, you already know who your users will be. There's usually no ambiguity about their demographics or knowledge level. It means you're mostly confident about what they want and how they want it.
I'll illustrate with two examples to give you a sense of what I'm talking about.
- 1. In my first year in the US, my roommates and I usually bought groceries and house supplies in bulk. We had very long itemized receipts, which took time to split. My roommate had to identify who co-bought items and split the price among paying parties. I saw a need to make this process easier and wrote software that divides the price of each item and eventually calculates a sum for each person. The interface had our initials next to an item amount, so my roommate could click on it to indicate that person X was (co)paying for an item. This software was designed to be used by three people living together and was heavily customized to our particular use case.
2. I made a website that collates and displays information about all the campus events that have free food for the current day (daily news but for food). I wanted something that could easily show me events within walking distance if I was hungry on campus. It does an API query on the university events backend with specific filters for selecting events for the current day and strict criteria that there will be free food. This website is hyperlocal since the core user base is UNC students looking for free food nearby.
In both examples, the software serves different types of local groups and audiences and was made for a specific purpose. Aside from the fact that I don't have to worry about scale, making these tools is also a lot of fun. Their design process is not rigorous since the people who will use them are obvious. If there are bugs or any concerns, the user can text me and it will be fixed immediately.
As you might expect, maintaining this type of software is also low-stakes. Good software is maintained, and maintenance is a display of love. I think the process of creating this type of software is akin to writing a letter or knitting a sweater for a lover or friend. People who will use your software are members of your community, so you must create it with care, just as you would any other piece of art.
The fact that a piece of software wouldn't scale doesn't mean it's not worth creating. I believe those with the ability should create software that has utility for themselves and their local communities. You create software that is local, fun, private, and free of commercial exploitation. Software can be like "a home-cooked meal" and something inherently personal.
Powered by Froala Editor