21–30 of 86 posts
The book "Peopleware" has documented this very concept decades ago (according to wikipedia, first edition was published in 1987), yet here we are in 2012 with still more "cool open" environments for programming teams. Here's a link to the top positive review in amazon, giving an insight as to its content http://www.amazon.com/review/R1R3N8JI29OPPE/ref=cm_cr_pr_vie... Lots of startups want to recreate the cafe experie…
My current company, a startup, has an even split of developers, half under 30 and half over 45. I'm one of the old guys. The development environment and approach, mostly set up by the young guys, is pretty modern -- lots of open source tools, hosting on launchpad, test-driven development, code reviews, all developers in one big open space, everyone does everything (as opposed to developers doing development, testers…
I couldn't make it past the first page of the article because I felt it was veering too much into the territory of "I have an axe to grind, and I'm looking for anecdotes to support it." My two sentence take: 1. In my experience, private space and time is necessary for individuals to get real work done. 2. In my experience, small, focused teams which have as-needed discussions and well-partitioned responsibilities are…
You should have read the whole article. The author does cite numerous third-party sources of evidence.
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.
Brainstorm sessions might surface creativity that has already happened. If you ask a group, "What are some product ideas we haven't considered?", there's a chance that some people have been independently thinking about new products, but wouldn't have thought to propose them.
Or they can serve to direct/request creativity. If you ask "What are some product ideas we haven't considered?", people who had not been thinking about new products, might start. It gives them something to think about on the drive home or in the shower. I've received some great ideas via email a few days after the actual session.
Places which have nothing but cubes and sealed-off workers do miss some of the "creative" or "interactive" benefits of open, collaborative workspaces.
At the same time, places that strictly "open"...do indeed inhibit certain types of focused work. Isolation definitely helps progress in particular problems. There are examples throughout this thread of that.
I think the best work environments/attitudes are those that encourage a blend: the last few companies I've worked at have had open, collaborative workspaces, but at the same time really encouraged folks to go find their own nook (in the building or somewhere else entirely) when they needed to focus. The concept of "desk hours" or "continuous availability" was basically nonexistent.
It's all about balance. If your workspace lacks that in any aspect, you'll have something to complain about.
Thank you to the writer of this. This is actually the reason I only take work that allows me to mainly work remotely. I used to work in an open layout as described and I would be interrupted for every little thing resulting in not much actual work being achieved. Oddly enough the open layout seems to be'the way' for cool startups - maybe in actuality this driven more by the cost savings of having an open layout offic…
Ideally, I think developers should have a choice. There should be rooms for working in a group when necessary, and there should be cubicles or rooms for working in isolation. People would switch depending on the situation or personality.
My current company, a startup, has an even split of developers, half under 30 and half over 45. I'm one of the old guys. The development environment and approach, mostly set up by the young guys, is pretty modern -- lots of open source tools, hosting on launchpad, test-driven development, code reviews, all developers in one big open space, everyone does everything (as opposed to developers doing development, testers…
Discussing it might not work if your boss/coworkers aren't good at grokking your needs, but their priority should really be to enhance your productivity the way you need it enhanced, not to force you to conform to their style.
Earlier quoted context omitted.
You should have read the whole article. The author does cite numerous third-party sources of evidence.
I felt he was confusing my two points, and it got frustrating. Collaboration does not imply literally working with those people in the room all the time.