The reverse is also just as true, of course.
It doesn't mean you know what feature is going to be delivered in 32 weeks in the future though.
Software is different from most other branches of engineering in that it is far less limited by physics and that the requirements are far harder to define.
For example the requirements for a bridge or a building are relatively straight forward (size, load capacity, climatic resistance etc etc). That's not to say that designing the bridge or the building is necessarilly simple (though it probably is for small bridges and houses because we have centuries of experience with them) but even for complex construction projects the requirements are relatively simple even if the implementation may be very complex (think channel tunnel or mileau viaduc).
In software there are much flexibility that most customers don't know what they want until they see it. They generally aren't capable of saying up front what they really want (and when they try to they are often wrong and end up saying "yes, that's what I said I wanted but now I can see it it's not good".
It is about mindset. Of course I do not mean that a programmer should suddenly be responsible for "doing everything."
What I mean is, the programmer should have as their personal mission the writing of the highest possible quality code that is ready to go to production as quickly as possible with a minimum of rework. And crucially, you have to be able to provide a realistic and reliable estimate of when your work can be expected to be completed. This ability is gained through experience.
Working well with project/product/design/etc. is part of being a good programmer. It is not enough to simply be a "good dev" - you must also be able to explain what your code does, why it does it that way, and any potential tradeoffs or flaws in design/implementation. If you cannot critique your own code in this way you are not a senior engineer. When you work with other people part of being senior is being willing to be held accountable.
Hopefully this makes what I mean more clear. It is about mindset.
Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng...
From The Unwritten Laws of Engineering, quoted in the article:
Promises, schedules, and estimates are necessary and important instruments in a well-ordered business. Many engineers fail to realize this, or habitually try to dodge the irksome responsibility for making commitments. You must make promises based upon your own estimates for the part of the job for which you are responsible, together with estimates obtained from contributing departments for their parts. No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors."
Also from the article:
Avoiding responsibility for estimates is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.”