This summer I started my first ever internship. It's certainly a culture-shock to transition from school to the workplace, but I generally like to pride myself on being a quick learner. At Red Hat, as a Systems Management intern, I learned a lot in just the first week.
I learned that open source is more than a word used to describe some vague coding communities. I learned how to use git correctly, how to write Go, and how to navigate a Linux dev environment efficiently. I learned that software engineers like to pick the dark chocolate bars out of the mixed bags of Hershey's chocolate and leave nothing but the less desirable Mr. Goodbars and Krackel bars.
I learned so much, that I'm more than a little embarrassed to look back at some of my Google searches from the first week on the job:
- vi how to use
- linux control r
- curl command
- how to use pointers
- chattr
- git rebase
But, we all start somewhere.
This summer, I worked on a team developing Project Atomic, a lightweight OS designed to run containers. Atomic is driven by a powerful tool called OSTree, developed by my mentor Colin Walters, and described as "git for operating system binaries" because it essentially allows atomic upgrades and rollbacks between OS deployments. Within my first few weeks, I had developed a new command for rpm-ostree, the program that integrates OSTree with rpm handling. After writing man pages for each of the OSTree commands, I had grasped an understanding of the structure well enough to start new projects that added functionality to these programs for system administrators.
With each new project, each new patch pushed to git, came a feeling of overwhelming satisfaction. I've already seen three of my features merged into the program, ready for the next release. It feels amazing to be doing something that I know will have a real impact. I've heard different stories from so many friends at their (technical) internships; they are frustrated that they're not treated as real employees, that they don't get any responsibility, or that they don't feel like their opinion is heard. I've never felt that at Red Hat. I have a voice in our sprint team, and the beauty of open source is that if you think something needs changing, you have the power and the freedom to change it.
Two of my patches were not actually ever assigned to me; I just started doing them because I was using the system and thinking: "Man, this would be a lot easier if I had a tool to..." The culture there supports and encourages that kind of behavior, allowing autonomy and trusting one's judgment in what you think might be helpful or necessary. Red Hat is a great place for an internship because I gained a lot of insight into what a software engineering job is really like, both the good and bad sides.
I felt the triumph of code finally working, the pride of having a patch merged upstream, and the simple pleasure of knowing I was contributing to something meaningful. On the other hand, I felt the weariness of waiting for code to compile, the frustration of code ceasing to function despite having changed nothing, and the indomitable sadness at the sudden realization that the bug you'd been tracing for two hours was caused by using "==" to compare two strings.
What I know for sure is that I'll go to school in the fall a changed person. I'll be the one taking notes in Emacs instead of MS Word. I'll be the one re-teaching my classmates how to use git /correctly/ for collaborative projects. I'll be the one using my Fedora machine as much as possible over my school-issued Windows build. I'll be the one out there advocating for F/OSS, (free and open source software).
Read more articles like this one about young professionals in open source.
1 Comment