You know you should sit back and reason out what the problem might be (it worked before -- what's gone wrong?) but the rookie reflex is to start coding right away and to slap something -- ANYTHING! -- in that might make things right. That should make the yelling stop!
When that doesn't work, another patch is put in. Then another, and another, corrupting data and making things even worse!
...and so the cascade of 'Hail Mary' programming fixes is put in place until someone finally pulls the plug and yanks the poor, choking programmer aside for a breather.
It's rare for programmers to have a 'do or die' moment and few are prepared for or recognize it when it comes. If you ever feel the urge to rush: Don't.
That ought to be printed out in 122 point font and pasted on every wall behind every monitor. Take your time to do it right, that way you don't have to do it 'n' times but only once. A quick fix usually only leads to more trouble down the road.
You could think of the entire organization as the athlete though. Especially in programming, the organization is unaware of exactly how things really get done, it just has certain reflexes. Under crisis it may feel the need to switch modes.
Panic: OMG the project is late! Hire more programmers! Buy someone else's thing and try to make it work!
Choke: What we're doing isn't working -- we need to hire a lot of consultants, we need more metrics before making a decision, we need to carefully plan out our scaling strategy before we make a prototype...
As for panic, that's more of a sysadmin thing, imo. When a RAID fails to come back after a power failure on the production server, it does take some guts to not start making random stupid moves.