Some experiences from a few really bad companies I have worked at:
1) "Don't use tabs or spaces in your code, they take up bandwidth".
2) "Don't put your javascript in a separate file, it makes it hard to find. Put it in the onclick for that DOM element"
3) No dev boxes or version control. Daily work involved SSHing into the production box and editing the PHP code in vim.
4) Got laid off from one company because I was insisting that they use version control and this upset a lot of the other script kiddies because I was making their work more difficult.
5) HR had cameras installed in the ceiling and pointed at all the monitors.
6) Trying to debug PHP code that outputs Javascript code that outputs HTML.
7) Spending 15 minutes trying to find the closing HTML tag, only to discover that it was in a PHP function that was in a separate file from the one that created the opening tag.
8) Being told, figure it out or you're fired several times a week.
9) "Stop abusing the <ul> <li> element to create navigation menus. <li> is supposed to be for bulleted lists only."
10) Being told to go home several times when I disagreed with a proposed design.
11) Being told they wouldn't get me a better monitor (only did 1920x1080) because screen space isn't important for programming. Meanwhile the boss had a 6 monitor setup (yes 6 monitors for a single computer) mainly used for IM conversations.
12) Being asked to create a favicon that looked like a secure SSL lock because our cert provider didn't work on some mobile devices.
13) Being asked to create a bunch of "bank sites". Bare minimum sites that meet the requirement to get a merchant account. That way they can just switch the merchant account when there were too many chargebacks. They were offering free subscriptions with CC verification and a small print $70/mo recurring fee that you had to scroll down quite a bit to see.
>12) Being asked to create a favicon that looked like a secure SSL lock because our cert provider didn't work on some mobile devices.
14) Having to explain to my employers what JSON is and why it's better than the weird CSV-like serialization format they just invented to pass things around because they don't know what AJAX is, then watching them reject it entirely because JSON looks too complicated and go with their thing, which proceeds to break the site in weird ways because they're dropping user data and queries from the database (which is not, mind you, even remotely optimized) directly into PHP generated javascript functions and surprise, surprise, shit gets messy.
14.5) Having to explain to them once they discover AJAX that writing to the database with it is a bad idea when there's no real authentication for the requests. And that, no, POST isn't somehow 'more secure'.
14.5b) Writing a barebones JSON API for them and watching their eyes glaze over when I explain what it is and why it's a good idea.
15) Writing a session-based login for them because up until that point, you could authenticate as any user by storing their username in a cookie(because "authentication" was, literally "do they have a cookie with a username? Ok."). Because my code caused people to log in every few hours the site was considered "unusuable" from a user experience standpoint and the code was rejected entirely, and rewritten from scratch, and then when they couldn't get it to work the entire concept of session-based logins was considered "impossible." Any future user authentication is planned to be handled using, and this is a paraphrase from the 'CEO', "if statements and hiding javascript or something."
16) Explaining why using mail() to send emails from a shared server account to maybe every email address in the database might not be the best use of the limited resources we have but being told to add a mailer to the site anyway because it creates a more unified user experience. Bear in mind - nobody is paying us for anything.
17) Pointing out that using usernames as primary keys is a bad thing. There are no foreign keys - usernames are just copied as as strings where relevant. Some usernames have spaces in them. These are also echoed into javascript and passed back as function parameters. To say there are occasional issues with double-escaping and encoding would be an understatement.
18) Pointing out that encrypting passwords is actually not that great an idea and that being able to log in as an arbitrary user with nothing but javascript is actually a bad thing and being sorry I ever showed them that because now it's apparently an indispensable part of the admin control panel.
19) Oh yes - the only way to develop is on the live server with FTP. Version control is asking if anyone is working on the file you want to edit first.
19.5) Includes including includes including includes. Including css. Because all of the css and javascript is inline and half generated on the server. Many stalwart souls have tried to chart it out, all have failed.
20) Dealing with a pathological fear and mistrust of third party libraries. If we can't write it ourselves then it probably won't be written. The rationale for this is not having to deal with code they don't understand and that might not be supported in the future. Never mind the time they're wasting discovering half-assed ways of implementing things there are already tested solutions for, and the fact that their understanding is rudimentary at best.
And at another job I was told to manually audit our database against a parts database because our boss didn't "trust the algorithms." I was fired after this took longer than he expected.
> 19) Oh yes - the only way to develop is on the live server with FTP. Version control is asking if anyone is working on the file you want to edit first.
