His point makes a lot more sense in the context it was originally intended. He's not making a point about programming or debugging in general; he's specifically discussing tech support as a one-man indie game shop. In particular, it's all about the cost-benefit tradeoff. In his words (taken from the first post in the series - http://jeff-vogel.blogspot.com/2011/06/seven-tips-for-giving...):
But at the same time, as a small developer, you have very little time to spare for support. Time spent getting the game working for one person is time not spent making a new game for everyone. You will need to develop a sense of when the time lost helping a person is not worth it, either because you won't be able to solve their problem or because they will not able to implement the fix you provide.
...
Remember: It's only worth the time to do tech support if you have the chance to, in a reasonable amount of time, fix a problem and make a loyal customer. If you realize that, at the end of the road, you aren't going to end with a happy person and a working product, end the conversation as quickly and pleasantly as possible.
In that context, I think his approach is very rational. If you pushed him, he'd probably agree that more often than not the issue is in his code (even if it's just a question of inadequate error handling). However, if the problem is only seen by a single user and will be a significant investment to try and fix, then it's simply not worth the time when he could be working on a new game, a port, or even a different problem that has been seen by multiple users.
A programmer working defense state-side does not make nearly those figures.
80 to 100 is much closer to what a software engineer with several years of experience makes working for a defense contractor than 250, though of course actual years of experience and how well one has played the corporate ladder game can make a big impact.
Past a certain point it is relatively difficult to advance salary-wise without taking on management roles and giving up the hands-dirty side of programming / engineering. Once you're there it's an apples-to-oranges comparison for the kind of startups that are typical for HN-types ~ certainly no early stage startup is going to hire a 10-year manager to be employee #1 when what they really need is a hotshot programmer.
I should not need to understand the subtle privacy interplay of several different and seemingly unrelated Google products just because I use one of them (Gmail).
I entirely agree with this, although I'll point out that IIRC Google Chat did the same thing in terms of modifying gmail but no-one seemed to really object to that. Buzz seems to be different because of the privacy issues, i.e. Google didn't communicate well what would happen (specifically a public profile that included your follower/followee lists) if you clicked "yes". That there's a new link on the left-hand menu can't really be the main issue, is it?
As far as FUD, I'm specifically referring to comments like this:
Don't let the FUD fool you. It's "active" in that you can see other people's buzz posts and you get a buzz item on the left menu, but until you create a public profile none of your information (such as follower/followee lists) has been made public.
For you (and others like you and I who picked 'no'), clicking 'turn off buzz' does seem to actually turn off the service for all intents and purposes. No info is made public. Sure, some people 'auto-follow' me, but only those who already had your email address. No real harm done.
That's just silly. A confidence interval by definition is a range; the commenter is arbitrarily choosing to post only the low end of that range. If the high end were posted instead, Washington's lead would look that much more impressive.
That's not to say the math is useless; a better statement (which could have been supported by the data) would have been "The difference between CA and WA is less than the measurement margin of error given WA's small sample size".
I don't mind smart people with limited relevant experience having opinions or even defending them vigorously. However three passages in particular struck me:
Mr. Deese was not the only one favoring the Fiat deal, but his lengthy memorandum on how liquidation would increase Medicaid costs, unemployment insurance and municipal bankruptcies ended the debate.
Every time Mr. Deese ran the numbers on G.M. and Chrysler, he came back with the now-obvious conclusion that neither was a viable business, and that their plans to revive themselves did not address the erosion of their revenues.
How is he drawing his conclusions? Does he really have a deep enough understanding of the underlying model when he 'runs the numbers'?
From there, he can make it quickly to the press office to help devise explanations for why taxpayers are spending more than $50 billion on what polls show is a very unpopular bailout of the auto industry.
I'm sure the NYT is not giving us the whole story, but there's a piece of me that worries that what makes this guy successful is not intelligence (though he certainly may be smart) but charisma. Just because you can sling a good presentation / memorandum and speak eloquently about it does not mean you should be setting critical government policy about tremendously complex problems.
That may be true for 'most' founders (although I suspect it is far from universal), but I think it is fairly evident that Peldi has chosen the latter path. See:
http://www.balsamiq.com/blog/?p=587
Peldi doesn't seem to be viewing Balsamiq as a stepping stone to getting rich and working on his next project in pursuit of some unknown end state; for him, Balsamiq IS the end state (or he hopes it will be).
If you really truly enjoy what you're doing - and it is clear he is - is there really any point to suffering some optional pain in exchange for a greater payout at the end?
(Standard caveat - Peldi, if you're reading this and I am way off base, please feel free to correct!)
I had an English teacher in high school who was highly attentive to this sort of construct. He would return many a paper with "VPR" marks sprinkled throughout for 'vague pronoun reference' and points deducted accordingly. Certainly a common error.
Yes, that is the jist of the last sentence. However that was clearly not the message the bulk of the post was intending to express:
He [Charlie Miller] did mention, in his interview with Ryan Naraine, that Chrome was pretty much in another league. Their 'sandbox' makes it extremely difficult to exploit
IANAL, but it is my understanding that at issue here is the deal would (could) have created / extended a monopoly. Antitrust in the US does not disallow monopolies, per se, as you note; however, it does disallow creation or furthering of a monopoly via contracts, M&A, conspiracies, collusion, etc.
From US Code Title 15, Chapter 1, § 1:
Every contract, combination in the form of trust or otherwise, or conspiracy, in restraint of trade or commerce among the several States, or with foreign nations, is declared to be illegal.
The other sections of that chapter discuss some specifics (such as §18, which specifically covers M&A) and there is a wealth of case law backing it up and clarifying, as well.
I'm not sure Joel wrote about this to brag; at the very least, he wrote about this because it made for an interesting / relevant entry for his monthly Inc.com article.
I agree that it might come off a bit as preening, but to be fair Joel's column hasn't stayed away from mistakes and bad decisions he's made as well. As such I take the tone as being closer to "this is what I've done and why I've done it" than "look at this awesome thing I did".
I find that the the weeding your garden example has a more general analogue outside of content: managing code debt. The more mature a code base and the more hands that touch it, the more often little shortcuts, design decisions that lead to later refactoring, incomplete or incorrect documentation, etc. will show up; these are like "weeds" in your "software garden".
As with letting weeds in the content choke out the actual signal, not taking the time to do code weeding will ultimately lead to buggy, unmaintainable code. Of course another approach is to try and avoid code weeds in the first place (e.g. TDD), but at some level code weeds / debt is inevitable over time for any sufficiently mature code base.
Does YC have some particular connection to the Web 2.0 Summit or is this simply a reflection of YC's leadership in the "companies that have developed nifty Web 2.0 sites (with only a little cash up front)"-funding business?
But at the same time, as a small developer, you have very little time to spare for support. Time spent getting the game working for one person is time not spent making a new game for everyone. You will need to develop a sense of when the time lost helping a person is not worth it, either because you won't be able to solve their problem or because they will not able to implement the fix you provide.
...
Remember: It's only worth the time to do tech support if you have the chance to, in a reasonable amount of time, fix a problem and make a loyal customer. If you realize that, at the end of the road, you aren't going to end with a happy person and a working product, end the conversation as quickly and pleasantly as possible.
In that context, I think his approach is very rational. If you pushed him, he'd probably agree that more often than not the issue is in his code (even if it's just a question of inadequate error handling). However, if the problem is only seen by a single user and will be a significant investment to try and fix, then it's simply not worth the time when he could be working on a new game, a port, or even a different problem that has been seen by multiple users.