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.

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

Yes. I would never have become the engineer that I am if people had always helped me when I asked.

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.

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

5th Year

Management publishes a Medium article "We fired our top talent. Best decision we ever made."

So... how does one break the cycle?

Managers inadvertently create this dynamic when they are focused on attacking obstacles rather than creating infrastructure. If <employee> knows how to do something, and that thing is not getting done, then <employee> is the obstacle. The discussion often doesn't make it to the point of 'why doesn't anyone else know how to do this?' Management needs to think more like logisticians rather than tacticians.

From an employee standpoint, when helping your peers ask them to take notes. Any additional requests -> ask them to refer to their notes. This sets a clear boundary and gives you a built-in defense while still helping the team achieve goals. Now you are no longer the obstacle, because you provided training. The obstacle is now <Peer's> inability to properly take notes or retain information. <Peer> knows this and is much more likely to attempt solutions rather than nag you into doing their job, or escalate to management. Additionally <Peer> will have better knowledge retention by synthesizing their own notes.

Documentation is a good barometer of this behavior (it's the first casualty). If your environment has little documentation, then you are probably looking at a group that will punish responsibility. No one documents anything if all that earns them is 'John's instructions don't work, I've asked him several times to fix it'.

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.

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

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?

Hmm, tough one. The default answer is "follow it up the chain" - if your boss isn't doing the right thing, talk to their boss, and so on. Another approach is to talk to the manager of the team who's leaning on you, and let them know (if they don't already) how much they're depending on you and that you should really be in that team. This can cause drama with your immediate boss (they're seen as 'poaching' you) but if said boss doesn't care then this might not be a problem.

Of course, by the time you have upper management yelling at you because "several teams are waiting on you", the response becomes "why have you allowed several teams to become completely dependent on one overworked person?"

The other, more drastic solution (as someone else said) is simply to move jobs. This can be the only way to fix the issue if the entire management structure is corrupted and you don't think it's fixable from within. You could even just leave, start a consultancy company, and let the second team know that you're available for hire when they need you.

Unless something is keeping you there, just find a new job, here are some reasons:

- If you reach this situation, you're more competent than the rest of the group. Nobody to learn from, time to go.

- "Management" is a big machine, with its own insider culture and politics. It does not change overnight, do you want to wait 6 months minimum for things to get better?

- Changing job is good for just about everything: career, money, knowledge... as long as you don't do it too often.

- Meta-bonus: getting into a job with better peers means tighter work-friends. It's not fun to be around people overdesigning object-oriented projects when you understand functionnal programming and low-level debugging.

This is absolutely true, and enlightening to see stated so succinctly.

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.

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.

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

>After 25 years of this

What has your career trajectory been like over the past 25 years?

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

For your own sake, I'd spend less time working and more time figuring out the emotional driver behind why you work so much.

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