Consider how you would estimate anything else. Say you want to retile a kitchen. Would you expect someone to just say, I could do this in a weekend? Because, that is what shows typically seem to need?
Or would you feel more comfortable asking how much they will have to actually do? For example, they would have to disconnect the fridge and move it out of the way, disconnect the oven and move it out of the way, then buy enough tile and mortar for the space, which would be X boxes, and then clean and do the work.
Benefit of this way is when you come back, if none of those tasks has been done on day two, you know it isn't likely to get done on day two.
So, try and use the same approach for programming. Don't just say "it will take 2 weeks." Instead, say, it requires updating X component, modifying Y tests, incorporating Z new dependencies, etc...
As a team, you can try and portion size estimates on each of these. But don't spend too much time on that. Experience is the secret, not perfect estimates. (That is, the more things the team has done, the better they will estimate what they can do.)
Right, my current approach, which works fairly well, is to spend some time writing out a couple approaches and splitting them it out into coherent delegatable tasks. This results in a 2-3 page doc that I can check with other engineers and business stakeholders to be sure it does what we really want it to. It also means we notice if an assumption we made is untrue and we need to re-think the scope or approach of the project.
I’m just worried that at some point, somebody will come along and ask for an estimate and I’ll say I cannot give one and that this means I am not really a professional.
Just be sure to do retrospectives on these documents and I'd wager that you are beyond any skill that I can lay claim to. Honestly, sounds like you are already beyond my skill levels.
Can't say if that helps strengthen your claim to professional, but that practice certainly sounds professional to me.
Or would you feel more comfortable asking how much they will have to actually do? For example, they would have to disconnect the fridge and move it out of the way, disconnect the oven and move it out of the way, then buy enough tile and mortar for the space, which would be X boxes, and then clean and do the work.
Benefit of this way is when you come back, if none of those tasks has been done on day two, you know it isn't likely to get done on day two.
So, try and use the same approach for programming. Don't just say "it will take 2 weeks." Instead, say, it requires updating X component, modifying Y tests, incorporating Z new dependencies, etc...
As a team, you can try and portion size estimates on each of these. But don't spend too much time on that. Experience is the secret, not perfect estimates. (That is, the more things the team has done, the better they will estimate what they can do.)