Hacker News Reader

Comment by codingdave | Hacker News Reader

Even better, drop hours as a metric of work. Offer the flexibility to work whatever hours are most productive... and find a boss who doesn't care whether that is 40 or 20, as long as he gets the value he expects from your time.

After all, employment is a business contract. You are given money in exchange for the value you add to the organization. Not hours... value.

View on HN

I have heard managers respond that if you can get your responsibilities done in half the time, you should be getting more responsibilities.

I'd respond that I'd expect to be getting a requisite increase increase in compensation.

At least I hope I would.

The problem is they directly translate hours in seat to pay, so your logic would make no sense to them.

Years ago I casually met an owner of a small software company who happened to be hiring, and I was looking for a job. He asked if I was cheap and I instantly answered 'why, are you?'

Normally I don't think of witty things like that to say until about a week after the event.

That's what I do at my job. I leave whenever I feel satisfied with the work I've done.

Supposed to be working 9 - 5, but I come variable times in the morning and usually leave at 3:30. Boss doesn't care as long as I'm punching in code that makes features work.

Hours are just easier to measure. Other things may not be measurable at all.

Works great if you are a single developer owning an isolated piece of the stack. Doesn't work so great if you need to collaborate with others to maximize your productivity.

Collaboration is overrated. IMO the biggest purpose of a good software architecture is to minimize the amount of required collaboration between programmers. Each gets a well-defined place to work on and focuses on that, instead of constantly discussing how to build every single class. The latter gives you a diffused design in which nobody understands any part of it. The former gives you design in which, while single person may understand all of it (as it always is due to fractal complexity), every piece of that design is fully understood by someone.

You speak as if the only work that exists is cathedral software development.

Look, I get you, I've been a professional programmer for a couple decades now, and hobbyist for another decade on top of that. But there are so many times when it helps to have a conversation with someone. Maybe you're team is not all senior level architects, maybe someone is working with tech someone else on the team understands better, maybe the designer is delivering an unworkable visual design and the engineer is implementing it by making tradeoffs that result in a terrible UX, maybe the programmer is going into a cave polishing his own micro-architecture without regard to what is useful and good use of time for the team as a whole.

The point is, it's not wise to cultivate a worldview where you hold your own knowledge and experience on a pedestal above everyone else. The things which a great team can build will always surpass what a great individual can create, and a bunch of great individuals operating independently without sufficient collaboration does not a great team make.

Maybe collaboration is overrated by clueless MBAs, but I'm not a clueless MBA, so don't make that straw man argument to me.

I agree with what you wrote here, but I don't think having a good team requires perfectly synchronizing their work schedule, as long as it somewhat overlaps most of the time. There are many times when you want, or need to sit down with your teammates and discuss stuff - design the overall architecture, brainstorm particular solution, troubleshoot a bug - but most of the actual coding work is done in silence and requires focus. And this work takes most of the actual productive time, so it doesn't make sense to synchronize the entire schedules just for the brief moments of direct, synchronous collaboration (quite a lot of teamwork can - and is done best - asynchronously, e.g. via e-mail).

> Maybe collaboration is overrated by clueless MBAs, but I'm not a clueless MBA, so don't make that straw man argument to me.

Apologies. I definitely didn't want my comment to sound personal in any way.

I'm a firm believer in flex time and heads-down time. Heck, I led an engineering team from 2 engineers (one of them being me) up to an engineering/product team of 25 with more nationalities on the team than employees (if that doesn't compute remember dual-citizenship), and distributed across 9-10 countries. I have successfully scheduled a three-person call between Melbourne, San Francisco and Berlin.

All this by way of saying: I have fully tested the philosophy that you should hire the absolute best engineers you can, no matter where they are based and when they want to work. For the right individuals with the proper workloads it's definitely worth it. But we shouldn't pretend it doesn't come with real tradeoffs. A story to illustrate my point:

I had my best video engineer in London, and my best ops guy in Seattle (and he didn't like waking up early). Even though these guys could do 95% of their work independently, there were times when they had to sort out hairy issues related to bugs or edge cases in 3rd party software. There was no way to easily shove it on one of their plates, the bottom line is it requires both their expertise. We nearly burnt out the first guy by making him stay up until 4am in order to get the necessary collab time. These are juniors either, but it still was a real issue that cost a significant amount of productivity and morale.

(PS I upvoted you as I don't see why you deserve downvotes)

So I'm assuming you write all your code with zero dependencies then?

No, but I keep my dependencies isolated in a well-defined way, and I provide well-defined interfaces for people who want to depend on my stuff.

That's basically software architecture 101 (modularization), and it serves exactly this purpose.

You should start a consulting business or startup and offer this.

Measuring that value precisely may ultimately consume more value than a crude metric like hours.

Reply on news.ycombinator.com