Always Multiply Your Estimates by π (2013)

This reminds me of my game development job I had years back.

I was new to the field (but not new to software development) and there was this small software team doing programming tasks for the game. The lead developer was concerned on my performance after a few months I was there.

I remember him drawing an image excatcly like the second picture in this article (an arrow going from A to B). He said that my performance was very poor, and then he drew another picture that was like the circle in the article.

The way I worked was searching for a solution, going wrong direction a few times, asking designers for more information and then eventually landing on a solution (that worked, and users like it).

But I was told this is wrong way of doing software. I was not supposed to ask advice from the users (because the team "knew better").

He also told me that a good software developer takes a task, solves it (goes from A to B), and then takes another task.

After a few weeks I was fired from that job.

To this day I'm still baffled by this. The company was really succesfull and everyone knew how to make software. It seemed like a very harsh environment. Is it like this in the top software companies everywhere? Like the super-pro-developers really just take a task and solve it without issues?

There are tasks you are experienced with that you can pretty much jump on and just do them, but there's also the other 90%.

What's weirdest about your story is that you were laid off a few weeks into your job. People usually get more time to get the hang of it even if they are senior, so I would mostly assume that it was a cultural fit rather than performance.

Some outsourcing/service (billed by the hour — which explains it for the most part) companies would look for very strict delivery cadence with focus on exactly the process you describe, but you'd be unlikely to have contact with the user in that case (just the customer).

Most importantly, if you ever get fired, be sure to ask for the explanation so you don't end up being baffled.

To clarify I was laid off few weeks after the feedback. I was on the job for a few months.

I asked for the reason, and it was indeed the performance.

It was just the diagrams in the original article that reminded me of this. It just didn't make any sense to me that one would "just solve" a problem at hand without considering other options.

But in my (15 years of) experience the "pi factor" is indeed quite accurate as there is always something surprising that comes up along the way, be it specification changes or technical issues.

To me, 3x is not "accurate" at all: it might be the approximate average, but I've worked on tasks that take anywhere from 0.1x to 10x the original estimate (or rather, a guess). Some were even infinite, in that they were scrapped when the real cost was uncovered.