The company managers don't care about you and your work/life balance, only the work they can get out of you. And in terms of efficiency, that means paying you the smallest salary and benefits that you'll accept. And it means telling you whatever is necessary to get you to be as productive as possible. If they can get you to inprove processes or something, even better.

Also, with pretty much everything in life, including software development, there IS a correlation between hours worked and quality/quantity. All other things being equal, the one who spends 40 hours working, not just typing, but thinking about the problem, fixing bugs, finding new ones, improving performance, refactoring to improve structure, et cetera, will produce work output that is higher quality or in grater quantity than the one who puts in 30 hours. And I know you're the special snowflake who can do a better job in 30 hours than that other guy can in 40, but that's irrelevant. They are paying you a complete salary, so they can demand that you put in complete effort. The good news is that once you can prove that you're producing more in your 40 hours than the other guy is, you can demand a higher salary or take your talents elsewhere.

Edit: Fixed grammatical error.

They can "demand" whatever they want. They can demand a pony for all I care. I provide what I want, and that's not always 40 hours a week. If it's still worth it to them to employ me, then they may continue to do so. That's all there is to it.

Let's not grant the corporation too much moral high ground. They routinely ask people for more than forty of those hours. Let's not pretend someone is a reprobate for granting fewer.

It's pointless to act like they have a moral right to a specific number of hours simply because that's the convention or because that's what they wrote in an employment agreement that grants you nothing in consideration for your concessions. I work, you pay me. If you don't like my work, fire me. I'll do my work in as many or as few hours as I please. Those are the terms I'll abide by.

Don't get me wrong, I understand the incredible luck I have to be able to operate this way. Only the strength of the seller's market that is software labor, and my own financial prudence, allows me this freedom. But it is a freedom I feel no reluctance, moral or otherwise, to exercise.

Honestly, I genuinely don't understand how the classical employment model (salary alone) ever worked for any professional employers/employees. Incentives are diametrically opposed, and in 90% of situations someone is getting at least partially shortchanged.

Yes; there's one shaped a bit like a bell curve. Too many hours, and you start losing creativity, your focus becomes too short-term, and you start missing things, making expensive mistakes.

Coding when tired is usually net negative, unless it's something throwaway for a demo due at short notice, or it's something you've done a dozen times before and don't need to think about. All too often, you overpay later fixing bugs and refactoring design mishaps.

I think there's a bit of a fallacy behind your assertions. Whether you're present at work for 30 hours or 40 hours doesn't make a massive difference to a job as intellectual as software development. Your brain doesn't completely shut off work when you go home. Much of the thinking time that you'd spend at work in 40 hours a week will happen at home when working 30 hours. Manual labour, and famously, showers, are conducive to this thinking.

I find I'm both more motivated and create better software if I stop working in the middle of something, before I've gotten too tired, and come back to it the next morning. I don't know my optimum number of hours that need to be spent at a desk in front of a PC to maximize my productivity. It's almost certainly less than 40.

We have one employee who thinks he is a rock star (he is not), he finishes his assigned tasks in 4 days instead of 5 and then takes Friday off because he thinks he "deserved" it for being so damn creative and intellectual and he thinks about work at home anyway... Guess what happens on Fridays, people are still at work and need to contact this guy, questions about old code, plans for future, a new task came in, and surprise surprise, the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that?

Its a tough balance, i am also very against pushing through when unispired and the sit on your chair and wait for the clock kind of job and I also need distraction free creative time. But this guy has thought me that many times the team needs you more than you need your oh so precious creativity and that is what you are being paid for, helping the team, the company, to move forward.

A team leader that uses people like this - cogs that munch through assigned tasks - is not operating at high efficiency. It's top-down directed, and is missing effective feedback from people who know most about the code, its architecture, what it can and can't do. People are treated as manual laborers rather than self-directed professionals. You're only using 40% - if that - of their capabilities.

There are times when a team needs to operate like that - e.g. impending business-related deadlines - but they should be exceptional. The top-down model creates work politics, where the team members need to lobby and scheme to influence the team leader to make particular choices, and it leads to atrophy of initiative, and destroys most of the creativity that ought to be latent in a team.

I'm extrapolating a lot from a single statement of yours, so it may not actually apply to your organization, but it definitely does apply to a lot of dysfunctional workplaces.

the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that

The person merging code should be the person reviewing the code, not the author of the code. If code breaks the build, the person reviewing it is at fault for merging it. And code isn't finished until it's reviewed and merged. Reviewing, at a minimum, means making sure it builds, the tests pass, and the tests have enough coverage, using code coverage tools if necessary.

If the code is no good and accidentally got merged, the merge commit should be reverted. If the code is absolutely necessary (e.g. for Monday), that's a crunch, the guy shouldn't have left on Friday, and he's let the team down. You can't do that too often without needing to leave. But not for productivity reasons, for team reasons.

> They expect that you treat your position not just as a job where you work so many hours or do just the tasks that you are asked to do, but that you take more personal responsibility for doing the very best job you can, improving your own productivity, and making the company function better and more efficiently.

That's actually how I prefer to treat my job, and why I like startups. But...

> The company managers don't care about you and your work/life balance, only the work they can get out of you. And in terms of efficiency, that means paying you the smallest salary and benefits that you'll accept.

If the company treats me like that then I'm going to start punching the clock, that's only fair.

There are a lot of employees that take advantage of their employer, and there are a lot of employers that take advantage of their employees (with more leverage FWIW), but such an adversarial relationship is a drag on overall resources and productivity. In knowledge work trust is paramount, there are no metrics which you can use to guarantee that an employee is "100%" productive, and management attempting to do so is a huge red flag for me.

The only difference in opinion that I see here is that those 40 (or 50, or 30, or whatever) don't all have to be done while sitting at a computer and looking busy.

Who is to say that the folks in the OP's article aren't thinking about work problems on a Friday? I'd be shocked if they don't get more of the thinking portion of their job done on a Friday (or after hours or over lunch or...) than they do in the remaining 32 hours "working hours" of the week.

People are up in arms about the lack of traditional appearance of work (that is, in a chair in front of the computer, or in a meeting, etc.), not the time actually spent thinking about how to solve a problem.

So when you think I'm working 40 hour weeks, I'm actually working 20 hour weeks and browsing reddit/HN. The guy you're comparing to that's working 30 hour weeks could actually be working 30 hours straight.

If you compare me working 30 hours and me working for 40 hours, I'll do the same amount of work (20 hours worth + emailing/meetings/other work-related non-coding things)

By the I knew Arrington (mentioned in the article) prior to Tech Crunch. He worked very hard to try and convince me to join Pool.com writing multiple times and not taking no for an answer. Back and forth, negotiating all of that. And I'm glad he did because after agreeing to get involved we made a ton of money from that service for years. I owe that all to the effort that Mike put in and was able to do so because of the hours that he worked (as well as the hours that I worked which was "all the time".)

[1] The problem is people don't realize that some people can work all the time, actually enjoy it and not be stressed. Just like some people can exercise or can climb mountains or swim fast or practice piano or anything else. Just because it burns one person out to work 7 days don't assume that it burns everyone else out to do the same. If you are exceeding your limitations and can't take it don't assume that everyone feels the same way (although they might..)

Working 7 days on extrinsic motivations is soul destroying.

Doing the same on intrinsic motivations is life affirming.

There's also different types of work. Manual labour can be done for long hours - if you're young. Mentally intensive work can be done briefly for long hours, but it rapidly stops working well. If you work is more about connecting people and motivating them, I think it's a bit more scalable, especially if you can feed from the emotional energy of interaction.

"Working 7 days on extrinsic motivations is soul destroying."

If being in the moment isn't its own reward, that moment only pays off when you get the reward at the end. If you need to put in too many of those moments, no reward justifies it.

If your work isn't playful, all work and no play makes Jack a dull boy.

Good luck selling that line when it becomes more profitable to outsource or eliminate your position.

Does this exist in software development? There is always more work to do than there are people to do it (wherever I have worked). If I clearly goof off/don't work friday while others struggle to push us to our goals, I will not have a very good relationship with my team. Our team philosophy is that if you finish early, then you help others out who are struggling. I'm all for working less hours, but there would have to be a perfect storm of events to make it a regular thing, including a push from management to make it the culture.

I don't think it's fair to blame this on bean-counting or crazy managers. Many of us are salaried and don't have people scrutinizing our hours worked.

That's a failure at the management level, not the developer's level. Expecting developers to make up for the management failure will work for a week, maybe even a month. Then attrition will rise, overall productivity will fall, and the team is screwed anyway.

It is quite literally management's job to identify what needs to get done when, and to ensure that they have the proper resources to get it done. If they can't hire, then they need to triage between pushing their workers harder now at the consequence of loosing their productivity (or the workers themselves) later, or pushing out the timelines.

The problem is that most managers don't understand the tradeoffs involved, because we as programmers don't provide the proper feedback (or they're just bad managers and don't listen to feedback that's provided).

> [...] I will not have a very good relationship with my team. Our team philosophy is that if you finish early, then you help others out who are struggling.

It sounds like management has been able to use group dynamics to create an unhealthy working situation. These kinds of attitudes typically come from above, not below. The problem which will arise from this situation is going to manifest itself as the "early finishers" dropping their productivity (why bother working hard when all I get is to pick up after my co-workers), burning out, or they just plain leave. Have you seen any of that yourself?

Try providing feedback up the chain that you need more workers for the given workload. You'll learn a lot from their response.

Sure, there are plenty of cases where management has unreasonable expectations. I'm not talking about that.

And it is often not a 'management' at all. I have side projects I'm working on. I can watch TV at night, or work on the project. I have a limited budget (time) and if I don't spend it on the project, the work won't get done. It's my equity, it's my labor, it's my project. If I'm rested and able to work, but choose not to, well, I end up with less as a result.

Management don't necessarily accurately know how much effort the work will take. They can ask developers to estimate this, but even then it will not always be accurate.

The crux of movements like the agile movement (and management processes like scrum within it) are to make things more process orientated - management ensures employees work for x hours a week following a process, and adapts based on what output they produce (increasing resources if they want more output).

Product orientated processes (where managers tell employees they have to produce y output, and after that they can slack off or go home if they want to) might work if someone's job is to sit on a production line doing a well understood process, but it does not work well for software. I think both businesses and developers are better off for the trend to abandon such processes when it comes to software.

Given a process orientated environment, it is the prerogative of management to make sure everyone works as close as possible to their contracted number of hours - someone who is working less should rightly get called out on it. They may have finished their current task, but they should help someone with their task, or work on improving processes / infrastructure / addressing tech debt to make likely future work easier.

Not everyone needs to work the same number of hours in a process-orientated environment, but if they work less, that should be in their contract (and most likely they will get paid less than they would have if they worked longer) and not just the employee unilaterally deciding that.

Or they listen and empathise, but their budget comes from above and there is nothing they can do.

The deadlines come from above, too.

Note, this is a subtly different response from "We will have to do more with less", which is manager-eese for "I've been shut down by my managers". That said, in either case you should probably be ready to jump ship (though in the second case, your manager will probably be willing to give you a good reference).

More manpower, more money/pay or more time off isn't the definitive answer to problems.

At the end of the day, an employee who is as rigid as you present yourself to be is the kind you hope jumps ship ASAP. It seems like you are the austist type who would complain that they wont be getting a greater variety of snacks in the break room because managers said "We will have to do with less" after being shut down by their managers.

Personal attacks aside, how would you solve the problem, in a way which won't result in churn or reduced performance?

Now, I do have to admit that for certain companies (such as EA or the Financial sector), this technique works fine. They will hire a developer who is "passionate" for the work (writing video games) or for the money ($250,000+ a year), work them for 80 hours a week for a year, and when they leave just replace them with another "passionate" developer who is waiting in the wings.

Any manager who consistently pushes their team to work 50+ hours a week is probably not doing their job correctly.

On the other hand, in a startup particularly there are always certain cases where everyone has to work 80+ hours a week for a while (ex. this is the closing date of the acquisition; for every day you delay integration, we are losing thousands of dollars in revenue.)

Good startup management is threading the needle between the two.

For instance I tend to be put on larger umbrella tasks which take a few weeks. It isn't uncommon for me to wrap up a little ahead of time - sure there are things I could do but usually because of the way things have been planned there are other pieces of that puzzle which aren't fully in place either. So I'll poke around a bit but take it easy for that day or so. Sure, I could jump in to help someone else out for that day but is it really worth distracting that person to get me up to speed with what they need and what they're doing for what would amount to a few hours worth of work? Not really.

The flip side of this is that when one finds themselves in a position where the deadline is going to be difficult to meet there's an expectation that extra time is put in to make it happen.

As long as the two are happening roughly the same it balances out anyways.

Give engineers the discretion to take on what they deem reasonable and trust them to finish it.

So if we assume that all the programmers are honest (which I do), then I can't just say "get this done by Friday." But I can say, "So you think this might take a week? Okay, I know how hard it is to do estimates, so please make your best effort to reach that goal, but if problems crop up, let me know and we'll adjust the schedule. Or if it turns out to be easier than you thought, let me know that too, and we can find another fitting task for you to tackle." Regardless, it only seems possible to ask a certain amount of time and effort from a programmer since that is the basis on which the schedule is created. Now I fully acknowledge the ideal amount of time is likely less than 40 hours a week. But still, it's the most a person can comfortably get done in a certain amount of time that we're paying for.

How else could it work? I fully acknowledge there may be better alternatives, and I'm glad to read about them. My only caveat is that such suggestions would be best if realistically applicable to full-time employees, which is short-term-unchangeable situation I'm in.

More specifically, give them a list of things to work on. Have them give estimates, silently apply the "Scotty" factor, and base their performance against that.

The list means that they are never short of work to do, so our ideally motivated candidate will always be working towards the company's goals. This list should comprise of at least one easy thing "I can do that in an hour", one "less than a week" project, and one "greater than a week" project. This provides your developers with a bit of variety, so they don't get burned out on trying to grind through the tough problems. It also makes them feel like they're making progress by letting them knock out at least one project every week - this can be very motivating.

The Scotty factor (development estimate * 3) will give you a more realistic idea of how long something will take. I use it on my own estimates, and it's accurate more often than it's not. You can use this to gauge both their skill at estimating, and as a measuring stick for identifying when they are underperforming (getting a second opinion on an estimate can help identify the underperforming part).

This does mean that you won't be able to look at the output of a given day/week and gauge a worker's performance just on that. However, you will be able to look back on a month, six months, or more, and get real data with which to identify the exceptional performers and those who need help (and perhaps even those who need to be let go).

So far, my strategy goes like this: rather than pressuring a developer to give me a more optimistic timeline, I instead do the opposite, I encourage them to really consider things that may go wrong. I'll sit down and try to talk about the potential overlooked risk. I try to understand the assumptions they're making, to help them become aware of the assumptions they're making. Are they assuming the data feeds they're counting on are available and easy to integrate? Are they assuming a certain amount of support from other departments will be available when they need it? Are they assuming they'll be able to understand and work with an existing code base before they fully immersed themselves in it?

This doesn't just improve your odds of getting a more accurate estimate of time-to-project-completion, I find it reassures the developers that you really do understand the difficulty of understanding and estimating a complex task.

I meant butt-in-chair time, not project completion time.

THIS.

But I understand companies. When they won a cash cow, they want to milk it.

A good dev can either slow down, till he's as fast as the others and keep chilling the rest of the time, or, get more money for getting more things done than other devs.

Suppose week 1 you tell me to get X done by Friday and I finish on Thursday. Perhaps I get Friday off, slack off or whatever.

Then on week 2 you tell me to get Y done by Friday and on Weds I realize that's not happening so I end up working an extra 8 hours over thurs and fri to make it happen.

What's the difference?

(Yes, I realize that this is an overly simplistic example, but hopefully it conveys the point)

I'm in a similar situation as you, one of an upper echelon of devs and while nothing is ever official sometimes increasingly there are people "under" me on any given project. So because of that, the tasks that I'm holding in my mind and have deadlines for tend to be longer running - not the typical 4 hour sprint ticket.

If I was fresh out of college and simply pulling stickies off the queue I'd likely have a different take on things. In those situations it's literally just a matter of doing something and moving on to the next something. My personal experience these days is different, it takes a little bit to shift gears and move on to the next thing, it's not as simple as simply grabbing a sticky.

I think it does have an unfortunate cooling effect though, in that, if they're paying you for your time there's no particular reason to put in extra effort to do things faster or better (other than personal pride and the nebulous possibility of a raise somewhere down the line).

There's been times I've gotten my entire sprint done in a couple days, only to get rewarded with... more stuff to do. That's not a criticism, I mean, that's the employment agreement I signed up for, I'm expected to do stuff 5 days a week, but I imagine that if I could get a sprint done in 3 days and then take 2 days off, I would be more motivated to get that stuff done quickly, and then QA would have more time to test it, and so on.

It's like the good old "Don't push on a Friday", except now "Friday" can be Wednesday or Thursday.

I imagine that there'd be more than a few of the less scrupulous devs who would push stuff earlier than they should (which creates more work for everyone downstream), to get the promised day off. In any case, if you do find yourself with extra days left-over in your sprint, why not tackle some tech debt or documentation, things that are usually lacking?

Remote from anywhere in the world has a lot of issues. The benefits are well known. Time flexibility and it forces management to focus only on results. However, doing face to face meetings is extremely difficult due to distance. Even tools like skype and hangouts are not effective when big time zone differences exist. Face to face communication has a lot of advantages and it's missing in this kind of workplace.

Forcing everyone to be in the office everyday also has a lot of issues. Going to the office and staying 8 hours or more regardless of productivity is a waste of time. There is also the wasted time commuting and it allows management to be lazy by focusing on hours in the office instead of actual results.

Allowing remote anytime anywhere, but hiring only within 50 miles of the office has the advantages of both. Face to face meetings are easy to schedule since everyone is only 50 miles away or less from the office. There are no time zone issues so skype and hangouts are very effective. It also allows all the flexibility of working remote.

If John is working only 4 hours coding everyday and gets stuff done. He can do double in 8 hours. So I should ask John to not goof around and focus on getting more things done.

So the challenge seems to be finding the ideal and somehow getting management to understand/believe it.

That's why every technical manager should have a technical background.

Has it genuinely been studied in a meaningful way, and this was in fact the conclusion?

http://skeptics.stackexchange.com/questions/14028/does-worki...

For myself, it's absolutely the truth. I do not get more meaningful work done in 8 hours than I do in 6, or some days, 1. I spend more time thinking about design and implementation than I do coding, and thinking does not require me to be at my computer, or even in the office. The only benefit of being in the office is the ability to BS with my colleagues (and occasionally it's even about work!).

If you're the owner, you're the one setting the goals and timelines. If your team seems to easily meet your expectations, then yeah, you're justified in pushing them a bit. But if they can't keep up, you have to make the choice between hiring more people or easing the expectations back to where your existing team can complete the tasks. There is a third option: push harder and expect more from your workers, but the tradeoffs from the short term productivity increase is just that - short term - and detrimental to your business in the long run.

More specifically, if person A can get `N/2` tasks done in a week (where N is the average velocity), and person B can get `N * 2`, reward person B, set up a performance plan for person A, assign out tasks appropriately, and move on with life. If you really need `N * 5` output every week and have four employees, hire another employee. Don't keep giving person A N tasks and expect persons B, C, and D to do their work plus person A's.

EDIT: Formatting fix

This is a simple question with a very simple answer: Because if you can get your work done in 15 hours, that means you can handle more work. I can't think of a single project I've ever worked at where there wasn't bugs or backlog or refactors that I could work on during spare moments. What kind of place do you imagine working for that doesn't have these waiting to fill in time?