Hacker News Reader

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!

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.

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.

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.

Usually when uncertain about something I'll try and approach it from several angles and batch up a number of questions to send them off in one go so that the person on the other end can answer them more easily and possibly gain extra insight as to what's amiss. But there are some people who are distracted and so when sent a list of five questions one of which is hard, they'll omit the answer to the hardest question... So with them I just resend a response with different wording and just that question. I'm usually not asking these questions of developers and instead communicating with stakeholders but yea, question weaseling is a thing, sometimes accidental, sometimes intentional, but it's good to resolve your question to a definite answer (including "I don't know")

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

I would go farther. The primary goal is to make sure that work can be distributed. It's not a team if you're all being held hostage by one person.

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

Yes, but for many people who do not know how to do X, there is the chance that looking into the problem on one's own will result in a solution that can be accomplished in a reasonable amount of time. It's just unknown to that person at the start.

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.

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.

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.

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

Even better, do so in person and then follow up with an email summarizing what was discussed and what clarification you expect in order to proceed.

You nailed it. Tell me you can't or won't do it, and I'll pull it back and re-assign it, or maybe just do it myself.

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.

One interesting tooling idea might be, in whatever issue tracking system you use, to attach a TTL to assignments, so if the task doesn’t move to “done” (or “in testing” or whatever) by a certain point, the task reassigns to the original requestor/reporter.

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.

How will the junior learn how to do it otherwise? Ultimately it's that first hand experience that will be the biggest lesson in teaching the junior.

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.

When it works, it’s great. When it doesn’t, it sows the seeds of resentment.

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

One important thing for anyone to learn is that they won't get work if they don't complete, or even just start work. The more effective someone is at working with other people the more valued they will be. Asking the right questions, and knowing which need to be asked, is an important skill to develop as well.

> If it's way more complex that I assumed? Tell me.

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.

Yeah. All the usual rules don't apply in dysfunctional workplaces. I hope you're either _really really_ enjoying the game industry, or getting enough runs on the board there and polishing your resume... Good luck there...

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.

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.

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.

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.

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

I tend to agree with you that fucking up teaches way better lessons, but it requires a foundation.

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.

Oh sure. Three decades worth of fuckups isn't something you can get in a bootcamp...

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

> However, either I overwhelm them or they don't want to put in the effort

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

I have a coworker who is similar to this. Not so much "do my work for me" group, but very much in the "will ask you for help and then turn down anything you tell them, while still getting it wrong".

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

Personally, I'll cut "the new hires" a lot of slack.

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

Which is something I haven't yet had to do as it seems a lot of relevant people are picking up on this and there are mumblings going on of this person getting the axe soon.

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.

So the company you works at wants to pay people to make them money. When people start at a new job there's often a ramp-up time until they become productive and usually a second period until they're stable enough to lead others, but if someone is stuck in that negative efficiency state then it is something you should pass up the chain. If you're an experienced dev who is spending four hours a day holding the hand of someone new to the company that's an investment but if it's still going on months later then your manager will want to help the situation so that you can use your own time productively.

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)

when seeking help from colleagues it is more beneficial to take the form of student instead of dictator, for the current task as well as future tasks.

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

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.

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.

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.

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

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.

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.

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.

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.

What's an example of something you've been having these problems with?

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.

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.