>>Of course, if the existing style is rife of bad programming practices, then... good luck to both the team and the new member. They'll need it.
>
>I think you've hit the hammer on the nail. I'm willing to change my coding practises when I'm involved in someone else's project, so I'd expect every one participate in my projects to adhere to my coding standards at least to a reasonable extend. Once I had one programmer applying for a position wanting to do it totally different in my project as he did object to my project structure and coding practises, arguing that his way was better. Needless to say we were forced to end the relationship. The sad thing was that, though he probably was a decent programmer he was not flexible enough to be a team member. I have to confess that I've been on both sides of the coin. I too, quite a few years ago, have tried to force my standards into another ones project (they were not using .EXE, but the runtime FPD 2.6 environment running PRGs, not using rushmore etc), but you'll find that indeed the relationship is not going to work out.

I've come to understand even some unreasonable limitations - because they were brought up by team bosses who had their share of all-nighters because of this or that bug, and solved it by never doing things this way, but rather doing them that way. Several versions later, the bug is long gone, but the whole thing is now pretty much impossible to change. And it works.

So, as ridiculous as it may seem, some teams don't use Rushmore. Some don't use any new field types (and definition of new may vary... down to "no dbc, no datetime, no integers, no currency...). Some don't use combos. Some use grids readonly. Some never use grids. Some never have multiple levels of containership on a form (even page on a pageframe is too deep). Some insist on on-form toolbars, some on on-desktop toolbars, some on absolutely no toolbars.

So what. You go in and try to prove that the limitation is bogus, and chances are you'll hit a small bug somewhere that'll make you look bad. Or you do fine but still can't convince the rest of the team to change their ways. This may work sometimes, item by item. But a frontal attack on the practice... may work only in one's wildest dreams. There's the issue of programmers' vanity. The issue of countless hours spent on the creation of the coding practice that's criticized. One guy asking the whole team to see the error of their ways... will be the boss soon, or won't last long. Either way, he won't be liked.

One has to play very carefully. Go step by step. Ask for approval of the proposed change. Write a builder or two to ease the conversion from ThisWay to ThatWay (so there's no additional burden on everybody) if he's already so smart and all-knowing.

Actually, a programmer who is so smart and all knowing should have a reality meter, and should be able to understand what can be done, what can't, and what can but we'll never have the time.