Are long hours and no benefits the norm for a junior programmer? [duplicate]

Question

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.

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.

Answer 5

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.

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.