7 ms·

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

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.

brobdingnagians 8y ago
If you can pin them down to giving specific steps or details in smaller doses, that could help. You might be able to do that by researching enough that you have specific questions to ask and get them to answer just that question succinctly. Or asking for a good resource to get the key points. Sometimes experienced people don't remember what it was like to be trying to stay afloat in a new ocean and instead try to give a satellite image when you just need to know where the flotation devices are kept.
TeMPOraL 8y ago
I end up in such situations too; your comments resonates. Such taks are sometimes what can be likened to quests from old adventure games: the quest giver doesn't mention the key, and the key is actually two lands and an hour of gameplay back. So you end up wasting couple more hours realizing this, and then backtracking, combing through every place you've been. Such things are rightfully considered as bugs in quest design these days.
protomyth 8y ago
I know the feeling. I had a report (excuse me business intelligence query with nice printing) that I was working on that took up north of a couple of hundred hours. My problem was that I had to do the business logic (and gather a huge amount of domain knowledge) too. It was something of an effort, and I didn't make it to the shop for the key for a long while. The best you can do is document, almost diary style, all of things you are doing to get to the goal and hope you have a project manager that will provide support and resources to get it all done. Frankly, all of my notes (which eventually went on a wiki for our group) helped in doing so much more. Honestly, I think the whole question of "do you need domain knowledge to complete the task?" should be something to consider. Many folks do programming that isn't the same at each company and this tends to generate a different path that might not have a 'Canary MacGuffin' until very late in the process. I also think that the whole "stupid task" is often mixed in the whole need / don't need domain knowledge. Many "stupid tasks" are related to the business process and often colored by not having technical resources with domain knowledge. I once ran into a developer who thought it was stupid that we wanted some calculated amounts stored in the database. He didn't understand that other parts (oh, like the billing system) would have a problem redoing the calculation. Extreme, but one person's stupid is another person's ability to get paid.
- mjevans 8y ago
  That too is sort of a business needs driven application. It doesn't occur to someone without sales or maybe accounting domain knowledge that prices on a 'cut' order, bill, or other receipt, while numeric in nature, must be fixed and distinct to that order/line item when it's finalized. It becomes no longer a number representing what a given thing should cost in the future, it is now part of a record reflecting the contents of a legally binding contract.
beatgammit 8y ago
I feel like I'm on the opposite end of that quite a bit. Quite often, colleagues come to me because they don't understand the task they're given, so I try to explain the pieces and how to learn about them. However, either I overwhelm them or they don't want to put in the effort, but eventually it ends up being: "do this, then that, and don't worry about how I knew to do that". Unfortunately, I don't think there's a good solution to either side of this. I mostly did what you did to get where I am, and I suppose I expect others to do the same. Usually my advice is: study this, that and the other thing, and come back to me after 40 hours of study (without my guidance, it could easily be several times that). However, the other side wants something that will take <1hr, and when I give them that, they complain that they didn't learn anything. It's a hard balance to strike.
- AndyNemmity 8y ago
  I feel just as much empathy for my colleagues. No one is wrong, or right in this situation. You're exactly right that it ends up being, "do this, then that", and the problem with following those instructions is you learn almost nothing. You're running a playbook, and have no context as to why. Before I did this, I followed that structure, and 6 months down the road, I had learned not nearly enough for the time frame. So I've just stopped, and am following this approach. At the very least, I will (and do) know and understand a lot more. At the cost of being a complete deliverable sink. The issue around communication is that, I really don't understand what is being said often. Essentially the things that people (rightly) assume is base knowledge, is not base knowledge for me. So the only way to get there, is to really study, take courses, learn about and rip apart what these things mean. And that takes time. Lots and lots of focused, intentional time. Now I'm building the foundation, and I'm learning a lot more, but I'm delivering a ton less. It's a challenge, but I will take responsibility for that, and just keep working hard to get better.
  - bigiain 8y ago
    Another view: Fucking up teaches you _way_ better lessons that studying and coursework. I often joke that the reason I get paid what I do is because of all the expensive mistakes I've already made on some other companies dime. A big part of my role as and older/senior tech guy, is to tell war stories carefully selected and curated to give very strong hints about how my less experiences junior devs are about to get things wrong. Some people never learn from other's mistakes - but if you've got expensive mistake stories to share, try very hard to ensure the people smart/perceptive enough to benefit from them get to hear about them... Give them the chance to "stand on the shoulders of giants" (even standing on the shoulders of ordinary people is better than making the same dumb mistakes they've already learned from...)
bigiain 8y ago
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 8y ago
  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.
  - iamdave 8y ago
    Do I keep repeatedly asking? That's the right thing to do, but as a human, it's a hard thing to do. Blunt answer: yes. Absolutely.
  - azernik 8y ago
    If you ask for clarification from a third party and get no response, first escalate through increasingly low-latency communications channels, from email to your workplace's chat system to maybe an in-person visit. If you still don't get a response after escalating as far as you feel comfortable - then that's what you need to report to your manager, so they can do their job and make sure you get the information you need.
enraged_camel 8y ago
>>I've been given a task I don't know how to do. So I'm working diligently on learning enough about it. >>...Is that good? Bad? Whether that's good or bad depends, but at the end of the day the important thing is that you should communicate the status fully to the person who assigned you the task, rather than obfuscate it by saying things like "still working on it" or "it's a bit trickier than I thought". Being assigned tasks you don't know how to do is fine. It's how you grow as a professional. However, there is a fine line between a task you don't know how to do but can learn in a reasonable amount of time, vs. a task you don't know how to do and can't learn in a reasonable amount of time. The latter, in my experience, is what results in the "Canary MacGuffin" scenarios Rachel describes, and it can be frustrating for everyone involved. Ultimately, the responsibility for figuring out the difference lies with the team lead or scrum master or whoever assigns tasks in your company. But they need you do be transparent with your level of skill and knowledge to be able to do that.
- AndyNemmity 8y ago
  I have communicated with no response given. I'm not obfuscating anything, and have spoken to other coworkers about the issues asking their help as well to understand context. The key is that I have to continue to communicate even with a lack of response. That is my responsibility, to not take a lack of response as an excuse to stop communicating.
  - iamdave 8y ago
    Do you have someone who resides above these coworkers or coworker who you can appeal to for support and guidance? I realize this may be a painful step to take but you can't nor should you allow your employer to see your lack of productivity and effectiveness on the team because you aren't getting the help needed from seasoned team members leaving you to suffer on an island.
throwaway080383 8y ago
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. That sounds like a problem to me. I don't know your situation, but when this happens to me, I am blunt and assertive that I don't understand what they're saying, like "I did not follow any of what you just said. I have no idea what X and Y are, and my understanding of Z is... Is that correct?" in the short term people may think less of you, but in the long-term you will actually learn this stuff assuming you have a helpful mentor. If the senior engineer's job is to break things down for junior folks, and you're not understanding their explanation, then they're not doing their job.
- AndyNemmity 8y ago
  I'm fine with people thinking less of me, but the response is either they explain it in a way I don't understand, or they offer to give me an exact list of things to do (do it for me). Neither of those deals with the fundamental issue. I have 0 issue with being assertive. It's a lack of basic knowledge that can only be acquired by backtracking, and doing.
  - AlexCoventry 8y ago
    What's an example of something you've been having these problems with?
Balgair 8y ago
This is years 1-5 in STEM grad school, to a T. In fact, I'd say this is most 'thought-centric' work in general. When it does come together, it feels like it all falls into place at the last minute, like a practiced artist's drawing. But the YEARS of practice it takes to be able to make that swoop of the brush seem effortless are anything but. If you have an advisor/boss that will suffer those years, thank them, even if they are a total jerk. Most won't suffer it at all.
- deleted 8y ago
  [deleted]
mmaunder 8y ago
I'm a guy who manages people who manage people. It's really important that you let the person who gave you the task know that you don't know how to do it. They may be able to help, or they may have a better use for your talents. Not telling them means you need to spend the time to acquire the skills to do the job, which may be a one-off, while they wait with increasing frustration and a lack of understanding of what the holdup is. The person who gave you the task is at fault for not confirming that this is within your skillset. So don't feel like this is all on you.
itronitron 8y ago
I recommend updating the person that defined the task you are working on of your current status and the sub-tasks that you are working on. They will value any information you provide and may also provide you insight to accomplishing some of the sub-tasks (the key is under the doormat, make a copy). They will also probably value hearing about your thoughts and discussing potential alternatives, and if they are not then that is important to find out as soon as possible.

brobdingnagians 8y ago

If you can pin them down to giving specific steps or details in smaller doses, that could help. You might be able to do that by researching enough that you have specific questions to ask and get them to answer just that question succinctly. Or asking for a good resource to get the key points. Sometimes experienced people don't remember what it was like to be trying to stay afloat in a new ocean and instead try to give a satellite image when you just need to know where the flotation devices are kept.

TeMPOraL 8y ago

I end up in such situations too; your comments resonates. Such taks are sometimes what can be likened to quests from old adventure games: the quest giver doesn't mention the key, and the key is actually two lands and an hour of gameplay back. So you end up wasting couple more hours realizing this, and then backtracking, combing through every place you've been. Such things are rightfully considered as bugs in quest design these days.

protomyth 8y ago

I know the feeling. I had a report (excuse me business intelligence query with nice printing) that I was working on that took up north of a couple of hundred hours. My problem was that I had to do the business logic (and gather a huge amount of domain knowledge) too. It was something of an effort, and I didn't make it to the shop for the key for a long while. The best you can do is document, almost diary style, all of things you are doing to get to the goal and hope you have a project manager that will provide support and resources to get it all done. Frankly, all of my notes (which eventually went on a wiki for our group) helped in doing so much more. Honestly, I think the whole question of "do you need domain knowledge to complete the task?" should be something to consider. Many folks do programming that isn't the same at each company and this tends to generate a different path that might not have a 'Canary MacGuffin' until very late in the process. I also think that the whole "stupid task" is often mixed in the whole need / don't need domain knowledge. Many "stupid tasks" are related to the business process and often colored by not having technical resources with domain knowledge. I once ran into a developer who thought it was stupid that we wanted some calculated amounts stored in the database. He didn't understand that other parts (oh, like the billing system) would have a problem redoing the calculation. Extreme, but one person's stupid is another person's ability to get paid.

mjevans 8y ago
That too is sort of a business needs driven application. It doesn't occur to someone without sales or maybe accounting domain knowledge that prices on a 'cut' order, bill, or other receipt, while numeric in nature, must be fixed and distinct to that order/line item when it's finalized. It becomes no longer a number representing what a given thing should cost in the future, it is now part of a record reflecting the contents of a legally binding contract.

beatgammit 8y ago

I feel like I'm on the opposite end of that quite a bit. Quite often, colleagues come to me because they don't understand the task they're given, so I try to explain the pieces and how to learn about them. However, either I overwhelm them or they don't want to put in the effort, but eventually it ends up being: "do this, then that, and don't worry about how I knew to do that". Unfortunately, I don't think there's a good solution to either side of this. I mostly did what you did to get where I am, and I suppose I expect others to do the same. Usually my advice is: study this, that and the other thing, and come back to me after 40 hours of study (without my guidance, it could easily be several times that). However, the other side wants something that will take <1hr, and when I give them that, they complain that they didn't learn anything. It's a hard balance to strike.

AndyNemmity 8y ago
I feel just as much empathy for my colleagues. No one is wrong, or right in this situation. You're exactly right that it ends up being, "do this, then that", and the problem with following those instructions is you learn almost nothing. You're running a playbook, and have no context as to why. Before I did this, I followed that structure, and 6 months down the road, I had learned not nearly enough for the time frame. So I've just stopped, and am following this approach. At the very least, I will (and do) know and understand a lot more. At the cost of being a complete deliverable sink. The issue around communication is that, I really don't understand what is being said often. Essentially the things that people (rightly) assume is base knowledge, is not base knowledge for me. So the only way to get there, is to really study, take courses, learn about and rip apart what these things mean. And that takes time. Lots and lots of focused, intentional time. Now I'm building the foundation, and I'm learning a lot more, but I'm delivering a ton less. It's a challenge, but I will take responsibility for that, and just keep working hard to get better.
- bigiain 8y ago
  Another view: Fucking up teaches you _way_ better lessons that studying and coursework. I often joke that the reason I get paid what I do is because of all the expensive mistakes I've already made on some other companies dime. A big part of my role as and older/senior tech guy, is to tell war stories carefully selected and curated to give very strong hints about how my less experiences junior devs are about to get things wrong. Some people never learn from other's mistakes - but if you've got expensive mistake stories to share, try very hard to ensure the people smart/perceptive enough to benefit from them get to hear about them... Give them the chance to "stand on the shoulders of giants" (even standing on the shoulders of ordinary people is better than making the same dumb mistakes they've already learned from...)

bigiain 8y ago

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 8y ago
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.
- iamdave 8y ago
  Do I keep repeatedly asking? That's the right thing to do, but as a human, it's a hard thing to do. Blunt answer: yes. Absolutely.
- azernik 8y ago
  If you ask for clarification from a third party and get no response, first escalate through increasingly low-latency communications channels, from email to your workplace's chat system to maybe an in-person visit. If you still don't get a response after escalating as far as you feel comfortable - then that's what you need to report to your manager, so they can do their job and make sure you get the information you need.

enraged_camel 8y ago

>>I've been given a task I don't know how to do. So I'm working diligently on learning enough about it. >>...Is that good? Bad? Whether that's good or bad depends, but at the end of the day the important thing is that you should communicate the status fully to the person who assigned you the task, rather than obfuscate it by saying things like "still working on it" or "it's a bit trickier than I thought". Being assigned tasks you don't know how to do is fine. It's how you grow as a professional. However, there is a fine line between a task you don't know how to do but can learn in a reasonable amount of time, vs. a task you don't know how to do and can't learn in a reasonable amount of time. The latter, in my experience, is what results in the "Canary MacGuffin" scenarios Rachel describes, and it can be frustrating for everyone involved. Ultimately, the responsibility for figuring out the difference lies with the team lead or scrum master or whoever assigns tasks in your company. But they need you do be transparent with your level of skill and knowledge to be able to do that.

AndyNemmity 8y ago
I have communicated with no response given. I'm not obfuscating anything, and have spoken to other coworkers about the issues asking their help as well to understand context. The key is that I have to continue to communicate even with a lack of response. That is my responsibility, to not take a lack of response as an excuse to stop communicating.
- iamdave 8y ago
  Do you have someone who resides above these coworkers or coworker who you can appeal to for support and guidance? I realize this may be a painful step to take but you can't nor should you allow your employer to see your lack of productivity and effectiveness on the team because you aren't getting the help needed from seasoned team members leaving you to suffer on an island.

throwaway080383 8y ago

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. That sounds like a problem to me. I don't know your situation, but when this happens to me, I am blunt and assertive that I don't understand what they're saying, like "I did not follow any of what you just said. I have no idea what X and Y are, and my understanding of Z is... Is that correct?" in the short term people may think less of you, but in the long-term you will actually learn this stuff assuming you have a helpful mentor. If the senior engineer's job is to break things down for junior folks, and you're not understanding their explanation, then they're not doing their job.

AndyNemmity 8y ago
I'm fine with people thinking less of me, but the response is either they explain it in a way I don't understand, or they offer to give me an exact list of things to do (do it for me). Neither of those deals with the fundamental issue. I have 0 issue with being assertive. It's a lack of basic knowledge that can only be acquired by backtracking, and doing.
- AlexCoventry 8y ago
  What's an example of something you've been having these problems with?

Balgair 8y ago

This is years 1-5 in STEM grad school, to a T. In fact, I'd say this is most 'thought-centric' work in general. When it does come together, it feels like it all falls into place at the last minute, like a practiced artist's drawing. But the YEARS of practice it takes to be able to make that swoop of the brush seem effortless are anything but. If you have an advisor/boss that will suffer those years, thank them, even if they are a total jerk. Most won't suffer it at all.

deleted 8y ago
[deleted]

mmaunder 8y ago

I'm a guy who manages people who manage people. It's really important that you let the person who gave you the task know that you don't know how to do it. They may be able to help, or they may have a better use for your talents. Not telling them means you need to spend the time to acquire the skills to do the job, which may be a one-off, while they wait with increasing frustration and a lack of understanding of what the holdup is. The person who gave you the task is at fault for not confirming that this is within your skillset. So don't feel like this is all on you.

itronitron 8y ago

I recommend updating the person that defined the task you are working on of your current status and the sub-tasks that you are working on. They will value any information you provide and may also provide you insight to accomplishing some of the sub-tasks (the key is under the doormat, make a copy). They will also probably value hearing about your thoughts and discussing potential alternatives, and if they are not then that is important to find out as soon as possible.