He doesn't mention emacs-starter-kit, so as a community service, I'm pointing it out. I had used Emacs for a long time, and switching to this made my life much easier. And my customizations still worked fine (although I was able to remove many of them)
I would label it as "essentially correct". The odds are very slim that you will
a) Find gold in California
b) Become a rock star
c) Win a lottery
d) Strike it rich and famous as an 'entrepreneur'
e) Achieve above average, long-term gains by trading tulips
Yet, the selection bias that promotes these dreams doesn't deter anyone who is going to go that route.
'The Little Schemer' is not intended to be a tutorial on Scheme. To quote the preface, "The goal of this book is to teach the reader to think recursively". Similarly, the other books in the series have well-defined goals.
When I first read the comments here, I imagined Gabriel knocking his head on the wall, Charlie Brown-style. But the more I think about it, the more I think he might appreciate the layers of absurdity.
"Then I added a little padding time because everything always takes longer than expected."
If you are implementing something which is almost exactly like something you personally have implemented before, then your estimate will be almost exact because you should have tracked how much time you spent on the original ... and assuming that too was a re-implementation of something you'd already done the R&D on. IOW, this is at least your third time.
If you are implementing something for which you have references that are very close to what you are building (but you didn't build it) and you already understand them, then you can make a reasonable estimate of the time to implement. In this case the OP's advice works .... add some padding. The more granular your breakdown of the problem, the better you estimate will be.
But when there is R&D on the problem, you are not talking about 'padding', but 'factors'. If you are doing something that is new to you, but you think you have (or can find) decent references, then you can estimate based on how you hope it will go (based on your breakdown of the problem), and multiply by 2.
If you can't find references, then factors of 3 or 4 beyond your ideal development scenario will be more realistic.
It's worth noting that if you are in the last scenario, then you probably weren't a good choice for the project. Also, 'agile' pricing would be better, but either fixed pricing or giving clients some idea of what to budget is more typical.
I use a slide rule regularly. It is neither quick nor accurate, but it is useful in the same way that making approximate calculations in your head is useful. That is to say, added precision doesn't help you understand the relationships in a problem and speed can obscure some of what's interesting. However, this kind of thing is only entertaining and instructive for curious people.
"most children classified as 'dullards' by the education system just don't understand how to cope with the traditional model of teaching"
Can't say I was ever classified as a 'dullard' but my grade school scores indicated that I was. Even when I went to college, after a stellar start, my performance deteriorated. After considerable time, I was able to go back to attend a world-class university and excelled, largely because I had learned what the goal actually was. When I was young, I mistook the 'traditional model of teaching' for learning, which was something I was quite good at. The goal of being the recipient of 'teaching' (ie, a student) is to achieve higher scores than everyone else. In fact, learning is potentially an impediment because it requires critical thinking, and you won't get far as a student with that. Some students understand the real goal and do quite well. And some may even learn at the same time. Many others are simply frustrated or turn off completely, as I did.
Not at all. I agree with Spolsky about needing two monitors for GUI work, but otherwise more screen real estate pretty much equates with shifting your focus between contexts, which in my experience is what kills productivity. Knowing what you are doing is the biggest boost to productivity.
I suspect that the 'calculator age' has caused kids (and kids that have now grown up to be parents) and maybe educators to over-value an increase in significant digits in calculations. It's interesting that the method of multiplication illustrated in the article is referred to as 'new' since when you use a slide rule, you operate in this way anyway. And to echo Hans Bethe, this is often "good enough".
If it makes you feel any better, the guy is talking about 1982. If you were 'in' to computers at all as a hobbyist during that era, it typically meant low-level tinkering. Not at all unusual. My own personal stories from that period sound today like I was a young engineering genius, but I wasn't. The same kids who learn Rails now were the ones doing assembly back then. And plain ol' luck is still as relevant today. And, of course, persistence.
Yeah, I caught the 'tort reform' misdirection as well. Also, I think earns north of $170,000 a year, which made his turning down the insurance 'on principle' a bit ridiculous.
Also, this is of course over and above what my company pays in premiums. Altogether it is a significant amount of money for a family of four that has no major medical problems. For a small business, the overall burden is problematic.
Something to add to the discussion: She says "my recent M.R.I. cost $1,300 at the “retail” rate, while the rate negotiated by the insurance company was $700."
I have insurance and the insurance company (BCBS) will only pay what it thinks is appropriate for a service, not some negotiated rate. That is, if the doctor, hospital, or lab says that it costs $1,300, but the insurance company wants to pay $700, I'm stuck for the other $600. The result is that in order to meet the high deductible (at which point I no longer have to pay out of pocket like this), I pay way beyond the amount of the deductible since only the approved rates are applied. In practice, I end up paying out 175% or more of the deductible amount.
I suspect that our experience will soon become the norm, if its not already.
Thanks for sharing your thoughts. This kind of analysis is required for any service business. Having done so for our company, I have the following observations on 'What to do?":
Scale -- Bingo! The goal is to make the fixed overhead (incl employees) an increasingly smaller percentage of revenue. But to handle the increased revenue (ie, workload) you have to concentrate on increasing efficiency/productivity. This has a lot of influence on decisions about process. Obviously, the more routine those processes are, the cheaper (and more easily replaced) the labor can be. Also, if the work is done under a fixed price contract, you can achieve a greater effective hourly rate if you are efficient and manage risk well.
Charge more -- "charging more pushes away your existing client base". This is not such a bad thing if you have your eye on 'scaling' (ie bigger projects). Bigger clients have deeper pockets (although they also have more unique needs, which introduces more risk).
Build a product -- See Nassim Taleb's discussion about 'scalable work' in "The Black Swan". The odds aren't good that this will pay off.
I'd add to that having already been paid for it and needing to hand off to others to maintain. I guarantee that the next project you do will be at a whole new level.
https://github.com/technomancy/emacs-starter-kit
WARNING!!! The version in git is for Emacs 24. You will need to actually download the earlier version to use with Emacs 23.