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.
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.
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.
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.
> 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).
I like this comment too but in many cases the requesting party has almost no relationship to the receiving party. The requester is almost always in a buyers market (filing an issue is cheap) and the receiver is almost always social (working closely with others to resolve issues).
This model does explain the different sides, but the problem remains.
So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value. So how do we solve that?
> but in many cases the requesting party has almost no relationship to the receiving party
That is a common occurrence - which makes it dangerous for either side to make assumptions about the other.
So the more I think about it, the more I feel that it's the "market approach" that's better-suited for work requests and issue reports, when the two sides don't have a preexisting personal relationship. "Market approach" is assumption-minimizing, and thus also mistake-minimizing.
On a side note, I wonder if that's what "rejection therapy" and assertiveness are both about: they're trying to teach you to ask people more (instead of assuming they'll say no), not take rejection personally, and to be ready to just say no to other people. Taken like this, they sound like attempts to correct people into using "market approach" where they tend to use "social approach".
> So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value.
I think this is not a problem at all. That's why I called it "market approach" - the market is the tool that's used to determine value.
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.
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.
> "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.
Note (for your forthcoming tweet storm, apparently) that just these evaluation steps could be pretty time-intensive for the other party in the first place.
I almost agreed with you until you used the pejorative “scatterbrained”. I think the explanation is “asymmetry”.
It’s simply easier to make a request, than it is to resolve it. The cost of filing an issue is greater than the cost of resolving it.
This is why schemes like “you can only file your top 3 issues” make sense. Forcing the end user to prioritise their top issues - and to manage the ones that don’t make the cut - distributes the triage work more fairly.
We have a job to do too and it’s a waste of developers time to force us to guess what’s important to an end user. That’s their job.
The people I'm thinking about are actually scatterbrained. They read about something new -- squirrel!! -- ask for it and then they forget they asked. When the requests are completed they never use what they asked for.
The social vs. market perspectives are interesting though, I had not thought about framing requests in this way, and I'm going to try to keep that in mind in the future.
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.
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..
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.
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.
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.
>+1 - subtly, if it's important someone will re-file or re-open it.
With all due respect, this absolutely is not the only outcome. I'm going through this right now with UniFi and Ubiquiti, which has been a raging development dumpster fire for years now though the rot has only really started to become critical and more generally obvious the last year or two. UniFi is full of very important bugs, issues, and missing or badly implemented core functionality. But, like many many others, after devoting a lot of time to detailed bug reports and figuring out how to make it reproducible and extensive work helping identify how to meet standards that all got closed/ignored or even actively got worse?
I simply don't give a flying fuck any longer. I'm not "re-filing" (of course, they've dumped even their minimal mediocre old feature/bug tracker anyway with no replacement, but I don't make new threads either). I mostly don't bother anymore with reporting anything UniFi at all. Instead I've been steadily migrating away entirely. For me, UniFi is now in a completely subservient role, still doing a certain amount of switching and WiFi but with 100% of core network functions, routing/gateway coverage etc moved to OPNsense. As the time comes to get new gear anyway for WiFi 6E/7 and more multigig switching that'll be the end of it for my ~100 pieces of kit.
Of course companies/projects are free not to care, and depending on what sort of goal a project has or what sort of lock-in/stickiness and core revenue areas a business has it may indeed not matter if there is an exodus of small/older users/customers. But it shouldn't be assumed in every instance that "if this is really important someone will poke us again" because everyone only has so much time themselves to poke you, and if word gets around that it's pointless to even try than that will be the last you hear from them until they're gone entirely. IMO, the true terror for many business/projects shouldn't be criticism, it's silence. When people simply don't even care enough to even invest the time to get mad anymore.
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).
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.
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.