
Lack of progress exposed by the Canary MacGuffin - ingve
https://rachelbythebay.com/w/2018/10/23/idle/
======
AndyNemmity
I'm likely in a Canary MacGuffin situation right now. What is the reason?

I've been given a task I don't know how to do. So I'm working diligently on
learning enough about it. But because I don't know how to do it, there are an
infinite number of concepts that may or may not be required to complete the
task.

So, I am using the time productively in the sense of breaking apart each piece
I don't understand, building it myself, learning about it, and moving on to
another one.

But I haven't collected the key from the shop. Every day, I write down what I
need to do again, and it changes and evolves as I learn things. I try again to
complete the task, fail again, use it as an opportunity to learn about that
piece.

If I had just got the key, maybe the task is complete, but I am no closer to
being able to obtain a different key, or providing any value on that surface
area.

So I'm optimizing for my ability to get keys in the future, not getting this
particular key.

Is that good? Bad? Lots of arguments in both directions I think. Maybe my
optimizations are 25% what they could be with direct help. But having
experienced direct help, what it actually means is someone talks over my head
no matter how much I say I don't understand.

They don't get just how far away I am. Given the constraints, all that can be
done is to improve to the point where their help, is help.

Hopefully that made some level of sense.

~~~
bigiain
So communicate that back to the person who asked you to do the task.

I don't mind discovering a task I've assigned someone is actually way more
complicated and time consuming that I expected (although I'd appreciate an
explanation so I can recalibrate my assumptions), and I don't even mind
finding out a team member I've assigned a task to is not yet skilled or
experienced enough to understand the best way of doing it or to complete it in
a reasonable timeframe.

What _does_ bug me (as RachelByTheBay alludes to) is the complete radio
silence where I've been kinda expecting the job to pop out of the queue
completed for the last few days/weeks, only to finally after giving you the
benefit of the doubt and not wanting to seem like I'm micromanaging you -
discover it's barely been started and doesn't look like it'll _ever_ get
completed.

If it's way more complex that I assumed? Tell me. If you're way out of your
depth? Tell me. If you think it's a stupid task and you're not going to do it
and hope it goes away? Just fucking tell me!

~~~
AndyNemmity
Completely fair. But it always goes both ways, it's usually never as clear (to
me) that one side is at fault.

For example, I've asked several times for clarification and got no response
back. Now you're busy, and rightly so, you deliver far more than I do, but I
considered those ignored contacts. Maybe you legitimately just missed them.

Do I keep repeatedly asking? That's the right thing to do, but as a human,
it's a hard thing to do.

The reality is, there needs to be a communication channel back and forth,
there is no hiding the details, but the channel needs to be there, and
respond. If either side doesn't fulfill that minimum, there is going to be a
lack of information.

~~~
bigiain
No no no!

Try and avoid thinking in terms of "at fault". The primary goal is to get the
work done. Mostly it never descends into blame storming and fingerpointing -
so try and avoid behaving like it's got there before it does.

You don't need to "keep repeatedly asking", but you do need to ensure you've
communicated clearly. If you asked for clarification and didn't get a
response, follow up at least once, and make sure you follow up when you decide
you need to shelve the task until you get a response (possibly in that first
follow up).

"Hey $boss, I haven't heard back about the question I asked about $task on
$date. I can't move forward without a response, so I'll put this task aside
until that's resolved. If it's still urgent or critical, let me know, and let
me know if I should continue chasing up that question with you or with someone
else. Thanks, $communicative-co-worker."

Your last sentence is key - communicate. Both ways. With the prime intention
of getting things done, and clear language explaining when things are stalled
at your end and what needs to happen to un-stall them. If you're doing all
that - you'll make your co workers and bosses very happy, and you'll have all
the paperwork you need if things _do_ end up in a blame storming session later
on. But don't optimise for the blamestorming, optimise for getting things done
and clear communication...

~~~
dasm
This whole comment thread reminds me of my recent experience at an Amazon
internship. I was trying to make my way out of the deep end, but my mentor was
looking for whose fault it was; when the party with the upper hand decides to
play this game, it's very difficult to escape.

~~~
TheOtherHobbes
Workplaces with that dynamic are toxic. You can't escape the blame game - you
can only escape the workplace.

I'm slightly baffled by the premise of the original piece. If you set a task
and hear nothing except "go away and leave me to it" updates for a long time,
instead of checking up on magic keys, isn't it more useful to have a detailed
progress session? Maybe ask for an approximate ETA?

In a non-toxic workplace it should be possible to do this in the spirit of
fact-finding without raining blame on anyone.

~~~
a1369209993
> Workplaces with that dynamic are toxic.

The problem with that is that, weighted by number of job openings (for
internship/begining/otherwise-not-already-successful candidates), _most_ [0]
workplaces are toxic.

If you can find somewhere to escape to, go for it, but sometimes you can't.

0: The exact proportion one sees will vary, but basically bear in mind that if
people aren't quitting in disgust, your own workplace is less likely to be
looking for replacement shmucks.

------
arbitrage
Perhaps the adventurer is asking themselves, "Hey, doesn't the task giver KNOW
the guy who has the key? And they're really good friends? And they know
exactly what they need? And where to get it? And what to do with it? So why
are they asking ME to do it for them?"

Perhaps they resent a poorly communicated request. Perhaps the task giver does
this literally ALL THE TIME ... getting other people to do their work. Maybe
the adventurer wants you to fail, because you do this all the time, and like,
maybe for once you should do it yourself.

There's lots of reasons things don't get done in projects. Mind-reading and
coming up with explanations about why someone is failing in the project is a
shitty replacement for communicating needs and wants clearly in an organized
fashion.

That is, when a project has a project manager, the project fails because of
the project manager.

~~~
ryandrake
This is true. My comment is going to seem self serving because I am a project
manager, but You Need A Project Manager! Someone who will ensure that things
that need communicating get communicated. Someone who can see across the whole
project and even multiple projects and communicate priorities clearly. Someone
who will chase down deliverables and ensure everyone is unblocked. Very rarely
will developers proactively reach out and admit they are blocked and can’t
complete task A because team B needs to deliver task C first. They’ll just
silently move over to the next Jira ticket. You need a project manager to pry
it out of them! You need a project manager who can indeed read minds. Why is X
not getting done? Why is Y ignoring her EMail? Why haven’t we heard from team
Z for a week? Risk + inaction = crisis. Good project managers smell risk in
the air before it turns into crisis, and take action.

~~~
bigiain
Agreed.

And while not every project requires or deserves a dedicated PM - every
project needs someone who'l own the PM responsibilities. It can be _very_ hard
as one of the devs on a very small project with no PM to "smell the risk in
the air" while you're deep down the rabbit hole of coding - but if nobody does
it things are very likely to eventually grind to a time wasting halt.

Great Project Managers are worth their weight in single malt scotch. (or
substitute your personal very expensive substance...)

------
brobdingnagians
I find it rather humorous in reading the comments that this seems to have hit
an interesting nerve, viz. being asked to perform [stupid] tasks for someone
else and then being monitored and reminded intermittently in a passive way
without clear communication.

Sometimes there are good and important tasks whose importance is clearly
communicated, but which go undone. But, in my experience, the majority of
tasks like this might need to be either (1) better specified so that they can
actually be understood and completed or (2) communicate better what the
importance of the task is with an honest evaluation by both people and
comparing to the value of other workload priorities at present.

We have a tendency to believe that our task is the most important one right
now, and that our ideas are the best ideas, without understanding what someone
else is really doing and without taking an objective look at why something
else could be more valuable.

We can use that ourselves when we try to assign tasks to others. Are we being
fair to them, their priorities, and their workload? Maybe our task isn't all
that important? Maybe we can communicate better with them to understand the
totality of what they value, or maybe what they think a better alternative to
our task would be. After all, Alexander the Great asked his troops if they had
any ideas for strategies... and he won a lot.

~~~
teilo
This is what immediately came to mind. The OA missed the fourth reason why his
Canary McGuffin wasn't touched: Maybe you, who gave the task, haven't clearly
communicated the problem, or the solution you are looking for. Now who is to
blame in that circumstance?

Presuming it's not an issue of laziness, or incompetence, or of higher
priorities trumping your request, why are you looking at your McGuffin instead
of communicating with the person you assigned the task?

~~~
taneq
Same, my thoughts went straight to the quest giver. After receiving a response
of "getting there" or "it's tricky" for the third time, rather than sitting
back and smugly speculating on the deficiencies of the adventurer while
"nothing happens", maybe they should have asked "what's the problem?"

I'm seeing a bit of a pattern in these blog posts, where the author is more
interested in proving their superiority over others than in actually getting
stuff done.

~~~
xamuel
>more interested in proving their superiority over others than in actually
getting stuff done.

I've noticed this happens a LOT in all kinds of meetings. I myself am guilty
of it, so now I try to think before I speak, "if I raise this pedantic point,
will that actually help further the team's goals?" Usually the answer is NO.

------
atoav
To me this sounds like a perfect example of failed communication.

Every question answered with “I am on it” or “top of the list” is often no
real question intended to get deeper knowledge about the issues, but a
rhetoric question acting as colourful wrapping for a “get it fucking done”.

Yes it might be legitimate for you to tell them to get it fucking done ― but
will this help? If you are lucky it might, but there are better ways.

Instead of monitoring them it could turn out to be more productive to make
clear why this task is important to you (”It seems unimportant but it is
blocking important Task X”), why it is them who need to do it (”I know it is
annoying, but I can’t do $Y because of reason $Z”) and finally really ask them
(”Maybe you have a better idea how to solve this”). This will show them why it
is important to you, why they are the only ones who can help and that they
have at least a little bit of control over it.

Most people like to help other people. But if you just treat them as a
blackbox taking instructions and executing them (like a computer), you will
get a smaller chance Iof getting a result.

A carnary dies when something fails this carnary stays alive if something
fails, so it is not a carnary. Also a MacGuffin is itself meaningless, it is
just there to move the plot along and could be swapped out with any arbitray
other MacGuffin (a mysterious parcel, a tiny plastic container, a black
suitcase, ...)

I know a carnary MacGuffin when I see one, and when I see it, I run

~~~
tvanantwerp
Agreed. I'm sometimes the "adventurer", insisting to the random NPCs of the
office that I'll get their quests done. But as anyone who has played such a
game knows, the random NPCs' quests aren't always the most important thing to
do. "Should I fight Ganon, or find this dude's missing cucco?" The cucco moves
up the list if the NPC makes it clear I'll get a badass sword or something
that will help with the whole Ganon thing.

------
thrower123
> Second, maybe the task is stupid, and they're waiting for it to be killed.
> (How this matches up with the fact the requester is still asking about it
> and is starting to get concerned is another story.)

There is often surprisingly little relation between a thing being stupid and
not worth doing and how much some party wants it to be done.

Notwithstanding the potential existence of fourteen other simultaneous
MacGuffins to be obtained at the highest priority that has the plucky
adventurer spinning plates and shaving far-off yaks, about which the requester
has no visibility.

~~~
buckminster
Exactly. Figuring out which tasks are bullshit and just not doing them is an
essential life skill. If you want someone to do something the best approach is
to convince them it matters.

------
JasonFruit
I've seen a couple posts from rachelbythebay that were like this: they
expressed an unsettling eagerness to catch co-workers not keeping up. Maybe
it's the type of work environment in which she's made herself useful, or maybe
it's more the way she expresses herself than how she works in practice;
whatever it is, though, it leaves a sour taste in my mouth.

------
johngalt
Isn't this an exceptionally lossy, and circuitous feedback method?

When I'm managing a team, I'm spending _all_ of my time ensuring that any
obstacles are obvious, and that everyone has the stuff they need. This article
seems to recommend leaving out details and waiting for people to ask for that
detail.

Normally I'd prefer to be as clear as possible.

1\. Our goal is to meet [objective], by [timeframe].

2\. The plan is to accomplish [supporting tasks].

3\. [Supplies] for tasks can be obtained here. Likely you will need X.

4\. Distribution of duties is thus.

Notes: Any ideas that will accomplish objective faster/better are welcome.
When we run into large obstacles or need help say something. Identify bad
decisions (especially mine) before they cause big problems or waste a bunch of
time.

Conversely this article wants to stop at step #1, and then wait for people to
figure out 2 & 3 on their own. Which is probably _exactly why_ they haven't
started work.

Perhaps I've been blessed with excellent team members, but I've only
encountered a handful of truly lazy people. Whereas, I commonly encounter
fractured teams because of competing objectives, unclear tasks, and ambiguous
goals. Engineering tasks to have hidden canaries is trying to solve the
uncommon problem (lazy professionals), by exacerbating the more common problem
(ambiguity during a coordinated effort).

~~~
vidarh
I don't see it advocating leaving out details at all. I see it suggesting that
if you know the necessary steps or figure them out when you wonder why things
are taking time, they become easy mechanisms for identifying if there's a
communications problem (that again may reflect other problems). Whether or not
you expressly communicates the next step at the start is incidental to that
(at some point you stop breaking things down in further detail; no matter how
detailed your plans are) - the only point is the _existence_ of a required
step that can be verified independently of a team or team member that is not
being open with you about the real progress.

> Perhaps I've been blessed with excellent team members, but I've only
> encountered a handful of truly lazy people.

But it's not necessarily about being lazy, but about people juggling multiple
priorities, and finding it easier to fob people off with a "working on it"
than explaining why their likely totally legitimate reasons have prevented
them from getting further. Yes, this signals organisational issues with
communication, but being aware this implies a problem does not make it go away
- people don't like being the bearers of bad news, so it typically takes a lot
of work to get visibility in these type of situations.

Often this is people trying hard to do their best, and delivering as fast as
they can, just doing it by sacrificing taking time for feedback to
stakeholders.

> Engineering tasks to have hidden canaries is trying to solve the uncommon
> problem (lazy professionals), by exacerbating the more common problem
> (ambiguity during a coordinated effort).

You don't need to engineer tasks to have hidden canaries. For most tasks there
will be canaries all over the place. The article even explicitly makes the
point she has not set anything like this up intentionally, but have seen them
when wondering why tasks take a long time.

And this would also reveal ambiguities: Maybe the cause is that the team _is_
building something, but it's different from what you expect and so doesn't
affect the canary. In which case that is still a valuable indicator of a
problem you may not have caught as quickly otherwise.

------
matt4077
I remember a "MacGuffin" not to be some preliminary objective in a plot, but
rather a meaningless, exchangeable objective that nonetheless is central to
the plot. The Indiana Jones films serve well as examples: the specific
artefacts he's trying to recover could be replaced with any other valuable
item without meaningfully affecting the story.

(But there's the distinct possibility that I'm wrong, or that I'm splitting
hairs, or just generally missing the point of analogies)

~~~
ggambetta
No, you're correct. I was going to point this out before I saw your comment.

The example I had in mind was the Rabbit's Foot in Mission:Impossible III.
Perfect example of McGuffin: it motivates the entire plot of the movie, but at
no point it becomes clear what it is (other than Simon Pegg speculating about
it). It's in a canister, the bad guys want it, and Tom Cruise has to stop them
from getting it.

~~~
Angostura
The suitcase in Pulp Fiction is perhaps the greatest example. You never know
what it is in it.

~~~
erulabs
"Is that what I think it is?" is such a brilliant MacGuffin line

------
misnome
Another option four: They have their own job to do and perhaps your task isn't
in their highest priorities? Or perhaps they want to work on it but haven't
had the time to make proper progress yet.

If it's important enough that it's actually blocking team progress then that's
a management problem, but nothing in this seems to indicate it's anything like
that.

~~~
rimliu
How does this case sit with:

    
    
      > You see them again a bit later, and they insist they're
      > "working on it". Time passes. Again, you hear from them:
      > "top of my list".

~~~
misnome
Being polite in a world of shifting priorities? Maybe they fully intended to
dedicate time to it but another emergency/high priority pushes it down again.
Or they want to work on it, and don't want it to be taken away, but haven't
had the time yet.

All of these seem more charitable, and contribute less to a toxic work
environment, than automatically assuming that all of your colleagues are
manipulative, dense or flaky because they have more important things to do.

~~~
ared38
While I agree jumping to the conclusion that they're unreliable and flaky is
ridiculous, being "polite" like that does no one any favors.

Just be honest and explain you've been caught up with higher priority issues
and haven't made progress. That gives the asker an opportunity to explain why
the task is more important than you thought, find someone else with less on
their plate to do it, or at the very least understand what's taking so long.

------
mtnygard
This reminds me of Van Halen's infamous "no brown M&Ms" contract clause.

[https://www.snopes.com/fact-check/brown-out/](https://www.snopes.com/fact-
check/brown-out/)

The story goes that they used this as a quick test to see if the venue
management had read the contract. If not, the crew would need to check all the
technical specs. (Adequate power, controlled risk of fires, etc.)

------
peterwwillis
From the perspective of the person receiving the request, this is just yet
another request in a minefield of random tasks, all which have varying
priority and deadline and complexity.

Even if _all_ the things they have to do are _easy_ , just juggling them all
is logistically challenging. Without the right process or motivation, there is
nothing making the author's "nothing task" require immediate attention. It is
common for a "simple" request to end up taking 3-6 months, because there's no
obvious way to balance work on that task against all other work.

The hope is that team integration paradigms like DevOps can help identify and
alleviate them. Take these blockers (that's what they are, not "canary
macguffins", just old blockers) and automate them or remove them entirely. If
you can't, add a step that allows your request to jump the line. Involve your
managers, but use empathy and open communication.

------
k__
I seriously don't get the point.

Do we have to add CMs to check if stuff is happening?

Do we have to add explanation for CMs so people will solve our problems?

~~~
AlexCoventry
No action is recommended. It sounds like someone disappointed her, and she's
writing about it parables to avoid open conflict.

------
jpfed
In the programming world, another name for the crystal key could be an
unshaven yak.

~~~
taneq
I was going to propose the term "yak scissors", since it's needed to complete
the side quest to get to the main quest.

------
Ws32ok
I've been assigned tasks and simply essentially ignored them after any of my
initial questions were ignored by those who assigned the task. Reasons
include: task not assigned by my supervisor. No funding. No resources in
general. No consultation. Person who assigned tasks has no authority to do so.
These are similar and all have happened to me more than once.

I get why the status update lying part offends but I'd also say the project
manager who tolerates this isn't really project managing. Setting traps isn't
the height of high performance I'd be aiming for.

But let's say you assigned a task and know the magic key is required. And the
magic key is never accessed or acquired. You as project manager have failed.
Did you reveal this dependency as a requirement? Are you sure that dependency
is real? And why did you wait so long?

I've got a project in my history where I was expected to use a corporate
credit card to purchase server time on AWS but didn't. When asked why I said
I'd found better internal resources that worked at higher performance for the
time needed. Imagine my surprise when I got criticised by immediate manegemenr
for not spending 30k but praised by upper management for saving 30k and
delivering ahead of schedule.

The real reason was that someone had 30k they wanted burnt before financial
end of year but didn't state this as a goal. The project instead simply
optimised for real cost and schedule instead, offending the management that
wanted the money burnt.

By the way, the canaries in the coal mines usually died. I feel that tech in
general should remember details like this and not create delicate metaphors
for real events that had gruesome realities. Something is only a canary when
the messenger died during delivery of that message. Just my $0.02 worth.

------
brazzledazzle
Ocarina of Time was the best Zelda game ever at the time of its release and in
many ways remains so. Not at all relevant but she dropped the gauntlet in her
opening comments.

------
bsder
And maybe I have a Canary MacGuffin of my own to let me know when your request
is actually important to the _business_ as opposed to simply being on your
_quarterly goals_.

And ignoring you is probably better for me because if I tell you properly to
go pound sand, you're a whiny little pain in the ass who is going to go
bitching up and down the management chain about me obstructing your quarterly
goals.

I'm normally pretty amenable to helping someone else, but I do have my own
stuff to get done. If I'm not helping, I'm either busy or don't see the
importance of what you asked--and I'm generally pretty straightforward about
telling you both unless you've burned me before.

If you want my help, you either need to convince me of the importance or
convince one of my bosses of the importance so that they put it into official
channels.

------
ropman76
I understand this situation applies if the “developer resource” is a direct
report. However in many instances the dev may have multiple projects going on
at once and there is some miscommunications on project priorities. Yes, this
has happened to me and it’s why I abhor the phrase “developer resource”

------
iokevins
To summarize, neologism Canary MacGuffin represents one likely, visible event
(to the requestor) the requestee would have to do while Shaving the Yak (?)

~~~
rzzzt
Chekhov's Gun of Progress

------
monochromatic
I’m trying to imagine a technical problem where a worker would _necessarily_
need to do something at the outset, and where it would be visible in the way
suggests. Other than really contrived scenarios, I’m coming up blank.

~~~
topspin
Here is a simple one;

I task you to add a feature to a system. I know you either haven't been
involved with that system previously, or not recently enough that you can
access it without contacting so and so to get the necessary credentials or
whatever. For instance, you might need to be added to a particular set of
group members for certain private GitHub repo to obtain source code; something
I point out to you at the outset. Perfectly reasonable situation; nothing
contrived about it. Yet I may now contact so and so myself to learn if you've
come around to get what I know you need.

I have occasionally resorted to 'last' to see if someone has been active on a
host I know they should have been accessing for one reason or another;
typically to troubleshoot something I've asked them to look at. Often there
are 'dev' hosts where the bulk of work occurs. Anyone touched it this week?
I've deliberately left database instances down to see if the person that is
supposed to be using it either notices and asks why and/or starts it
themselves.

In an ideal world we suffer no dysfunction; people pursue their commitments.
In the real world people make claims that they can't or won't live up to for a
whole host of reasons, often times because they've been put in a position for
which they lack the ability or haven't been provided the time, tools,
authority and/or budget to cope with properly. A wise person detects this
early. A naive person gets told stories and played for a sucker.

Sometimes just dropping a hint that you're not entirely oblivious to the real
state of affairs is enough to get someone off the dime. (I talked to so and so
yesterday; she's expecting to hear from you...)

Over time people learn that I'm not the one to play. That tends to reduce the
net dysfunction, at least in my life.

------
tomrod
Manage up, manage up, manage up.

Unless you are the CEO or have remarkable autonomy, you are executing someone
else's vision. Over-communicating advances and next steps builds a lot of
trust in large orgs.

------
taeric
An interesting proposition. Though, oddly one that the game mechanics
themselves can also have more fun with. Quite simply, it could be that your
task is just a side quest. Sure, it is important to you, but not at all
necessary in any meaningful way for the adventurer. Nor for any of the
actually important things in the game world.

That is, I reject the 3 explanations at the end. It could be that the person
is very reliable, the task isn't stupid, and the person is unable to complete
your quest without an item. In a world where things are constantly getting
prioritized, it is just not making it to the top of the list. Isn't
necessarily at the bottom, either, but needs to be "on the way" for the person
to get it done.

This seems to be more common when you have people push goals without sharing
success metrics. As much as I was annoyed by Measure What Matters, there is
some element there to consider.

~~~
ryandrake
> In a world where things are constantly getting prioritized, it is just not
> making it to the top of the list. Isn't necessarily at the bottom, either,
> but needs to be "on the way" for the person to get it done.

Lots of people just don’t want to say “This isn’t a priority, and I’m not
working on it.” It’s easier (and it sometimes ends the conversation faster) to
say “I’m working on it, it’ll be done sometime!” and kick the can down the
road.

~~~
taeric
I call that the "don't ask questions you know someone doesn't want to answer"
philosophy. It is why I don't ask my kids "who made this mess?" It is asked in
a way that typically tells the correct answer will make you upset.

To that end, it is much better to ask questions such as "can you get over here
and help me clean this?" Or, in the project management space, "when can I see
the plan on how we are going to do this?" Even a "what do I need to cancel for
this to happen first?" Even better, nether presupposes that the answer is
"progress."

------
lifeisstillgood
I am coming round to an idea of "event driven business" \- where instead of
taking a software project, estimating it, and then everyone else taking those
estimates and turning them into your deadlines (we are blocked on you guys to
deliver this), that a business should eventually realise that those deadlines
force crappy quality, over pressures work and promises much like
rachelbythebay is complaining of, realise and then just stop setting deadlines
and have an entirely event driven schedule - write a test for
"CrystalKeyHasBeenPurchasedByTeamZelda" and when that test returns true, hat
next set of work can start - it's of a deadline, it's a dependency and if you
don't like it, decouple.

~~~
jpfed
Sounds kinda like Kanban.

~~~
lifeisstillgood
not as i understand it - where is the linkage between a task - this involves a
sort of linked list approach to tasks, where you cannot start a given task
until a IRL test passes (and presumably you get a IRL acceptance automated
test for finishing the task)

------
tvanantwerp
Reminds me of Van Halen and the infamous "no brown M&M's" clause of their
contracts. They didn't really care about M&M color, but they did care that
people setting up shows were paying close attention to detail because the
shows had lots of complicated equipment and effects that could be dangerous if
not set up properly. If they saw brown M&M's, they knew the contract wasn't
being followed and stripped everything down to do a safety check.

------
nautilus12
This whole way of thinking about things seems like dangerous advice that reeks
of lack of trust and transparency between individuals.

I'll pass on this one.

------
jackconnor
Why didn't the adventurer mention that they were blocked? I feel like this is
on them, though it would have been preferable if the task-creator had known
the key was required. But, if I say I'm going to do something, and then don't
do it and don't give any details why, it's always my fault.

~~~
taeric
To be fair, modern video games pretty much train you to ignore people that are
just asking for things. Dragon's Quest is rather amusing in this regard. It
will even handily keep a log of active quests with graphical pointers to where
quests can be found. That said, to my knowledge, there is no penalty for not
doing quests. They just pile up, endlessly.

I don't think this is any different than any other open world game I have ever
seen. Sure, some will have time bound quests. Most aren't, though.

------
nineteen999
If people dislike the assigned task, or the way it has been suggested it be
achieved, or think it is not important enough for them, or "beneath" them they
should speak up.

Few things are more annoying than hearing "yes I will do that" when the person
really means "no I won't".

------
hughes
This is kind of the inverse of detecting an exploit - If you as an NPC start
leaving notes around the world describing the quest, and eventually someone
makes a request to the shopkeeper for the crystal key, you know you have
successfully injected instructions into a player's task queue.

------
killjoywashere
Isn't this just a MacGuffin? A canary is specifically something I carry which
alerts me of a terrible event about to happen or in progress. The crystal key
is just a MacGuffin.

~~~
Skrillex
The name is meant to reference an item that serves as an indicator to what
stage a task could be at at the time of checking. The word I would have used
is "evidence".

------
liveoneggs
surely "Zork" was meant instead of "Zelda"

------
RyanShook
To use the video game analogy, I think often it’s possible that the player
doesn’t have enough XP to collect the key in the first place ; )

------
mcguire
Or maybe they're really busy with higher priority work.

------
dreamdu5t
There's a fourth explanation: Engineers don't get paid more for producing
features faster (or on time), they just get more work. A smart/rational
engineer eventually realizes they don't get rewarded for finishing tasks
quickly or on-time, they get the opposite: more work. And promotion happens
laterally not vertically, they get it by changing jobs because it's not
obtainable by delivering more things on time or faster.

As long as engineers are paid based on salary/wages this will always be the
case, and has been the case in every company I've worked with.

~~~
nemothekid
> _As long as engineers are paid based on salary /wages this will always be
> the case, and has been the case in every company I've worked with._

I don't think this is 100% true, and the problem you are describing doesn't
necessarily follow the cause you put forth.

Problem: Engineers do not work through tasks quickly because they aren't
rewarded for completing tasks.

Solution (hypothetical): Reward engineers for completing certain tasks.

Problem: How do you value how much a task or feature is worth?

Solution (hypothetical): A task's value is correlated with the impact on the
business's bottom line.

Anyone who's worked at a large SV tech firm can see the problem coming -
engineers will only want to work on valuable, front facing tasks, and
maintenance and technical debt tasks never get cleaned up. For example,
Google[1], ties their promotion system to the value of the tasks you have done
at Google - which obviously leads to a lot of gaming the system to increase
your worth. So while I agree there might be a _motivation_ problem, I don't
think it's clear cut that the compensation model is the solution.

[https://mtlynch.io/why-i-quit-google/](https://mtlynch.io/why-i-quit-google/)

~~~
dreamdu5t
Yeah, good points. I've never worked with a company that even had a promotion
system... :)

------
AlexCoventry
The concrete underlying story seems a bit strange... Maybe they just copied
the file in a development sandbox you're unaware of?

