Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Overtime: the "Bad News" Warning Sign

by sundialsvc4 (Abbot)
on Dec 22, 2010 at 21:27 UTC ( #878675=perlmeditation: print w/replies, xml ) Need Help??

Cardiologists seem to take two general approaches.   Some want to see you for the first time on a gurney (presumably alive).   The others want to keep you from going there.   Physicians in the latter category therefore urge you to pay a lot of attention to things that appear to be useful as “early-warning signs” that might be a warning that you’re about to get into serious trouble.   Sort of like a sign by the road that says, “Bridge Out.”

I submit that we have just such an early-warning sign in our industry, too:   Overtime.   Generally, this issue (if it comes up at all) is “slow-balled” at the very end of the interview, couched with terms like “team player” or other similar vague references to professional sports.   And, whenever it does, I urge you to run away ... fast.

There seem to be three four general approaches to overtime:

  1. It is seen as a way to increase available labor by 2/7ths (without increasing costs).   (I can only very-delicately say that it must really suck to be in the USA on an H1-B visa.)
  2. It always happens at the end of a project, after a long period in which nobody seemed to have anything in particular to do.   (They seem to be admiring the passing scenery as their raft drifts ever-closer to the falls.)
  3. The project is declared, “finished,” but then all hell breaks loose.   Overtime is demanded “to fix the problems that have recently come up.”
  4. Testosterone.

No matter what “justification” is proffered in its defense, overtime is (IMHO...) generally the easiest-to-spot sign that a project has been poorly specified, poorly planned, poorly managed, or some combination of the above.   The ship is still several miles offshore, is probably lost, and the easiest solution to the problem is to flog the people who are holding the oars.   (Not the ones holding the compass and the charts.)   But this never produces good, robust, reliable software... and it never will.

Good software execution is a methodical, sometimes downright boring process.   It requires a level of daily focus and attention that also demands rest and diversion on a very regular basis.   Contrary to popular belief, your coding abilities do not get markedly better at 3 AM.   When a long project arrives at its intended destination, on time and on budget, the reasons for that success occurred both before the project formally started, and throughout every day of its completion.   There is not, and there can never be, a “heroic” substitute for these fundamental things.

When a company weaves the discussion of overtime into their negotiations with you... break off those negotiations.   If they don’t, ask the question directly.   As you do so, look the ranking manager squarely in the eye but watch the minions who may be present out of the corner of your eye.   The briefest flick of a telling expression can tell you all you really need to know.

Sure, it takes ... fortitude ... to walk away from a job when you have gone to a place to get one, but finding yourself in Overtime Hell is a great way to wind up with a heart attack at an early age.   One kind of cardiologist wouldn’t recommend that.   The other kind just got a customer.

Replies are listed 'Best First'.
Re: Overtime: the "Bad News" Warning Sign
by eyepopslikeamosquito (Chancellor) on Dec 23, 2010 at 20:23 UTC

    A few quotes from Peopleware on the subject of overtime:

    Overtime for salaried workers is a figment of the naive manager's imagination. Oh, there might be some benefit in a few extra hours worked on Saturday to meet a Monday deadline, but that's almost always followed by an equal period of compensatory "undertime" while the workers catch up with their lives. Overtime is like sprinting: It makes some sense for the last hundred yards of the marathon for those with any energy left, but if you start sprinting in the first mile, you're just wasting time.

    It has been our experience that the positive potential of working extra hours is far exaggerated, and that its negative impact is almost never considered. That negative impact can be substantial: error, burnout, accelerated turnover, and compensatory "undertime" ... When you take into account the way that the team members' differing abilities to work overtime tends to destroy teams, the case against it becomes persuasive.

    They further note that Jerry Weinberg proposed an interesting psychological explanation for why so many folks propose overtime even though they know it's not going to help: "we don't work overtime so much to get the work done on time as to shield ourselves from blame when the work inevitably doesn't get done on time".

      Peopleware is one of my must-reads, and it flags many warning signs. It has interesting opinions about open plan offices, having too many things to do, and it's amazing how little seems to have changed for the better in the past couple of decades.

Re: Overtime: the "Bad News" Warning Sign
by JavaFan (Canon) on Dec 23, 2010 at 23:12 UTC
    There are different times of "overtime". In IT, I'd recognize the following types:
    1. Certain work needs to be done outside of office hours. (Installing new memory in a server. Upgrading a database. Recabling the office, etc)
    2. Emergency. (Hardware failure. Software bug causing to lose business. Attack by evil outsiders. System overload.)
    3. Bad planning. (Deadlines)
    I don't have a problem doing overwork for the first two cases; that I see as part of the job. The first one is usually planned. If the second one happens too often, something is wrong. The third one I'd be more reluctant. I'm not eager to do overtime if a salesperson makes promises to customers he isn't qualified to make; OTOH, I've worked for employers who do show their appreciation for anyone doing overtime (free food, parties during workhours after the deadline, give time off as compensation without any problems, not complaining if you cannot (or don't want to) do the overtime).

    So, do overtime or not? It depends on the reason, the attitude of the employer, and the role you're playing inside the organisation.

      Rather than overtime #1 should be covered by proper work schedules. These things are usually known in advance and schedules of the individuals involved can generally be adjusted to cover it without overtime

      #2 shoudl be coverd by some sort of rotating on call schedule that covers at least the triage of these issues. Actual over tiem should be kept to a minimum by not expecting a regular 8 hour work day following the completion of an emgergency all nighter. And yes I have wokred jobs where this was the attitude. "Why are you going home at 11 am for the day!??" "Maybe becuase I have been here working with the vendor to fix the problem for 20 straight hours?"

      Of course we are not helped by those in our profession who sit on their hands while things go to hell .. so that they can pull all nighters to 'save the day' before some important event and be heroes. I have seen way too much of this (especially with government contractors) those who create emergencies by negligence and shine when they put in massive overtime to save the demo. They get promoted for their "dedication", where those who do their work diligently abnd correctly are unknown to the senior managment and remain mostly invisible.

      Misha/Michael - Russian student, grognard, bemused observer of humanity and self professed programmer with delusions of relevance
Re: Overtime: the "Bad News" Warning Sign
by BrowserUk (Pope) on Dec 24, 2010 at 01:57 UTC

    In the latter 10 or so years of my career I made a speciality of taking on the very jobs that you would have rejected.

    1. It paid extremely well.
    2. It afforded me many latitudes.

      For example, I made it my habit to start work at midday or a little earlier, and work until midnight or a little later. This provided sufficient overlap with the 9to5ers to ensure good communication. And sufficient alone time, free of: ringing phones or nagging emails; nearby loud discussion of last night's game or soap; meetings, stand-up or sit down; micro-managing managers and lead-from-all-sides project leaders; to allow me to be at least doubly productive as I am in a 9to5 day. (And often as not triply productive as many of my peers.)

      I would work 4 days weeks or 3 week months, and at least double my usable free time.

      And they picked up the tab for my evening take-outs, as well as the hotels.

    3. There is considerable personal (and group; I was usually part of a team that took on these roles), satisfaction in bringing a behind schedule & over budget, doomed to fail project in, back on track.

      Even better if you can bring it in, on or near to time & budget.

    As with all aphorisms, over-simplifications and dogmas; there are always (at least) two ways to view things.

    If you are charged with developing an up to 12 man-month -- 4 men/3 months; 2 men/6 months etc. -- (say) 50k-100k, data-entry or shopping cart project, for the 3rd or subsequent time, then you can, maybe, get away with a big-design-up-front-and-hope-the-implementation-works, waterfall approach to project management.

    But, once you reach the scale of projects costing (multi-)millions and requiring high-10s/low-100s of developers, by the time you've researched and planned your project to the level of detail required to ensure that method succeeds, you are bankrupt!

    Because your competitors brought 3 or more revisions of your vision to the market place and stole the march on you. They were probably imperfect--lacking functionality or a slick interface or both--but that improved over their 3 releases. And at that point, it doesn't matter how perfect your implementation is would have been, it won't get a look in. That's in the commercial software world.

    In governmental projects, you were cancelled before you wrote your first line of code. Actually, before you even came close, because almost all government contracts call for an early proof of concept demonstration; and then frequent sometimes unannounced, proofs of progress.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      I personally think that what you are saying, and what I am saying, is not mutually-exclusive at all.

      Certainly, some tasks need to be done during “other shifts,” specifically so that they do not impact the first-shift activities.   (And, in an Internet that works around-the-clock, “it’s eight o’clock somewhere.”)   (Reference to a Jimmy Buffett/Alan Jackson hit song.)   There can indeed be great advantages to working a shift that overlaps nine-to-five.

      I am quite confident, BrowserUK, that you are experienced enough to have planned your own work (and/or your own team’s work) very well, even if the hours worked were unconventional.   It is easy to know from hearing you “speak” that you have been around this block many times:   yours is the voice of well-seasoned experience.   The particular situation that I was speaking of is a different one:   lack of planning, both before and during the execution of the project.   (As you well know, a project that is designed to have staged-deliverables and prototype deliverables must be planned before and during its execution, even more carefully and nimbly than other projects must be.)

      I just had the very unpleasant experience of being close-at-hand to what turned into a one-month long train wreck.   It was a very time-consuming data load process for a production system; a process that indeed would take several weeks, and it should have had two weeks to spare.   But no one took the time to make sure that all of the files to be loaded were in place, that they were the correct versions, or that they were not corrupt.   No one took the time to make sure that tablespaces were big enough, nor that temporary space pools would not be exhausted, even though this was a monthly process that had been done many times before.   (Apparently it was always like this.)   And so the train-wreck happened, I surmise, again.   Steps were running for days and then crashing.   One step after another after another, and it obviously could never have been otherwise (for entirely predictable, technical reasons).   “This thing’s gonna blow, because it cannot possibly do anything else...”   I frankly could not believe my eyes.   What was the subsequent demand?   You guessed it ... overtime.   What possible good it would do I know not, but very single person on that team was expected to throw their lives to the wind for the duration.   “Ride up to the front with our horses and lances and try to dodge the machine-gun bullets as we battle heroically save the day.”   There was no planning, only reacting ... like having one’s head stuck in the middle of a gumball machine.   It was the damndest thing to watch, and a certain Billy Joel song was running through my head.   It happens.   Frequently.

      I know that, for myself as for anyone else I have ever worked with, mental fatigue is a critical concern.   (And as I get older, my stamina is not what it used to be.)   You can get tired, and your concentration goes to hell, and you go into what I call, “stupid mode.”   I know from experience that the only thing to do is to “take a backup now, and get the hell away from the keyboard.”   No drinks, no coffee.   Read a book and go to sleep before you do any serious damage... because you will.

Re: Overtime: the "Bad News" Warning Sign
by JavaFan (Canon) on Dec 22, 2010 at 21:52 UTC
    In a previous job, I quickly noticed that they often scheduled a Saturday for testing, recruiting some "volunteers", only to cancel it more often than not on the Friday before. And when it happened, people had a hard time to get a compensation day. By the time they started asking me, I answered, "sure, if I can take my compensation day *tomorrow*". Needless to say, I never did work on a Saturday for that employer.
Re: Overtime: the "Bad News" Warning Sign
by MishaMoose (Scribe) on Dec 23, 2010 at 13:18 UTC

    When in such situations it was amazing how often I would hear such wonderful advice as "You need to work smarter not harder" from the management that was responsible for the situation. I even had one manager, when I was working 80 hours a week as a sysadmin, suggest that the answer to my problem was to use my freetime to develop AI code to structure my work. free time(?) Sigh. The same manager who insisted we send out a mass email to explain to users that email was down.

    Problem was we were trying to run a 25000 user infrastructure with 3 sysadmins one of whom managed never to be available for his on call cycle. Mangement said they could not justify the recurring costs of more staff After 6 months of that I was a wreck.

    Misha/Michael - Russian student, grognard, bemused observer of humanity and self professed programmer with delusions of relevance
Re: Overtime: the "Bad News" Warning Sign
by zwon (Abbot) on Dec 24, 2010 at 12:14 UTC

    I'm sorry, what country are you from? I worked in Russia and now in Malaysia, and it is not common at all to work overtime. Even in f*n' Russia they have to pay you at least 1.5 times (usually twice) for working overtime, and they usually have no right to force you to do it, you can easily ask for two days off for working on Saturday. That's kinda the thing I learned since I started my working experience -- YOU MUST NOT WORK MORE THAN 40 HOURS PER WEEK -- the health is more important. And it's not like there's a problem to find a good job for a qualified programmer, more like it's a problem to find a good programmer.

Re: Overtime: the "Bad News" Warning Sign
by Limbic~Region (Chancellor) on Jan 14, 2011 at 19:36 UTC
    Before I call you crazy, let me say that forced overtime sucks and should not be something one just accepts.

    No matter what “justification” is proffered in its defense, overtime is (IMHO...) generally the easiest-to-spot sign that a project has been poorly specified, poorly planned, poorly managed, or some combination of the above.

    You are crazy. What planet do you live on? Perhaps you have lead a statistically improbably life where the majority of the places you worked got projects completed on time, on budget and feature complete. In general, it is a fairy tale. There isn't any company I know of that consistently is able to meet those standards including Microsoft - the most successful software company in existance. It doesn't matter if you are following CMMI, ISO 9000, ISO 15504, spiral development, waterfall development, eXtreme programming, etc - software projects very seldom are finished on time, on budget and feature complete. That in no way should be the sole indicator that you should walk away from a company or that they won't be great to work for.

    I would probably have taken a different approach. Like high cholesterol, overtime can be an early warning indicator of problems ahead. I would then take the analogy further an say that there are both good kinds and bad kinds of cholesterol. That it is important to ask up front about overtime and provide a list of specific questions to ask that might help differentiate between the items raised by JavaFan and BrowserUk from the detrimental to your health kind that you are obviously concerned with.

    What is personally important to me is knowing if overtime is mandatory, what compensation is provided and what frequency/duration I can reasonably expect.

    Cheers - L~R

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://878675]
Approved by moritz
Front-paged by moritz
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2018-06-18 11:50 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (109 votes). Check out past polls.