4 ms·

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 ex

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...)
  - AndyNemmity 8y ago
    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.
    - bigiain 8y ago
      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...
bigiain 8y ago
> 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).
- dvtrn 8y ago
  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).
  - bigiain 8y 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...)

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...)
- AndyNemmity 8y ago
  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.
  - bigiain 8y ago
    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...

bigiain 8y ago

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

dvtrn 8y ago
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).
- bigiain 8y 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...)