Coffeehouse Thread

40 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Very tired

Back to Forum: Coffeehouse
  • User profile image
    ScanIAm

    Timesheets are used to skirt the laws about salaried employees by forcing them to 'lose leave' if they work less than 40 hours even if they don't gain leave for working over 40 hours.

    The whole point of salaried workers is that your hours don't matter as long as you produce.

  • User profile image
    evildictait​or

    , ScanIAm wrote

    It's the same in the US.  Some jobs are classified so that employers MUST pay for overtime.  Tech workers are usually exempt from that because they are hired as 'salary'.

    Oh. That's easy then. If my contract said "9-5:30, no overtime will be paid" then I would auto-reject all meetings and phone calls scheduled before 9 and would select "hibernate" on my computer at 5:30.

    This is a good habit to do anyway, since if you're routinely working more than your contracted hours, it's probably because your department is under-resourced. By working those extra hours you're rewarding the clever guy at the top who says he only needs two staff instead of three - you're not helping yourself or your co-workers.

    Ultimately the decision as to whether your boss wants to pay for your overtime is a decision that your boss makes - not one that the law makes. Just because you're salaried, doesn't mean your company doesn't have overtime.

  • User profile image
    Bass

    I can't even imagine having to work 60 hours a week, 40 hours is way too long as is.

  • User profile image
    cheong

    For a record, I've been working for 46 hours this week upto Thursday, and there's 2 workdays left in this week.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    ScanIAm

    Deadlines are deadlines, so sometimes you have to just suck it up, but there's no gun to your head (I hope).

    I've found that if you grab your stuff and go home, nobody will stop you.  They also tend to want you to come back the next day.

    If not, then you haven't lost anything.

  • User profile image
    kettch

    @ScanIAm: While I'm sure we can all agree that deadlines should be based on when the project is done, that doesn't always happen. However, deadlines are usually known ahead of time. Work should be scheduled and prioritized based on that deadline. Sadly, few companies seem to understand this. I'd rather work harder at the beginning so that there is more time to slow down and coast across the finish line.

  • User profile image
    CaRDiaK

    Personally I'm not a 5.01 coder..

    I find I work well under a certain amount of pressure.

    It's when this pressure becomes too great (not having enough time to actually write the program, never mind thinking about it) when I start to crack. Sometimes this leads to MMM by getting more resource my way (when it's too late) although not always. Sometimes you just have to march on and get your scar.

    It's retrospect where the process needs to be investigated and amended. Agreeing sensible amounts of work doesn't always happen for me.

    There are so many variables and circumstances that not all PM's can forsee.. But again in my case, when it hits the fan, quality is out and JFDI is in.

    I feel for you. Hope your ok!

    We can only see a short distance ahead, but we can see plenty there that needs to be done.
    Last modified
  • User profile image
    evildictait​or

    , ScanIAm wrote

    Deadlines are deadlines, so sometimes you have to just suck it up, but there's no gun to your head (I hope).

    If you're coming up against a deadline and need to stay late - that's because the project manager screwed up. Not because you're obliged to stay late.

    Project managers should allocate extra time close to release in order to make sure that everything can be done in a logical and ordered way. If you're forcing your staff to work ridiculous hours - all you get is a stressed out workforce, your good staff will leave, and mistakes will creep in.

    Deadlines are deadlines - and while it's fine for you to stay late a couple of times to help out, or to correct your own errors, you should be careful about ever getting to a place where it is expected that you will work more than your contracted hours for no benefit.

    Don't let your boss exploit you. 9 times out of 10 in this industry he needs you more than you need him.

  • User profile image
    spivonious

    I make it a point to work no more than 40 hours a week, unless it's an emergency, salaried or not.

    A planned release being behind schedule is not an emergency. It's a sign that the deadline will be missed and that the project manager screwed up. Consistently missing deadlines means your estimation is way off and the whole team needs to reevaluate how they're doing things.

  • User profile image
    evildictait​or

    , spivonious wrote

    A planned release being behind schedule is not an emergency. It's a sign that the deadline will be missed and that the project manager screwed up. Consistently missing deadlines means your estimation is way off and the whole team needs to reevaluate how they're doing things.

  • User profile image
    kettch

    @spivonious: And if that's consistently the case, then you need to be somewhere else, because poor project managers rarely take the blame.

  • User profile image
    ScanIAm

    , kettch wrote

    @ScanIAm: While I'm sure we can all agree that deadlines should be based on when the project is done, that doesn't always happen. However, deadlines are usually known ahead of time. Work should be scheduled and prioritized based on that deadline. Sadly, few companies seem to understand this. I'd rather work harder at the beginning so that there is more time to slow down and coast across the finish line.

    The few times I've tried to be proactive, I've seen no improvement to the crunch at the end of the project.  Usually the subject matter experts (a.k.a. eventual users) will drag their feet and/or wait until the last minute to test (and find bugs). 

  • User profile image
    vesuvius

    , spivonious wrote

     A planned release being behind schedule is not an emergency. It's a sign that the deadline will be missed and that the project manager screwed up.

    Developers almost always get "bucketed" with the Project Manager, because ultimately it is you that provide the project manager with the data to make a guesstimate.

    There are certain classes of problems where you just should not even attempt to use sprints or whatever project planning mechanism you choose. If is is a webforms/Mvc application, with a bunch of CRUD, you can more or less get the project plan right. The problem with most IT projects is that they require innovation a lot of the time, and it is much harder to quantify somebody wanting to produce an application where there is nothing on MSDN or Google or any Books.

    Lets take the cloud for example, I have been interviewed where people want something like Azure with Push notifications on Android and iPhone and asking whether they think I could do it in 6 months.

    Most of the time developers are too optimistic, and constantly dissapoint, by saying something is easy, and weeks or months later a task they said would take a few days is still not quite working.

    All in all, I prefer working with Scientists, as typically for example, a biologist can run experiments for 3 months, and find that things just plain don't work. They accept that failure is a direct consequence of innovation, dyed in the wool, project managers consistently manage IT project with targets like people are producing cans of Heinz beans.

  • User profile image
    vesuvius

    , kettch wrote

    @spivonious: And if that's consistently the case, then you need to be somewhere else, because poor project managers rarely take the blame.

    poor project managers never take the blame

  • User profile image
    vesuvius

    , ScanIAm wrote

    Usually the subject matter experts (a.k.a. eventual users) will drag their feet and/or wait until the last minute to test (and find bugs). 

    You need to take mind-reading classes

  • User profile image
    kettch

    @vesuvius: A few months ago we started a project where the project manager told the customer that he wasn't going to devote a single development hour to the project until the information gathering, business analysis, and other planning was all complete. This was something very new for our organization. After much wailing and gnashing of teeth the customer relented, and they did 4 months of business analysis, gathering specs and all of the stuff you wish you could do all the time. When the development package was handed off to the developers, we were in awe. It was a complete departure from previous projects. So far it's been quite fun. We never have to ask questions, it's all in the documents. Plus, it looks like we're beating our time estimates.

  • User profile image
    spivonious

    , kettch wrote

    @vesuvius: A few months ago we started a project where the project manager told the customer that he wasn't going to devote a single development hour to the project until the information gathering, business analysis, and other planning was all complete. This was something very new for our organization. After much wailing and gnashing of teeth the customer relented, and they did 4 months of business analysis, gathering specs and all of the stuff you wish you could do all the time. When the development package was handed off to the developers, we were in awe. It was a complete departure from previous projects. So far it's been quite fun. We never have to ask questions, it's all in the documents. Plus, it looks like we're beating our time estimates.

    And that's how it should be. Too many dev departments are afraid to stand up to the customer like that. You can't give an estimate until you know what you're supposed to be doing.

  • User profile image
    vesuvius

    , kettch wrote

    @vesuvius: A few months ago we started a project where the project manager told the customer that he wasn't going to devote a single development hour to the project until the information gathering, business analysis, and other planning was all complete. This was something very new for our organization. After much wailing and gnashing of teeth the customer relented, and they did 4 months of business analysis, gathering specs and all of the stuff you wish you could do all the time. When the development package was handed off to the developers, we were in awe. It was a complete departure from previous projects. So far it's been quite fun. We never have to ask questions, it's all in the documents. Plus, it looks like we're beating our time estimates.

    4 months planning is just too long for most projects that fail, so you are writing of the essential practices that contribute to less stress all round and better chances of success.

    Be very careful though, sticking to documents that were written 4 - 6 months ago means that you may finish the project and when the project fails, you can say you did what was written down, but supplied the customer with a product that does not suit their needs.

    Be prepared to have to do a big rewrite midway, because of a subtle but essential detail that was misinterpreted or the customer finding out that what they said they wanted wasn't exactly what they wanted. It is the ability to accommodate this type of change in well managed projects which results in a successful project, rather than wasting time and money blaming the person that gathered the requirements or the customer.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.