Anyway, I was reading this article titled Things I Think John Carmack Said At QuakeCon and was really struck by the truth of this paragraph.
"It used to be a joke at id when someone would say, 'How long would something take?' 'Two weeks.' Because a programmer can get anything done in two weeks," Carmack joked. "Fourteen days, if you stayed up, you could just get anything done in that time. Of course, it doesn't actually work out like that. In any of the projects I've worked on, I've never failed in any of them, but I've never been on time."
It's true! When you're assigned to a programming task you've never done before, you have some idea what needs to be done, but 99.9 percent of the time, there's something that comes up that you didn't anticipate that is a real bitch to work around. The 0.1 percent is for the few times that I write a bunch of code, compile it, and miraculously it just "works". It's a great feeling, but it makes me really nervous at the same time because there's no such thing as "bug free code".
For me, one of the worst things to experience on the job is having a manager come in to your office and say, "I want you to work on [this]. It's extremely critical that it be done on time. How long will it take you to do it?". Ugh! I want to reply, "I don't know. How long will it take for you to train to be able to clean and jerk 500lbs over your head?".
Probaly the best manager I ever had would ask me how long I think it would take and then would triple it for the product planning sheet. It was usually dead on.
Good managers are so hard to find.
1 comment:
I know someone who used to figure that an eight-hour workday meant at most five or six hours of actual work, so that "it will take us forty hours to do this" meant a week and a half. That usually came out right.
I still haven't figured out the answer to "how do you know when you're done?", though.
Post a Comment