I once worked at a company that had several interesting practices:

• It took over 3 months before IT could get me the access to the various file servers I needed to do my job. Apparently they didn't believe in setting access policies by groups, only on a per user account basis.
• We had numerous processes that depended on old PCs that for some reason could not be made to work on different systems. We had to do a major data import to our Sybase servers from Paradox. Only one system was capable of completing the import about 70% of the time. Every other machine might succeed 10% of the time. Without this data $1000s in billing could not be completed.
• We had tons of scripts scattered accross multiple fileservers, that were used by various processes that accessed the database with all of our billing information (including credit card data), which included hard coded passwords. All were using the same account. I found copies of these scripts on 'all employees' shares as well as more restricted areas.
• The password used by this well published account was very insecure. 8 characters, all the same. I won't say which character.

The biggest sin I committed was that I gave up and quit pushing to get sane policies in place. I got tired of pissing people off and getting nowhere, the money was good, and the work was easy--so I just let it slide while I tried to make sure that the new stuff that I worked on was sane.

Similar to yours, in a way: I taught an introductory PHP class recently (this is me - the guy who thought that PHP was something you did in a dark room with the curtains drawn, and washed your hands afterwards.) I did, however, spend a significant part of the course showing the students how to defang the stuff - and how to test it afterwards, MySQL and PHP ends both, to make sure that it was indeed defanged. I also spent a bunch of time on how to program with "register_globals = Off" and with "open_basedir" set - and emphasizing that they still need to use Suhosin, etc., if they wanted even a slim chance of surviving the Big Bad World of Out There.

As to other 'sins' - well, early on in my career as a consultant, I was quite "hungry" and I'd made some compromises in my work that, on later reflection, I shouldn't have made. Nothing huge or horribly damaging, but they left a really bad taste... and they serve as a very strong reminder not to do that again. Perhaps I'm coming from a privileged position when I say this, but to me, my professional ethics are a stronger motivating force than money. I've turned down several large contracts (2 of them were $10k+ each) because the client and I clashed over what I saw as the ethical implications of doing the work, and he was unwilling to be flexible in that area. I've never regretted those, either.

The pitfalls... oh, this was such a pit that it was funny - even as it was happening. Even though I got fired from that job. :) Right after the break-up of the coin telephone monopoly in New York, I got hired by an enterpreneur type who decided to ride that particular gravy train. He interviewed the hell out of me (electronics, mechanical ability, a bunch of weird tests that turned out to evaluate communication skills, and a polygraph test (!!!)), hired me as a "senior repair technician", sent me to an expensive coin-telephone repair school in Texas, and then... put me in a cage - an enclosure built of heavy wire, a sort of a mini-jail to which I had the key but which was my assigned work area, on the first floor of the warehouse - while all the rest of the techs were on the second floor, in a large open space. More than that, the techs were strongly and explicitly discouraged from "bothering" me in my cage. I repaired all the dead phones that he had during the first two weeks or so - the cage being where they were stored - and went to the Big Boss to ask him what was next... at which point, he vehemently and summarily fired me FOR NOT BEING A GOOD MANAGER. It seems that this was his deepest secret wish for me ("I've treated you as if you were my son, and you've let me down like this!!!") which I had somehow - viciously and intentionally - failed to fulfill despite all the opportunities that he gave me.

I was a bit surprised (although not shocked - I'd smelled something in the wind) at the time, but I give myself great credit for not laughing hysterically right then and there.

I saved it until I'd been out of the building - with my last paycheck in hand - for at least ten seconds. :) I laughed so hard that I dropped to my knees and a cop had to stop by and ask me if I was OK.

-- 
Human history becomes more and more a race between education and catastrophe. -- HG Wells

When you want something nested you have to render the sub-templates within the controller, add the resulting html as variables to the main template ...

• slow (as some of you might know, that hurt me as a performance freak)
• it had no elsif tag and other nice features
• it was unreadable - no possibility to put whitespace in the tags, and together with the missing elsif-tag that forced you to write veeeeery long lines with nested if/else and no whitespace
• it never died - wrong nested tags were just ignored, and it was difficult to find out where the error in the template was

my sin? i critisiced the system and basically said that any templating out there on cpan would be a better choice. from other jobs i knew that it is often ok to gripe about the templating system because everybody knew it was bad and only there because of historical reasons. here, though, i think i offended the one who had written it. also i suggested my own templating system on cpan, and starting at a company and basically saying "your templating is bad, mine is better" is probably not the best you can do. my learning: try to be more diplomatic.

i quit because it was, besides from the templating, very limited on what modules you were allowed to use. the company has a very successful website, and i was convinced at that time that the system could be made more comfortable for the programmers in order to get new features in faster. i still think that and i hope for the company that someday it will happen because otherwise it is very likely that someday a php/ruby/python/java guy comes along and just replaces the whole system. and it would be a pity to lose such a successful perl-powered website to a different language.

Biggest sin? Probably the database application with an Access backend. What can I say? I was young and foolish, and the client flat out insisted that Access was the only possible option they would accept.

No, wait, maybe that pales into insignificance in comparison to a certain mission-critical application implemented in, um, JavaScript... and I don't mean the socially acceptable AJAXy kind. (There were reasons, I swear! And it's very good JavaScript, with all kinds of clean abstraction and an exhaustive test suite and everything.)

Alas, I fear that I have perpetrated such unforgiveable acts that no amount of penance will now see me permitted entry through the Perly Gates...

Biggest pitfalls, that's an easy one. At my current job we don't use a CMS - instead every commit to SVN goes lives immediately and everyone (and I do mean everyone, not just coders) makes commits to SVN. Oh, and about half the code is copy-and-pasted Mason! Oddly enough, it's still a great job.

Runner-up would be the job where I did design and code review for 10 programmers in India. I couldn't actually talk to them, I could only talk to their managers. And I didn't actually have any power over them at all, despite the fact that a few of them obviously couldn't code. And I didn't get to go to India to visit them and travel the countryside. (I'm still bitter about that last one - I was all set to go, had my visa in hand when the trip was cancelled.)

-sam

Why would anyone need to write a templating system for a templating system?

Biggest sin: I had a short term contract which I discovered half-way through was indirectly for the Pentagon. I didn't quit.

Biggest challenge: I am in a contract where we have a setup not unlike what you describe with the PHP. We're using home-rolled templating to dovetail into TT2, in three different ways, and every reasonable base package that we use is wrapped in home-rolled versions which do not inherit from the base packages, truly just wrap them, while often inheriting from other internal packages which are manifold... and in some places rely on similarly redundant and wrapper-based PHP, and that' really just the beginning. It's almost the best part about the setup. I really like the people (they know the problems and are trying to dig out from the spaghetti) and the money is excellent but now and then the "challenges" feel more like a Hemlock Society recruitment seminar.

Biggest pit-fall? I implemented a communications emulator for an HP midi to act as if it was an IBM 370. I later found out HP had been contracted to develop it for United Technologies, which needed it to test a robot tank they were developing...

Good news indeed for you, me, & rest of us.