Re:Ask HN: How to address horrible practices at new job?
by SideburnsOfDoom on Tuesday June 23, 2015 @03:54PM
(#9767321)
I would seriously look at the terms of your employment contract. there is usually a "probation period" of a few months during which time you can be let go at very short notice because it's not working out for whatever reason.
It's not always kept in mind that "it's not working out" cuts both ways. If you aren't happy there (and I really would not be) then it's time to decide - as they say "if you can't change your company, then change your company."
Some of these practices, YMMV. For instance, "Code is committed directly to master, not on branches" gets a big shrug from me. What does it matter so long as only 1 person is working on a repo at a time, or if changes are isolated and merges are frequent?
Others, like no testing, no build automation, no live monitoring, give me the creeps. There is actual harm from them "an api went down and we didn't know" so there is leverage there to pitch you can make for mitigation of recurrences of actual problems and for proven industry practices. But it looks like a lot of uphill struggle.
It's not always kept in mind that "it's not working out" cuts both ways. If you aren't happy there (and I really would not be) then it's time to decide - as they say "if you can't change your company, then change your company."
Some of these practices, YMMV. For instance, "Code is committed directly to master, not on branches" gets a big shrug from me. What does it matter so long as only 1 person is working on a repo at a time, or if changes are isolated and merges are frequent?
Others, like no testing, no build automation, no live monitoring, give me the creeps. There is actual harm from them "an api went down and we didn't know" so there is leverage there to pitch you can make for mitigation of recurrences of actual problems and for proven industry practices. But it looks like a lot of uphill struggle.