megaduck

What exactly are you trying to say?

<BEGIN PSA> Please, please, please, do not use hover controls. They are useless for touch users as well as screen readers, and the discoverability is poor.

Modals are also really really hard to make accessible, and are often confusing. If you MUST use modals, please use a well-vetted library instead of rolling your own.

There's a lot of things that look really cool but make life difficult for people that aren't you. We appreciate your consideration when you build your UX. <END OF PSA>

I run the Pivotal office in Singapore. Breakfast is wonderful, but it's hardly mandatory.

Standup at 9:06 is important, though. In order for pairing to work, you need to have everybody there at the same time.

The iron bargain is that you work a rigid eight hour schedule, but then you go home (or wherever) and don't think about work. No overtime or crunch mode, ever.

It's not for everybody, but many folks really really really like it.

I've worked with Eno (the OP) on the product that he's talking about (Cloud Foundry). It's worth noting that the first versions of Cloud Foundry were written in Ruby/Sinatra for the reasons that you're talking about.

We switched to Go because Ruby's concurrency model was obtuse/inefficient and scaling the codebase was challenging even with excellent developers and great engineering practices. The performance gains with Go were a really nice bonus.

If you're solving Google-style problems like writing a PAAS, then the benefits of Go outweigh the headaches. If you're writing a more straightforward CRUD-style Web API, then Rails might be a better choice.

Predictability. We pair program, so we need everybody to be there at the same time.

People sometimes work less, due to doctor appointments, child care, home repairs, and such. However, they never work more.

I'm not convinced it's optimal! However, it's a "known good" number that's easy to convince people to follow along with. Running experiments is hard and expensive, so we just haven't tackled that yet.

My personal suspicion is that optimal is probably in the 35-45 range, but I'd love to have more data.

We use Pivotal Tracker, and it's pretty easy to see how many bugs are popping up and how often.

Code quality shows up in your velocity over time. My favorite saying right now is "quality is future speed". We also do regular reviews to assess things like cyclomatic complexity and how well SOLID principles are being followed.

I enforce a militant "40 hours only" policy for my employees, and it's incredible for productivity. When you work longer hours defect rates increase, code quality drops, and things are on fire all the time. You also lose really good people due to burnout.

Sustainable pace is super important for creating and maintaining high performance teams. Crassly, it's just a more profitable way of doing business.

I wish more managers would stop buying into the myth of "time in seat == productivity", and look at the real output of their teams. When you actually run the numbers there's a lot of results that run counter to conventional wisdom.

You're clearly the target market for these new MBPs, and that's great. Glad you have a machine that fits your needs.

People with more strenuous computing needs are miffed because the MBP used to fit our use case, and now it doesn't. There isn't a single Apple product focused on the high performance market any more, and some of us are bitter.

I work at one of those "contracting shops" (Pivotal Labs), and I think you're misunderstanding the reason we push TDD so damn hard: It's not about speed. It's about predictability.

Good TDD forces you into building loosely-coupled code that's easy to refactor and change. When new business requirements come in, the effort for implementing them isn't increased because of your previous code getting in the way. There's an overhead to writing the tests, but it's a fixed continuous cost. As a result, you're always in a position where you can ship a new feature in a predictable (and reasonably fast) fashion.

Not doing TDD often leads to tightly-coupled brittle software, which can be very fast to implement but also difficult to change down the road. It certainly doesn't have to, but in reality that's what happens 90% of the time.

There's a few successful startups that immediately spring to mind that use TDD (Taskrabbit and Modcloth spring immediately to mind). However, the real question you should be asking is, "Which startups died because they got buried under the weight of their own codebase?" That's a long and very depressing list. In many of those situations, some TDD might have helped.

In short: TDD won't make your startup healthy, but it helps ward off some of the more common fatal diseases.

I know because I've seen it. My wife and I used to live in China, and we did traveling in both the high and the low places.

I can't speak to the particulars in Daisey's story (since I don't know which ones were made up), but the overall picture he painted sounded familiar. It's unquestionable that there are horrible working conditions in Chinese factories.

That's the tragedy here. There's millions of awful wonderful horrible stories you can tell about Chinese factories, and Mike Daisey is obscuring them by making up his own.

What's really tragic here is that the truth in Mr. Daisey's story will get dragged down by the weight of his lies.

Chinese factory conditions are often horrible, and there's often a blatant disregard for human life and dignity. Mr. Daisey did a pretty good job of conveying these ideas in a way that well-heeled westerners could understand at a gut level.

However, his pursuit of storytelling over journalism is going to destroy all that. People are going to (rightfully) pitch the fact out along with the fiction, because there's no way to distinguish the two.

It just makes me sad.

This is fantastic news. WebOS has always been full of great ideas, but held back by shaky underpinnings. It's like the inverse of most open-source projects. Great UI, not-so-hot implementation.

There's a lot of folks (myself included) that would have been happy to jump in and assist, but couldn't due to the closed-source nature of the platform.

The real prize, however, is Enyo. It's a great Javascript framework, and works in virtually any webkit-based browser. The biggest problem was the licensing terms: You could only use it on WebOS phones. Now that barrier's being removed.

I'm really looking forward to this. Can't wait to dive into the code. :)