14 ms·

If you work for a corporation and feel overwhelmed try what the emacs people did, example for email: 1) select everything in your inbox, 2) mark as read, 3) arc

If you work for a corporation and feel overwhelmed try what the emacs people did, example for email: 1) select everything in your inbox, 2) mark as read, 3) archive. For bugs it would be unassign everything from yourself, or just close them without fixing. I've done this several times and it's magical how you end up losing almost nothing important in the end. I think it works because if something is important enough you'll either remember it yourself or it will be communicated to you again, perhaps even via a "higher priority channel" such as the management chain. And if you think I'm being extreme then yes, maybe, but maybe you haven't yet drowned in the never ending stream of problems for a long time.

colechristensen 5y ago
This is definitely a real phenomenon, there is a lot of "work" that if ignored long enough turns out didn't need to be done at all. Lots of things get done which don't need to, knowing which is which is a really valuable skill.
- rightbyte 5y ago
  There are crappy workarounds for many bugs. The cost is just moved from the mantainer to the user. After a while the bug becomes lore.
- seoaeu 5y ago
  Sometimes it is more a matter of getting most of the work done, without it mattering if some gets missed. Ignoring all reported bugs might be unsustainable because eventually all your customers would get fed up and leave, but it is unlikely that any particular bug would be the breaking point between the company succeeding or going under.
- throwawayboise 5y ago
  At my job I have learned which people ask for things that they aren't really serious about. Only so many times I am willing to reorganize my work to install some "urgently" needed software or system configuration changes, only to later observe that they were never used. Now when I get requests from those people, they go immediately to the back burner. If I hear nothing more, they get closed; if I get followups then maybe it is something they need after all. It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work. Rather than try to demand some realistic sense of priority for these requests, this approach lets the urgent stuff bubble up naturally and the rest of the chaff sink to the bottom.
  - TeMPOraL 5y ago
    > It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work. But, should they even care? Maybe they think it's not their job? What I mean is, there seem to be two archetypes of ways to ask someone else for something. For lack of better terms, I'll call them "market approach" and "social approach". "Social approach" is when you try to predict how costly your request will be to the other person, and only ask them if the importance is clearly much greater than the cost. You then expect the other person to feel compelled to prioritize your request, as they know you wouldn't be asking if it wasn't very important. "Market approach" is when you don't give any thought about the cost to other party - you just make your request, and expect them to tell you whether they'll do it, how long will it take, and what they expect in return. You then negotiate the scope of the request and the "price" until both sides are satisfied, or the request is rejected. I don't know which one is better. But I think we're living the worst case: everyone operates at a different point between these two idealized approaches. So, in your example, you're taking the "social" perspective - you treat requests as high priority ("they wouldn't have asked if it wasn't important") and get annoyed when your hard work isn't used. Meanwhile, those people may be operating closer to the "market" perspective - perhaps they expected you to push back on their request if it's disruptive to you, and were willing to negotiate (they knew it wasn't that important, but they didn't expect you to assume it was).
    - dmurray 5y ago
      This is a great insight and deserves to be turned into a more pretentious blog post that goes viral on VC Twitter. I should get better at recognizing which of my partners are on the social strategy and who prefers a more market-based one. Probably all of us should learn this skill.
    - j1elo 5y ago
      I agree with the sibling comment, your comment transmits a great insight that would make for a great longer form read. Deep down, this is another instance of the problem of human expectations and how important it is to handle them correctly for sane interactions with other peers at work.
asah 5y ago
+1 - subtly, if it's important someone will re-file or re-open it.
- touisteur 5y ago
  Yeah and I agree especially for poorly documented issues, unclear demands on your time, etc. But as someone with a long QA experience, sometimes I'm so disappointed in the 'no one bothered me, it must be bothering no one, close'. What about the time and effort of the person who described a defect in your system? Don't you want people giving you clear, researched bug reports? When you close their issues, although there CLEARLY is a problem and the ball is CLEARLY in your (sw dev) team, I feel like you're saying 'don't give me precise, actionable bugs'. That's what I'm hearing anyway. And soon enough you get the eternal dev complaint about how 'no one fills tickets properly' and the 'no one opens issues anymore although they face clear annoying bugs' with heavy faulpelz connotations... Well you reap what you sow. I'm not saying the project has infinite resources and that you should fix all issues all the time... I actually understand the real world tradeoffs. But put them on a special list, like knowledge database, known-bugs, not 'closed until some annoying piece-of-work busybody complains', and try earnestly to fix one once in a while, I even had a principle when I was team lead, to correct at least 5 more-than-2-years-old issues (or add a 'red' test for that bug). After all with tech turnover, those often make great onramping tickets. And I can testify to the sheer joy of having one of your 'low priority' issues fixed, even 2-3 years later. 'hey I know it's been a long time, and we're not sure it's still annoying to you, but anyway we managed to reproduce on the latest version and we put a fix in place, let us know if you want a nightly to double-check or wait until next release'. Even though it doesn't show on SLAs, I do put in a word when renewal time comes around (even more now that I have a small bit of clout).
  - touisteur 5y ago
    And the worst part is that for anything else than clearly laid out bugs/issues, I apply GP's described strategy (if it is important, it'll come back or I'll remember), especially as a protection against burnout. I have taught myself to stop worrying missing an email or not be on top of everyfuckingthing. Yeah I'll come around to look and will say 'must be redone, sorry' and there's waste. It's bad. But you can't do everything and when the external environment doesnt you adjust to your work capacity by itself, I've decided to let not-so-critical things slide a bit. If/when there's a complaint, either I'll resend the email about not having the time to follow subject X or my manager will... It's OK.
aprdm 5y ago
When I was young I hated that my manager asked me to email many times if it was important. Nowadays I understand … it’s the a way to keep sane and to see what matters. Mainly in companies that have been around for decades with multiple products and many many people..
- ploxiln 5y ago
  I've been in a place where lots of things were flaky and sub-optimal, and leadership could not prioritize, because only P0 CRITICAL was ever actually addressed, lots of dumb stuff had to be marked P0 CRITICAL to have any chance of consideration, and lots of little easy bugs reported from reasonable developers were never fixed. So, this doesn't always work, it can just be a way to kick the can around, and end up in the same place but with lots of extra junk flying by.
waych 5y ago
When doing this email trick I'd often broadcast the fact as I was "declaring email bankruptcy" to let others know I did this and may have missed their email. I've also lead many mass bug closures. Most stale bugs just need a ping or a friendly closure message. The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero, and in the off chance it ignites interest in some other party still paying attention it at least signals intent and starts a conversation.
- scrollaway 5y ago
  > The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero Except when maintainers decide to lock the bugs automatically because Reasons. Nothing screams contributor hostility as much as that.
esalman 5y ago
Wow. That explains a lot about our lab HPC "facilitator's" attitude towards us haha.
notatoad 5y ago
i just took this comment as inspiration to close all the open bugs in our jira instance that hadn't been updated or commented on in the last three years. spot checking a few of them, they were all either duplicates of other bugs that had already been fixed, or no longer relevant. it felt pretty good.
lrem 5y ago
For about three years I say openly that if an email is important, my manager will read it out to me. Seems to work and in that time keeping ~100 people somewhat aligned became my core responsibility.

colechristensen 5y ago

This is definitely a real phenomenon, there is a lot of "work" that if ignored long enough turns out didn't need to be done at all. Lots of things get done which don't need to, knowing which is which is a really valuable skill.

rightbyte 5y ago
There are crappy workarounds for many bugs. The cost is just moved from the mantainer to the user. After a while the bug becomes lore.
seoaeu 5y ago
Sometimes it is more a matter of getting most of the work done, without it mattering if some gets missed. Ignoring all reported bugs might be unsustainable because eventually all your customers would get fed up and leave, but it is unlikely that any particular bug would be the breaking point between the company succeeding or going under.
throwawayboise 5y ago
At my job I have learned which people ask for things that they aren't really serious about. Only so many times I am willing to reorganize my work to install some "urgently" needed software or system configuration changes, only to later observe that they were never used. Now when I get requests from those people, they go immediately to the back burner. If I hear nothing more, they get closed; if I get followups then maybe it is something they need after all. It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work. Rather than try to demand some realistic sense of priority for these requests, this approach lets the urgent stuff bubble up naturally and the rest of the chaff sink to the bottom.
- TeMPOraL 5y ago
  > It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work. But, should they even care? Maybe they think it's not their job? What I mean is, there seem to be two archetypes of ways to ask someone else for something. For lack of better terms, I'll call them "market approach" and "social approach". "Social approach" is when you try to predict how costly your request will be to the other person, and only ask them if the importance is clearly much greater than the cost. You then expect the other person to feel compelled to prioritize your request, as they know you wouldn't be asking if it wasn't very important. "Market approach" is when you don't give any thought about the cost to other party - you just make your request, and expect them to tell you whether they'll do it, how long will it take, and what they expect in return. You then negotiate the scope of the request and the "price" until both sides are satisfied, or the request is rejected. I don't know which one is better. But I think we're living the worst case: everyone operates at a different point between these two idealized approaches. So, in your example, you're taking the "social" perspective - you treat requests as high priority ("they wouldn't have asked if it wasn't important") and get annoyed when your hard work isn't used. Meanwhile, those people may be operating closer to the "market" perspective - perhaps they expected you to push back on their request if it's disruptive to you, and were willing to negotiate (they knew it wasn't that important, but they didn't expect you to assume it was).
  - dmurray 5y ago
    This is a great insight and deserves to be turned into a more pretentious blog post that goes viral on VC Twitter. I should get better at recognizing which of my partners are on the social strategy and who prefers a more market-based one. Probably all of us should learn this skill.
  - j1elo 5y ago
    I agree with the sibling comment, your comment transmits a great insight that would make for a great longer form read. Deep down, this is another instance of the problem of human expectations and how important it is to handle them correctly for sane interactions with other peers at work.

asah 5y ago

+1 - subtly, if it's important someone will re-file or re-open it.

touisteur 5y ago
Yeah and I agree especially for poorly documented issues, unclear demands on your time, etc. But as someone with a long QA experience, sometimes I'm so disappointed in the 'no one bothered me, it must be bothering no one, close'. What about the time and effort of the person who described a defect in your system? Don't you want people giving you clear, researched bug reports? When you close their issues, although there CLEARLY is a problem and the ball is CLEARLY in your (sw dev) team, I feel like you're saying 'don't give me precise, actionable bugs'. That's what I'm hearing anyway. And soon enough you get the eternal dev complaint about how 'no one fills tickets properly' and the 'no one opens issues anymore although they face clear annoying bugs' with heavy faulpelz connotations... Well you reap what you sow. I'm not saying the project has infinite resources and that you should fix all issues all the time... I actually understand the real world tradeoffs. But put them on a special list, like knowledge database, known-bugs, not 'closed until some annoying piece-of-work busybody complains', and try earnestly to fix one once in a while, I even had a principle when I was team lead, to correct at least 5 more-than-2-years-old issues (or add a 'red' test for that bug). After all with tech turnover, those often make great onramping tickets. And I can testify to the sheer joy of having one of your 'low priority' issues fixed, even 2-3 years later. 'hey I know it's been a long time, and we're not sure it's still annoying to you, but anyway we managed to reproduce on the latest version and we put a fix in place, let us know if you want a nightly to double-check or wait until next release'. Even though it doesn't show on SLAs, I do put in a word when renewal time comes around (even more now that I have a small bit of clout).
- touisteur 5y ago
  And the worst part is that for anything else than clearly laid out bugs/issues, I apply GP's described strategy (if it is important, it'll come back or I'll remember), especially as a protection against burnout. I have taught myself to stop worrying missing an email or not be on top of everyfuckingthing. Yeah I'll come around to look and will say 'must be redone, sorry' and there's waste. It's bad. But you can't do everything and when the external environment doesnt you adjust to your work capacity by itself, I've decided to let not-so-critical things slide a bit. If/when there's a complaint, either I'll resend the email about not having the time to follow subject X or my manager will... It's OK.

aprdm 5y ago

When I was young I hated that my manager asked me to email many times if it was important. Nowadays I understand … it’s the a way to keep sane and to see what matters. Mainly in companies that have been around for decades with multiple products and many many people..

ploxiln 5y ago
I've been in a place where lots of things were flaky and sub-optimal, and leadership could not prioritize, because only P0 CRITICAL was ever actually addressed, lots of dumb stuff had to be marked P0 CRITICAL to have any chance of consideration, and lots of little easy bugs reported from reasonable developers were never fixed. So, this doesn't always work, it can just be a way to kick the can around, and end up in the same place but with lots of extra junk flying by.

waych 5y ago

When doing this email trick I'd often broadcast the fact as I was "declaring email bankruptcy" to let others know I did this and may have missed their email. I've also lead many mass bug closures. Most stale bugs just need a ping or a friendly closure message. The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero, and in the off chance it ignites interest in some other party still paying attention it at least signals intent and starts a conversation.

scrollaway 5y ago
> The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero Except when maintainers decide to lock the bugs automatically because Reasons. Nothing screams contributor hostility as much as that.

esalman 5y ago

Wow. That explains a lot about our lab HPC "facilitator's" attitude towards us haha.

notatoad 5y ago

i just took this comment as inspiration to close all the open bugs in our jira instance that hadn't been updated or commented on in the last three years. spot checking a few of them, they were all either duplicates of other bugs that had already been fixed, or no longer relevant. it felt pretty good.

lrem 5y ago

For about three years I say openly that if an email is important, my manager will read it out to me. Seems to work and in that time keeping ~100 people somewhat aligned became my core responsibility.