> Many companies are just not aware, because they never hired the people who are familiar with automated testing.
Established shops mean established culture. If it doesn't already exist, and you aren't in a position of sufficient authority to make it happen without buy-in, this "opportunity" is probably more likely to be bailing out the ocean.
Like anything, often it's just a matter of selling it properly, even without "authority". Even at an established shop, if something will make a difference in the bottom line, it will likely gain traction.
I've been at a company with thousands of developers, where a guy that was just hired came in, saw a need for a tool that had been missing, prototyped something, and showed how useful it could be.
When there are missing needs like this, it's a tremendous opportunity for someone who is sufficiently motivated.
Of course, there's a balance between a good company that is just missing some things here and there, and a very bad company that is missing just about everything...
Selling "we need to do weeks of LOE to address a problem we don't necessarily believe exists" generally requires more than line-developer authority. (I've been there. My current company is moving towards test coverage only because I can lay out that we should do this for our mobile group, and because I'm raising hell about the rest of the company.)
There's a significant difference in difficulty between building a tool and institutionalizing a labor-intensive (though very valuable) process. And given the surplus of developer jobs out there, it's probably easier, and better, to just move on to your next option.
I work at a relatively large technology company (Bloomberg) and I have had great success in changing developer culture for the better. It takes a lot of elbow grease, many meetings and you need the gumption to ride through it but we've truly made the day-to-day productivity enhancements that we need for our business. In just this year my team has accomplished:
> GitHub Enterprise deployment;
> Massive project conversions from Ruby 1.8.7 to 1.9.3;
> Adoption and training of AngularJS building reusable directives;
> Utilizing Boxen to make developer work environments reproducible and deterministic;
> Consolidating build systems (Jenkins) and integration with corporate internal systems;
We're really on a roll and I think once you gain the trust of management and they see the moral changing for the better you can really stop the world. But coming in from the outside I can see how this is intimidating and, roughly speaking, you need to consider most organizations are not going to give you the keys to the castle with merely blind faith. You need to disrupt a bit.
> But coming in from the outside I can see how this is intimidating and, roughly speaking, you need to consider most organizations are not going to give you the keys to the castle with merely blind faith. You need to disrupt a bit.
I've been there, man; I'm not exactly saying something I haven't tried. :-)
"Intimidating" isn't the right word, though. "Vastly unlikely" is probably closer to where I'm standing. Unlikely to the point where the downside risk--being stuck at a job with regressive coworkers and management who doesn't want to change anything--probably outweighs, for most people on HN, the potential upside given that they probably have other options.
I could go in and risk my time and my earning potential to change things somewhere, or I could go to the next place with their head on straight.
Established shops mean established culture. If it doesn't already exist, and you aren't in a position of sufficient authority to make it happen without buy-in, this "opportunity" is probably more likely to be bailing out the ocean.