bmccormack

One thing Dan didn't mention (but perhaps alluded to), is that an objection does not immediately translate into a request to engineering to add feature X. For example, in Dan's discussion of priority and severity, he didn't go running to the development team telling them they needed to add severity to FogBugz in order to nail a big client. This allows developers to focus on good long-term design decisions that hopefully make the product better.

Granted, if you hear enough of the same objection, it may be something that you want to add to your product, but you want to keep that as part of an existing engineering workflow instead of treating every object as an urgent request to help get a sale.

The talk you gave, which highlights how DVCS can help you seamlessly manage bug fixes and features in multiple versions of software, was an excellent example of explaining benefits over features (which Dan talked about in the source article). Sure, Kiln has a ton of great features for getting the most out of DVCS, but explaining the benefit of how DVCS can positively affect your team helped tons of people "get it," myself included.

A lot of this is really great. I think the part that stuck out the most to me is that sales, at its core, is really just a conversation to give someone information about how your solution solves their problem. If that's true, then I guess I've been "selling" in one form or another for quite a long time!

Working in a customer-facing position, I have a hard time not wanting to champion every legitimate feature requests that comes in. However, I've learned that if I want to get engineering to work on something when it really counts, I have to be very judicious about what I send their way.

Thankfully, having a product with multiple customization options (API, plugins, javascript and CSS), I can always give the customer the opportunity to write their own feature, and if it's simple enough, I'll just write some code and do it for them.

One of the guys on our support team had his sister come to lunch at Fog Creek during their visit to NYC. Even amidst all the wonderful things they did in New York, she said that coming in for lunch and seeing Fog Creek was the highlight of her trip. It wasn't that the incredible food (though it was), but rather it was witnessing the comradery the exists at meals and the overall wonderfulness of the workplace. When my colleague shared her story with us, it made us realize that we oftentimes take for granted how rare it is to work in such a great environment.

Would this even be a problem for most scenarios? I don't think most users have (or would want to spend) the time to look at two browsers for every set of comments I want to view and/or vote on.

One of the first things I noticed when I started working at Fog Creek is that most everyone in the office is always working and it stays pretty quiet. We rarely have meetings and individuals are able to remain focused on getting things done.

The office is generally quiet except for lunch. Lunch gets pretty loud when Fog Creek and Stack Exchange gather around two long tables to eat great food. Sometimes we talk about work, but most of the time it's off-topic. Occasionally people eat at their desks, but most of the time everyone is together for lunch.

The people I work with are incredible and I'm excited to join them for lunch every single day. Perhaps I get an extra boost at lunchtime because I'm an extrovert, but I think even the introverts enjoy this time together with great people.

I see a lot of comments here about how awful it is that introverts are forced to sit with others at lunch. I suppose that's possible, but I don't get the slightest impression from anyone that they'd rather be eating alone. Since most developers are shielded from distractions most of the day and are heads-down in code, lunch allows them to connect socially with other people at the company.

Maybe you'd have to experience lunch with great coworkers day-in and day-out to understand Joel's perspective. I couldn't agree more with what he wrote.

Don't forget "Fire and Motion" - http://www.joelonsoftware.com/articles/fog0000000339.html

Via http://www.zenit.org/rssenglish-30009, I learned that Villanova's Communications department is responsible for the technology behind the images. There are more links to 360 views at the bottom of that article, including this one to see St. Peter's: http://www.vatican.va/various/basiliche/san_pietro/vr_tour/i...

That's certainly possible, but I personally find sarcasm very difficult to detect on the web. I generally avoid it when communicating online and via text.

Regardless of whether or not one agrees with Yusuf Mehdi's conclusions, I can certainly understand his passion in defending his team. Google's accusations yesterday were very accusatory and polemic (e.g. "We look forward to competing with genuinely new search algorithms out there—algorithms built on core innovation, and not on recycled search results from a competitor. " ouch).

Miguel and the mono team will probably knock this out before the weekend.

Maybe the reason these lists are not easily discovered is because they are taxing the server pretty heavily. It took quite a while to return the "leaders" list the first time I ran it, but it wasn't as bad the second time.

"Dropbox limited its feature set on purpose. It had one folder and that folder always synced without any issues -- it was magic. Syncplicity could sync every folder on your computer until you hit our quota."

I think I had started to use Dropbox because of its popularity on LifeHacker and other sites. One of my first complaints was that I was required to use a single "My Dropbox" folder instead of being able to use my own folder structure. However, I quickly adapted to the Dropbox model and realized that for every computer that's connected to Dropbox, everything that's in the Dropbox folder gets synchronized and everything that is not in the Dropbox folder is not. Its simplicity is probably the reason why I am still using it.

Does PostDesk Debates only host one "debate" at a time? I find it odd that an article with such a pejorative tone is the only content on their site.

Perhaps the fact that I was surprised that the article's author didn't immediately think of Fiddler is evidence of how exclusively I've worked with web services via .NET. Personally, I've had a great experience with SOAP from within Visual Studio. Once the service reference is established, all coding is against the strongly-typed code-generated classes. If I must, I use Fiddler to debug. My experience has been positive.