A forty hour work week is 2080 hours of work per year or 260 8-hour days. A fifty hour work week is 2600 hours of work per year or 325 8-hour days. A sixty hour work week is 3120 hours of work per year or 390 8-hour days. Working 8 hours a day, seven days a week is 56 hours of work per week or 2912 hours per year.

There are about 8765 hours in a year according to Google. Sleeping the average 7.5 hours of sleep per night takes 2737.5 hours per year.

The forty hour work week leaves a person with 3947 hours of time remaining for other activities. The fifty and sixty hour guys have 3427.5 and 2907.5 hours of time remaining, respectively. That's almost 10, 9 and 8 hours of free time per day, respectively.

When the hours are typed out in that way it would seem as though one could easily balance work and life into neat boxes on a Gantt chart. A block for 7.5 hours is allocated to sleep, 10 hours to non-income generating activities and the remaining 6.5 hours are all about work. To be clear, that last bit assumes that you work 7 days a week 6.5 hours per day, weekends are simply removed from the equation entirely.

Let's consider that same Gantt chart with weekends. The hours become 37.5 for sleeping in a 5 day work week, 40 hours of work in a week, and 48 hours for the weekend leaving 42.5 hours of free time in the work week or 8.5 hours of free time per day. The fifty hour guy has 6.5 hours of free time per work day and the 60 hour guy has 4.5 hours of free time per work day.

"Free time" is a loaded term, it really means non-income generating time. Out of that time comes activities like eating, bathing, cleaning, commuting, shopping, kids (if you have them), other maintenance activities and recreation.

Now these stats may sound a little unlikely: how many software engineers really work more than 50 hours a week? Well, according to the Bureau of Labor Statics, a branch of the U.S Department of Labor, 17% of software engineers in 2006 were putting in more than 50 hours per week.

There is a famous survey from 1996 of lawyers that asked whether the surveyed attorney would take a 10% pay cut in return for 10% more free time. Attorneys can have incredibly busy lives depending upon the kind of law that they are trying to focus upon. A 50 or 60 hour week can be very reasonable and in fact 37% do. But how many would trade the long hours for less pay? 84.2% of attorneys in one survey would love to slash their pay in favor of more time off.

One aspect of software development, especially early in one’s career, is to work a lot of hours on a lot of projects to get exposure to as many technologies, algorithms, design patterns and styles of software development. All this exposure in the early years can be beneficial in a similar way as an attorney or a doctor being packed full of information during their job’s rights of passage. We have no more or less a difficult and thought requiring job, though we usually can’t account deaths to our mistakes.

There is a point of diminishing returns though. How long before a new developer starts to build the same components over and over again? EJB’s are an example of a technology that nearly every Java developer has implemented a few times and then understands the underlying issues and difficulties. Are you going to learn very many new insights if you keep writing dozens more? Does the work stop being one of new learning and become rote repetition?

It is entirely possible to get a 40 hour work week but it usually comes with a price. Bigger companies and non-profits often require fewer hours than small companies and startups. The downside is that there is far more bureaucracy, slower schedules and sometimes less innovation. On the other hand, there is a push for greater software correctness, design and process. Startups are often not so good on the design and process side of things because they are in a rush to get their product out the door so they can have income. That is only my opinion on design and process, though I’m pretty sure I could find a survey to back that up.

Bigger companies do not necessarily pay any better or worse than other companies, however, their option packages are generally small and irrelevant. Big companies are often public companies too, but a public company can only sell shares at a small discount or hand out a relatively small number of options. The difference is that they are worth something, but the likelihood of becoming a millionaire at a public company as an engineer is pretty slim.

A startup may give a pretty sizable number of shares to its early employees which results in a chance at making a pile of money. The downside is that it is very likely that the options will be worthless as only a very small number of startups go public or are bought out at a profit.

Option packages and employee stock option programs (ESOP) at big companies are usually a good deal. An ESOP is usually discounted so you buy at say 10 to 15 percent below market value, which means you can often flip the stocks, rather than hold them, and get a great return on your investment.

There is an important distinction though between big companies and small companies for senior developers. Big companies can afford to pay well beyond small companies for senior developers. By senior, I mean developers with more than 15 years of development. These developers often top-out the salary range in small companies, while large companies may have significantly larger salary caps.

Salaries alone do not motivate developers, project complexity and responsibilities are often very important for attracting developers. That’s obvious though, pay a creative person a lot of money to do a boring and repetitive task and he’ll still quit. It is simply a matter of time. Give that same developer an interesting job and he will quit too, but he may stick around for years.

Free time comes into play when a developer reaches a point in his life when he is happy to trade salary for free time. Going to a big company or a non-profit may result in an initially lower pay level but much more free time than the average startup. The questions are where are you in your career and how important is it to be able to other things than work?

Some developers look down on these conversations, and interestingly enough, so did the partners of various law firms mentioned in the survey. The complaint is that good lawyers have to love the work and so they want to put in the extra hours. This is what separates the average lawyer from the great lawyers, accord to some of the partners. It’s the level of commitment, not necessarily the actual contribution or quality of work that mattered.

I think we see something similar in the software engineering. There is a “keeping up with the Joneses” attitude related to hours worked. “Land of the overworked and tired” talks about a situation in DC during the summer in which office workers all were dressing up for work because everyone else was doing it. The unspoken communal rule was to dress up and so everyone did it.

We see this in our own work places too. Hours-worked is a great example where people put in really long hours because everyone else is doing it. The problem is that quality of work and start time can become irrelevant in measuring how good of an employee you actually are. Consider that a developer shows up at 6 in the morning and leaves every day at 4. He’s been at the office for 10 hours. Compare him to the developer working from 10 until 7. The other developer has been at the office for 9 hours. A great manager will see the difference and acknowledge that the early morning fellow is really putting in the hours. A mediocre manager may miss that entirely and see the developer working into the evening as the more committed.

However, it is unclear who is actually more productive. It could be that the person with the shorter workday is producing more bug free code than the person putting in the additional hours. It could be argued that a person working long hours is not working as efficiently as a person working shorter hours. It could also be that the longer hours person has been assigned much more work. It could be that the longer hour person is goofing off more or less than anyone else. It’s not possible to tell which is the better employee from hours worked at all. It’s a bad metric.

An argument for working longer hours is to get a promotion, better projects, learn something new, avoid some other activity, get ahead of schedule and as an attempt at getting more salary. The positive is that you may be more productive and making a valuable contribution to the company. It’s really important to love the work and derive real pleasure from it such that the work is its own reward. The negative is that people may not notice or care and thus the positive feedback and esteem that you were hoping for may not occur.

There is a risk that once you work so many hours voluntarily that it can become an expectation. Consider that if you work a 55 hour week every week that eventually your task assignments shape themselves around that schedule. Let’s say that you always get 40 hours of task assignments but work 55 hours. You exceed expectations by accomplishing an additional 15 hours of work on your own initiative and applauded for it. The problem occurs when you are tasked 55 hours of work the following week. At that point you have a new bar to reach each week. Others may still receive 40 hours worth of work though. Now your longer hours are expected but no one else is working as hard as you. Your peers are working 28% less than you and you are getting paid the same as if you were working 40 hours. In theory, the company may reward you for your efforts at review time.

Small companies generally require more hours than larger companies as mentioned a dozen or so times so far. You get better pay depending upon how far the company has come and you may work on something really interesting. The issue of making more money is that it often comes with some kind of externally driven status. You get a slightly neater watch or an expensive car. You get to save more money or have a snazzy couch. The time you are expected to work could easily be 50 hours a week but most companies still go into crunch. How long that crunch lasts for is important.

A crunch in a small company may mean working the 8, 9, 10 or 14 hours a day for 5,6 or 7 days a week. Compare that to a crunch at a company that requires only 40 hours a week. There may very well be a serious issue with ordering people to work the really long hours at a big company. They may raise the hours to 50 or 60 hours too but you started at a much lower number of scheduled hours per week.

In the small company we had a person doing the 2600 hours a year and then working more hours because of a crunch. In the big company, we talked about a person working 2080 hours a year and then raising because of a crunch. No matter how you slice it, the person at the 40 hour a week job is still working fewer hours generally and so has more free time.

There is this steady drive to make more and more money and the easiest way to accomplish that is to hitch up to a small company and work the additional hours. At some point you can look at the salary and ask whether they are paying so much because you are an incredibly skilled developer or because they are compensating you for the additional hours.

There is a moment when your life turns and you realize that you have missed too may weekends, summers, seasons and years. That the big money stops being so worth while and that all you really want is to spend some time barbecuing with family and friends. At that point, maybe it’s time to take fewer hours for less salary and do what so many attorneys wish for.