Remix.run Logo
ghickPit 13 hours ago

For mojuba and myself, email is a way to organize TODO items. Things to take care of exist either way, and email is an awesome way to keep track of, and process, events / tasks asynchronously.

shermantanktop and you, forbiddenvoid, seem to refuse organizing TODOs, or perhaps even the concept that external events be allowed to generate TODOs for you ("my attention should be directed at what I want to do, when I want to"). I closely know this -- i.e., "garbage dump with tire fires in it" -- because that's precisely what my SO's mailbox looks like. Whereas I've maintained a perfect inbox 0 for several decades, both at work and privately.

This is an unbridgeable psychological divide between two attitudes toward, or even two definitions of, tasks and obligations. People who can naturally implement inbox 0 never lose track of a task (not just in email, but in any other medium either), and get indignated when they receive reminders. They're excellent schedulers, and orderly, but also frequently obsessive-compulsive, neurotic. People who can't instinctively do inbox 0 cannot be taught or forced to do it, they tend to need repeated reminders, and may still forget tasks. At the same time, they have different virtues; they tend to shine with ill-defined problems and unexpected events.

Neither group is at fault; the difference has biological roots, in the nervous system. Our brains physically differ.

shermantanktop 6 hours ago | parent | next [-]

I kind of agree, but I explain it differently. Everyone’s job is a mix of reactive and proactive work. For my particular job, reactive work is necessary but will expand to fill all my time and then some. Proactive work is ambiguous and uncertain, but usually ends up being the highest value work that I do.

If I spend all my time on other people’s demands, it will all be urgent, but not enough of it will be important.

ghickPit 26 minutes ago | parent [-]

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

mojuba 8 hours ago | parent | prev [-]

Thanks, that's a great explanation!