Hacker News new | ask | show | jobs
by dangus 2311 days ago
The other factor is a lack of personal life boundaries.

The 10x engineers that I’ve interacted with can be found working on nights and weekends because they enjoy it and have nothing better to do.

Working those nights and weekends without coworker interruption also means that they get to learn more things freely rather than being interrupted.

As a result they tend to be highly productive, but I’d argue that it could be seen as unfair to the rest of the employees who want to live a balanced life.

3 comments

I don't think that is unfair. It’s perfectly acceptable to be a 3x developer.

What bothers me is the people that are happy to be a <1 developer. Or even a <0 developer, whose benefit to the team is net negative.

>What bothers me is the people that are happy to be a <1 developer.

We can't all be above average. So we are either all 1 developper, or some of us are bound to be less.

But we can all aspire to be a >1 developer, even if we're not one currently. I don't necessarily think that contentment with being below average is universally bad (maybe it's perfectly rational given one's preferences for leisure vs. work, for example), but I'd hope that most <1 developers are juniors who hope to improve over time.
Fair enough, but given the current ecosystem <1 still means something.

If it ever gets to the point where everyone is floating somewhere between 0.9 and 1.1, I’ll revise my statement.

It's unfair if they're normal employees, but fine if they're contractors/have their own company.

When they're spending all their working hours on one topic they're taking a huge personal sacrifice which is invisible to their employer while at the same time raising the expectations towards their colleagues. If there's for example two such maniacs in a team, the rest can say goodbye to promotions and raises even if they're actually just as good but don't sacrifice their life at the altar of programming.

These engineers end up with much more experience in a shorter time span. The guy that worked 40 hours for the last 5 years is going to have far less experience than the guy who worked 60 hours for the last 5. More experience tends to lead to better decision making and better code.

That said I'm the 40 hour guy. I want to work to live not live to work. That will make me less of a developer than others but I think I still bring value to my work place. I don't want to look back on a life lived in a cubicle.

I'm not sure about that, there are diminishing returns on extra hours. If you work long enough hours then it will start to have a detrimental effect.
Glad to hear that you don't buy into the myth that longer hours are better for their own sake - I agree.

Realistically, I've never met any programmer who has more than 4 to 6 (on a really good day) hours of solidly useful work in them per day.

Time spent above that, and those 20+ hours above 40, are invariably spent spinning wheels and making mistakes from fatigue, etc. and I think ought to be discouraged in sensibly run orgs.

Making mistakes from fatigue is the tip of the iceberg. As designers and implementers of software, we don't just have to redo the few minutes of work that making the mistake took. The consequences can be much worse:

* Missing key insights which would shave a large percentage of work off of the project.

* Making mistakes in architectural decisions, which require hours of extra mundane boilerplate work.

* Introducing difficult-to-reproduce bugs which require hours, days or weeks debugging

* Destroying key hardware which needs to be re-acquired (if that's the kind of thing you work on).

At this point in my career I'm of the opinion that asking teams to pull late nights and weekends is actually detrimental to project timelines, over anything longer than a single day. All it does is reassure PHBs that maximum effort is being made.

I guess the "nights" part is an exaggeration. Anyone working days + nights will either burn out soon or they're on drugs and will crash and burn later.