A Guide to Learning Anything in Two Weeks

How can I effectively learn about topics of interest in an unstructured environment?

Why independent learning?

My background is in computer science and tech, having worked at various startup companies in Silicon Valley. Before that foray, I was a research assistant in neuroscience labs.

Over the past year, I began to take a harder look at my interests and why I pursue them. I have been immersed in the tech startup culture for the past five years and increasingly pursued activities out of extrinsic motivation rather than out of thoughtful deliberation.

At times, it felt like there was an increasing chasm between work that I was getting paid to complete and the activities that piqued my natural curiosities. I wanted them to be the same. This exercise is based around the idea of re-aligning my interests in a way that bridges that gap.

Even though the freedom to structure how we learn is gratifying, it can still be difficult to navigate without accountability. It can be easy to have the learning goals for ourselves fall by the wayside when life gets in the way. Thinking about these potential pitfalls, I created a framework to maximize my time and hold myself accountable.

This will be the first post in a series about how I approached my learning framework.

Photo credit to iStock

Sprint outlining

I brainstormed the following topics to either dive into or brush up on: neuroscience, venture capital, artificial intelligence, writing and the media industry, open source software, civic innovation, Chinese tech, traveling, and cryptocurrencies and blockchain.

I narrowed the field to five topics: open source software, artificial intelligence, Chinese tech, cryptocurrencies and blockchain, and civic innovation. I removed the four that I did not see myself potentially making a larger commitment to in the near future. The goal was to learn as much as I could in two weeks while also completing an optional mini deliverable. Afterwards, I would be able to build upon what I learned and take a next step towards a path that felt compelling.

In software product development, the practice of sprints is commonly used to develop a feature quickly. It is a time boxed effort that begins with planning to identify the work to be completed, a daily check in, and a review at the end with the goal of a working feature or product completed. This concept was my inspiration for how to learn about these subjects and to document what I had learned.

For each topic, I wrote down the following:

1. Why the topic interests me
2. What the key organizations are
3. Who to reach out to or learn more about
4. What questions to answer
5. What deliverable(s), if necessary, to complete
6. How to spend my weeks

After outlining the sprint, I then executed for the next two weeks to be able to answer the key areas I addressed.

An example of a sprint

To elaborate more on this process, I’ve provided an example of my first sprint on open source software.

As a software engineer, I felt an obligation to learn more about and contribute to open source software because of how essential it has been to digital infrastructure and to many of my projects. I had never contributed to any open source projects before, so I was not sure where to begin.

When my previous company, Stripe, hosted an Open Source Retreat, I got to know a few of the individuals who were selected to work at the office on their own open source projects. These grantees worked on projects ranging from OpenMRS, a healthcare delivery platform for developing countries, to Belle, a configurable component library for React.

Through looking back on my conversations with them, I began to think of how to approach this sprint. I decided to make this a weeklong sprint instead of two weeks because my goal was to simply contribute to a project.

The first step was to outline key questions I had about open source software.

• What are the big organizations and conferences around open source?
• What are the processes/plumbing around open source projects on Github?
• How does one get started in open source development?
• What are the major project categories for open source development?
• How did the concept of free open source software get introduced instead of trying to charge for it?
• What are currently the biggest open source projects?

These were the top of mind questions based on what I had been exposed to over the past few years. I hoped to be able to answer them by the end of the sprint.

Next, I made a starter list of some individuals to learn more about. I read about them through some initial research and added more to the list as the week progressed. My friend Blake, a prolific open source developer, also offered to guide me through the week.

Guide during the sprint:

• Blake (friend)

Met or had conversations with:

• Xavier (founder of OpenCollective)
• Pascal (OpenMRS)

Individuals to learn more about:

• Nadia Eghbal (wrote open source paper at Github)
• Ethan Zuckerman (MIT Center for Civic Media)
• Eric Holscher (creator of Read the Docs, which hosts software documentation)
• Andrey Petrov (creator of popular Python library urllib3)
• Sayan Chowdhury (how to get started guide)
• [Other major open source contributors]

I created an initial list of key organizations as well that I had come across. I didn’t end up researching all of these organizations extensively, but they were good to have in the back of my mind.

• Linux Foundation’s Core Infrastructure Initiative
• Mozilla’s Open Source Support (MOSS) program
• OpenSSL Software Foundation (OSF)
• Open Source Initiative
• OpenCollective
• Internet Engineering Task Force
• World Wide Web Consortium
• RubyGems (hosts various Ruby libraries)
• Ruby Together (organization formed to help pay for maintenance and development of Ruby infrastructure)
• Bountysource (find and post bounties with monetary rewards)
• Red Hat (open source business model that offers services to businesses that use Linux)
• Salt (a platform by Bountysource dedicated to crowdfunding open source projects)
• Patreon and Gratipay (pledging small amounts of recurring revenue)
• Software Freedom Conservancy
• Apache Software Foundation

Lastly, I wrote down the deliverables to have completed by the end.

• Contribute code to an open source project
• Have a write up of what I’ve learned

For the first few days, I read extensively, drawing on the lists I created to help find information. This was interspersed with discussions about OpenCollective, the general open source community, and what it’s like to be an open source developer.

A few of the readings, articles, and publications:

• Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure by Nadia Eghbal
• What is open source? by opensource.com and RedHat
• What is open source software, and why does it matter? by How-to-Geek

I found the Roads and Bridges paper to be particularly insightful when it came to providing a bigger picture overview of the field and its history.

The technical component involved shadowing Blake on his pull requests and having him show me the plumbing of Github for different projects. According to OSS Watch, a pull request is “a method of submitting contributions to an open development project…A pull request occurs when a developer asks for changes committed to be included in a project’s main [body of code].”

Discussions with Blake and others about open source on Github plumbing, papers to read, open source community, conferences, the state of open source:

• Part 1. Github plumbing
• Part 2. Shadowing pull requests (PRs) and sharing resources

Technical resources and lists of issues/projects links:

• How to Contribute to a Open Source Project on Github (an Egghead video series by Kent Dodd)
• Code Triage (can get an email with a daily open issue to fix)
• First Contributions (tutorial to walk you through making a contribution)
• Great for New Contributors (Github list for beginner friendly projects)
• How to Win Friends and Make a Pull Request on Github (guide to pull requests)

My contributions and projects:

• Numenta Nupic. Implementation of hierarchical temporal memory (HTM), a theory of intelligence based on the neuroscience of the neocortex
• CodeBuddies. Community organized hangouts to learn programming — built using MeteorJS

I found the Egghead series to be the most impactful online resource for me to learn the process of contributing to a project.

Although there are many resources out there, I found that some were not consistently updated. It took a decent amount of sifting and looking through Github’s website before I found an open issue that I felt like I could fix relatively quickly. Additionally, the standards for labeling open issues were inconsistent across projects — some were labeled “beginner” when they were much harder to fix than other “beginner” issues. Nevertheless, by the end of the week, I was able to accomplish my goals by contributing to two projects.

I wrote about some of my further learnings about open source here.

Reflections about the overall process and improvements

The structure of the framework gave me a strong basis for my day to day learnings. I could refer to it to see what I should read and what I had already learned. Additionally, I now have mini accomplishments to show as the outcome of some of those sprints.

In terms of refining the process, it’s important to prioritize early. I would read through a firehose of information for the first few days. I needed to learn when to stop reading because I could have also used the entire week or two weeks to read and not build. It was important to gain a sense of what specific deliverable(s) to accomplish by the end of the sprint one or two days into the sprint.

Additionally, it is extremely helpful to find a “guide” for the sprint if possible. As noted above, my friend Blake helped guide me through my open source sprint. My progress would have been significantly slower had he not been there to answer some of my questions quickly.

Although it can be useful to have conversations with multiple individuals in the field during the sprint, I found that it wasn’t necessary since it was a short timeframe. Those conversations are more useful once I had more of a foundation in the field and could talk about what I learned.

Lastly, it is helpful to have some buffer time in between sprints to reflect and re-assess rather than leap into another sprint right away. Unexpected opportunities or new directions may appear, so it’s important to be flexible with what you decide to complete next.

This type of fast-paced learning is useful to gain an initial understanding of a topic that seems difficult to tackle. A sprint is a mini experiment towards potentially taking bigger steps in that direction. It is a “cheap test” to find out if the topic is something you can see yourself doing more of, which could entail a bigger project, a program, schooling, etc. Progress is never made through large jumps at once. Instead, it is always through little steps, and I’ve found that the sprints framework has helped me clarify some of my interests.