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:
- You will have different skill sets, so you will learn things from each other
- 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.
- Both of you will get to go on vacation without things screeching to a halt.
- 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.