Hacker News Reader

Comment by samspot | Hacker News Reader

> If you're getting your work done, on time, and to the quality specifications...

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.

View on HN

> There is always more work to do than there are people to do it

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.

> (or they're just bad managers and don't listen to feedback that's provided

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

The deadlines come from above, too.

In which case it's their job to push back on "above". They are particularly well suited to writing up a business case which says in a thousand words of manager-eese (and with lots of dollar figures) that "we need more people to finish your projects on time". Simply pushing back on you with "I have to work within the constraints set from above" is the manager being lazy.

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

Your posts are fairly thematic in the sense that you are always willing to do less or need more resources to accomplish the task.

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.

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

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.

Honestly, I think you both have some good points.

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.

You get a round of funding, or you have X in revenues. That's all you have. There is always more things that you want to do with your product than that amount of money will buy. That's not a failure of management, that is physical reality. You can't change physics, even if you are a manager.

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.

Sounds like you assumed we are working overtime, we're not. I'm describing the reason why on Friday morning I don't just take the day off if i've met my goals. I don't think the desire for team success is unhealthy, and would counter that only caring about your own work is pretty unhealthy. Just my opinion though.

> That's a failure at the management level, not the developer's level

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.

At least at my work there's always more to do but that doesn't mean it's always worth jumping in on it.

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.

That's basically what makes agile (in the original iteration) so valuable.

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

This can be addressed by managers making more reasonably attainable goals. Every other industry in the world has an endless list of things to do as well and yet most don't suffer from the same lack of work/life balance.

Reply on news.ycombinator.com