I hate to say it, but you may be in for a rough time. When I worked in a place like that, I faced similar problems. I had to deal with people who couldn't see the point of anything I talked about, and who used to stand around in groups and tell me how their code was self documenting, and how good they were at coding, etc...

In my case though, I was on a fixed term contract, filling in for someone. There was no chance of renewal although a year later they called me and offered me a job.

I don't recommend that you try any of the things below if you value your job. What I do suggest is that you gently make your point, if you can do it in a way that doesn't offend people (many people get very offended by critiques of their programming). Then do your own code the right way. When people ask why, explain.

You might end up being ordered to do something wrongly for a variety of reasons. Mention that you heard of a better way, and if they don't bite, knuckle down and do it wrong. That was a hard lesson for me...

Onto my experiences... They were bad coders and I knew it. They weren't even using any version control (because they were "good programmers" and their code "always worked"). So one day after a week of bitching at them for not using ANY version control I went and changed the script timeout to 1 second then left for a two day holiday. At the end of the first day, my friend called me to describe his horror day, since all of his scripts started failing randomly, and he couldn't figure out why. After he agreed that having a backup would have saved his arse, I told him the trick. I was glad I was 30kms away at the time...

After that I tackled the self documenting code fallacy by finding some really nasty code left by a previous programmer. I chose this code because it took the whole morning for me to figure out. It was nasty because it contained a variable (a filename) that was used in three files. In one file some code trimmed off the extension. In the second file tbe code added an extension, saved some data in it, then passed it to the third code file, which read the file back in, trimmed the extension, passed it to another routine which saved it into it's destination directory under - you guessed it - another name.

The only error checking done was in one routine which checked if the filename was empty. If it was it printed out "Danger, danger Will Robinson", and then quit.

I sat everyone down with the printouts and encouraged them to explain to me what the code does. After five minutes of them guessing (wrongly) we actually started to talk a little about coding standards and specifications, and documentation. One of the coders acutally went so far as to go back and document some of his code.

I just realised. I really am a bastard.

____________________
Jeremy
I didn't believe in evil until I dated it.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.