Even all the experience in the world doesn't prevent error.
For instance, TheHackerCIO actually resigned from a client contract once!
He happened to work for one of the stupidest managers ever seen in the technology world, at a BHB -- or Bureaucratic Hidebound Behemoth (AKA a "Large Enterprise"). Not only was this manager as stupid as ever a manager could be: we're talking Dilbertian levels here, but was also, actually evil. Not in the humorous sense of Catbert. Rather, in the sinister manner of a dishonest, and mean-spirited person.
Here's how you can get pushed into doing the wrong thing before you realize it. Here's the case-study.
I had been assigned the task of documenting a specification for a proposed development project, where the lead developer was not available for consultation. All right, I'm a worker. I do what I'm told. With no developer to ask, I have to make assumptions. Then, before I know it, there is a review meeting scheduled with the end-user. OK, but I have to get some face-time with the lead developer prior to that. Then, the lead developer, who is working from home and has no time for me comes back and it turns out that a number of assumptions made in the spec are wrong and need to be changed.
Now is the time to inform the manger. So TheHackerCIO levels with this in-duh-vidual. The spec is wrong; the review is tomorrow; and even if I worked continuously from now until the review, I couldn't get the changes documented for the review. We need to reschedule it.
But the manager said, "Just go ahead and review it. We don't have time to reschedule the meeting."
And this is the point where I made my error.
I thought, OK, I'm a contractor & it's my job to do what I'm told.
That's an excellent work-ethic, but it misses out a crucial point. One that became clear by retrospective analysis.
Implicit in this demand was a requirement for me to present a known falsehood. It was the most uncomfortable review I ever participated in. I realized, afterward, that it was because I wouldn't lie, yet felt reluctant to be forthcoming about the nature of the document being reviewed. I can damn well assure the gentle reader that I will never do that again. And, as a matter of fact, shortly after that review, I resigned from the position. I told them that I didn't think I fit in with their way of doing business. That's for sure!
But it's only by doing a retrospective like this that you can learn what you will damn sure never do again.
The lesson brought home a crucial value for me. I want to do my work my way. I won't ever again be pressured into doing someone else's work some other way. And part of doing my work my way is understanding the full spec of anything I program or build. I advise this of any junior programmer: don't program something you don't fully understand. If the spec is lacking, recast it yourself and review it with the other spec-writer, as a means of communicating your understanding of what is to be done & what you will, in fact, do. And don't spec something without being able to talk to the key people. Don't try to do something unless you're actually able to!
I Remain, With Edge Intact