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 admit my knowledge of stateside engineers in the large defense contractors is secondhand; trying to convert known deployed salaries and known eng and pm salaries at small product companies selling to usg.
Substitute working for a fund on the dev side and double my numbers to make the original argument stronger.
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.
It's not FUD. I don't have a Google Profile, but Buzz was automatically activated (even though I clicked the no/cancel/whatever-it-said-because-it-totally-ignored-me-anyway button) when I logged into GMail.
I don't care if it was made public. If I had a profile, and it was made public, that would not have made things better. That would be worse. 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 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:
I've been wondering the same thing: why does it bother me so much that Buzz auto-follows frequently-emailed contacts, but it doesn't bother me that gchat automatically adds frequently-emailed contacts? I think it might be because having contacts added in gchat doesn't mean I'll actually be communicating with them, whereas auto-follow does mean that some communication will take place... I'm not sure though. Also, I guess that having a strictly professional contact's name sitting in my gchat contacts list is different than that person being notified that I'm following them.
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!)
Hi gwc, Peldi here. You go it exactly right, Balsamiq is not a 'startup' in the pg sense, but rather a lifestyle business...I hope to be working on/for Balsamiq Studios for as long as possible, and to continue to have a great time doing it. The goal is to build a small company of rock-stars who do great work, delight our customers and love to work together every day. What's not to like? ;)
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.
Do you mean you-singular, or are you addressing everybody in the thread who used a pronoun that could have referred to teachers. I think he meant that they fed the monkeys bananas because the teachers were hungry.
I don't remember having teachers who focused on that, and I really wish one of my coworkers had.
After a few minutes of talking to him it's very hard to figure out what he's saying because he'll have dropped nouns all together in favor of pronouns. This can get very confusing when talking about technical stuffs.
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
Two hikers are running from a grizzly. One of them asks, "Do you really think we can outrun the bear?" The other says, "No, but I think I can outrun you!"
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.