Reading 07: A Tale of Two Internships

 ’ll start off by saying I think there is a lot of value in ESR’s list of lessons for creating good software. I honestly think it extends beyond just software development - there are numerous times I can think back to solving an algorithms or theory homework problem, and realize halfway through my solution that I didn’t even truly understand what the question was asking until I got halfway through (Lesson #3, #12). As I have moved throughout my career as a computer science major, I have begun to see the truth of each one of these lessons - some more than others. But I still wonder, is this the ideal roadmap towards software development? And that’s one of the core questions I am asked to consider in this blog post: comparing the cathedral and bazaar models of development. 

At my internship post-sophomore year, I spent every morning in scrum meetings, and spent hours every few weeks in large, sprint planning meetings. I was restricted from making edits to other developers' code, and while I participated in many meetings, I was mostly in the dark as to how the other software at our firm worked. But I contend that this was a good thing. After all, I don’t think a 20-year old CS major should be immediately thrust into a position where he/she can immediately be looking at and making changes to other developers’ code. Even though it disagrees with the bazaar style, I think the cathedral method provides a lot of security - especially when the group of developers is small. 

I contrast this experience with my most recent internship experience, where I was placed in a much more familiar environment - Macbook, VSCode, Python, Linux, etc. And while this group wasn’t anywhere near the Linux community, it felt a lot more like a bazaar than my previous internship. My first assignment was to look at some pre-existing code and make edits to the unit tests. I was encouraged to set up meetings with everyone on the team to understand what their primary projects were and how their code operated. And what’s most interesting is I think this group required more security than the previous one - we were operating with millions of highly classified data points from leading hedge funds. But despite this, the group considered themself a “tactical squad” who identified key problems within the bank and operated as quickly as possible to get them done, following rules #7 and #4. 

So which model is superior? While it may sound like my experience in the second internship was better, I can’t say for certain which model was better. The first model fit me well: I was unfamiliar with the coding language, the IDE, and the team. So it made sense for me to be mostly sheltered from what else went on in the rest of the group.

By the second internship, I had a lot more confidence and experience, so being able to move freely between the team and gain exposure to everything that was going on was very enjoyable. 

Ultimately, both groups used the different models to their advantage, and are both successful groups within their respective organizations. My final conclusion would be that either model can be successful, as long as you are not ignorant to the potential advantages of the other.