Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
Asked to put in extra hours

I am currently in the final 6 months or less of a project scheduled to be a year long. Currently I am facing really tight deadlines for our software releases, and a ton of bugs to be fixed on earlier releases.

I am working in 8 to 8 work days, and even goes back to work during my weekends. I do not receive overtime or any other benefits. And still I seem to have so much to do.

Regardless of this, just to be clear, I love what I am doing, i.e. coding. I wouldn't consider myself doing anything else for a living at this moment, but I feel the long work hours are starting to create an imbalance in my life.

I'm just a fresh grad with half-year work experience. Is this a norm in software projects? Should I be expecting good benefits, as well?

Edit: The 'any other benefits' here I meant was benefits which were linked to the extra hrs I put in. We do have the typical benefits employees in any normal firm would receive such as yearly bonuses, annual leaves, medical allowances.

share|improve this question

marked as duplicate by Yannis Rizos Mar 8 '12 at 15:41

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2  
Highest voted Duplicates 1 Asked to put in extra hours 2 Typical hours/week for programmers –  Aditya P Apr 23 '11 at 18:32
    
Commenters: comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this question with others, please use chat. See the FAQ for more information. –  user8 May 3 '11 at 19:51
    
Are you working long hours because you are new and inefficient and still learning and just not as productive as others? I don't expect Junior developers to produce as much as someone with 10 years experience, so you are either agreeing to to much load or being given too much load, which is it? –  Jarrod Roberson May 3 '11 at 20:51
    
Do you consider compressing 5 years experience into 2 to increase your salary potential quickly a benefit? –  Jarrod Roberson May 3 '11 at 20:53
    
Just an update: Went back slightly early today. And boy it was sure hard and weird to leave that early. Guess I got to start getting used to this, for my own good. –  juniordeveloper87 May 12 '11 at 13:08

15 Answers 15

Companies that value their developers and their products know that sustainability is important. 60 hour weeks are not sustainable. Developers are not manual laborers, they are decision makers. Our decision making faculties become depleted and require rest far more quickly than our bodies. This will have adverse effects on the developers (like causing them to leave) and the product (like causing it to fail).

No, 60+ hour weeks are not commonplace. Lack of benefits (at 60 or 40 hours) is not commonplace. Your company is abusing you and taking advantage of you and other naive or desperate developers (and yes, 6 months of experience makes you naive, but that's ok). Look around. How many talented senior developers do you have? I suspect not many. I know I wouldn't work there. Do you think a company built on naive and desperate developers is likely to succeed? Do you want to work at a company where your ability to learn from more experienced peers is curtailed?

Get out now. Find a better job.

UPDATE:

I'm incorporating some useful information from the lengthy comment discussion before it is cleaned up.

The OP suggested that they were "not FORCED to work 60 hour weeks" and they they are "doing it at [their] own choice in order to meet up with the workload". However, I believe that doing something "in order to meet up with the workload" means that you aren't truly exercising free will. It certainly sounds like the OP didn't feel free to stop doing the extra work.

One possible explanation for management's behavior, suggested by Havoc P, is that a new, inexperienced CS grad may need more time to complete the same work as a more experienced programmer and the managers are not taking this into account. This could help differentiate between a problem managing individuals or a problem managing projects in general.

There is general agreement that a company where everyone works overtime all the time is broken.

share|improve this answer

There are companies who will work you 60 hours a week, and companies who work 40. There are companies who pay great wages and have great benefits, and companies who don't. These axes are orthogonal. That is, you don't have to work like a slave to get a good paycheck and good benefits.

If you want to work 60 hours a week, find a company that pays well, and do something you love. If you want benefits, don't stay with a company that doesn't offer benefits.

If a company wants to find workers to work 60 hour weeks for sucky pay and no benefits, that's what it will do. It may hire foreigners willing to slave in exchange for a visa. It may hire guys with no college degree and no better choices. It may hire new grads who don't know any better. It will chew them up and spit them out. You can run a company this way, and feel like you're really smart.

There are other companies who pay well and don't burn out their staff. It's possible to be successful by finding and retaining good people. It's very much a matter of style.

You are not a failure if you leave a bad job. Don't reward a company or a manager for abusing you. A company may say that they value their employees. (They may even mean it). They will nevertheless dump you in a heartbeat if they need to make their numbers next quarter. They have to. There is no such thing as loyalty. It is a myth used by managers to exploit workers.

Always do what is good for you. Leave a bad job as soon as you find a good one. Leave a low-paying job if you can move to a high-paying job (other factors being equal).

Don't come to believe you are irreplaceable. If you can't be replaced, you can't be promoted. Irreplaceable means stagnant. A company can lose interest in the line of business at which you were irreplaceably valuable. They can hire talent. They can move in a different direction. Keep training. Keep trying new things. Best if you can get your company to train you, but if they won't, you must do it on your own. No company will take care of you as well as you can take care of yourself.

share|improve this answer
2  
"you are not a failure for leaving a bad job". Indeed! –  louisgab Apr 28 '11 at 3:38

Burnout is real. I know at least a half-dozen developers who had to leave programming because they worked too many hours and burned out. Don't let any company do that too you. Until you see it happen you don't realize how serious an issue it is. It could take years to recover. The dangerous part is that the person doesn't even see it coming, it just appears. You may love the programming but putting in all those hours does not allow you to balance your life and it will take its toll after several years.

At most you should be willing to put in a couple of 60 hour weeks a year. If more than that is necessary you should request to get paid for it and even then at most add about 3 to 4 50 hour work weeks a year on top of the 2 60s. Any more than that and you are asking for trouble. As for me, when I go on a job interview the question of how many hours a week is typical is one of my highest priority questions. The answer better be almost always 40 hours or I don't even consider the job. 40 hours is already too many hours out of my life that I could be spending with my family. Even though I love programming and designing systems, Why would I want to spend any more time away from my family and hobbies?

share|improve this answer
2  
very healthy and rational perspective. Life > code –  Sophia Apr 28 '11 at 4:15
1  
I agree most with this philosophy as there are at least a few times I am pretty happy to put in some extra hours...usually right before launch or some key phase. Burn out has happened to me and it did take me about 3 years to get my 'groove back'. I could still make little stuff, mostly did web design those years, but very infrequently. It came to the point I had to get a landscaping job to clear out my mind and then FINALLY I could code steady again a few months later. –  Garet Claborn May 1 '11 at 23:02

The other answers have some great advice. In addition, you might want to start learning more about software project management practices. If you really like your organization, you can try to become a leader and change things for the better. Otherwise, once you understand the different methodologies you can recognize which companies provide a good work environment.

Jeff Atwood has a good reading list to get you started: http://www.codinghorror.com/blog/2004/02/recommended-reading-for-developers.html . You may also be interested in learning about Agile software development.

share|improve this answer
1  
I do think it's better to try to affect a change than just quit outright. Much better that you can come out of it saying you had a positive influence on the company. Of course, don't stay forever if nobody is willing to listen, but if you give up now, it's likely you'll just have the same problem at the next place. –  Dean Harding Apr 26 '11 at 22:26

I am working in 8 to 8 work days, and even goes back to work during my weekends. I do not receive overtime or any other benefits.

You are a programmer. In the US, by Federal statute, we programmers are "exempt" which means that in the absense of a union contract to the contrary, we don't get overtime.

29 U.S.C. § 213 a(17) any employee who is a computer systems analyst, computer programmer, software engineer, or other similarly skilled worker

http://codes.lp.findlaw.com/uscode/29/8/213

Is this a norm in software projects?

You are describing a death march, which is the norm in software development. I usually recommend reading the book Death March. This book should give you ideas of what sort of death marches might appeal to you, and which you should walk away from. It is an occupational hazard and the reason that many developers quit before they hit 35ish. Staying at the office for 12 hour days is hard, and becomes impossible when you have a wife who wonders if you are cheating on her, or children you never see. Listen to the lyrics of the song Cat's Cradle.

Not all companies do this, some just have no clue what they are doing and this is the sort of mess that comes out of managers. And some companies plan on losing staff to burnout and plan it into budgets and schedules. Perhaps you ought to read the rant by EA_Spouse about this sort of thing.

My recommendation for death marches is to get lots of sleep and exercise. When you go home, "forget" your pager and cellphone about half the time. If they are paying for the cell phone, leave it at the office every night.

edit: there was insufficient room to answer Rein's comment in the comment section, so I'm adding more details here.

From the preface of Death March:

industry surveys ... as well as statistical data ... suggest that the average project is likely to be 6 to 12 months behind schedule and 50 to 100 percent over budget.

So the real questions are: If you can't avoid death march projects, how can you survive them? What should you do to increase your chances of success? When should you be willing to compromise—and when should you be willing to put your job on the line and resign if you can't get your way? That is what this book is about.

I can't tell you if you will or will not like Death Marches. Some death marches can and do appeal to the participants, and those score high on the "happiness" scale. The ones Yourdon labeled "kamikaze" might be ones that normally you'd describe as "glorious failures" but you'll never work with such amazing people/technology/whatever again, so going down with the ship is not necessarily undesirable. "Mission Impossible" style death marches are the sort of things where you know that if your competitor gets X to the market ahead of you, then they'll steal your oxygen and your company will shrivel up and die.

My leet skills with MS paint helped me make this!

What makes you happy isn't necessarily what makes me happy, and juniordeveloper87 needs to understand that what he's (or she, but most likely "he" from the demographics of our profession) experiencing right now is not unusual, not uncommon and more likely than not to happen over and over again. I constantly recommend reading the book Death March because it will help the reader understand what goes on, what will go on and how to cope with it. Sometimes the way to cope is to quit. Sometimes to just suck it up and go on. You, me, everyone has to learn that for ourselves; and we need to learn what our own limits are.

I've worked on projects in all 4 quadrants, and the ones high on happiness are bearable and sometimes a lot of fun. It is my experience that "ugly" death marches are the most common of all.

As appalling as the advice "just get used to it" sounds, it is the only rational advice for practitioners in this field. If you are unwilling and unable to "get used to it" then you are going to need to find another career, or join a union. Otherwise you will burn out. There are too many idiots running companies and countries to get away from the stupidity. We do not live in a meritocracy. We live in a world run by the people who used to (and some still do) beat up nerds, and the majority of us were, are and will be nerds.

share|improve this answer
1  
Are you actually suggesting that he decide which death marches "might appeal to [him]"? How about "none of them". –  Rein Henrichs Apr 27 '11 at 19:15
1  
@Rein Henrichs: he still has a point. And even if many of us work under better conditions, there are those facing something like this regularly. Peopleware and other books by the same authors along with several books on project management and team building or the Mythical Man Month "enlightened" me. It's far more difficult to enlighten my bosses, though. Even if I can point to the books written by people with more years of experience each, the bosses may not listen at all or ignore some of the more important details in favor for the shallow and easy "change". –  0xC0000022L Apr 27 '11 at 22:37
2  
"we programmers are "exempt" which means that in the absense of a union contract to the contrary, we don't get overtime." Wrong. No unions needed, just a contract. It's up to you and the company to agree on that contract, not some union exec who only cares about who wins the next election. –  jwenting Apr 28 '11 at 6:20
    
"If they are paying for the cell phone, leave it at the office every night. " check that contract. It might state that you're expected to be "contactable", in which case not carrying it might be reason to fire you. –  jwenting Apr 28 '11 at 6:22

You should know the expectations and the compensation when you accept a job, project, etc. Extra demands should come with extra benefits. If you failed to ask what is a typical work day during the interview, you've learned a lesson.

share|improve this answer
1  
Would it be unreasonable to expect a typical work day to be equivalent to the hours agreed to? –  user1249 Apr 26 '11 at 20:14
    
yes and no. I've worked for companies where the contract hours were a 40 hour workweek, but there were company rules (which here are typically never disclosed to applicants, they're considered company secrets and only get shown after you sign your contract and an NDA) stated that "given the nature of the job you are expected to put in 10 hours overtime a week, overtime pay is therefore not granted for the first 10 hours overtime" or similar wording. Effectively then you sign up for a 40 hour work week but the additional terms (which are legally binding) turn that in 50. –  jwenting Apr 28 '11 at 6:17
3  
@jwentig "legally binding terms" that are only disclosed after an agreement is made are not legally binding at all (in most jurisdictions, IANAL, etc). If they were disclosed before you sign the contract, then that is what you agreed to, full stop. –  Rein Henrichs Apr 28 '11 at 21:34
1  
I'd love to see someone hand me a piece of paper that I sign, that says 40, and then I'd like it in writing that they expect 50 hours, and then I would like them to claim that this is legally binding. I think I could make life very interesting, provided this company operates in a non-banana-republic with a functional court system. Bring it on. –  Warren P May 2 '11 at 19:50

Every company's approach is different. Often the company will pay your salary with expectation that you'd do whatever it takes for project to succeed.

In the end, what's more important to you? Is it money, sanity, free time to devote to family and side projects, education, or glory of the project?

It's definitely a balancing act.

Keep in mind that it commonly takes extra effort to grow into company culture and code base. As your productivity increases with experience, you might also realize that your workload increases. This is because you'll see more bugs in the code you write and code of others. Should you fix all the bugs?

As for the art of project estimation, I saw a pretty cool product called FogBUGZ.

share|improve this answer
    
great question there. Thanks. For me, id want to come home with enough brain juice left to work on other languages or technology I dont get to play with at work.. –  juniordeveloper87 Apr 23 '11 at 17:00
3  
When "succeed" is defined by the same people that make the schedules and set the deadlines, this is meaningless. If I say that you have to work 80 hour weeks for the project to "succeed", do you do it? 100? 120? –  Rein Henrichs Apr 23 '11 at 17:03
    
That falls under education in my book :) –  GregC Apr 23 '11 at 17:03
1  
@Rein Henrichs: +1 for making a distinction between project goals and project planning. –  GregC Apr 23 '11 at 17:26
2  
Okay, what will be necessary for the project to succeed? I'd suggest developers who aren't tired and burnt-out, and ideally can put in extra work specifically when needed. Tired is stupid, and stupid developers can create more work than they accomplish. –  David Thornley Apr 26 '11 at 20:00

Sometimes, it helps to take the time (from wherever) to reflect a few minutes. You say that the deadlines are really tight, and there's lots of bugs from earlier releases. Let's ask why there are lots of bugs.

My guess would be intense pressure. When the deadlines are tight, the reaction is to figure out ways to ignore or paper over bugs until it's time to ship. When people work long hours, they become tired, and write more bugs.

The fastest way to good software is to do it as nearly right as you can the first time. If you work on a bug shortly after you created it, it's usually fairly easy to come up with a good fix. If you work on a bug two releases after you created it, it will be much more difficult. Moreover, if you created a bug in a routine earlier, another developer may have written code that works only with a buggy routine. The concept of "technical debt" is useful here, and it frequently has an interest rate that a credit card company would consider usurious.

The way to get good software written fast is to select good people, and have them work forty-hour weeks. That way, they can stay reasonably fresh. Not being excessively tired or burnt out, they write good code. It's possible to do more by working more hours for a short time, but after months of sixty-hour weeks, you're unlikely to get the same level of output you'd get if you'd stuck to forty-hour weeks. This means that forty-hour weeks are as much long-term productivity as you're likely to get, and it allows you to make a spurt of extra effort. Somebody working sixty-hour weeks has no extra effort to give.

Therefore, you're working for a company that almost certainly doesn't manage software projects well. That they don't give you any benefits (are you in the US?) suggests they don't value you. You're expendable, and you're being expended. Go somewhere else, where you'll learn more and suffer less.

And, in the name of Babbage, if you live in the US do NOT do anything to endanger your health if you're not on a good insurance plan.

share|improve this answer
    
Thanks for the reply. I work in a country in Asia. Yeah, we do have the typical benefits of any company, such as yearly bonuses, annual leaves, yearly medical allowances, and the like. However what I meant by 'benefits' in the above passage was the 'benefits linked to the extra hrs I put in', such as probably a week's vacation, and etc. –  juniordeveloper87 Apr 27 '11 at 13:29

Some thoughts from my experience:

  • Every person has a level of work they can put forth per week on an ongoing basis without a cost to their output. It's different per person, but it's generally going to be less than 60 hours.
  • The further a person goes over their "comfort zone" in number of hours worked, the more their work suffers.
  • Going over your comfort level for a week or two generally doesn't have a huge cost. doing it week after week adds up, though.
  • The actual cost of working over your comfort level can manifest in a number of different ways. Design decisions, code quality, motivation levels, and dealing with other people... all can be negatively impacted.

Because of the above, working extra time, week after week, to keep up with schedules is almost never a good solution. You need to figure out what level of work is best for you. You need to make your management understand that that's the level at which you're providing the most benefit to them, and that the schedule should be set so that that level of work can meet it. If you don't, there are (from my experience) two things that WILL happen:

  • You (and your employer) will pay the costs of you not being able to give them your best work, and
  • Your employer will get used to you working that much, assume it's normal, and just add more work on top of what you already have because they assume you can always cram a little more work in.
share|improve this answer

I have a few counter questions - how long has the expectation been 12 hour days + weekend time? Has it been like this since you first arrived, or have the requirements grown? Do the people around you express this as an extraordinary circumstance or as the typical state of being?

The reason I ask is that it's not unusual for a project to hit a crunch. A crunch can be a month or even 3 months for a project. A project that has been in crunch mode for 6 or more months, however, is a project on the skids and it's probably time to keep your eye out for something better. Whether you've had the misfortune to hit a crunch time or whether overwork is a state of being is best figured out by talking to people in your company. "Is is always like this?" is a fair question to ask. I have had our junior developers ask this at crunch time, and I've been very happy to be clear on what's expected and that Herculean efforts would not be the norm, as I want engineers, not zombies, on the team.

Also - When you say "no benefits", do you mean "no healthcare benefits" or do you mean no free lunch, bonuses or other gifts. A typical U.S. engineering job, even at a junior level, should include medical insurance, it often includes dental and vision as well. Generally a 401K plan is provided, and it's not unusual to have the company contribute up to a certain % in matching funds, either in cash or stocks. Also, 2 weeks vacation plus federal holidays is a given.

When it comes to the thank yous for hard work, that can vary significantly from company to company. I've noticed that hip, newer startups and smaller sized companies in general, can get very cool and wacky in what they provide - trips to amusement parks, massage therapy delivered at work, really awesome sounding catered lunches or dinners, etc. Older, bigger companies that are hemmed in by corporate process are more likely to provide gift checks, gift certificates, incentive bonuses, stock options and less thoughtful gifts. Younger companies tend to provide the bonuses on the spot. For older companies the reward can take up to 6 months to trickle through the red tape process.

It's not a given - a company doesn't have to reward an exempt employee and most permanent employment jobs are exempt positions under US labor laws.

Also - rewards may not come in the form of something handed to you. At times when I've been a go getter in my company, the reward did not come in the form of cash, but in the form of education - I've had more opportunities to self-educate than many of my peers in my department. But that was something I had to ask for, rather than something that was handed to me. But given that my Master's cost the company around 10K per year, this was hardly small money.

If there's really no appreciation shown (including no personal thank you from your direct manager) then it really is time to start looking - not because you had a right to it, but because if your manager can't say thank you (which costs nothing!), it's time to find a place that appreciates you.

share|improve this answer
    
The 12hr days started midway through the build phase (Waterfall methodology used here), which was abt 2 mths ago. Ppl around me see that as normal! The core management team and a handful of seniors typically dont leave till its half past seven, even before the build phase. Its good to know that software projects do face a crunch time. I really hope this is our state right now. The fact that this is a 1 yr proj, and d fact that we r pushing really hard in these few mths, could possibly mean we are just hitting crunch time. Thanks for your insight –  juniordeveloper87 Apr 27 '11 at 13:32
    
I'm hoping for a crunch, too. Midway through code/unit test isn't unheard of in a waterfall project, although it could mean that your company has a habitual problem with scope creep. 2 months can mean a danger zone if you guys truly have to do this for the rest of the year. People just can't ignore their personal lives that long without having the personal life and/or the work life fall apart - and when life falls apart, work gets even harder, not just for the person, but for the team. –  bethlakshmi Apr 27 '11 at 14:40
    
waterfall ?? really ?? i thought really old ppl used waterfall. sorry for the sarcasm –  Wildling Jun 15 '11 at 8:08

If you do not protest, you are doomed to live like a slave for life. I refused to work long ridiculous hours in one of my earlier companies. Things changed. Read on, there is more to it. Long hours are generally an indicator for one of the following problems: 1) You are not good enough for the job @ hand If you are struggling to finish a feature because your lead expects a certain level of competence and you are not upto mark then, well, nothing much you can do. Either own up and talk to your lead or forget weekends. It might mean leaving the job. If you are struggling to finish a feature because of numerous bugs you are adding, then learn to do it better. Invest more time into doing a better job (plan better, code reviews, take help, talk to your lead about your problems). Iam sure someone will come to your rescue.

2) Your manager/lead is accepting work that his/her team is not capable of delivering Your lead/manager is promising his/her higher ups the sky. Sit down with your lead and explain to him/her your limitations. Your lead/manager has no clue what's happening - bad planning. Talk to your lead's manager and sort this out. You might be called a rebel, but hey remember Star Wars - as long as you have the power, you will come out shining. Best thing to do is to log the number of hours you are logging.

In any case you have to act on this. Stay quiet and things will continue the way they are. If you get fired because you complained find another job - can't be worse. If you are good you will find another job easily. BTW this initially happens to "junior" programmers but won't take long to catch up with the "senior" programmers.

I went through a similar issue but I fixed it by making sure that every feature creep hurt the lead's reputation. Fast<->Good<->Cheap Pick two. I always use that concept. It is amazingly useful when you have to talk to your leads. BTW one of my first oaths when I became the lead was to eliminate crunch time. Trust me, my team members have a social life and the number of bugs they seem to add went down drastically because I would refuse useless feature creep from clients.

share|improve this answer

Unfortunately, there is a tendency to use and abuse programmers. Part of that, I think, is because we don't put out a physical item (such as a car) or do things that are physically demanding (such as working at FedEx), so people don't think we do "real" work. The problem with this mentality is that it can't be farther from the truth. Mental work takes work, and we're at least as prone to burnout as any other creative individual.

Is it the norm? Well, it's not quite as simple as yes or no. There are a lot of companies that do that, yes, but there are also a lot of companies that actually value their employees and don't encourage people to work 12 hour days every day. It's bad for morale, it's bad for burnout, and it's bad for your physical health in a number of ways (weight gain from inactivity, vitamin D deficiency from lack of sunlight, repetitive stress injuries, and so on).

I highly, highly recommend reading the book "Why Work Sucks (and How to Fix it)". Two of the big things it covers that are relevant here is the dawn-to-dusk attitude ("if you're not the one turning on the lights in the morning and turning them off at night, then you're not a team player"), and fabricated emergencies. I also highly recommend reading this blog post and see how many apply to your workplace (hint - I know of two for sure, from what you've posted, and two or three more that I wouldn't be surprised to see in your work environment, as well).

Overtime is a normal part of working, but it should not be a constant thing. From reading your comments, this is a normal thing in the company, which means a project manager is really bad at their job (part of being a project manager is learning how to accurately estimate timelines).

In short, get out as soon as you can. It's great that you're getting experience, but it should never be at the expense of your health (and working weeks that long will take a toll on your mental and physical health). I also highly recommend looking into companies that use Agile methods of software development. The waterfall method only works for what it was designed for - physical structures. Software development is an ongoing process. There will always be bugs, no matter how good you get.

share|improve this answer

I had this happen to me for a little bit in an internship position with a small company. It's certainly not sustainable for anybody, but for a while I was excited because I was learning a few new things. At this rate, ones productivity may also decline. You need to make sure you are not over-working yourself to the point where you are working all the time and still not getting anything done.

share|improve this answer

Long hours only appear to be the norm because new developers usually want to learn and improve skills, and impress managers in hopes of getting a not-so-junior jobs and pay as quickly as possible.

Some managers take advantage of this dilemma, but you commented that you do it by choice as do many others.

You mention not getting paid for overtime. I assume you are salaried, or is the overtime a donation on your part? I don't believe that a company can opt-out of paying you overtime if you get paid by the hour.

The lack of benefits is troubling. Definitely not the norm in my experience. Any decent company will offer you some benefits after 90 days.

share|improve this answer
    
Yes we are paid salary-based. –  juniordeveloper87 Apr 27 '11 at 13:36
    
Going off personal experience only, I've employed a number of salaried junior developers who put themselves through the paces. We offered health insurance 60 days after starting and didn't force overtime. Most worked as much as they could anyway, just to get experience. Once you have a year under your belt, more options open and hopefully you don't make yourself work so much. –  Fred Wilson Apr 27 '11 at 17:07

It can be normal for some companies but not most.

Does everyone else in the team & department work the same hours or are you just doing overtime because you can't say no?

I really like working in the evenings when everyone has gone home, its a great time to get things done without interruptions. However looking back I spent a lot of time doing extra work for bosses and got nothing out of it, it really wasted a big chunk of my life for very little return.

So, if everyone in the company is doing it and you'll get fired if you dont, you're going to have to keep up the hours. If its your own perfectionism or lack of backbone that means you're working longer than everyone else, decide how you're going to play it, either start going home earlier, or work only on the projects that are especially interesting or useful to you.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.