Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are many parts of this article that boil my blood. The biggest of which is the use of "Groupthink" to describe a practice of creativity. Groupthink has a very specific meaning in many peoples minds which does not apply in this situation. Dilution of the word Groupthink as well as the mischaracterization of a practice the author happens to dislike are both egregious.

Creativity is often spoken of as an end. I do not believe that is true. Sitting in complete isolation being creative does good to no one. Instead, it is a goal to share and execute on your creativity and vision that you have thought of in your own mind.

Programming is interesting because it is a marriage of creativity and skill--it is not art nor engineering but is a craft. You forge creativity with skill (and experience) into lines of code.

However, that does not scale. If we have 50 programmers working in complete isolation then we will have 50 different programs. Collaboration becomes key to scaling the craft.

The only way to scale craft is through constant, effective communication. The tools we use every day as software developers serve to enhance, enforce or provide communication. Even in completely remote projects like Linux, there are tools used to ensure communication: code is submitted to a committer in small, readable patches; style guides focus on the readability of code rather than their cleverness or creativity; changes are discussed and debated on mailing lists and IRC; subcomponent Czars are assigned that share the overall vision of the project.

The so-called "Groupthink" isn't about Creativity--it is about effective real change in the real world by actually applying the creativity that we have instead of allowing it to evaporate.



However, that does not scale. If we have 50 programmers working in complete isolation then we will have 50 different programs. Collaboration becomes key to scaling the craft.

Sticking 50 people into the same room does not guarantee true collaboration. Especially if they have different goals, which is often an overlooked factor in large companies.


Nope.

But its one of many tools to encourage collaboration.


"The only way to scale craft is through constant, effective communication."

I am skeptical of the "constant" part. Communication needs to happen, of course, but it doesn't need to happen constantly.


> If we have 50 programmers working in complete isolation then we will have 50 different programs. Collaboration becomes key to scaling the craft.

Since most programs can be broken down into a set of components I believe it should be relatively easy to parallellize the workload.


"""Since most programs can be broken down into a set of components I believe it should be relatively easy to parallellize the workload."""

The "easy" part of your phrase, is the one key misconception that project managers have since the beginning of software engineering. The mythical man-month and peopleware anyone?


You are probably correct, I haven't read those books yet! But, I was not explaining myself fully either way.

While I think the individual parts could be considered easy, the interaction of these and their integration I would consider a hard, complex problem with the potential to bottleneck all of the work.

The reason being: it's very difficult to parallelize integrative work because by its very nature, functionally it suggests dependency and coupling, and socially requires efficient communication.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: