This is essentially a one-line blog post and is basically just spam. Even as a developer I've had to spend significant portions of my day on the phone, which you can't really do in a library-quiet voice. Many offices don't have adequate amounts of dedicated rooms for this, and it is not very practical to abandon your desk for a significant portion of the day to do work.
>This is essentially a one-line blog post and is basically just spam.
I've often thought about what makes 37Signals blog, Signal vs. Noise, so popular and attractive. What's interesting about their blog is that they never post about managing projects or how to organize your contacts. You know, the problems/solutions related to their popular products. This is an important lesson.
All too often, startups dedicate time/money to a blog with post after post about the problem that their software solves or a very closely related subtopic. What 37Signals does is blog to their audience. Who is their audience? The Fortune 5 Million, or the millions of small, profitable businesses out there.
When these millions of companies and businesses need project management software, they're going to look to the guys that have been teaching them all along how to run a hip, cool business that operates counterintuitive to more "traditional" business rules (see Rework). The majority of people who punch in their credit card number for a Basecamp subscription don't know what Ruby on Rails is. Believe it or not, they know of 37Signals from posts like this.
If you're a business owner, growth hacker (sorry...) or blogger looking for more page hits you should have a simple text file that contains the fears, desires, wants, needs and emotions of your audience in both personal and professional contexts. Write so that your audience knows you understand their feelings and emotions. They'll keep coming back for more. And if you're done a fair job of aiming your audience scope, a majority of your blog visitors will be interested in what you're offering.
What's interesting about their blog is that they never post about managing projects or how to organize your contacts. You know, the problems/solutions related to their popular products.
Although I agree with most of the other things you said, this particular paragraph is not true. Over the last couple of months (starting with http://37signals.com/svn/posts/3194-backstage-an-inside-look... I think) they've published several Basecamp projects showing how they use it. It's not only a write-up either, you can go into the actual BC project and see it's entire history.
To be fair, the author kept the post short. I didn't find any fluff in it.
Perhaps as the guy on the team that's constantly interfacing with managers or clients, you don't find any value in a quiet atmosphere. How do the rest of the folks on your team feel?
Of course, cultural practices reinforce each other. If your team practices both Everyone Is Client-Facing, and Phone-First, then there's likely a lot of chatter anywhere you go in your office and people ironically resort to headphones to find quiet.
In many teams, there are only a few that require the use of their voice above a low volume, and even then it's for limited intervals only. Without a simple well-understood rule, such folks can dominate environments and unnecessary interpersonal friction can develop.
I code around 16 hours a day and only have to do one call a day. I'd love a library office. Hell, sometimes I have to take my laptop outside to get some big commit done that will take 6 hours of concentration or so, if my various headphones can't block out the constant talking.
More hours does not equal higher productivity. Working for six hours on a single commit (as the poster indicates) means the commit is far, far too large. Unless he means 'feature', then it's okay.
I don't see how you can make that deduction. You must be some kind of commit-nazi. Working hours do not correlate with the size of the commit. There might have been a number of hours just thinking about the implementation, designing the solution, fix, whatever, before writing a single line. The actual commit can then be e.g. 10 lines of code. There are many, many reasons why a single commit can take several hours of work. And it's perfectly fine and normal. Don't be judgmental like that.
