I think there is a bigger picture takeaway to be made here, but I'm not sure if I can phrase it too well. The Douglas Adams "I love the whooshing noise [deadlin

I think there is a bigger picture takeaway to be made here, but I'm not sure if I can phrase it too well. The Douglas Adams "I love the whooshing noise [deadlines] make as they go by" quote is perhaps a good introduction. I think the general concept starts out in education, deliver this by date that or there's consequences. And in that moment, the consequences tend to be very real, and if you prefer a smoother ride, not something you want to deal with. What starts out as a way to teach both discipline and whatever it is you're currently learning will then go on to accompany you in your professional life. In reality, in software development all deadlines are pretty much arbitrary. Sure, there is profit to be made if you move quicker, but there's considerably more profit to be made if you move in the right direction instead of just moving quickly. The latter tends to often be overlooked in the management style outlined in the article. I think the healthy choice is to estimate, but not stress over the situation. Your estimate is not a promise, and make that very clear when you do give one. If your estimates are taken to be promises, it isn't probably an environment you want to work in for long.