[doppel]

I feel it's completely acceptable to wish to stay in an IC position, but to refuse outright to give advise or share the experience (it's hard to tell from your short paragraph) seems... odd?

It's acceptable to want to stay in a specific role, but I am not certain I feel it's acceptable to eschew an increasing responsibility or mentoring role as you gain experience. That way lies the "genius programmer that works alone and writes code no one else wunderstands".

[tm-guimaraes]

Saying “no” is the correct answer.

It’s the same as not solving chat request bypassing prioritization.

The company is full of incentives to ask that guy for guidance/things, if he doesn’t say no most or all of the time, he simply won’t have time for his IC role, and would remain a lead just not in name.

It’s hard that it comes to that extreme measure, but if his requests aren’t being heard, it’s either that or leaving. The company has to let him be an IC or explicitly tell him that he can’t stay there as IC, are at least negotiate some timme allocation for those requests and log them

[bboygravity]

Another simple trick if you don't like saying "no": become a freelancer.

It will never ever occur to anybody in the company that a freelance software dev could possibly be put into a management role, so they won't ask. As opposed to an employed software dev.

Bonus if you're in the EU/UK: in most countries in the EU this will even lead to tax breaks and higher before-tax hourly rates. To the point that you'll make (way) more than your "higher"-up(s).

[haspok]

> It will never ever occur to anybody in the company that a freelance software dev could possibly be put into a management role...

If by "freelancer" you mean "contractor", then this statement is false. I had worked at multiple places in the UK where this happened, I suppose mostly because paying these people a salary would have required an disproportionate amount of money (as opposed to a standard daily rate) - UK taxes are very high in the top bracket.

If by "freelancer" you mean a real freelancer (the guy who has multiple short gigs at the same time, and needs to be constantly on the lookout for new opportunities) then that is already half of a management position, even if you don't have anyone reporting for you.

It is true though that as a contractor one can reasonably easily avoid management duties, and enjoy not having to worry about company politics. The downside is that it is easy to end up in a place where you have to accept that comparably junior people dictate architecture and some tech decisions which you discarded 10 years ago as ineffective, stupid, fad, or all of the above (TDD being a typical example). The upside is that your time at each place is limited anyway, and there is always something to learn...

[wing-_-nuts]

>TDD being a typical example

Shots fired! I love tests, but I mostly agree with you. The whole idea of 'write your tests first' is great if everything is precisely defined. I find it odd I haven't seen more pragmatism around unit testing in the blogosphere. It's TDD or death out there.

[MoreQARespect]

Where not everything is precisely defined but "you know the right outcome when you see it" is where I think snapshot test driven development really shines:

https://hitchdev.com/hitchstory/approach/snapshot-test-drive...

E.g. "define API call -> don't define API response -> write the code that spits out the correct response -> auto-rewrite the test according to the response and commit".

[damagednoob]

> Bonus if you're in the EU/UK: in most countries in the EU this will even lead to tax breaks and higher before-tax hourly rates.

Having been a contractor in the UK for 5 years, I don't think this is true. Between VAT, Company and Dividend tax, the taxman (HMRC) always gets his share.

[HelloMcFly]

I think it's one thing to push back on repeated requests for your input/opinion outside of your role in a way that makes you a "de facto" leader. But I think it's wholly another if you're the person with the best insight, and there is need for your knowledge to be shared. Coders are knowledge workers, not widget makers - they're paid for what they know and can do with that knowledge. This doesn't need to mean you become a manager, join committees, get added to ever-increasing cross-functional project teams.

[tm-guimaraes]

> But I think it's wholly another if you're the person with the best insight, and there is need for your knowledge to be shared.

But what if you whole day is doing just that? and you just want to spend some time writing some code? Companies are always in need of people to write the code, so there will always be other jobs, obviously it won't pay as much, but self fulfillment is important.

I'm with you, the trade is about theory building, removing ambiguity from requirements, and the update of these, code is just a tool. Still it fells nice building something, it feels nice to see something you build working in prod / to customers. Once base needs are met, it's fine for people to not want more responsibility than necessary.

[wiz21c]

> , but to refuse outright to give advise or share the experience

I think there's mentoring and leadership. These are different. I sure can mentor and help people to better think/program but don't ask me to push a team to meet a deadline they don't want to meet because they warned the marketing department 2 months before that they wouldn't do it. Been there, done that. Once in that position, you're pushing people, you become the bad guy and you have to explain that it's "for the good of the company, because they have to see the big picture, etc", IOW "screw you, I'm the boss". For that you need to be crazy enough to think that what you want is more important than what other humans-like-you are. OK, leadership is not always that and most often, you have to gather enough trust from your team so that from time to time, you can be a pusher. But if you don't have trust and you are always pushed to push, well, welcome to hell, and say goodbye to your health.

It's very different than "let's work together to find the best possible way to solve a problem, taking all the necessary time to produce something reliable".

[wingerlang]

> I feel it's completely acceptable to wish to stay in an IC position, but to refuse outright to give advise or share the experience (it's hard to tell from your short paragraph) seems... odd?

I think it depends on how much time they expected him to take out of his days. My girlfriend resigned from a job after becoming a go-to person for everything and everyone. It caused her to not have time for her own work, effectively being way underpaid, and being stressed all the time.

[MetaWhirledPeas]

Yes, this happens. If one behaves like a pleasant, helpful individual (as one should!), it's a risk. There are only so many hours in the day!

My advice for any such person is to find a way to redirect questions to other capable people (when you're overloaded), or to reframe answers to be more educational. I'm not perfect at it but I'm trying.

Some helpful tips:

- If you're going to give someone instruction, ask them to share their screen while you walk them through the steps. They are far more likely to remember it this way.

- Avoid short answers. Be annoyingly informative when appropriate. Yes, I'm happy to tell you about XYZ but not without giving you way more than you bargained for!

Consider these scenarios. In each scenario, which option would you pick?

A: Look at my notes and figure it out for myself OR get an answer from Annie in 5 seconds

B: Look at my notes and figure it out for myself OR be accosted by Annie for a 30-minute video call where I'm asked to screen share my way through the steps

I think B is more likely to produce self-reliant teammates.

[amelius]

It can be explained by social anxiety issues, as these people typically prefer to sit in a corner coding and be left alone. Probably a self-reinforcing condition that's difficult to get out of. Just one example I can think of.

[ravenstine]

This is how toxic middle management is born. Management is not seen as a skill of its own but as a title that obviously everyone should strive for.

Also, "acceptable"? By whom? Why should I care what they think? I want to be engineering software. If they don't like that, they can either deal with it or let me go. Good thing there's plenty of developer jobs as well as corporate bozos to take the coveted management positions.