Today's assignment was to go read and discuss two articles from opensource.com. I chose "How to teach undergrads how to become open source contributors without writing any code" which is about a class full of college students learning to become functional open source contributors without having to write code (redundancy here due to the title I know. Sorry about that), and "Culture eats strategy" which is about why understanding a company's culture is so important. Let's get to it, shall we?
"How to teach undergrads how to become functional open source contributors without writing any code" by Sebastian Dziallas
I chose this article mainly because of the course I'm currently in, which is why I created this blog. I felt that what was done in the class taught by Dziallas is almost exactly the same as what we're doing in this class with Dr. Bowring--learning how to become functional contributors to open source projects without writing code. The author lists three main elements to the class: the cultural, the technical, and real projects and interactions. This is Dr. Bowring's approach as well. We are assigned articles to read about working in open source development and case studies (the cultural); we learn about packaging (the technical); and finally, we learn about and interact with real projects (real projects and interactions). Now, here's where the difference in the two classes comes into play. Unlike Dziallas's class, we don't work as a collective whole to make contributions to a project. Dr. Bowring divides the class into groups (teams) who each get a project to work on, and no two teams are allowed to have the same project. Reading it, I enjoyed seeing a slightly different take on this approach to this type of class.
"Culture eats strategy" by Jonathan Becher
I chose this article based on the title. It just really caught my eye and looked interesting. In the article, Becher discusses his experiences at a company called SAP. While his experiences are in the marketing department of the company, I found the lessons he learned from them relevant to software engineering. His main point is that without an understanding of the culture in your work environment your strategy won't work, regardless of how good it is. Becher basically says that thinking "all successful change management projects require executive support", or "if you aren't the lead dog in the sled, the view always looks the same" is a load of crap. I completely agree. Managing projects is a team effort, not something that is done by only one person. If one person makes the decisions, then they're not going to be as open to suggestions and will do whatever they decide to do. Team decisions promote communication between team members, which in turn leads to better decisions about a project and better performance overall in the team.
No comments:
Post a Comment