It's time to start comparing wages instead of absolute income.
Of course, there are still employers that won't even consider giving you any of that but make it a regular practice of overworking their employees. Don't work at these places.
High salaries come with high expectations. If you're getting paid a lot, expect to work a lot, too. If a good work/life balance were free, everyone would have it. It has a definite opportunity cost.
You are willing to put up with this behavior because you believe that one day your training and experience will lead you to a very high paying job. Lawyers, doctors, accountants, engineers, the professionals, all understand that there is a necessary grind in order to prove your worth.
If you are not cut out for it, there is always work as a desk clerk making above minimum wage working 9-430. Yes, some employers have very relax policies relating to getting work done. But who are the ones producing the highest quality innovative work? The people working hard on a daily basis.
It has very little to do with being "cut out for it" and more to do with not being exploited. And yes, there's a whole host of exploitation of various degrees even in modern workplaces and many people have had or still have to go through with it but that doesn't mean it's a good thing whatsoever (unless, of course, you're the employer).
That right there is the crux of the issue. You don't work for free. Period. If it is expected that you'll be working long hours during busy seasons, then the initial salary offered should reflect that. If two people are getting paid the same salary but only one is expected to take overtime constantly, one of them is getting screwed.
Once he advised me, "Always make sure that you send an e-mail, late at night to anybody in the organization, before you call it day."
"Why?"
To make it short, per his advise, the single most important thing about those e-mails, wasn't the contents, but just the timestamp.
I tested your site with Chrome 28.0.1500.72 m. The back button worked fine.
I then tested your site with Internet Explorer 9.0.18 and the back button worked fine.
I then tested your site with Firefox 22 and the back button worked fine.
Sorry for the vagueness!
But what this is basically suggesting is "locking out" your employer. While I agree that is absolutely what should happen, doing this without the leadership AND the developer in agreement about why sounds like disaster.
I know it's likely impossible to capture all the work and discussion it takes to reshape a company's process in a blog post, but I feel like if I had a dependence on OT in my company (as the "patient"), and a lockout went into effect, I would be focusing on the lockout, not every other problem in the company that caused it (which as management, it's my job to figure those problems out). What is being suggested is basically arm twisting to get what you want :/
That never works when you cause more pain to the company than it's able to alleviate over time. They'll eventually get tired of the pain and move on to another drug unless you succeed in getting them to understand.
I feel like better advice is to tell developers that they need to discuss this with their direct reports, boss, whomever, and talk about the problem and WHY you'll actually make the company better gains at sustainable pace. And by all means, point out and suggest ways for your boss to improve things.
If after educating your "patient" the issue still persists, of course, twist away. But not everyone in this world needs these sorts of tactics to improve their workplace, and even in those workplaces, there are likely more successful ways to cure the pain, not just treat it.
Seems like we're both saying "an ounce of prevention..." here
I think the deeper insight of TFA is that there may be short term gains for the employer, but the long term results are muddy or outright negative -- management becomes addicted to poor management habits that hurt the company health in myriad ways.
One of my college Computer Science professors, the one I liked and respected the most, worked at Novell for quite a while back in the day. Not sure if his entire 20+ year programming career was spent there before going back to school to get his PhD. In any event, at one point he was a team lead at Novell. He made sure to hire, train and develop the right kind of programmers for his team. The kind that write tests, solid code, and practice good engineering principles.
To my memory, when he was telling us this story, the overtime he and his team worked was somewhere between minimal to non-existant. Their code was clean, well-tested, and worked. So at 5pm they would go home.
There was another team that was always scrambling at the last minute, and clocking lots of overtime.
When it came time for company/management recognition, which team received the accolades? The team that clocked all that overtime, because they MUST have been working harder to get things done than the other team. Right?
