👀 Review time

The time has come to wrap up this sabbatical. Turns out my company won’t pay me to just learn about go forever. This post will be a qualitative and quantitative review of my time. I will look back over my original goals and see if I met them or not.

📝 The original proposal

In my proposal I wrote:

During my sabbatical I want to become a golang open source contributor and gain a deeper understanding of networking in golang. This will enable me to better support our customers when TAS has problems where golang is the root cause.

The proposal also includes the following goals:

Quantitatively Measurable Outcomes

  • Submit PRs with docs changes
  • Submit PRs with bug fixes
  • Be involved in discussion on issues
  • Build a professional network in the golang community

Qualitatively Measurable Outcomes

  • Become more comfortable debugging golang
  • Gain a deeper understanding of networking with golang
  • Gain the ability to easily submit PRs to golang in the future
  • Become more active in the golang community

📚 The plan

Before starting this sabbatical I read André Arko’s blog post “How to Contribute to Open Source or: From No Experience to the Core Team in 15 Minutes Per Day”. One of André’s suggestions is to read everything you can about the project, including every single open issue. He suggests chipping away at this for 15 minutes a day. Despite reading this blog post back when he published it in 2016, this point has stuck with me.

I also read a handful of blogs on “contributing to go for the first time” and the first suggestion is almost always to contribute to documentation. In go there are “testable examaples”. These are snippets of code that run in the official golang docs that show an example of how to use each function. But not all functions have one!

So my plan was:

  • read every new github issue (I had no plan to read the entire 5k backlog of issues)
  • add some testable examples

👩‍💻 What I actually did - the story version

My time during this sabbatical mostly falls into four sections:

  • Broken testable examples
  • Go fuzz
  • Assembly
  • Language matching

💔 Phase 1: Broken testable examples

I was investigating a github issue, when I found a broken testable example (if go 1.18 is not out yet then it will still be broken). Testable examples check the output of the example function against and expected output. This expected output is provided in a specially formatted comment that is the last comment block in the function. It turns out that if it is not the last comment block, then the test will report “passing”, but it actually didn’t test anything.

I fixed this one case of a broken testable example, but I thought there might be more and opened an issue to propose a broader fix. In order for something to be added to go vet you have to prove that the issue is widespread. So I wrote a parser and ran it against the top 1000 golang repos. I ended up finding an additional 6 instances.

This was enough to allow a new go vet analyzer so I made the needed changed and submitted the feature!

🧶 Phase 2: Go Fuzz

I noticed that there were a lot of issues being written to track the work around fuzz testing, a new feature coming out in go 1.18. The writers were asking people to play around with it and give feedback, so I did. I tried out go fuzz (the new feature) and I tried out go-fuzz the 3rd party package it was based on. I found that the output of go-fuzz was much more human-readable than the output of go fuzz. So I made an issue and submitted a fix to make it more human-readable. I also got to add some little features to improve the CLI experience.

🧩 Phase 3: Assembly

In my daily github issue reading, I noticed that many (many, many, many) issues were about the compiler. These issues would include assembly code that was incomprehensible to me. I went down a track of learning about assembly language in general and specifically go’s pseudo-assembly knowledge.

I learned a lot. I asked questions in the assembly channel in gopher slack. I became friendly with one of the regulars there who started reading my blog and giving me feedback on my assembly code. Ultimately, though the learnings were interesting, I didn’t feel like I was contributing to go. So I stepped back from assembly and set my sights elsewhere.

🇫🇷 Phase 4: Languages

During my daily github issue reading, I saw an issue about language matching not working. I investigated and it turns out language matching is just one massively complex algorithm that has lots of caveats for socio-political reasons. In a word: fascinating! After multiple days of debugging, I was able to determine that the algorithm was working as intended.

I spent a bunch of time mucking around in language matching and I wanted to see if I could put this knowledge to work, so I found some related open issues. One was a duplicate of the first, easy! One was about the Slovak language not collating accents as expected (I think this is a bug in go) and another was about the matching algorithm not taking private tags into account (turns out this is on purpose).

👩‍💻 What I actually did - the data version

📩 Submitting PRs now and in the future

Yes! I did this! I submitted 15 PRs…

  • 12 are currently merged
  • 1 is waiting to be merged
  • 2 will probably not be merged
  • 7 PRs are documentation related (mostly testable examples)
  • 5 are features
  • 3 are bug fixes

💬 Being involved in discussions on issues

Yes! I did this!

  • I opened 6 issues in golang/go. 5 are now closed.
  • This issue resulted in an 18 comment discussion.
  • Commented on 9 issues that were not mine.
    • Including providing analysis for 4 different language matching issues.

🔨 Building a professional network in the go community

I didn’t really do this.

  • I initially was in contact with a go contributor. He was helpful initially and then ghosted me.
  • I made a friend who is active in the assembly channel in gopher slack who helped me out a lot.
  • I found slack very overwhelming.
  • I was very worried about bothering people.

🐛 Becoming more comfortable debugging go

Yes! I did this!

During this sabbatical, my team ran into a go related networking bug. I was able to replicate it in test (no need for a stand alone reverse proxy and multiple apps) and then determine which commit broke it in one day.

I tried to do something similar in the past, but had trouble figuring out how to test local versions of go. This time it felt second nature.

💡 Gain a deeper understanding of networking with go

I didn’t really do this.

I ended up not doing a ton with the networking packages. There was just so much to learn in areas that I had never heard of before!

My favorite networking learning was about the new netip package that is coming in go 1.18 and why go needs yet another ip package.

🏃‍♀️ Being more active in the go community

Yes! I did this!

🙏 Thank you!

Big thank you to my mentor Gareth for encouraging me to pursue this sabbatical. Thank you to the three blog-readers that I know of (Gareth! Chris! Gabe!) for answering my rhetorical questions and motivating me to keep writing everyday. Lastly, thank you to my daily crossword friends for providing me with 20 minutes of human interaction each day and keeping me sane.