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!

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.

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

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.

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.

In that context there is no blame, there's just information: Work can't be distributed for reasons, reasons that should maybe worry us. One of the least likely reasons is "person X is stupid". Far more common is "person Y and Z have a serious case of the Curse of Knowledge".

YET, if said person raises concerns immediately, there's also the potential for that work to get reassigned in a manner that never gives the said person to learn how to do X.

I agree that this is a selfish action, and ideally we do not act in such ways when under pressure to perform and work as a team. But I've found that this psychology often explains why teams find themselves with facing a Canary MacGuffin.

Blunt answer: yes. Absolutely.

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.

Tell me "you're on it", and what choice do I have? Any action I take will be seen as "undermining a junior engineer who needs to grow".

Don't ask me why I know this.

Perhaps the solution is something in-between - assigning the task to the junior, expecting honesty and communication from them, and pointing them in the right direction as they need it. With competent but inexperienced junior, this works and results in a stronger team.

Now imagine your job is to wander around and find things, fix some, but mostly inspire others to weed their own gardens, so to speak.

Eventually you step in the wrong place.

“Click.”

The main reason this doesn’t work is because one of the biggest use cases for such tools is to formally promise that you’re going to do something (see, your bug report/feature request is in our backlog, you can track this ticket!) with no intention of ever actually doing it.

So you can just tell me that I'm going to need to start working unpaid overtime nights and weekends until it's "done" for some unspecified definition of done? Nope, sorry, fell for that when I was young and stupid, not going to fall for it again.

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.

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.

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.

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.

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

I'm an older/senior guy as well. The difference is that, I decided to accept a role, that changed into a role doing something I had never done.

I was never a programmer, and I accepted a role that unknowing to me, ended up being a development role. I decide that it would be fun to become a developer, and explore this world.

I would be considered an expert in other similar fields, but not this field. The biggest misjudgement on my end was that I didn't understand how far behind I would be. I assumed it would take a lot of effort, and drive, but I completely missed how much it would take to become competent.

Still enjoying the experience, and am getting very excited towards a future where I can deliver and be relied on for critically important things.

But I think understanding that the greybeard over in the corner has those three decades, and that even if they fucked up using Perl running on hardware they physically touched/owned - they probably learnt some critical lessons that directly apply to your $language-de-jour running on $cloud-platform-of-the-week...

Become the person who'll get told, and listen too, their war stories...

I've seen both of these a lot. Eventually you end up classifying coworkers as "people who want to learn" and "people who try and get you to do any difficult work for them".

I will dial down the overwhelmingness and dial up the helpfulness a _lot_ if you land in the "eager to learn" group. If you regularly show yourself to be in the "do my work for me" group, I'll eventually just throw you some keywords to google and point out that I'm busy getting through my work (possibly while Ccing your boss if I'm in "a mood" or if you do this all the damned time).

Let's pretend our infrastructure is a home kitchen with a failing microwave oven.

"Hey, why isn't this button on the microwave working?"

"Because that's a refrigerator, not a microwave"

"No I KNOW it's not a microwave, but how do I get it to heat up my lunch?"

"Refrigerators don't heat things..."

"Sigh I know how microwaves work, why isn't THIS one working?"

I really wish I were being hyperbolic about this, but I'm not. Lately I've taken your tactic and just throw them keywords and proffer that I'll help them out when I can break away from other items. It hasn't failed that after a couple of cycles they'll say "Hey you were right about that microwave" and in my mind I'll say "no kidding".

On a darker note: there's quite a few of us who don't think this engineer is long for the company (they were hired only a few months ago).

It's a hard situation and I've been lucky that I haven't been stuck with anyone who can't overcome that initial learning phase, but if you find yourself there you should try and unload the problem to people more HRy and save yourself the stress.

(All the above, BTW, is not to imply that one-person rockstar programmers are a thing (they aren't) and skills vary, I am only talking about extreme scenarios)

"A few months" is way within the "still trying to work out who the fuck they are and how they fit in".

If they haven't bailed on the company in ~12 months, but are still asking the same lack-of-understanding-questions they've been asking all along, that's when I redirect my effort/energy elsewhere and dial my help back down to just offering relevant search keywords and a "sorry, I'm busy, maybe ask my boss to schedule a meeting after the end of this sprint if you still need help?" response (In writing. With an auditable paper trail...)

There have been more than one occasion where I'd find a potential solution to an issue this engineer is having, send it over to them as a helpful gesture-and I'd watch as they pull up the link, scroll immediately to where the commands are, bypassing every bit of text that gives insight into what commands are about to be ran, dependencies to interrogate before, or considerations that may be unique to a specific instance, and start slapping away at the keyboard without a clue in the world what the command they're entering is actually going to do.

I think it's less a skills gap but an issue with someone who is baked into their ways and hasn't been shaken loose from them on a more functional team.

edit >> (unless you work with assholes that see the student form as a sign of weakness)

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.

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.

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

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.

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.

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.

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.