pgroves

As a freelancer, I really only use it when seeking out the next contract, which is every few weeks or months. So Highrise is overkill and just slightly too expensive to justify. (But switching to something else never really becomes my top priority.)

One last note: a sales pipeline is useful for many types of relationships... finding customers, hiring employees, getting investors, etc. They all have the same first few steps.

My first reaction (feel free to ignore it) is that advertising the number of hours you are willing to donate to a project or an example of how complex of an application you're willing to make would be helpful. I'm a software contractor (not web apps, however) and even I'm not sure what $100K would get me in central Ohio.

(and I do like the concept... I hope to hear how it goes.)

What is the harm in someone putting their own money into a pseudo-science experiment? It will fail if it's an incorrect hypothesis either way.

In fact, the feedback loop between a "believer", their money, and reality, seems like a feature not a bug.

http://www.hnsearch.com/search#request/all&q=%22let+me+e...

The fact that there is more text in a comment let's the reader know more explainin' is on the way. No need to point out that you're about to elaborate. Are people worried we'll get to the end of their paragraph and not know if the next paragraph is related?

But then that gets back to the original problem: how do you get people to do that so github watch lists only contain worthwhile comments?

I think this is going to turn out to be a killer feature of Ocaml once people get used to the fact that using 8 cores at once isn't that great of a goal when on-demand computing platforms let you scale much much larger. Pretty soon no one will be all that concerned about how much happens on any one machine. It will be how much gets done per process, and how much gets done per 'cloud'. AppEngine already does this.

And it already is a design feature. The GC is not single threaded b/c they're too dumb to figure out how to fix it (not that you were saying that, but people tend to jump to that conclusion). It's because they want the fastest possible single threaded performance, which means not polluting the GC with the kinds of locking mechanisms necessary to support multi-threaded operation.

There are times I end up doing a commit just to switch from my laptop to desktop. In Mercurial I end up with a million commits with the message "merge" b/c I really just did a pull of someone else's code and it forces you to do a commit just to get synchronized with the master (even with no meaningful conflicts).

I wish I could nuke all those ugly checkpoint commits and bundle them into a single commit with an intelligent comment when I push to the main server, but that's just not the standard workflow.

[1]http://en.opensuse.org/Product_highlights

I've always wondered how big an effect this has on these stories about old engineers finding it hard to find work. The older you are, the more likely your last position had a significant project management component that makes you sound like a PHB.

[1] http://blog.cloudharmony.com/2010/05/what-is-ecu-cpu-benchma...

How true is this?

If the main implementation of ed isn't even POSIX compliant these days, I'd say POSIX is officially pointless.

You will likely find people to partner with that have more niche markets to go after. One of your problems, IMO, is that you're product is very general and therefore has lots of competition. Once you are familiar with a smaller (but not too small) market, you will likely end up with many more ideas for products people will pay money for.

Contracting is underrated in the startup world, IMO. You can spend 6 months out of the year building other people's ideas, and the rest of the time building your own until your own products can support you.

MS coming out the message "but...but...but...you should support everybody!" is a bit of a pot/kettle situation and I hope they are treated with the same passive-aggressive apathy as they treated Linux and Mac users for all those years.

I know I'm being petty but I can't seem to make myself stop smiling.

At some point, the standard techniques for dealing with these issues will become Standards. This is a well worn path. Html was a standardization of the previous 10 years of work on markup languages, plenty of them proprietary. There are other examples... ODF standardizing on XML and cloning established MS Office functionality... etc.

Real Standards that could address the article's concerns are only reasonable when NO innovation is necessary, merely choosing a methodology that has already been built and proven to work in practice. IMO, Java more or less committed suicide when it started a standards-first innovation process, which resulted in many multi-year projects doing design-by-committee of an api before anyone tried to build an implementation or an actual product on top of it.

As long as G+ is introducing features not available elsewhere, the fact that it's a currently closed system just isn't a reasonable criticism.

When it's a blog, the big spikes come when posts goes viral. I'm not sure what would be the big spikes for google+ now that the public launch has happened. Maybe just a bunch of little spikes in their case.

One more suggestion: Do label the time zone. even if it correctly detects the user's time zone, that's unexpected on the internet. Plus you don't label 'current' time... for all I know it's a Time Zone ahead but only updates once an hour. Anyway, all confusion goes away with a label.

Edit: Took out references to my personal time zone

You'll notice from my hedging that I only half believe the story. Also, it may be a true story, but may have happened in the '50's or something.

PR people talk about what's good about a product all day. That's their job, and it's whose words you normally read in the press. Engineers' jobs are to focus on what's bad about the product and to improve it. People saw Yegge's post and it was an engineer's view and they're flipping out. If Brin has ever talked to an engineer in his life he knows it's no big deal.

I personally have seen sales people who have been touting the virtues of a product for months have a single meeting with the engineers and come back absolutely devastated that things aren't all roses and unicorns.

I've also seen engineers brought into sales meetings and then talk about everything that's wrong with the product he's supposed to be helping to sell. (The engineer typically then gets his ass handed to him by the senior salesperson as soon as they're out of the customer's earshot.)

The problem was that over time almost every company in the S&P500 made it into the indices. The example I remember off the top of my head was a company with a terrible environmental record getting on the list of 'good' companies due to their generous maternity leave policy.

Gigantic companies are so gigantic that they have many examples of good and evil inside them, just like every other organization full of humans.

As far as I can tell, this advice only applied to people who weren't in the same room as him.

(I'm hesitating to hit submit on this comment - please regard this as a criticism of Steve Jobs the force of nature not Steve Jobs the person.)

But it still worked.