Lessons Learned From an Open Source Capstone Project

The last term of my undergraduate Computer Science degree is almost over. Yay! My software engineering capstone project also comes to an academic close in a matter of days and I wanted to take a moment to reflect on some of the key lessons that I’ve learned from this entire process.

For the uninitiated, Computer Science undergraduates at Portland State University (and likely many other institutions) are required to participate in a two-term software engineering capstone. The primary goal of the capstone project is to enable students to gain hands-on experience working on a team that is tasked with the entire software development life-cycle of an open source project that they can put in their portfolio.

I wanted to take a moment to regroup and collect my thoughts on some of the valuable lessons that I learned from this experience.

I consider myself very fortunate to have been assigned to a project that involves contributing a feature to an already-established, highly popular open source project for a number of reasons. The primary reason is that contributing to an established project more closely resembles what my day-to-day job will be like in industry and involves the cultivation of important collaborative skills (and not all of them technical).

Well, what are we waiting for?

Know when to ask for help

Seriously. I am kicking myself over this. Disabuse yourself of the idea that you will bother somebody on a mailing list with your questions. Adjust your expectations with what is considered your due diligence for forming an educated question. Ignore the voice that says “I have to earn their advice” and instead drown it out with “I have tried x, y, and z. I want to accomplish w. What do you think?” If you listen to “I have to earn their advice”you will spend hours of your life going through letters a-z only to learn that the right thread to pull at exists somewhere in the Greek alphabet. You don’t even speak Greek. If you had the upper body strength required to flip a table, you would.

Discuss early and often

Sure, I’ll admit this one ties in pretty easily with the last one. I thought your eyes needed a break so I put a header there for this next thought. My team and I recently posted our work up for an RFC. We should have sent that out first thing – long before even writing any code. It would have been invaluable if we sent out incremental patches and design ideas throughout the term rather than waiting until a minimum viable product is reached.

Incremental feedback can smooth design issues, implementation gotchas, and help you acclimate to the code base significantly. You will learn things that you didn’t even realize were a part of this universe. Someone might mention an edge case that blows your mind.

Get out of your cave. Don’t forget sunscreen though.

This article is about inviting other people into your workflow

As well as reminding you to be an active participant in theirs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s