introduction

Wikipedia is the confluence where open-source software meets free encyclopedias. Being an intern on the Wikipedia iOS team comes with its own set of responsibilities. However, I am fortunate and privileged to be on an active team that ships code every two weeks. Burying my head in a sea of iOS codebase written in Swift and Objective-C can be intimidating and interesting. In the first two weeks of my internship, I worked on search widget features and switched Git branches to fix UI issues in my previous pull requests. It might sound daunting, but to be honest, I'm loving it at the moment because I enjoy being pushed. Here comes my struggle, I have always wondered how developers manage to work on different features in a single codebase, make source code changes to other files, save modifications for later, create a new branch from the main, and seamlessly switch between different pull requests all while shipping software for different release labels based on feature priorities and bug severity.

Git Stash

Boom, here comes my latest friend, git stash. One takeaway I have had from working with experienced developers during my internship is the reality that professional developers don’t just write great code they master commands that help them work faster and one of those commands is git stash.

Git stash temporarily saves your uncommitted changes and reverts your working directory to a clean state, as if you hadn'tmade any edits. It is like a digital clipboard for your code. I will be sharing how Git Stash ended my multitasking woes and made me ship faster as an iOS developer.

I first learned about the git stash command during my outreachy contribution phase. The least expectation from new contributors in open source is to fix issues in the organization’s repo and I was doing just that. But out of curiosity, I wanted to do more. I wanted to contribute to Wikipedia more than fixing issues and also work on different issues at the same time. Taking a look at the Wikipedia iOS open pull requests, something stuck out like a sore thumb to me, I noticed the maintainers had multiple pull requests open and they were pushing commits to these PRs which had different software labels. Seeing that I instantly realized there would be a git command that would feed my curiosity. With AI tools at my disposal, I was just a prompt away from knowing git stash as a command and its use cases. It didn't take long before I put it into use during the contribution phase. I was working on an issue that requires replacing the x button labels on different views with a blue Done button when I got a notification about the reviews left in my previous PR. The reviews in my previous PR were just a tiny fix so It was the perfect time to use git stash. luckily Xcode had it baked into its IDE so I stashed the changes made to the WMFReferencePopoverMessageViewController, WMFImageGalleryViewController, TableOfContentsPresentationController and the ReferenceViewController on the update-x-close button branch I was working on and gave it a description. Hence I switched to the previous branch where I had pushed changes to my PR which needed a tiny fix. After committing and pushing the fix that was needed, I switched back to my current branch and popped my stash changes. It was multitasking at its finest.

SemVer

My first internship task was to implement an iOS search widget feature for the Wikipedia iOS app and I was told by my mentor during my sync-up that the team releases a new software version every two weeks. I always like a new challenge so I was excited. I figured out how to implement a widget and I opened a PR for the feature ASAP. During our next sync-up call. I noticed she added a label to my PR and I was curious what the three numbers separated by dots meant. (7.7.7). I was one Google search away from learning a new term in open source software release. Without hesitation, I fed my curiosity again and from search queries on Google, I discovered the three numbers separated by dots added as a label to my PR was called Semantic versioning (SemVer) for short. Where the first number means a major release, the next number indicates a minor release, and the third indicates a patch. (7.7.7 = Major . Minor. Patch). SemVer is a widely used term and a set of rules for versioning software in open source and other contexts. It provides a standardized way to communicate the nature of software updates through version numbers, indicating whether a change is a major, minor, or patch update. It was an awesome feeling to have the feature I implemented to be part of the next release. ☺️

A/B Testing

After getting my “iOS search widget for Homescreen” PR merged. I asked my mentor about a term I saw on the Phabricator for my task (A/B Testing). Open source is all about communication and we are often told to ask questions when we encounter new terms or vocabulary. So this made me more comfortable and confident to ask questions. During our sync-up call, My mentors broke down what A/B testing is to me and it was one of the most detailed explanations I have ever gotten about a new term I came across. For new interns and new contributors, it is perfectly fine not to know it all. It is perfectly fine to ask questions when your task is vague or when you come across new terms in open source or other contexts, it is perfectly fine to ask for help. No one knows it all. Asking questions makes your life easy and helps you get things done faster. After my mentors explained A/B testing to me, it now made sense why it was included in the Phabricator task. The feature I worked on will be tested by different groups of users when the team ships the new software release 7.7.7.

A/B testing is a method for comparing two versions of a webpage or app against each other to determine which one performs better.

My struggles

The biggest takeaway for me in software engineering is that it is a marathon and not a sprint. Every open-source maintainer, senior software engineer, and staff engineer set out as a beginner and it is okay to struggle, it is part of the process. It is one thing to write code and it is another to distribute it. Over the years I find myself learning git every time I tend to write software and make it public. For me, git isn’t a know-it-all-at-once tool. Its commands are porous and learning it on the go takes your skills to new heights as a developer. I have often struggled with setting up my development environment, installing tools, writing code, writing clean idiomatic code, stage commits, rebase commits, merge conflicts, stash changes, and branch divergence. The past few weeks I have struggled with widgets and localization spaghetti code and my mentor's code review has been teaching the do’s and don’t of DRY ( Don’t Repeat yourself). Adapting the DRY principle as a new contributor is one of the best ways to improve your skills. You aren’t just writing software to make it work but also writing it well to be maintainable. Day in and day out, I am overcoming my struggles and I am leaning on the go with every line of code I write, commit, and push.

Conclusion

For me, the best way to get started in open source is to ask questions. As an intern or new contributor do away with timidness and ego. No man is an island. There is a saying that goes by ‘A little drain of water makes the mighty ocean’ The micro contributions here and there from different contributors set up the mighty codebase that sits in repos. Asking for help can make your life easy. If there is one thing I will leave with the reader of this blog post, it is “It is okay to struggle and it is fine to ask for help”. See you in my next blog post. 👋