Hacker News new | ask | show | jobs
by tm-guimaraes 1117 days ago
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

2 comments

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

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

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

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

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

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