Catalyst for Thought

A professor of mine once opened a lecture at the beginning of a semester by asking, “What are we? Engineers or artists”. As we were in a software engineering class, the most natural answer was “engineer”, however, to my surprise, the class’s vote was almost perfectly split between students. On that day I felt confident in my answer that as a software engineering student I was becoming an artist of sorts because we were all studying the “art” of writing clean, effective and efficient code. After all, what had I done up to that point as a student of Computer Science but attempt to refine my code to fulfill requirements set by professors and graders? The development process up to that point for me had been short, usually week-long, stints that would produce a product refined as much as time allowed. From my experience at the time I can hardly blame myself for seeing us all as, “artists of code”.

Revelation

However, with the experience I gained from that course I would no longer describe myself, or software engineers as a whole as, “artists of code”, but rather as, “artists of collaborating on code”. It was in that class that I had my first experience working on a large team with a whole host of “artists” such as myself. The class was divided into two working integration tracks, each with five teams. I was then only a single developer on a team of twenty-five all coming together to build a single piece of (hopefully) working software. Whereas the majority of work in my experience before had been dedicated to crafting a small product that performed a specific task, now the work was in up-keeping a fast and responsive network of communication between at least one member of each team.

Conclusion

My recent experience with large, multi-contributor projects has lead me to the conclusion that even with the latest technologies and frameworks, the most comprehensive plans, and the utmost enthusiasm, nothing decides the success and quality of a project like a cohesive and well organized team.