Graduate student in statistics at Duke University. Former dev.to employee. I like to blog about data science on my Medium publication, perplex.city, and on dev.to
In terms of allocating time, I've found that in the real world I'll occasionally have underestimated how long something will take by entire orders of magnitude whereas in school, I always had a decent sense of how long something should take (perhaps because, with rigid deadlines, there was only so long something could take).
I once read (in a book I'm now forgetting the title of) about some project manager who, given a time estimate for a task by one of his teammates, would always double the number in his mind and increase the time unit -- so something that should be done in "2 days" would actually take 4 weeks. I think the idea was somewhat tongue-in-cheek, but you get the point.
Senior software developer at Amazon Web Services. I work on the AWS Serverless Application Repository and AWS SAM. I’m passionate about writing quality software and teaching others how to do the same.
Location
Seattle, WA
Education
BS Computer Engineering, Minors: CS and Math
Work
Sr. Software Development Engineer at Amazon Web Services
Great callout Walker. This blog entry is actually an excerpt from a talk I gave internally at Amazon. During that talk I discuss software estimation in a little more detail. I recommend reading the essay, The Mythical Man-Month, which is one of the essays in the famous book with the same title. The essay is short, but it does a great job summarizing several reasons why software is so incredibly difficult to estimate.
In the talk I said inexperienced software engineers can underestimate a project by as much as 4-6 times(!!) since they generally don't even think about the cost of tasks required to really productionize a service, such as unit/integration tests, metrics/monitoring, oncall dashboards, etc.
I definitely know of managers who apply their own padding to their developers' estimates before communicating them up.
Graduate student in statistics at Duke University. Former dev.to employee. I like to blog about data science on my Medium publication, perplex.city, and on dev.to
Interesting -- will check out the essay. There's a similar sentiment in data science, which I'm studying, which says that 90% of any project is simply acquiring and cleaning the data. All those fancy predictive techniques only come into play in the last mile.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In terms of allocating time, I've found that in the real world I'll occasionally have underestimated how long something will take by entire orders of magnitude whereas in school, I always had a decent sense of how long something should take (perhaps because, with rigid deadlines, there was only so long something could take).
I once read (in a book I'm now forgetting the title of) about some project manager who, given a time estimate for a task by one of his teammates, would always double the number in his mind and increase the time unit -- so something that should be done in "2 days" would actually take 4 weeks. I think the idea was somewhat tongue-in-cheek, but you get the point.
Great callout Walker. This blog entry is actually an excerpt from a talk I gave internally at Amazon. During that talk I discuss software estimation in a little more detail. I recommend reading the essay, The Mythical Man-Month, which is one of the essays in the famous book with the same title. The essay is short, but it does a great job summarizing several reasons why software is so incredibly difficult to estimate.
In the talk I said inexperienced software engineers can underestimate a project by as much as 4-6 times(!!) since they generally don't even think about the cost of tasks required to really productionize a service, such as unit/integration tests, metrics/monitoring, oncall dashboards, etc.
I definitely know of managers who apply their own padding to their developers' estimates before communicating them up.
Interesting -- will check out the essay. There's a similar sentiment in data science, which I'm studying, which says that 90% of any project is simply acquiring and cleaning the data. All those fancy predictive techniques only come into play in the last mile.