And they prefer using uncool tools intelligently to solve a complex problem; rather than using the next cool thing dumbly that creates more problems than it solves.
I'm not fantastic with Powershell but there's another potential reason: you're not allowed to run "random" exe files on $SERVER but (signed) Powershell scripts are fine.
I'm not sure where the cutoff point is between this needs to be an app / this can stay as a script, but Powershell seems to lend itself to going either way. I can either incrementally replace C# functions with Powershell (while importing types and functions that I need) or incrementally replace Powershell with C# with the same method.
Sounds like a bunch of C# devs who didn't know Powershell and couldn't be arsed to learn it. Even though it has similar syntax. To some developers every problem requires the only hammer they have.
Must have been really bad. Why not just hire you on as a consultant?
And sometimes they are unbelievably set in their ways, for example using procedural code ( STATIC ALL THE THINGS! ) in Object Oriented languages like Java.
And that's the rub. When you are hiring experienced devs, are you getting Mr I-use-staticz or are you getting Ms Let's-use-boring-tech-because-it-works?
What I think in such cases is "unless I can convince him that this is a bad idea, then I should let him do it". Yes, I understand that sometimes we aren't entirely sure why a thing is bad, we just have a gut feeling that it would break something, or is a bad practice.
So first off I try to convince them with everything I got. That usually works if I have solid concrete reasons. If I don't and let them do it there way. Sometimes it turns out my instincts were right and I get to learn exactly what was right about them. Sometimes it turns out I was wrong and his way was much more efficient and I get to learn something new.
Either way, it doesn't make the junior dev feel I am imposing my will on him. People tend to work harder when they feel it was their idea.
When I was a junior dev (and some days I still feel like that), sometimes I needed to write a proof of concept to see why something wouldn't work. Luckily this kind of development (at least in the early stages of a project) was encouraged. I still throw together small scripts and apps to test ideas all the time (http://github.com/voltagex/junkcode)
I would assume most devs do the same all the time to benchmark technologies or approaches to problems.
(Then again I seem to meet far more devs who are telling me about using shiny new tech X and how amazing it is, than ones who actually tell me about how a specific tech solves their use case).
But about as annoying as senior devs who give bad advice or ignore half the words in your sentences and then give you bad advice, or who start giving you bad advice during a planning meeting after a 30 second brief about your problem that was directed to your manager.