In which @itamarst reads a pop-sci book and dishes out advice based on it with little evidence to support it.
But a few more serious thoughts:
The opening creates a pleasant fairy tale but one should be distrustful of it. Your manager probably isn’t doing so great if your project is in that situation. But maybe you aren’t so hot either. It’s hard to know the difference. Just saying any arbitrary situation, the problem is the manager stinks and the programmer isn’t working smart is ridiculous.
Some projects just require a lot of work no matter how smart you want to work. There are plenty of causes for a situation where the problem simply requires a lot of hours. Maybe hiring failed, maybe the scope is large. But you can’t just “work smarter” out of any situation and just because something requires a lot of time doesn’t mean you’re fixed mindset.
I believe this is another blog post taking a complicated situation, lossily simplifying it, and dishing out B-grade advice based on the simplification.
You’re right on all counts, but I still think developers need to put their collective foot down and refuse to work unpaid overtime. Tired programmers are as prone to mistakes as tired workers in any other trade or industry; the main difference is that a tired factory worker might get himself or others hurt or killed, whereas a tired developer might commit a “clever hack” that ends up leaking PII for millions of unsuspecting users after a year or two in production.
If companies have to pay for over time, they will be (in theory anyways) less likely to make their workers work over time, and will instead have some actual planning and project management in place so working 12 hours straight is not needed.
I’m against unpaid overtime. Making all waged and salaried work by non C-suite workers eligible for overtime pay might deter some managers from allowing/persuading/gaslighting/bullying/coercing/etc workers to do OT, though the current time-and-a-half rate might not be sufficient to serve as a deterrent. Triple pay for OT might be better.
If not, and my boss is ignorant enough to take that kind of risk and incur that sort of cost, then I’m not going to say no to more money.
If you work in a production based environment with deadlines, the amount of work you have is directly correlated with how many orders the sales team racks up, and you can very easily end up having to work long hours from necessity to meet the demand and deadlines. Many industries also have off seasons and busier times, especially those that deal with schools or taxes.
Yeah, I get that. If sales people are promising new functionality by a certain date then there’ll be pressure to build it by then.
And I can now see why the school calendar could matter.
What I’m not getting is why tax season makes a difference.
Because tax laws change over time, so if you’re writing software that is dealing with something that got changed by your government with a given deadline, you’re going to have to deal with it by said deadline, or face whatever consequences come from not being in compliance with said law.
A big one in the past few years was all the changes related to the Affordable Care Act in the US. It isn’t that every year brings a change like this (to my current knowledge), but they are a thing with real external deadline pressure.
In which @itamarst reads a pop-sci book and dishes out advice based on it with little evidence to support it.
But a few more serious thoughts:
I believe this is another blog post taking a complicated situation, lossily simplifying it, and dishing out B-grade advice based on the simplification.
You’re right on all counts, but I still think developers need to put their collective foot down and refuse to work unpaid overtime. Tired programmers are as prone to mistakes as tired workers in any other trade or industry; the main difference is that a tired factory worker might get himself or others hurt or killed, whereas a tired developer might commit a “clever hack” that ends up leaking PII for millions of unsuspecting users after a year or two in production.
Clarification: Are you against overtime or unpaid overtime? Because even if I’m getting paid for overtime, I can still commit the mistake you stated.
If companies have to pay for over time, they will be (in theory anyways) less likely to make their workers work over time, and will instead have some actual planning and project management in place so working 12 hours straight is not needed.
I’m against unpaid overtime. Making all waged and salaried work by non C-suite workers eligible for overtime pay might deter some managers from allowing/persuading/gaslighting/bullying/coercing/etc workers to do OT, though the current time-and-a-half rate might not be sufficient to serve as a deterrent. Triple pay for OT might be better.
If not, and my boss is ignorant enough to take that kind of risk and incur that sort of cost, then I’m not going to say no to more money.
I’m against overtime, it causes problems that need to be cleaned up. It’s as dumb as throwing bodies at the problem.
No matter how much work something requires, it doesn’t need to force people to work long hours; they can just do it slower.
If you work in a production based environment with deadlines, the amount of work you have is directly correlated with how many orders the sales team racks up, and you can very easily end up having to work long hours from necessity to meet the demand and deadlines. Many industries also have off seasons and busier times, especially those that deal with schools or taxes.
Can you explain why software development timelines need to follow academic or fiscal schedules?
Software development in a business setting is all about keeping other people’s promises.
Yeah, I get that. If sales people are promising new functionality by a certain date then there’ll be pressure to build it by then. And I can now see why the school calendar could matter. What I’m not getting is why tax season makes a difference.
Some software changes are necessitated by tax law changes or other external deadlines. I’m working on one right now.
Because tax laws change over time, so if you’re writing software that is dealing with something that got changed by your government with a given deadline, you’re going to have to deal with it by said deadline, or face whatever consequences come from not being in compliance with said law.
A big one in the past few years was all the changes related to the Affordable Care Act in the US. It isn’t that every year brings a change like this (to my current knowledge), but they are a thing with real external deadline pressure.