logoalt Hacker News

ghickPityesterday at 1:49 PM1 replyview on HN

That's a super interesting situation (and description).

I always order reviewing the work of others ahead of working on my own code. This works wonders for the team. But admittedly, if the review workload is not distributed well, then my approach produces an annoying imbalance for me, and over the longer term, it leads to burnout.

Put differently, if I enable / assist / mentor others, that produces value comparable to my own personal output, for the company (or that's at least how I understand things). However, the emotional value of each, to me, is comparable only up to a certain extent -- namely, as long as I get to write enough code myself. The proportion must be right.

I rely on management / the team to (self-)organize the review workload, and then I prefer to help others first, and work on my own stuff second. I draw much more satisfaction from working on my own code, but I feel the importance of supporting others, so I prioritize the latter. This particular prioritization too rewards me emotionally, but only up to a certain point. I can say "no", but, in my view, if I have to say "no" frequently, to requests for assistance, then the workload is ill-distributed, and that responsibility is not mine. (I explicitly don't want to be promoted to a level where I become responsible for assigning tasks to people.)


Replies

shermantanktopyesterday at 5:04 PM

I’m in a senior position and just coming off a year where I intentionally focused on enabling others and making the collective group more effective. That meant more reactive (and less visible) work.

I got feedback that my contributions weren’t tangible and visible enough. I switched gears back to my previous mode (more proactive work) and all is well again.

Different work cultures treat this differently. At another company my enabling activities would have been valued more. But I do think being the glue in a group is usually undervalued.