Welcome to Still Computing #3!

Still Computing is an email newsletter for curious programmers, largely written by members of the Recurse Center community.

This week’s issue focuses on personal data and how it’s collected, used, and analyzed. Our feature piece is by Aliza Aufrichtig, who built her own period tracking software after becoming dissatisfied with existing apps due to their data usage and export policies. We also have a creative programming contest(!) and a lively Dear Zu in response to a reader’s question about the responsibility programmers have to the rest of society.

We at RC have a complex relationship with online tracking. Recently, we’ve tried not to use it. For example, this newsletter isn’t tracking you! We disabled all open and click tracking before we sent the first issue. However, we do use Google Analytics and store data about page views on recurse.com, some of which is really helpful to us in understanding how people use our website. Most websites would be hard to operate and improve without *some* kind of analytics data, but where does it cross the line into being creepy or a violation of privacy?

It’s a tough question. In this issue, some Recursers grapple with the implications and share their reflections as they work to figure it out.

- James

I created a full-featured period tracking app using Google Sheets, Calendars, Forms, and Apps Script. Dissatisfied with existing period app options after using them for more than ten years, and wanting easy access to my data, I decided to make my own. The tracker includes all the features I used with my prior tracking app. I can:

• Easily record period days, flow, and any symptoms
• See past period dates and trends
• Anticipate upcoming periods and fertile days
• Get email alerts (for myself or anyone else)
• See past and future periods and fertile days on my Google Calendar

Crucially, I can also:

• Own and access the raw data
• Customize the tracker in any way I'd like

And you can too! If you want to get right to it, see my period tracker app. For some background, read on.

I've been tracking my period for 21 years.

Tracker v1: Ever so discreetly marking tiny baby blue gel pen circles on the wall calendar in my childhood bedroom so that nobody would notice, because gosh, that would just be humiliating.

Tracker v2: Birth control pills. The pill packs took care of the tracking themselves. I loved those little sticker strips with the days of the week that came with pill packs and I put them all over my dormitory walls.

Tracker v3: I stopped using birth control pills in 2009, about the same time I got my first iPhone. It was also a time when I thought a genuinely fun activity was to just search around for some cool apps, so I downloaded a popular iPhone period tracking app of that time.

It was useful: you could easily enter period flow and symptoms, see period days in a calendar, get predictions for future periods, and be alerted when yours was coming. (You can see screenshots from a 2009 article featuring its bubbly pre-Material design.)

And I kept using it. The generally decent UX and functionality remained the same for ten years. It wasn't stylish, but it was dependable.

Then, in late 2018, the app makers released an innocuous-looking update that changed the entire user experience, caused users to lose data, and began charging a subscription fee for existing services that had been free. Take a look at recent reviews to see scores of long-term customers utterly devastated.

I was horrified to find that ten years of precious health data were just gone. A few minutes into freaking out, I realized that I had backed up my phone a few days before. I decided to try restoring my entire phone from a backup. Miraculously, the backup included the old version of the app with my old data intact. Phew!

Until a few months ago, I was still using the old version of that app, very very carefully making sure to never click "Update all apps." Kind of silly.

I was perpetually nervous about losing the data again. See, it's critical for me to track this data, as I have a history of menstrual issues. Starting in 2013, I started having very long periods, but it was one of those things that just slowly gets worse and worse and you don't remember that things haven't always been bad.

While at the Recurse Center in 2016, while reading a basic D3 bar chart tutorial, I thought, "huh, maybe I can use my period data to try this out." I managed to download my data from iPeriod (and had to pay them $2 to download it!), and after cleaning up the messy data export, I created some charts. Not great charts from a data visualization perspective, but revelatory charts. I sent screenshots of them that day in this email to my now-husband.

Doing my own very simple data visualization, I was able to see that my periods had actually gotten markedly worse from how they used to be. Note the chart title: "Quantifying Misery."

I showed these charts to my doctor. A few months later, I had surgery to remove the fibroids that it turned out were causing this problem. And things got way better.

So, yeah, this data is important to me.

In addition to the trends, I really like knowing when my period is likely going to come. It helps me roughly plan not to be running a race or planning a beach trip on a day I might have bad cramps.

And the thought kept popping into my head: "Aliza, this is silly. You know how to work with data and build little apps. You do this on a daily basis. Why not just build your own period app? Why are you using this sketchy old app that you can't ever update again?"

First I considered writing a Node app, which I do frequently. But I thought it was very likely that I would lose the desire to maintain it, and I'd still need the data, and probably end up just exporting it to a spreadsheet. Then I'd be back at square one.

Then I thought, why not try an app that came out after 2009? I downloaded a few apps that were top rated. These were their opening screens.

I was turned off by something about each one. For Flo, it was the long bulleted list of data I was agreeing to share. Clue wouldn't let me explore the app without signing up or giving it access to one of my important accounts. And finally, chatting with an emoji-wielding chat bot on Period Tracker Period Calendar did not personally instill confidence. The main thing I wanted to know was: can I easily (and freely) download my data to a spreadsheet?

And then it hit me! Rather than being so concerned about being able to export this data to a spreadsheet, the app could just be a spreadsheet.

So that's what I did (and what you can do, too). It took some time to settle on the correct format for the data. To get the auto-updating and presentation I wanted, I was wading amongst some real spreadsheet formula deep cuts like ADDRESS and INDIRECT. I am both proud and somewhat confused by the formula I made that generates tiny bar charts:

=IFERROR(SPARKLINE(INDIRECT(ADDRESS(MATCH(A13,data_by_date!A:A,0),2, 1,TRUE,"data_by_date")):INDIRECT(ADDRESS(MATCH(IF(A14, A14 - 1, A13 + $T$9),data_by_date!A:A,0),2, 1,TRUE,"data_by_date")), {"charttype","column"; "empty","zero"; "nan", "convert"; "color", "#f4cccc"; "lowcolor", "#ea9999"; "highcolor", "#e06666"}),"")

I had only used Apps Script once before for a small work purpose, but was pleased by how well-documented and easy it was to use it to integrate sheets with email and calendars. I did spam myself relentlessly with emails and calendar events in the process, but I've worked that out by now.

After user testing this on myself for a few months and making revisions each month, I've very happily replaced my old, broken app. My tracker allows me to easily enter my period data, view past periods and trends, and see projections for upcoming ones. Which are all the things I wanted from my old app. (To be clear, I make no claims to any sort of medical expertise or accuracy or prediction. Questions? Ask your doctor!)

Here's why I think spreadsheets are great for this sort of thing:

• The data is right there! Once you determine how you want to record data, it is easy to transform it into any shape you need for analysis and visualization. And if you don't like how you're recording it, you can easily change your approach.
• The formulas are right there! There is no hidden code and you can see exactly how everything is working. So if you don't like the way I'm calculating something, you can just change it! And the formulas are truly reactive: whenever you enter new data, they just run and update, which is very useful for projections.
• More people can run their own app! Far more people can use and maintain a spreadsheet than host and maintain their own Node app. And I think it's great if more people are in control of their own data.
• More people could customize the app to their own needs. This was built for what I wanted: period records and projections. But you could add tracking for weight, skin, mood, favorite song, whatever. Or more excitingly, change it in some other way I haven't thought of.

It's tracking without the tracking! Well... except that I'm making heavy use of the Google ecosystem. But that ecosystem is something I use for so many purposes every day that I was comfortable storing my data there. If you're not comfortable with that, I sort of got the app to work in Excel, and I'm sure with some tweaking it could run on more open spreadsheet software. By using Google, I was able to get a few built-in benefits:

• Sharing. You can share your period data with people who might be interested. (Friends, lovers, etc.)
• I could use Apps Script to easily integrate my period data with my email and Google calendar, two tools I use dozens of times per day.
• I could bookmark a linked form to easily enter additional data from my phone.
• Built-in version control. If I mess something up in the sheets, I can go back.

To be fair, there are a few downsides to my approach:

• If I make improvements and changes to the app, it will be potentially harder for other people to update their spreadsheets accordingly.
• Formula-laden spreadsheets can be very sensitive: one bad cell entry can mess up a lot of things.
• You are more limited in the sorts of functions you can write, and the functions can get complicated and hard to read pretty fast.

I have to say, writing complicated spreadsheet formulas gets me back to my coding roots. I first became interested in programming when, after writing increasingly complicated Excel formulas to support the company I was working at, someone suggested I try learning SQL. And then once I got fluent in SQL, they said… try Python… And you all probably know how this goes…

And after the last four or so years of fighting with JavaScript builds and Python versions, I realized I'd developed a deep appreciation for the elegance of spreadsheets.

Create your own period tracker here!

Dear Zu is an advice column where anyone can pose a question to our community and get a taste of what it’s like to participate in RC. You submit questions (about code, tools, systems, jobs, or anything related to life as a programmer), we put them on Zulip, our internal chat system, and then we publish some of the most interesting responses from our community of over 1700 really nice programmers in these letters!

This week, niftynei asks via Twitter:

As programmers, what responsibility do we have to the larger, non-programming society?

In the ensuing conversation, Recursers debated the merits of ‘co-design’ as a framework, what recent trends in automation have to do with the Industrial Revolution, and whether programmers have special responsibilities as programmers beyond our general ethics as human beings.

Wesley: I heard the phrase "the right to co-design computer systems" a few days ago in the !!con West keynote by Erin Glass, and that really struck a chord with me. This was in the context of employees of a company that was adopting a computer system for some information that had previously been on paper. I think that one important thing is making sure that people who will be affected by the systems you design have the power to shape what those systems look like.

Concretely, I've been thinking about this in the context of writing tools at work to help people who do repairs in our data centers work more effectively. Step one of that was visiting one of our data centers and asking the techs there what problems they had that they would like better tools for.

I still have a lot more to think through here, especially around how automation and surveillance are so often tied together, but I think that at the very least, we have an obligation to involve people affected by code (and not just users of the code) in the design of software systems.

Lea: I have some nebulous feels about "co-design," which is increasingly a vehicle of ethics-washing -- e.g. Shannon Mattern's thoughts about the way "participatory design" is used as a PR tactic by Sidewalk Labs

Wesley: Yeah, definitely. It seems to me that it's more useful as a way of guiding design if you have good intentions but want to make sure that you aren't accidentally or carelessly building systems that will hurt people, and less as a benchmark for whether a design process is "good" or not.

Perhaps using the phrase "co-designing" even for yourself is allowing it to be used as a tool to ethics-wash. I found it to be a useful concept, but I definitely think that it's important to think about how to relate to concepts like this, to make it more difficult to successfully use them as PR tools.

Anonymous: The immense wealth that the tech industry generates by automating jobs needs to be shared with everyone, starting from the less privileged up. Find ways that the computer revolution actually benefits those who need it the most instead of wage-slaving them into poverty.

The 40-hour week is an arbitrary number, and the reduction to 8 hours a day was born out of the working class's desire to take for themselves a slice of the immense productivity gains of the Industrial Revolution. It cost the lives, blood, sweat, and tears of many workers to limit the work day to 8 hours. That was in the 19th century! Before that, according to Wikipedia, work days typically ranged 10 to 16 hours, 6 days a week. Child labour was also extremely common, including in the deadliest, most harrowing conditions like mining work.

Why aren't we fighting for a 25 hour work week, a century later? This was the promise of the century of automation. If software is the next revolution, it's our duty as one of the classes that benefits the most from it to try and share the benefits as much as possible with the rest of society.

Aditya: <rant>

Our responsibility is to actively promote the idea that software is NOT eating the world, nor must it be allowed to "eat" the world.

I think we're in the midst of an antibiotics-and-painkillers-level over-prescription of Computers for All That Ails Humanity.

We are using computer systems to "solve" "problems" that are better solved by figuring out how to relate to each other at a human level inter-personally, inter-group/team-ly, inter-state-ly, internationally, and intra-personally -- by law, by culture, by market systems, by various treaties and protocols etc...

Examples of domains/situations where it is not working as hoped (or advertised):

• Systemic fraud. Well, a tag-em-bag-em national ID system isn't going to solve it.
• Loneliness/Camaraderie. Well, the social network cuts both ways and actually brings out the worst of humanity as a collective.
• Discontent in the workplace. Well, forcing people to take bi-weekly "happiness surveys" ain't gonna fix it.
• Poverty. Well, pushing digital payments is going to make it worse for the most at risk and also centralize risk for nations.
• All of the Above, and Literally Everything Else. Well, the blockchain. Ah, maybe we have the ultimate solution.

The efficacy or meaningfulness of software-engineered responses to problems we experience when navigating these various domains fundamentally depends on the quality of the human systems of the domain itself.

This is especially evident when we put code in the path of public services. For then, code becomes law: brilliant in an egalitarian society populated by responsive system maintainers and kind laws, but a weapon of mass incarceration in the hands of the powerful who can take away your freedoms at the touch of a button (see China's and India's respective national ID systems).

Computer systems appear to foster economies of scale of unprecedented proportions, and lead us to marketplaces with power-law distribution of winners and everybody else. Search, browsers, mobile operating systems, e-commerce, banking, payment systems, ERP systems, etc.

The IT/computing field is young and we have jumped headlong into depths of which we know nothing. Perhaps this is the way of the world: accelerating along the inevitable, inexorable arrow of progress, now set afire by code.

We who can see a little better, through the smoke (and mirrors?) need to help others see better too.

</rant>

Christopher: I don't think that, as programmers, we have a responsibility different than we would if we were cooks, gardeners, comedians, or any other sort of niche interest. We share the baseline burden of being kind and welcoming to our hobby and being open to teaching others, but I don't think that programmers owe anything to anybody else.

However, the more specific case of software engineering I think comes with some specific baggage, as it is a professional compact. To crib from RFC2119:

• We MUST be transparent in how our software works and the limits of its design (and thus, our own knowledge).
• We MUST seek informed consent from the people who are on the receiving end of our software wherever possible.
• We MUST welcome people into the field and give them at least as much support as we had when we started.
• We MUST treat our coworkers, employers, and clients with respect and act professionally when making estimates or contracts.
• We MUST abide by all applicable laws in applications and code we deliver.
• We SHOULD refuse to develop software that causes harm.
• We SHOULD attempt to judge each other solely on the basis of quality of work and professionalism.
• We SHOULD discourage inefficient practices that create waste or consume excessive resources.
• We SHOULD NOT pursue policies or practices that would lower our economic status.
• We MAY refuse to work on software that disagrees with our politics.
• We MAY aggressively recruit others to our field, since it's some of the easiest and best-paying work at the moment.

An incomplete list, but a start.

Joe: As programmers, whether we understand it or not, we occupy a powerful and privileged position. At the very least, we should recognize our place and power within it, because one of the main uses of our work is to automate and amplify the reach of human will.

We should think hard about what's being asked of us. We should consider the second and third order externalities. If one of the implications of our work is that exponential gains will accrue to us or our employers, who or what is receiving logarithmic returns for the work they're doing? Who benefits most from the fruits of our labor? Should they?

Everything after that is negotiable, but those are the table stakes for ethical participation in the industry.

Kalli: Not sure if this has been said already, but I wanted to add that we should not forget how young this field is, in the context of human history - and be humble with our intentions. Helps put things into perspective.

Suggested reading from the thread:

• On Design Thinking by Maggie Gram
• Ruined by Design by Mike Monteiro
• Post-It Note City by Shannon Mattern

Have a question for Dear Zu? Send it to us at stillcomputing@recurse.com.

This issue, we’re having a programming contest! Here’s how it will work:

Write a program that prints or displays the words `Never Graduate!` (“Never Graduate” is RC’s motto, a nod to our belief that learning is a lifelong process.) For example, you could submit the following Python program:

print "Never Graduate!"

and that would be a perfectly good entry. However, we encourage you to achieve this task in the most creative, inventive, or unusual way you can. Try using a language you’ve never used before, obfuscating your code, rendering the letters in 3D, scraping them from the web, or something else entirely! Bonus points if your code contains a pun, is self-referential, or is particularly clever or elegant.

Send your submission to stillcomputing@recurse.com by 5pm ET on Thursday, April 9th. The winner will have their submission featured in the next issue and receive a $25 gift card to their favorite local business. If your program requires an unusual programming language or environment to run, please also send us a video or other demo of it working.