What is a software engineering job really like?
2014-08-11 00:00
627 查看
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).
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).
相关文章推荐
- 一份好的简历应该是这样的(This Is What A GOOD Resume Should Look Like)
- Is this really what you want?
- Which background is a greater advantage for a software engineering career?
- What is free software?
- Software Engineering is NOT an Engineering
- "Computer Science" is Not Science and "Software Engineering" is Not Engineering
- 一份好的简历应该是这样的(This Is What A GOOD Resume Should Look Like)
- What is a cronjob, and how do I use it?
- Which background is a greater advantage for a software engineering career?
- Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?
- What is the 'software life cycle'?
- What is good video editing software on Linux?
- What is the world like in the coming ten years?
- Testing Is the Engineering Rigor of Software Development
- 软件随想录(local.joelonsoftware.com/wiki)-2001年05月05日 这个国家的狗做什么工作? - What Is the Work of Dogs in this Cou
- Testing Is the Engineering Rigor of Software Development
- what-is-the-best-components-stack-for-building-distributed-log-aggregator-like
- What is a software architecture?
- Google Caffeine: What it really is