(This post may come off rather naval-gazing. Pardon me. I started it at 5am and I’m not used to waking up this early yet.)

One of the things that took me by surprise when I started programming in the real-world is that nobody has any idea how long anything will take, ever.

Because of that, accurate estimates in the software business are extremely valuable and an engineer who can make accurate estimates is worth her weight in gold. Unfortunately I am still not one of them. I am tremendously bad at estimating.

I would go so far as to say it’s my weakest point as a software engineer. But a wise person once said “Good judgement comes from experience, and experience comes from bad judgement.” So there is hope for me.

I had thought that professional programmers knew exactly what they were going to do and did it, just like in building construction which seems to me, an untrained observer, to often succeed on time. I didn’t even think this was going to be a skill I’d have to develop, just something I would magically acquire.

So what have I tried already to improve at estimating?

Some of the methods I’ve heard are things like “take your best guess, then triple it.” I’ve applied literally that and it kind of-sort of works, maybe half the time. I’ve also heard (and in the past, advocated) ‘give a confidence interval with your estimate’, which doesn’t really help with coming up with an accurate amount of time to complete a task, it just gives the programmer an out when things go bad. “well, I wasn’t confident in that estimates accuracy anyway!” It’s about as useful as giving none at all.

Neither of these are good solutions. Fortunately I’m lucky enough to have worked with some folks that are really good at providing and hitting their estimates. How do they do it? I think the skill is really a function of professionalism, knowledge of the domain and existing software environment, and self-confidence. Just like the good ol’ SDLC, there is no magic methodolgy for generating a correct answer to ‘how long is that going to take?’.

I already said that I’m tremendously poor at estimating, and now I’m saying that estimating is a function of professionalism, domain knowlesge, and self-confidence. So what I’m really saying, to my blog and to you the reader, is that in order to improve on this skill, I need to work on these three things.

The experience in the domain I think is the most important. When I start a new job and get my first couple of tasks, I’ve always struggled because I’m unfamiliar with the surrounding codebase. Why is this dataaccess class written this way? How come all these modules are written this way? Why doesn’t my __ work when I run locally? Those kinds of questions crop up at a really high rate when you spin up on a new environment. When you have some experience under your belt you can come up with answers to those questions faster and also have a better idea what questions are worth looking into and what ones aren’t worth bothering.

Professionalism is also important because you need to be able to work and communicate consistently without getting distracted. It’s really easy to just jump on reddit and lose an hour of your life in the middle of programming something, or see an email asking you to do some tangentially related thing, or take care of some household chore or pay a bill or whatever. Dividing time cleanly and working with full focus takes some effort to learn if you don’t know how to do it already.

Lastly, confidence. (Allow me to get into my armchair for some psychological analysis.) I’ve noticed this in myself and its related to professionalism. When I feel confident that I can accomplish a task, I always hit my estimates. This is both because I show more professionalism by managing time effectively, and because I work with a sense of thoughtfulness that I’d love to have all the time. It’s a type of thing that builds on itself: when you’re feeling confident about some problem you’re working on and you think ahead to some task and proactively fix it before it becomes a problem, your confidence rises even higher. But if something goes wrong, it takes a lot of character to not let it bring down your confidence and take down the whole ‘house of cards’. So its a skill that can be trained just like anything else. Its important to go into the software engineering job every day thinking “I’m going to do my best today.”

I suppose its important to go into every day whether you’re programming or not like that.