4 ms·

> We don't have tests. - Get out Maybe it's an opportunity to introduce automated testing. I've worked at many companies where my managers wouldn't allot any

by ye 13y ago

> We don't have tests. - Get out Maybe it's an opportunity to introduce automated testing. I've worked at many companies where my managers wouldn't allot any time to develop automated tests and change the deployment to accommodate them. Many companies are just not aware, because they never hired the people who are familiar with automated testing.

eropple 13y ago
> 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.
- ShirtlessRod 13y ago
  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...
  - eropple 13y ago
    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.
- johnbellone 13y ago
  > Established shops mean established culture. 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.
  - eropple 13y ago
    > 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.
bowlofpetunias 13y ago
This applies to virtually any item on that list. The questions are good, but the lack of ambition bothers me. But maybe that's just me, I would always prefer to work at the place that isn't 100% perfect but will give me the opportunity to change things. Much more of challenge in that than just being a replacement cog in an already perfectly tuned machine.
- quanticle 13y ago
  There's a huge difference between "we don't have tests and we don't see the value in automated testing", and "we don't have tests right now, but automated testing and process improvements are something we're working on". I suspect you're talking about the latter, whereas OP is talking about the former. Culture is a lot harder to change than code. If the people already there don't see the value in process improvement, then attempting to introduce any sort of process improvement will be a Sisyphean task. You'll make progress only to see it get rolled back time and again by teammates who just don't believe in what you're doing. Take automated tests as an example. I have worked at a place where I committed automated tests and configured them to run before build. Then, I got a bug report for a module I had worked on and wrote a test suite for. The test suite should have caught the bug... had it not been disabled by another developer who'd committed the breaking change and, instead of investigating why the test failed, just dropped @ignore annotations until the tests passed again. That's the sort of thing that OP is warning against. Life isn't long enough to spend time bashing your head into walls like that.
- dinkumthinkum 13y ago
  This is actually a very useful and insightful comment rather than the obligatory "What!? You aren't using tool X that I watched a YouTube vid about!? No way I'm working here!" responses you expect in these kinds of threads.
- damncabbage 13y ago
  There's a baseline level of competency I'm willing to work with. I've had to fight for basic things (like version control) over and over again, and I'm fed up to the point of not wanting to fight those wars again every time I join another company. The lack of testing culture, for example, was what first drove me away from PHP (to Ruby). Every PHP role interview, I'd gingerly have to ask if they knew what Automated Testing was ("Yes? Great. Have you done any yet? ... No? You don't want to? Oh."), whereas at every interview for a Ruby role I've basically gotten a "Of course we're testing. What else would you be doing?" response. Once you get past talking about things up to the baseline, you can start the real interview.
rmc 13y ago
Maybe it's an opportunity to introduce automated testing. Sure, but this is why you ask a follow up question, "why don't you have tests?" If the answer is "We are just starting this project, and haven't done any yet. We'd like you to help us write tests", then that's an oppertunity. If the answer is "Tests don't work, they're useless and never catch serious bugs. Our team is smart enough to not break things, and we have to move too fast to waste time write silly little unittests for everything", then there's no oppertunity here.

by ye 13y ago

eropple 13y ago

> 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.

ShirtlessRod 13y ago
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...
- eropple 13y ago
  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.
johnbellone 13y ago
> Established shops mean established culture. 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.
- eropple 13y ago
  > 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.

bowlofpetunias 13y ago

This applies to virtually any item on that list. The questions are good, but the lack of ambition bothers me. But maybe that's just me, I would always prefer to work at the place that isn't 100% perfect but will give me the opportunity to change things. Much more of challenge in that than just being a replacement cog in an already perfectly tuned machine.

quanticle 13y ago
There's a huge difference between "we don't have tests and we don't see the value in automated testing", and "we don't have tests right now, but automated testing and process improvements are something we're working on". I suspect you're talking about the latter, whereas OP is talking about the former. Culture is a lot harder to change than code. If the people already there don't see the value in process improvement, then attempting to introduce any sort of process improvement will be a Sisyphean task. You'll make progress only to see it get rolled back time and again by teammates who just don't believe in what you're doing. Take automated tests as an example. I have worked at a place where I committed automated tests and configured them to run before build. Then, I got a bug report for a module I had worked on and wrote a test suite for. The test suite should have caught the bug... had it not been disabled by another developer who'd committed the breaking change and, instead of investigating why the test failed, just dropped @ignore annotations until the tests passed again. That's the sort of thing that OP is warning against. Life isn't long enough to spend time bashing your head into walls like that.
dinkumthinkum 13y ago
This is actually a very useful and insightful comment rather than the obligatory "What!? You aren't using tool X that I watched a YouTube vid about!? No way I'm working here!" responses you expect in these kinds of threads.
damncabbage 13y ago
There's a baseline level of competency I'm willing to work with. I've had to fight for basic things (like version control) over and over again, and I'm fed up to the point of not wanting to fight those wars again every time I join another company. The lack of testing culture, for example, was what first drove me away from PHP (to Ruby). Every PHP role interview, I'd gingerly have to ask if they knew what Automated Testing was ("Yes? Great. Have you done any yet? ... No? You don't want to? Oh."), whereas at every interview for a Ruby role I've basically gotten a "Of course we're testing. What else would you be doing?" response. Once you get past talking about things up to the baseline, you can start the real interview.

rmc 13y ago

Maybe it's an opportunity to introduce automated testing. Sure, but this is why you ask a follow up question, "why don't you have tests?" If the answer is "We are just starting this project, and haven't done any yet. We'd like you to help us write tests", then that's an oppertunity. If the answer is "Tests don't work, they're useless and never catch serious bugs. Our team is smart enough to not break things, and we have to move too fast to waste time write silly little unittests for everything", then there's no oppertunity here.