I've been writing software for 40+ years at most every level and in dozens of different languages... and everything in this article is either things I learned the hard way decades ago, or have spent decades telling people.
The deadline part is one of the most jacked-up parts of the entire process in that clients these days have utterly unrealistic expectations... and I've been using that as a litmus test as to whether or not to even take on a client. If they balk at my time estimates, I don't even bother pursuing them further anymore.
One of the best ways to handle time estimates is to take a lesson from real engineering; specifically over-provisioning.
It's the #1 mistake I see people make, is saying how long it would REALLY take and/or should take, without any provision for if something goes wrong. Learn from Scotty!
Kirk: "Mr. Scott, are you always in the habit of doubling your time estimates?"
Scotty: "How else do you think I got my reputation as a miracle worker!"
I'd rather say something is going to take three weeks and deliver in two, than say two weeks and have it take 15 days. Even if you're only one day over, you look stupid. You overestimate the time allowing room for corrective action, you look like a pro every time.
"A good engineer is always a wee bit conservative, at least on paper." -- Scotty