You won't gain that understanding until you actually complete both of those projects.
Industries and occupations that manage estimates well do so because bulk of the work is repeatable and predictable, and the people doing that work have done nearly identical kind of work before. There is some variability involved, but there's only so much of it, and it yields to tried and true classical project management techniques (not the things that pass as "project management" in software companies).
For example, even an inexperienced carpenter, asked to install a door system they haven't seen before, will be able to do it two or three times to get a feel and work the kinks out, and then when they're hired to install it in 300 flats of a new apartment complex, they'll be able to give you an accurate estimate of time and effort required.
With software, almost universally, your project is meaningfully unique, and your workers have never worked on something very similar before. The sources of variability are endless - project-unique challenges ahead, programmers never doing that particular component in that particular combination of languages, libraries and frameworks, in their specific versions, programmers and PMs never working in that specific domain before, etc. - and that's before you add stakeholders changing their requirements every other week.
The understanding one needs to have first is that the software project they're holding a stake in is typically best thought of as R&D effort.