Hacker News Reader

Comment by wastedhours | Hacker News Reader

Also worth realising that in a lot of companies you're not being paid for your output, you're being paid for a certain amount of access to your brain.

The value in your job isn't your output, it's the organisational outcomes that occur as a result of you doing what ya do.

Some companies are fine and built around the outcomes of 5 hours a day of your code. Some organisations though really want 8 hours a day of access to those sweet, sweet neurons. Even if the constant interruptions, meetings and feelings of unproductivity are side effects, perhaps they value the outcomes of 2 hours a day of your code and the value sharing that comes from an inane question at 17:59, more than absolute output.

Not saying the latter is more efficient or should be right, but just showing there's different value companies derive from their employees over and above project deliverables.

View on HN

> you're being paid for a certain amount of access to your brain.

I understand what you are trying to say, but if this would be true, I should be paid for a lot, a lot of overtime. When I left the office, my brain still process some job-related topics. I catch myself thinking about some work issues on weekends, evenings and holidays.

Some of the best ideas for work problems I hadn't had in the office.

Conceptually, I think that's one of the primary reasons for a salaried, full-time, permanent employee (in "knowledge"-type roles.)

Of course there is still have hourly pay based work but, in principle, those would be for specific tasks or specialties not routinely needed.

Yes, I realize these are idealized, but the occurrence of misuse doesn't negate the point. That said, idealizing may be an unfortunately common affliction I suffer from...

Is that really true, or is it just a well-sounding rationalisation we tell ourselves to avoid doing anything to make things better?

Granted, I specialise in well-sounding rationalisations ;) however, I do think it's true for some knowledge worker jobs that it's not just the direct knowledge we impart into a specific project, but the knowledge distributed within a company.

I know that I've learnt things from meetings where it's evidently a burden/"waste of time" for the party I'm gaining from, and likewise, am fairly certain I've delivered value to others when it's been a waste for me.

It might not be the best way of handling it, but some organisations are designed to work that way, and as much as we can try and mould where we work around us, sometimes it's just a different dynamic.

It -can- be. I know I am woefully undertasked, and in way, way too many meetings. Oftentimes I'm thrown at things that are floundering despite having no knowledge of them, their history, their current deliverables, etc. Not to actually code, but to just be present. Even though I feel entirely useless in such a role, it seems to provide some comfort to my superiors, and even to the teams in question. There are enough areas I'm extremely knowledgeable in, there are enough times I -am- able to save people/teams large amounts of work, there are enough times I can basically just look at a set of stories that they're predicting will take man-weeks, and say "I'll have a solution in place for you to start playing with tomorrow", that my presence seems to benefit a number of people even when I do nothing at all, just as a security blanket. If that's worth my salary to them, while I still have time to learn things on my own (and, er, browse HN), fair enough.

I hope you're an architect-level or at least getting there. I kind of feel sad for some architects though, they rarely get to code anymore, their existence is meetings, but presumably their ability to coordinate and prioritize the big picture outweighs having them apply their coding chops. For coders that can't give up coding it's a self-limiting move to resist that direction, lots of companies seem to have pressure that to advance you have to do 'less'.

When you do your big prototype solutions is it usually something you toss over the fence to the team that now takes on the rest of the dev/qe responsibility or do you try to work closely with one or two people on that team as you build it? I mostly ask because another sort of altruistic (or selfish if you're just killing time until the next round of meetings) thing you can do with your role is go around dropping mana on heads-down coding grunts by working with them directly on something; they'll probably have a nice feeling of appreciation like this person, who they aren't quite sure does what but must be very valuable, is taking time to work with them, and hopefully you teach them a few useful things from your deep knowledge to boot.

Kind of. Due to some internal politics, we have an 'architecture team' being formed, by someone who I don't want to work for (but who wants to poach me). Meanwhile I've been the de facto architect for a year and a half for software development. My actual title is 'backend tech lead'.

As to approach, it depends. Occasionally I've written and hosted a solution, and given endpoints for people to test with, before then walking people through the specifics and bringing devops on board to move it to production, and then will still actively take a hand in making changes/fixes/etc. Other times I've basically just POC'ed it, and then suggested to a team "Hey, this looks like it will solve a problem you're facing, here's some POC code, maybe play with and evaluate this approach, see if it'll fit your needs?" and they have, and in the process have learned more about the particulars than I knew, so that they're in a good place to do the real evaluation and decide what direction to head in. And still other times, especially common with juniors, when someone hits a roadblock, I'll sit with them, seek to understand the problem, and either explain the nature of the problem, and some possible solutions, and leave it up to them to pick one (since they have the most domain knowledge), or work/talk with them to work to and understand an ideal solution (if it doesn't require domain knowledge I don't have).

> in a lot of companies you're not being paid for your output

...you are being paid to be in a chair.

This. I have been on contracts where "butts in seats" was a metric--they had to have the appearance of moving the ball on the project even though it was in the early stages and there was nothing for the developers to even do yet. I hate those deals.

You're either an asset or a cost. If you're an asset, you're directly going to generate the company more value than they're paying you by doing your job, whether that's encompassed by 'raw output' or just 'access to your brain'. If you're a cost, well, someone needs to keep the gears running and occasionally cleaned of the worst bugs, make sure communication lines are clear, etc., and there's a certain market rate for that, so at worst you're just another cost of doing business like the hardware you use. At best the company will repurpose largely idle costs so you can potentially become an asset by coalescing and together creating value worth more than the sum of your individual costs. But some companies don't do that, so they just have these skilled workers loafing around paid for their availability (butt-in-chair) to activate on fixing some random problems as they come up.

Absolutely. There are plenty of examples where the job completely dictates the hours: Operational roles can either require shifts, or on-call availability. And hours only get worse for people with critical skillsets!

Reply on news.ycombinator.com