Reading Time: 7 minutes

I have begun live streaming some of my development work on an open source React Native mobile application for The Zooniverse.

What is The Zooniverse?

This video provides an excellent explanation:

How do you write code for The Zooniverse?

Well, I happen to work with them, but all the code is open source…so you can contribute, too, if you like! That’s what we’ll be doing together in my live stream video today.

In this post, you’ll find:

1. An embedded (short) introductory video about my setup to work on the repo,
2. The embedded (long) video of the live stream,
3. A link to the commit on github that we write in the live stream, so you can review the code yourself,
4. And an outline of the topics we talk about in the live stream, with links to time stamps on the video.

Let’s get started.

Here’s the (10 minute) introductory video. I go over what the Zooniverse app does, and I show you my development and debugging setup in case you’d like to duplicate it or follow along with the live streams.*

*Now you know what I look and sound like without any makeup or coffee. This is a new level of intimacy for us. Lucky you!

Show Notes: Reactive Themes for React Native Components

In today’s live stream, we are working on museum mode for the Zooniverse mobile app.

This mode will tailor the user experience of our mobile app for use in museums, so exhibit designers can showcase a particular project for their guests to learn and participate. Museum exhibits tend to be dark places, so it would be jarring to have a white screen on the app. For this reason, we are implementing a dark mode that will activate when we know the project we are showing is being displayed in a museum.

This requires us to change several visual elements of the app based on a response to an API call. These changes must remain consistent across several different components, so we want to consolidate that logic rather than insert conditionals in every component.

We do that work in this live stream. In the next live stream, we’ll switch to the backend integration portion of developing this feature.

You can explore the code from this live stream!

Here is the full commit that we cover in this live stream, including the commit message and the full set of changes we made to the code. If you’d like to review or copy-paste any part of the code we wrote, you’ll find it here.

You can also get a transcript or closed captioning for this live stream.

In this post, I explain how you can get those things in one or two clicks on YouTube.

The Outline: What we cover in this live stream

6:28: The coding starts here.

15:30: Iterative commit messages: when and how do I make work-in progress (WIP) commits? What do I do with those commits when the WIP is finished?

22:28: Evaluating legacy code: I can tell the difference between a seasoned software professional and someone who is greener or more insecure with their own abilities based on how they evaluate legacy code. Here, I describe how pros do it, based on what they know about how software is written.

24:46: We start coding: Starting with a discussion of the value of consolidating logic. If you haven’t heard don’t repeat yourself (DRY) satisfactorily explained, this might help.

30:13-33:29: break

39:21: Import order: This is a stylistic thing on which programmers have different opinions. Here is my (loosely held) opinion.

40:47: Iterative function naming, part 1: We don’t always know exactly what to name something when we first create it. So we can give it an interim name and come back later when we have more information about what name might be appropriate.

46:11: Conditionals: These are my (again, loosely held) opinions on some options for expressing conditional logic.

51:43: Iterative function naming, part 2: In which we return to the naming question posed ten minutes earlier.

1:02:35: On when to DRY things up: This part explains how I decide when it’s time to de-duplicate code and begin thinking about generalized solutions. I discuss this in my technical talk on refactoring, so now you can see that logic in action.

1:04:56: Debugging example: Here, we encounter an error, and we need to figure out where it’s coming from. I believe this is an extremely useful thing for programmers to learn to do and to see other programmers doing, and I think that creating more resources around debugging and troubleshooting can help the programming community :).

1:12:41: Debugging strategy: So first you see me track down an error, and then I explain my high level strategy for doing that.

1:22:50: Making values explicit: This is another stylistic thing on which programmers have different opinions. Here is my (loosely held) opinion.

1:34:11 break

1:48:59: We see a benefit from the decision we made 45 minutes earlier at “On when to DRY things up.”

1:56:06: Difference between component types in React Native: we convert a fat arrow function component to a class based component.

2:02:46: Preparing to refactor: We make the code work, then we list out the things we would like to fix, and we commit before we start fixing so we can return to a working state if needed.

2:20:31: Exploring the Apple Human Interface Guidelines: The HIG is an excellent resource for iOS developers, as well as for folks learning about interface design for touchscreen devices.

2:24:13: We start refactoring.

2:28:36: Whoops. I want to highlight this moment for developers who have felt inadequate while learning a language or framework. This is the part of the video where I manage to take fourteen minutes (up until right here) to discover that my method doesn’t work because…I did not include an explicit return statement.

I want you to know that I make mistakes. I want you to know, the next time you make a mistake, that it happens to all of us. I have seen this (or something like this) happen to every developer I have paired with, including the most seasoned witches and wizards I know.

Mistakes don’t mean you can’t write code; they mean you’re just like the rest of us 😂.

2:46:02: Wrap-up and recap of our refactoring

2:48:57: Wrap up last commit (including a live interactive rebase for you to watch)

2:58:11: Pushing to GitHub and creating the Pull Request: In which you can see the process that our team uses to work on code together.

Top Takeaways:

Three things that other people have told me they found valuable about watching this session:

1. Folks enjoyed seeing me debug slowly while explaining what I’m trying to learn at each debugging step. Later in the video we debug again, but faster, and having done it slowly the first time helped folks follow my thought process the second time.
2. Our discussion about evaluating legacy code resonated with many developers who have worked extensively on teams of engineers.
3. People liked seeing me mess up. Don’t worry; I’m sure there are many more mess-ups where that came from ;P

That’s it for this session, y’all. See you soon!

If you liked this piece, you might also like:

This post on my entree into live coding (plus, how to get a transcript of a YouTube video)

The series on reducing job interview anxiety—no relation to this post, but people seem to like this series.

This talk about the technology and psychology of refactoring—in which you’ll hear me explain some of what you see me do when I code!