> On my second week opn the job, I commented out, by > mistake, the initialization of variable $user (arrrgh!!). > The website crashed on all the signed-in us

> On my second week opn the job, I commented out, by > mistake, the initialization of variable $user (arrrgh!!). > The website crashed on all the signed-in users. I'm trying to imagine a professional, well run software shop that would actually hold you responsible for this. I can not. It seems to me that for this to have happened, many things must have gone wrong, or many professional practices must have been completely missing: 1.) there were no code reviews 2.) there were no unit tests 3.) there were no functional tests 4.) no one noticed any problems on the development site 5.) there was no QA person, or the whole QA team somehow failed to test this 6.) there were no 3rd party testing services that might have caught this (like Airbrake), nor any in house error logging services (errbit) I could go on. I'm trying to imagine how a programmer comments out the $user variable and that change makes it all the way to production without anyone noticing. I think a lot of things have to wrong, all through the organization, before that becomes possible. I read your story and I have 2 quick thoughts: 1.) I have made many worse mistakes (thought I was changing database password for dev, in the config file, but actually changed it for production) 2.) None of my worst mistakes ever made it to production, because the company had some process that caught them before such a change ever got pushed to production. No programmer can avoid mistakes. That simply isn't possible. To insist that a programmer always write perfect code would be like insisting that an NBA basketball player make 100% of his 3 point shots: the world would be a very different place if it was possible to insist on perfection. A well run organization has multiple checks that ensure mistakes made in development don't make it to production. Any organization that puts 100% responsibility on one programmer is taking a 100% certain risk that eventually some terrible mistake will make it to production. Some organizations put more responsibility on individual programmers and some organizations put less. That is fine. A range of strategies can be defended. But if an organization wanted to shift most of the responsibility onto a single programmer, then they would also have to give that programmer broad latitude regarding time, so that the programmer can implement whatever they feel is necessary to ensure the robustness of the code (for instance, unit tests, functional tests, setting up automated uptime checks, etc). I'm guessing, from what few details are written above, that the above commenter both had responsibility for the code but was also under pressure to move quickly and shove stuff out the door. Under such circumstances, management needs to take 100% responsibility if something goes wrong. Now I will qualify everything I said above with an anecdote: In 2005, when working at monkeyclaus.org, we had a little startup where I was the only programmer and we would push my changes straight to the "live" site. But we hadn't really launched yet and the few dozen users we had were just friends of ours, so the "live" site was really a "dev" site.