i kinda started thinking about how project estimation and deadlines fit into our process of software development. For example, say you're building some feature

i kinda started thinking about how project estimation and deadlines fit into our process of software development. For example, say you're building some feature and you guesstimate it'll take you 3 weeks to implement, maybe it's non trivial but not too hard. How do you convince yourself, or your stateholders, that spending an extra 2x-3x of time would result in delivery a better product. in other words, if all software was built with the bare minimum amount of time to ship, i think we'd miss out on a lot of quality and a bunch of features that weren't thought out enough. so there are people that somehow are able to stop this rushed process of development and posit that the solution requires additional thought and planning. They go slower to move faster and knowing how to do this I think is a mark of an excellent engineer. anther interesting element to this is that when one is granted the additional time, the outcome progresses our field. As an example, someone spent _a lot_ thinking about how to implement a concurrent wait-free list data structure. how are you to convince your PM that we have to delay the "onboarding popup" feature because you'll be spending the next 3 months investigating wait free data structures.