Senior studying CS.
Overall, I’m extremely grateful to have taken a class that forced me to learn yet still offered freedom. I felt forced to learn because we were required to work on real-world projects, often ones the rest of the class had never seen. In my case, the first stable release of Gleam, the project I chose to work on, was one year ago.
I’ve finally completed one of my code contributions for Gleam. One of the existing issues complained that a certain erlang script used for compilation was left over in the final build of gleam projects, and this file could not be compiled by integrations that used erlc. Moreover, this file is not needed for anything after compilation.
Our standup meeting went well this week, but the deadline for this project has me quite worried. In just a few weeks, we’ll have to give a presentation, but I haven’t made any PRs yet. The issues I chose to work on are turning out to be more difficult than expected.
The first lesson mentioned in the essay is, “Given enough eyeballs, all bugs are shallow.” I actually don’t like this aphorism and most aphorisms in general because they’re not always true. I think this aphorism is true for large projects that don’t require a lot of specific knowledge.
At this point, I’ve read through half of Building an Interpreter in Go by Thorsten Ball, all of the Gleam Language Tour, and some of the Rust Programming Language. A lot of the details are a little fuzzy, and as expected, I’ve had to work quite quickly.
I’ve continued making smaller contributions on Wikipedia and OpenStreetMap. Interestingly, all of the contributions I’ve made have been fitness-related. On wikipedia, I edited the content of a page discussing eccentric weight training.
Open source in finance probably sounded absurd a decade or two ago - why would big banks share anything, right? But now I think the composition and culture of the financial industry is changing. From anecdotal and personal experience, new hires at top hedge funds, prop trading firms, and even prestigious banks tend to be IMO, Putnam, and IOI winners.
My group chose to work on the Gleam compiler, written in Rust. I have no experience in Gleam, Rust, or compilers, so why would I ever agree to this? My reasoning is similar to that of my last blog: learning comes from working on new things - things I haven’t seen before. How can I plan to be a great software engineer and know absolutely nothing about compilers?
Finding pages on Wikipedia that needed change was trickier than I thought it would be. First of all, I didn’t want to just fix broken links - that feels boring and like busy work. However, changing the content of a page requires specific knowledge and more insight than the original writers.
In terms of choosing an open source project to work on with a group, I have a slight dilemma. On one hand, I have quite a bit of work this semester, so it would make sense to choose a project that doesn’t have many prerequisites.
The git exercises we did in class were mostly review for me, though it would probably be valuable to just read the git book assigned in class. I’ve always believed doing is faster than reading or watching, but having a thorough mental model of git or any subject won’t come through a bunch of google searches or trial and error.
My team chose to build a website that tracks time spent on each website. Our group work was divided pretty evenly on all dimensions of this project, but I really found the programming the most engaging. I’m not interested in working on contributing and license files. I did find that if a project is sufficiently small, it doesn’t even make sense to divide up the work and do it asynchronously. We ended up sitting behind the same screen for a few hours and completed most of it in one sitting.
Open source projects depend on people working together across long periods of time, so it makes sense to set a standard for behavior and communication. The Go code of conduct and the contributor covenant seem quite similar, but the Go project has extra sections on the importance of healthy debate and not the absence of it. Also, Go has dedicated Project Stewards, who deal with issues like bad behavior. Overall, the Go project just feels more specific.
When I hear “open source,” the first thing that comes to mind is transparency. I think of Twitter or now X open-sourcing parts of their recommendation algorithms, and I think of the need for LLMs to be open-sourced.