I look at the task in hand and take multiple variables into consideration:
Have I written similar before?
Does it require anything new I'm not familiar with?
What language(s) would be required? (Fluency and knowledge etc)
What is the deadline for this?
Is it just me working on it or is there other devs on the project?
From these variables I'm normally able to give myself a rough estimate on how long, especially with the entities of have I done it before and the familarity, we all know bugs are a giant pain in the ass at times if the answer to both of these questions are yes then it can both slowdown or speedup a process.
As Benjamin mentioned below I sometimes double the time depending on how hard or simple I feel the project could be. I often find that the code side of things takes up roughly 65% of the work, spending more time writing documentation, tests and in some cases a how to use guide for the client can take up a substantial amount of time.
Well when something breaks or a bug is caused it all depends on the type of issues. I normally mark them from severetiy between 1-10. 1 being like a typo and 10 being holy crap everything is on fire what did I do wrong?!!?!?
I'll focus more on the high priority bugs first and find that they can take a lot longer, even if its something very simple causing the issue I'll sometimes find that the period of time to find the actual cause is very long. I can't really guess whether or not bugs is going to happen before I start the actual project, however I can take a little guess on whether or not something may or may not be an issue down the line.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I look at the task in hand and take multiple variables into consideration:
From these variables I'm normally able to give myself a rough estimate on how long, especially with the entities of have I done it before and the familarity, we all know bugs are a giant pain in the ass at times if the answer to both of these questions are yes then it can both slowdown or speedup a process.
As Benjamin mentioned below I sometimes double the time depending on how hard or simple I feel the project could be. I often find that the code side of things takes up roughly 65% of the work, spending more time writing documentation, tests and in some cases a how to use guide for the client can take up a substantial amount of time.
How about the buffer to cater for accident?
Well when something breaks or a bug is caused it all depends on the type of issues. I normally mark them from severetiy between 1-10. 1 being like a typo and 10 being holy crap everything is on fire what did I do wrong?!!?!?
I'll focus more on the high priority bugs first and find that they can take a lot longer, even if its something very simple causing the issue I'll sometimes find that the period of time to find the actual cause is very long. I can't really guess whether or not bugs is going to happen before I start the actual project, however I can take a little guess on whether or not something may or may not be an issue down the line.