6 ms·

What makes my stomach turn is the interpersonal aspect. How can all your teammates see you fail through no fault of your own for days and pretend they don't not

What makes my stomach turn is the interpersonal aspect. How can all your teammates see you fail through no fault of your own for days and pretend they don't notice. Unfortunately in my experience, that's not a rare occurrence.

derekp7 9y ago
I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck. Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done. So if there is a micro-crunch coming up (i.e., I need to have an SOP drafted, tested, etc by this afternoon), the entire morning I tend to blow off other peoples issues. Until I can get a chance to come up for air. But that makes me feel bad, so what I end up doing instead is I go home at the end of the day and work till past midnight just to get caught up on what I couldn't do in the daytime. For any outside-the-box work I tend to pull 20-30 hours stints over the weekend. After 25 years of this, and as I need more sleep since I'm getting older, I can be a bit snippy when someone breaks me out of my concentration because they can't figure out something, and they have a down customer that needs service "right now".
- jartelt 9y ago
  It is also easy to get irked when people are seemingly unwilling to do any digging or reverse engineering on their own and go straight to asking for help. Allowing someone to search for an answer for several hours may seem like a waste of their time, but it also could allow them to learn how to figure out a problem on their own. Of course their is a fine line between being a jerk and not helping someone because you want to maintain your technical superiority and not helping someone because you want them to learn how to problem solve. Clearly you do not want to leave someone roadblocked for 48 hours when they are trying hard and you know the fix is some stupid bug. But, it's not always super straightforward either.
  - saltcured 9y ago
    Yes. Unfortunately, by the time you start to think people are asking for fishing lessons just to get lunch, it can become difficult to recognize a true student. I started out as the eager mentor, even when it was among my peers in university. But somewhere in my ~25 years of R&D, I started to notice how coworkers would become dependent. They would ask for help on types of things that I knew I had figured out myself, even when I was a novice. They develop the plea for help as a first reflex to avoid any learning tangential to what they consider the task at hand. So, I found myself swearing under my breath and refusing to be their search engine or man-page. Depending on my mood that day, I might tell them I have no time and they should google it themselves, or I might pretend I don't know the answer either. Sometimes I relished the time to sarcastically school them on the mundane deductions it would take to answer their question from the very screen full of error messages they pasted at me. But, I already knew they would miss or ignore the hint, and be back again next time they stumbled. Sadly, I think this cultivated impatience leaked out into my attempts to mentor a very junior staff member we had a couple years ago. I could no longer really distinguish "too lazy to try" and "drowning". They found a new job after a year or so, and it was probably wise for them. I am still trying to visualize how I can do better the next time we try to onboard somebody far junior to our current team...
  - sdhgaiojfsa 9y ago
    Yes. I would never have become the engineer that I am if people had always helped me when I asked.
  - tachyoff 9y ago
    I struggling with this constantly. If I have to fix another VPN issue caused by weird DNS server entries in OS X I’m going to scream. “Anybody else getting this error?” No, figure it out. I’m at a loss to explain how so many people wind up in software dev roles while lacking the most basic of problem-solving skills.
- inetknght 9y ago
  That's neither healthy nor sustainable. You're the one that sees a problem; you absolutely need to make your boss aware of that situation and that the company needs to arrange for better utilization of man-hours. If management doesn't fix that to be healthy, consider moving to a healthier position.
  - deleted 9y ago
    [deleted]
- deleted 9y ago
  [deleted]
- johngalt 9y ago
  Capability and responsibility become conflated very easily. You start off as the superhero who can fix problems, but that gradually creates dependency. 1st year 'Thanks for your help finding that error that was holding us up.' 2nd year 'We are all finished now. Just sent it over to you for debugging.' 3rd year 'Hey we are all waiting on you to fix. Big deadline for big customer.' CC: management 4th year Management: 'we need to talk a about the regular delays here. We have several teams waiting on you. Also your own code checkin's are much lower than theirs. Seems like you are only making changes to what others write.'
  - rzzzt 9y ago
    So... how does one break the cycle?
    - jjoonathan 9y ago
      For managers: better metrics or fewer metrics. For programmers: jump ship. A well-executed handoff process will not only maintain goodwill but remind others of your value.
    - taneq 9y ago
      Start by actually talking to your management instead of just trying to be a rock star. "Hey, I'm spending a lot of time doing Team X's job and it's impacting on my assigned work, if you want me to keep doing this then put me in charge of Team X, otherwise let's all sit down together and clarify who is responsible for what."
      - Infernal 9y ago
        So I'm asking this not to move the goalposts, but because it's the situation I'm in - what do if your manager is too weak/distracted/uncaring to actually act on this information and/or the projects in wait state on you are not actually within your manager's sphere of influence?
        taneq 9y ago
- joncrane 9y ago
  >After 25 years of this What has your career trajectory been like over the past 25 years?
  - derekp7 9y ago
    I'd best describe myself as a "computer person". Other than the first few years when I first started at around 15, my job has been Unix Systems Administrator / Engineer, but I've always thrown a lot of programming at my job too. Not just systems automation programming, but various utilities, apps, etc. For example, back in 89 (I was 18 - 19 then) the company I was at had a need to access multiple screens at the same time in their green-screen (serial terminal) application. So I wrote a multi-session terminal emulator. Ended up being a lot like what GNU screen is today (not sure if screen existed then, this was pre-internet days for me). Other times I'd write up software distribution systems, monitoring systems, etc. Or work on creating things like a custom interpreted language, just because an app developer at my company needed that. Or write hand-coded postscript, because someone's app needed that. In my current company, I'm still a Linux systems engineer / Lead, but I've been on-loan to our app development team to help with C-based libraries that they need (this code is a couple decades old, and they don't have any C hackers that can work on it). This is software that interfaces with medical testing equipment, so it feels like I'm making some difference. Lately I've been brushing up on my web development skills, becoming buzzword-compliant, and putting together web apps both for internal use, and related to maintaining our product. I guess I should have went into full time development years ago, but I was always worried that I'd get shoved into boring business applications instead of working on really interesting stuff. So I've stayed in the Unix/Linux ops role, found out that a lot of what I've been doing is now called DevOps, and doing open source work on the side. As for the trajectory, I haven't changed jobs that often. I've had a couple of dud-type jobs where I lasted 1 - 3 years (they didn't want someone who could do "extra" stuff, because that "made the rest of the team look lazy" as I was told in a performance review once). But when I start at a good place I try to make a good first impression, then a better second impression, and try to work and support as many people as I can (while doing my best to make them look good, but making sure I get recognized too). Helps to have a number of people that "have my back".
- e12e 9y ago
  Just to try to put this in a (unfair to you) constructive context: > I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run. >> I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck. This is why I always try to follow readmes, log my progress and fix errors as I find them. Also document hidden assumptions etc. That way others can help themselves - follow the readme, look at the up to date network/architecture diagram etc. Partly this is because I really cannot be bothered to keep such details in my head, anyway.
- pyrale 9y ago
  > Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done. Honestly, there's not much you can do if you feel like your company is not acknowledging work that you believe is a valuable use of your clock time. What I notice more senior people do is 1) expose clear SLAs to require their help and 2) get in the habit of producing more artifacts while they concentrate so they can refocus faster after an interruption.
- mratzloff 9y ago
  For your own sake, I'd spend less time working and more time figuring out the emotional driver behind why you work so much.
  - derekp7 9y ago
    I've actually slowed down a bit in recent years, however the main driver is that the work is fun. During the day I do the necessary (but not necessarily fun) work. After hours, I work on stuff that is mentally challenging and needs concentration, but only if I find it fun to work on. I do this instead of watching TV for example. As long as I get in enough time for other activities (hiking / bicycling, woodworking, designing my own creations, time with family) then hopefully I have a balance. But I have always had a slightly unhealthy fixation on sitting in front of a computer screen and creating (whether I'm doing it for work, or personal projects).
NutriSugar 9y ago
Having been the 'goto build guy', I've had to cut people off who were seeking me out for very self explanatory issues. For example, when the build threw an error because it couldn't find a file, pointing out where in the error to get the file, but the person seeking help didn't even try reading the error. Basically I limit my intervention to prevent enabling helplessness. The amount of help given also depends on the role of the person as well, junior devs get more hand holding then senior devs.

derekp7 9y ago

I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck. Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done. So if there is a micro-crunch coming up (i.e., I need to have an SOP drafted, tested, etc by this afternoon), the entire morning I tend to blow off other peoples issues. Until I can get a chance to come up for air. But that makes me feel bad, so what I end up doing instead is I go home at the end of the day and work till past midnight just to get caught up on what I couldn't do in the daytime. For any outside-the-box work I tend to pull 20-30 hours stints over the weekend. After 25 years of this, and as I need more sleep since I'm getting older, I can be a bit snippy when someone breaks me out of my concentration because they can't figure out something, and they have a down customer that needs service "right now".

jartelt 9y ago
It is also easy to get irked when people are seemingly unwilling to do any digging or reverse engineering on their own and go straight to asking for help. Allowing someone to search for an answer for several hours may seem like a waste of their time, but it also could allow them to learn how to figure out a problem on their own. Of course their is a fine line between being a jerk and not helping someone because you want to maintain your technical superiority and not helping someone because you want them to learn how to problem solve. Clearly you do not want to leave someone roadblocked for 48 hours when they are trying hard and you know the fix is some stupid bug. But, it's not always super straightforward either.
- saltcured 9y ago
  Yes. Unfortunately, by the time you start to think people are asking for fishing lessons just to get lunch, it can become difficult to recognize a true student. I started out as the eager mentor, even when it was among my peers in university. But somewhere in my ~25 years of R&D, I started to notice how coworkers would become dependent. They would ask for help on types of things that I knew I had figured out myself, even when I was a novice. They develop the plea for help as a first reflex to avoid any learning tangential to what they consider the task at hand. So, I found myself swearing under my breath and refusing to be their search engine or man-page. Depending on my mood that day, I might tell them I have no time and they should google it themselves, or I might pretend I don't know the answer either. Sometimes I relished the time to sarcastically school them on the mundane deductions it would take to answer their question from the very screen full of error messages they pasted at me. But, I already knew they would miss or ignore the hint, and be back again next time they stumbled. Sadly, I think this cultivated impatience leaked out into my attempts to mentor a very junior staff member we had a couple years ago. I could no longer really distinguish "too lazy to try" and "drowning". They found a new job after a year or so, and it was probably wise for them. I am still trying to visualize how I can do better the next time we try to onboard somebody far junior to our current team...
- sdhgaiojfsa 9y ago
  Yes. I would never have become the engineer that I am if people had always helped me when I asked.
- tachyoff 9y ago
  I struggling with this constantly. If I have to fix another VPN issue caused by weird DNS server entries in OS X I’m going to scream. “Anybody else getting this error?” No, figure it out. I’m at a loss to explain how so many people wind up in software dev roles while lacking the most basic of problem-solving skills.
inetknght 9y ago
That's neither healthy nor sustainable. You're the one that sees a problem; you absolutely need to make your boss aware of that situation and that the company needs to arrange for better utilization of man-hours. If management doesn't fix that to be healthy, consider moving to a healthier position.
- deleted 9y ago
  [deleted]
deleted 9y ago
[deleted]
johngalt 9y ago
Capability and responsibility become conflated very easily. You start off as the superhero who can fix problems, but that gradually creates dependency. 1st year 'Thanks for your help finding that error that was holding us up.' 2nd year 'We are all finished now. Just sent it over to you for debugging.' 3rd year 'Hey we are all waiting on you to fix. Big deadline for big customer.' CC: management 4th year Management: 'we need to talk a about the regular delays here. We have several teams waiting on you. Also your own code checkin's are much lower than theirs. Seems like you are only making changes to what others write.'
- rzzzt 9y ago
  So... how does one break the cycle?
  - jjoonathan 9y ago
    For managers: better metrics or fewer metrics. For programmers: jump ship. A well-executed handoff process will not only maintain goodwill but remind others of your value.
  - taneq 9y ago
    Start by actually talking to your management instead of just trying to be a rock star. "Hey, I'm spending a lot of time doing Team X's job and it's impacting on my assigned work, if you want me to keep doing this then put me in charge of Team X, otherwise let's all sit down together and clarify who is responsible for what."
    - Infernal 9y ago
      So I'm asking this not to move the goalposts, but because it's the situation I'm in - what do if your manager is too weak/distracted/uncaring to actually act on this information and/or the projects in wait state on you are not actually within your manager's sphere of influence?
      - taneq 9y ago
joncrane 9y ago
>After 25 years of this What has your career trajectory been like over the past 25 years?
- derekp7 9y ago
  I'd best describe myself as a "computer person". Other than the first few years when I first started at around 15, my job has been Unix Systems Administrator / Engineer, but I've always thrown a lot of programming at my job too. Not just systems automation programming, but various utilities, apps, etc. For example, back in 89 (I was 18 - 19 then) the company I was at had a need to access multiple screens at the same time in their green-screen (serial terminal) application. So I wrote a multi-session terminal emulator. Ended up being a lot like what GNU screen is today (not sure if screen existed then, this was pre-internet days for me). Other times I'd write up software distribution systems, monitoring systems, etc. Or work on creating things like a custom interpreted language, just because an app developer at my company needed that. Or write hand-coded postscript, because someone's app needed that. In my current company, I'm still a Linux systems engineer / Lead, but I've been on-loan to our app development team to help with C-based libraries that they need (this code is a couple decades old, and they don't have any C hackers that can work on it). This is software that interfaces with medical testing equipment, so it feels like I'm making some difference. Lately I've been brushing up on my web development skills, becoming buzzword-compliant, and putting together web apps both for internal use, and related to maintaining our product. I guess I should have went into full time development years ago, but I was always worried that I'd get shoved into boring business applications instead of working on really interesting stuff. So I've stayed in the Unix/Linux ops role, found out that a lot of what I've been doing is now called DevOps, and doing open source work on the side. As for the trajectory, I haven't changed jobs that often. I've had a couple of dud-type jobs where I lasted 1 - 3 years (they didn't want someone who could do "extra" stuff, because that "made the rest of the team look lazy" as I was told in a performance review once). But when I start at a good place I try to make a good first impression, then a better second impression, and try to work and support as many people as I can (while doing my best to make them look good, but making sure I get recognized too). Helps to have a number of people that "have my back".
e12e 9y ago
Just to try to put this in a (unfair to you) constructive context: > I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run. >> I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck. This is why I always try to follow readmes, log my progress and fix errors as I find them. Also document hidden assumptions etc. That way others can help themselves - follow the readme, look at the up to date network/architecture diagram etc. Partly this is because I really cannot be bothered to keep such details in my head, anyway.
pyrale 9y ago
> Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done. Honestly, there's not much you can do if you feel like your company is not acknowledging work that you believe is a valuable use of your clock time. What I notice more senior people do is 1) expose clear SLAs to require their help and 2) get in the habit of producing more artifacts while they concentrate so they can refocus faster after an interruption.
mratzloff 9y ago
For your own sake, I'd spend less time working and more time figuring out the emotional driver behind why you work so much.
- derekp7 9y ago
  I've actually slowed down a bit in recent years, however the main driver is that the work is fun. During the day I do the necessary (but not necessarily fun) work. After hours, I work on stuff that is mentally challenging and needs concentration, but only if I find it fun to work on. I do this instead of watching TV for example. As long as I get in enough time for other activities (hiking / bicycling, woodworking, designing my own creations, time with family) then hopefully I have a balance. But I have always had a slightly unhealthy fixation on sitting in front of a computer screen and creating (whether I'm doing it for work, or personal projects).

NutriSugar 9y ago

Having been the 'goto build guy', I've had to cut people off who were seeking me out for very self explanatory issues. For example, when the build threw an error because it couldn't find a file, pointing out where in the error to get the file, but the person seeking help didn't even try reading the error. Basically I limit my intervention to prevent enabling helplessness. The amount of help given also depends on the role of the person as well, junior devs get more hand holding then senior devs.