Evaluating ones abilities.
-
I tend to underestimate myself. Barring the occasional snafu, my estimates run conservative - very, to the point where clients expect if I say a day, I'll have it in an hour. If I need a week, it means a day or maybe a day and a half. It's like that. People consistently tell me I'm fast, maybe in part because of the above, but I even get it here at codeproject sometimes, and other programming venues I haunt. I'd be foolish not to acknowledge it, even if it feels awkward doing so. Realistically, even if I don't change how I estimate to my clients, I'd like to be able to more accurately assess myself. Confidence plays a part, and I get imposter syndrome a lot. Sometimes I'm confident, because intellectually I know I'm in my element, but over all I tend to magnify my own shortcomings and short sell myself in terms of what I can deliver. How the heck do you do it? It's far from the worst thing in the world, being underestimated, even by myself. It has advantages, like me not going over my estimates. Still at the same time it would be nice if I knew what a project was actually going to cost me to deliver.
To err is human. Fortune favors the monsters.
My experience has been that over-estimation beats under-estimation every time (duh). I'm pretty good at estimating work on my own code. Unfortunately more than half of my job is supporting products written by others, and estimating work there is difficult. The most practical skill I've developed over my career is managing disparate tasks efficiently. Some short tasks I do immediately so that they're not taking any of my attention. If part of a long task is difficult or requires concentration, I'll ignore everything else until I get to a good stopping point. If a lot of items have accumulated in the meantime, I'll knock all of them out just to rid myself of the distraction. While this approach works for me, obviously YMMV.
Software Zen:
delete this; -
My experience has been that over-estimation beats under-estimation every time (duh). I'm pretty good at estimating work on my own code. Unfortunately more than half of my job is supporting products written by others, and estimating work there is difficult. The most practical skill I've developed over my career is managing disparate tasks efficiently. Some short tasks I do immediately so that they're not taking any of my attention. If part of a long task is difficult or requires concentration, I'll ignore everything else until I get to a good stopping point. If a lot of items have accumulated in the meantime, I'll knock all of them out just to rid myself of the distraction. While this approach works for me, obviously YMMV.
Software Zen:
delete this; -
I tend to underestimate myself. Barring the occasional snafu, my estimates run conservative - very, to the point where clients expect if I say a day, I'll have it in an hour. If I need a week, it means a day or maybe a day and a half. It's like that. People consistently tell me I'm fast, maybe in part because of the above, but I even get it here at codeproject sometimes, and other programming venues I haunt. I'd be foolish not to acknowledge it, even if it feels awkward doing so. Realistically, even if I don't change how I estimate to my clients, I'd like to be able to more accurately assess myself. Confidence plays a part, and I get imposter syndrome a lot. Sometimes I'm confident, because intellectually I know I'm in my element, but over all I tend to magnify my own shortcomings and short sell myself in terms of what I can deliver. How the heck do you do it? It's far from the worst thing in the world, being underestimated, even by myself. It has advantages, like me not going over my estimates. Still at the same time it would be nice if I knew what a project was actually going to cost me to deliver.
To err is human. Fortune favors the monsters.
Delivering early to a client/employer will eventually come back and bite you, as you have found. They then set timeframes that you cannot possibly meet, they get shorter and shorter because every time you meet a short deadline they will continue to shrink them. I would hold back on delivery to a time closer to the deadline. What I never did was shorten my estimation of the time it would take to deliver. Estimation: Break down to the smallest buildable blocks Estimate the hours for each block Add the hours - double it and double it again. If billing then add the time for the estimation.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
I always overestimate and my team has adjusted. For example, last Monday afternoon I was asked when I could have some changes done. I said, 'by the end of the week'. The followup meeting was promptly scheduled for Thursday morning. :|
"Go forth into the source" - Neal Morse "Hope is contagious"
So you work 4 days a week :laugh:
-
I tend to underestimate myself. Barring the occasional snafu, my estimates run conservative - very, to the point where clients expect if I say a day, I'll have it in an hour. If I need a week, it means a day or maybe a day and a half. It's like that. People consistently tell me I'm fast, maybe in part because of the above, but I even get it here at codeproject sometimes, and other programming venues I haunt. I'd be foolish not to acknowledge it, even if it feels awkward doing so. Realistically, even if I don't change how I estimate to my clients, I'd like to be able to more accurately assess myself. Confidence plays a part, and I get imposter syndrome a lot. Sometimes I'm confident, because intellectually I know I'm in my element, but over all I tend to magnify my own shortcomings and short sell myself in terms of what I can deliver. How the heck do you do it? It's far from the worst thing in the world, being underestimated, even by myself. It has advantages, like me not going over my estimates. Still at the same time it would be nice if I knew what a project was actually going to cost me to deliver.
To err is human. Fortune favors the monsters.
You obviously are not subject to the Dunning Kruger Effect. Those people overestimate their capabilities because they don't have the ability to accurately estimate what they don't know. Competent people know what they don't know, so underestimate accordingly.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
-
I tend to underestimate myself. Barring the occasional snafu, my estimates run conservative - very, to the point where clients expect if I say a day, I'll have it in an hour. If I need a week, it means a day or maybe a day and a half. It's like that. People consistently tell me I'm fast, maybe in part because of the above, but I even get it here at codeproject sometimes, and other programming venues I haunt. I'd be foolish not to acknowledge it, even if it feels awkward doing so. Realistically, even if I don't change how I estimate to my clients, I'd like to be able to more accurately assess myself. Confidence plays a part, and I get imposter syndrome a lot. Sometimes I'm confident, because intellectually I know I'm in my element, but over all I tend to magnify my own shortcomings and short sell myself in terms of what I can deliver. How the heck do you do it? It's far from the worst thing in the world, being underestimated, even by myself. It has advantages, like me not going over my estimates. Still at the same time it would be nice if I knew what a project was actually going to cost me to deliver.
To err is human. Fortune favors the monsters.
The way Scotty puts it, always give yourself a wide berth. If you deliver before, okie dokie, but if you need more time...well that's why we give ourselves 4 times as much time. And it's ok to request even more time (if you have several projects, nobody can expect miracles)
-
I tend to underestimate myself. Barring the occasional snafu, my estimates run conservative - very, to the point where clients expect if I say a day, I'll have it in an hour. If I need a week, it means a day or maybe a day and a half. It's like that. People consistently tell me I'm fast, maybe in part because of the above, but I even get it here at codeproject sometimes, and other programming venues I haunt. I'd be foolish not to acknowledge it, even if it feels awkward doing so. Realistically, even if I don't change how I estimate to my clients, I'd like to be able to more accurately assess myself. Confidence plays a part, and I get imposter syndrome a lot. Sometimes I'm confident, because intellectually I know I'm in my element, but over all I tend to magnify my own shortcomings and short sell myself in terms of what I can deliver. How the heck do you do it? It's far from the worst thing in the world, being underestimated, even by myself. It has advantages, like me not going over my estimates. Still at the same time it would be nice if I knew what a project was actually going to cost me to deliver.
To err is human. Fortune favors the monsters.
The only way you can accurately provide software estimates is by using standard Software Engineering practices such as Function Point Analysis. Function Point Analysis relies on the use of a metric system in which every project you complete, you then record the metrics that were apparent in the endeavor. Over time you will generate metrics for small, medium, large, and huge projects that can then be used as comparative standards to measure anew project accurately. Function Point Analysis is well described in the Bible of Software Development, Stephen McConnell's, "Rapid Application Development (1996). However, there are more modern ways to perform this task, which have been developed in The Royal Netherlands. I have used the original techniques myself with great accuracy. Unfortunately, most technical managers and clients aren't very understanding about Software Engineering as most of these people are just idiots. But you will get those people who will be very appreciative of your increasing accuracy...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
The only way you can accurately provide software estimates is by using standard Software Engineering practices such as Function Point Analysis. Function Point Analysis relies on the use of a metric system in which every project you complete, you then record the metrics that were apparent in the endeavor. Over time you will generate metrics for small, medium, large, and huge projects that can then be used as comparative standards to measure anew project accurately. Function Point Analysis is well described in the Bible of Software Development, Stephen McConnell's, "Rapid Application Development (1996). However, there are more modern ways to perform this task, which have been developed in The Royal Netherlands. I have used the original techniques myself with great accuracy. Unfortunately, most technical managers and clients aren't very understanding about Software Engineering as most of these people are just idiots. But you will get those people who will be very appreciative of your increasing accuracy...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
I'm fairly good at estimating whole projects for some reason. It's the individual tasks where I overestimate how long they will take.
To err is human. Fortune favors the monsters.
-
I'm fairly good at estimating whole projects for some reason. It's the individual tasks where I overestimate how long they will take.
To err is human. Fortune favors the monsters.
Function Point Analysis is based on the individual tasks, so it will be able to help you...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Function Point Analysis is based on the individual tasks, so it will be able to help you...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Cool thanks! I'll look into it.
To err is human. Fortune favors the monsters.