Like 99% of us here, I work full-time in a non-programming role. (I do work for a software company though).
Count me in on the 1% too. I actually work in a software architectural role, which makes me one who programs AND tells people what they should be working on and how late they should stay to do it. I think I've required my guys to work beyond 40 hours one time, and I was sitting right there with them doing the coding.
Yup. Sadly the programmers don't get to program the all-important development schedule though! In my, admittedly fairly limited commercial experience as a programmer, i've found that crunch time is determined arbitarily by a deadline plucked from the air by commercial needs irrespective of how much work needs to be done by somebody who designs web pages in MS Word.
Again, as Flameduck said, this is a result of poor planning, naive management and/or lack of experience to quantify how much time it's going to take to develop a section of code that solves the problem you need to solve. Commercial needs are generally the need for a product that works. The approach you've described doesn't accomplish that.
However, I understand that you probably don't have a lot of say in it. Just don't get roped into the mindset that "it is what it is" because of the poor decisions your managers make.
The most common flaw in management style is when a manager attempts to negotiate development times with experienced developers. If a competent developer says it's going to be late, it's going to be late. The better course of action is to drop/suspend requirements or consider extending the deadline.