Hacker News Reader

>They are paying you a complete salary, so they can demand that you put in complete effort.

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.

This is why I love working at early-stage startups: it aligns incentives. Nobody is pushing me to work those extra hours: I'm doing so because I genuinely believe that they will materially increase the value of the company (and thus my stock).

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.

Your stock options? The whole 0.01%? Unless you own > 3% (and there is little dilution), or the company is the next Google, then you may be in for a surprise...

Also, with pretty much everything in life, including software development, there IS a correlation between hours worked and quality/quantity.

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.

You are not only paid to write your piece of code and be happy about it. You are also paid to be on stand by and do whatever you can to move the company forward which includes helping out other people at work.

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.

Well then obviously your company should let him go. If not, then maybe he is as productive as you seem not to think.

he finishes his assigned tasks

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.

These two sentences do not jive:

> 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.

> 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.

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.

The problem is that I can't put in 40 hours of meaningful work in a week. I think the average is 20 hours of work. When I work actual 40 hour weeks it's usually a lot of time wasting.

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)

"Special snowflake" actually describes quite well stories like the OP which totally are not representative of how the world actually works for 99% out there. Most people have to work very hard much of the time and as a general rule it pays off. [1] Nobody that you have ever read about and for that matter all the people that I have ever met that nobody has ever read about have gotten there working a short schedule. Exceptions? Sure. This nonsense has to end. Unless someone has for some reason hit the tech startup lottery, work hard, as much as you can. You won't always (when you are older) be able to do so.

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..)

I think you're confusing intrinsic and extrinsic motivations with willingness to work hard. You're ascribing a behaviour to a character trait or ability (a "type of person") that is IMO usually due to work circumstances (i.e. a situation that person finds themselves in, and well placed to exploit with the resources they have).

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.

Can you explain further what you mean by this:

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

If you're working overtime all the time chasing a carrot on a string, you're wasting your life on a tomorrow that will probably never come.

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.

The book Drive, by Daniel Pink, does a good job of explaining the differences between intrinsic and extrinsic motivations. I recommend the book regardless, but especially if this topic is intriguing to you.

> You're not just an hourly assembly line worker, you're part of the team, an insider, and remember, "We're all in this together."

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

Probably true that 40 hours results in greater output than 30 hours of work.

But it may not be true for 40 vs 50, 60 or 70 hours of work.

I remember reading the 40 hour work week actually was the result of research into maximizing productivity (but I'm too lazy to look it up right now).