I think this is a great technique. To all those who think programming IS a job done under pressure, really think hard about your specific job and your specific situation. We all like to glorify our careers (to the point of fooling ourselves) and imagine scenarios where something mission critical breaks and it HAS to be fixed in five minutes (something like you'd see on the show 24).
But has that ever happened at your job? If so, instead of hiring high pressure programmers, could you take steps to eliminate the high pressure scenarios, e.g., unit testing, back up systems, roll back plans?
I know everyone will have counterexamples of this high pressure thing that happens.. but is it really typical for your job, really?
Comments
I think this is a great technique. To all those who think programming IS a job done under pressure, really think hard about your specific job and your specific situation. We all like to glorify our careers (to the point of fooling ourselves) and imagine scenarios where something mission critical breaks and it HAS to be fixed in five minutes (something like you'd see on the show 24).
But has that ever happened at your job? If so, instead of hiring high pressure programmers, could you take steps to eliminate the high pressure scenarios, e.g., unit testing, back up systems, roll back plans?
I know everyone will have counterexamples of this high pressure thing that happens.. but is it really typical for your job, really?