Work environments for software engineers have been studied more than you'd think. Fastcompany.com contained a "Death to the cubicle!" rant this past summer.
The most famous study I know of is "IBM's Santa Teresa Laboratory - Architectural Design for Program Development". Scroll down the document to see illustrations of floorplans and even furniture layouts. A "Joel on Software" forum about office space contains more links.
Steve McConnell's 30th chapter of Rapid Development (the CSci 152 textbook) is a really nice summary. McConnell also has insights about "people-related classic mistakes" in chapter 3.3 and 12.4 "problem personnel"). He summarized his ideas in his "Dealing with problem programmers" column -- here's an excerpt and a link.
- It’s rare to see a major problem caused by lack of skill. It’s nearly always attitude, and attitudes are hard to change. If the problem is caused by lack of ability, that is even harder to change.
- The longer you keep a disruptive person around, the more legitimacy that person will gain in the eyes of other groups and managers, the more other people’s work will be affected, the more code that person will be responsible for—overall, the harder it will be to remove him from the team.
- Some managers say that they have never regretted firing anyone. They’ve only regretted not doing it sooner.
Besides working in our offices/cubes, what else do we do? Schedule, agendize, and attend meetings! STSC CrossTalk has a very interesting article from 2004. Here is the abstract and link:
Every one of us has spent many hours, days, maybe even years in meetings. We all have experienced good meetings and bad meetings. Do software engineers spend large portions of their time in meetings? What factors make such meetings successful? This article presents the results of an industrial measurement study conducted to determine why some meetings are successful while other are not.
