How to know if I'm slow or fast at programming?

Question

I understand that it's extremely depends on a particular case, but I really would like to know at least roughly how long a specific task can take for completion to average programmer. Is there any examples of pairs like "project - completion time"?

I'm absolutely ok with my own time-estimation abilities. So is my employer. But my problem is I have never worked in a team and I can not even roughly estimate how long something will take for other programmer.

For example, my last task was to integrate our sales-business software (which is my own product, js+php+mysql) to a local delivery service API: syncing address database, preparing package information and creating specific orders to delivery service, printing labels for packages, sending customers their package info, a web-UI for doing all that. This task took me like 150-170 work-hours to complete.

I always considered myself a slow programmer. But now I wonder how much of speed the development can gain by hiring new programmers. Is there any examples to compare?

Answer 1

Not only is it hard to say, but the answer is not very useful.

Even highly experienced developers find it difficult to estimate how long a given project will take them. This is largely because the programming process consists mainly of understanding the problem fully, and elaborating a solution. The hard part is the full understanding. Writing the program is, essentially, explaining it to the computer. For most purposes the most useful way to estimate a project is to look at how much effort it took to complete a previous, somewhat similar, project.

The reason I say that this is not very useful though is that it very much depends on what one means by finished. As a young programmer I thought that "finished" was when the program was written. Pretty quickly I realised that finished is when the program works, and does what it's supposed to do. In the decades since then, I'be learned a lot about all the different ways a program which is apparently already complete can still not be finished (scaling issues, usability defects, missing or out of date documentation, undefined behaviour, ...)

If you're working as a sole programmer, It's pretty likely that hiring a second person is a good move, for lots of reasons, but here are some of them:

1. You will have different skill sets, so you will learn things from each other
2. You'll keep each other honest. Read each other's code, tell each other when things are not clear, and need better comments, better design, or simply need to be refactorred or rewritten.
3. Both of you will get to go on vacation without things screeching to a halt.
4. The need to get the code base into decent enough shape that your colleague will be able to work on it will also be useful when you yourself need to work on the code a year or two later, when the things now fresh in your mind have faded. See also some of the quotes by BWK here: https://en.wikiquote.org/wiki/Brian_Kernighan

One final note: tests are very important. If you don't have decent automated (e.g. unit) tests, your code has more bugs than you likely realize. It doesn't really matter much how fast you code if your code is buggy. Contrariwise if you think you're slow, perhaps you're simply careful, and think clearly enough to write few bugs.

Answer 2

I don't think that one can accurately predict how much you can save on development time by hiring another programmer, except that there are going to be /some/ time savings - people simply differ too much. You can try a guess by asking a potential hire about the time it took him to complete a project (and what 'complete' meant for them), and compare that to your own speed; but even that is just a guess.

The other thing to consider is that with additional people you will also have to spend time on coordination. For example, imagine that you could work with an identical clone of yourself: your speed would not truly double, as you'd have to spend some time talking with each other instead of writing code.