You can find a bunch of articles by googling "never accept counter-offer" but they don't provide much in the way of hard data, it's mostly anecdotes.
Some articles say your relationship with your employer is like your relationship with your partner - any indication of looking elsewhere is disloyalty, and will inevitably lead to a break-up down the line if not now. Or it'll put you first in line for lay-offs. Other articles say your employer has a moral duty to pay a 'fair' amount, and if you can get 20% more elsewhere, that shows you should resent your current employer, and leave on principle. Or that threatening to quit and not following through makes you "the boy who cried wolf" and shows a lack of integrity. Or that the fact you were interviewing in the first place shows you weren't satisfied and fulfilled at your current job.
A lot of the articles are written by recruiters. They don't want people to take the counter-offer because it means they miss out on their 20% commission.
Personally I once accepted a counter-offer and it went just fine - in fact, the job offer would have needed an hour-long commute, whereas my job at the time had a 20 minute commute, so I got the extra money without the extra commute. It didn't limit my career or get me laid off or anything.
This was talked about in The Hard Thing about Hard Things by Ben Horowitz, iirc, but from the other side. It advises to not offer a raise to keep an employee planning to leave. This is because the implication is that you were underpaying them before or that you're willing to overpay them now for threatening to quit. This encourages employees to follow suit instead of working towards promo. So pay what you're willing to and don't play that kind of game.
The book/article goes in more depth. I thought it was still online for free but I can't seem to find it.
Sounds to me like it's the employer that should dislike counter-offers, not the employee. This advice is also made through an "employer is always right" lens. Is it really so bad to send a signal to an employee that they were underpaid?
To one employee? No. But other employees will probably find out. Now how will they try to get a raise? By working hard, or getting an offer letter and threatening to leave?
As an individual, if you fully intend to leave, and find your current employer trying to keep you that's a personal decision for sure. For me, I figure if I already put in all the effort to find a better job, I might as well take it. Maybe irrational, but at that point I've already weighed the decision on whether to go. My decisions to leave have usually not been purely about comp but other issues I have with the job.
One anecdata: The one time I accepted a counter-offer (but not for more money), I regretted it.
(I was at place that had an existential problem, and unhappily fighting it. Then, coincidentally, a different company, which had previously made me a tempting offer, checked back in. They made an offer to double my TC, which included a big title jump, to fit their pay grades. I wanted to be loyal to my team, so I went to the appropriate exec at my employer. I said I had an unsolicited offer that I had to decide on immediately, but I would stay if we could solve the problem. Was assured exec understood, and we could tackle the problem. I also asked for the company to do right by a couple other employees, while I had the exec's ear and the moment. Existential problem got worse, and couldn't be solved, for political reasons. Everyone was miserable, and I was out the boost to lifestyle and resume decorations.)
The more usual reasons I know not to mess with counter-offers are that: if the employer wasn't treating you fairly before, that's a problem; you might be flagged as disloyal; they might pay to keep you for temporary convenience, but get rid of you when more convenient for them.
Few organizations invest in solutions only understood by one or two individuals on their team. This is actually what prevents undergraduate cs knowledge from having an impact. It makes me sad.
Undergraduate CS isn't about the things you do most of the time. It's about enabling the occasions where the alternative is to give up and shrug, or perhaps speculate instead of evaluate.
The biggest downside of knockout is that it parses the template from the dom, and the template is rendered as dom until first execution. Then that it eval it's bindings. I suppose tko should help with those issues but seems kinda dead.
Knockout reactivity primitives are also a lot more naive then modern signals implementations.
I think the West Wing clip highlights how out of date the thinking in the article is. When this clip was filmed, turn by turn navigation didn't exist yet. If the average person saw a map, it had north at the top. By contrast, these days, if I see a map, the direction I'm currently going is normally up. I don't find it freaky for maps to be oriented with north down because I see a map like that every time I drive south in my car.
Came here to see if anyone recommended that clip. I watched it just last night, it never fails to crack me up, especially CJ's reaction. "You can't do that!" "Why not?" "Because it's freaking me out!"
Effective scene, too -- I've thought a bit differently about maps and some other things ever since, things that might not have ever occurred to me before. It's not a bad idea to expose people to different map projections / configurations to shake up their view of the world.
It's always a matter of chasing the bottleneck. It's fair to say that network isn't the bottleneck for most applications. Heuristically, if you're willing to take on the performance impacts of a GC'd language you're probably already not the target audience.
Zero copy is the important part for applications that need to saturate the NIC. For example Netflix integrated encryption into the FreeBSD kernel so they could use sendfile for zero-copy transfers from SSD (in the case of very popular titles) to a TLS stream. Otherwise they would have had two extra copies of every block of video just to encrypt it.
Note however that their actual streaming stack is very different from the application stack. The constraint isn't strictly technical: ISP colocation space is expensive, so they need to have the most juiced machines they can possibly fit in the rack to control costs.
There's an obvious appeal to accomplishing zero-copy by pushing network functionality into user space instead of application functionality into kernel space, so the DPDK evolution is natural.
TCP is generally zero-copy now. Zero-copy with io_uring is also possible.
AF_XDP is also another way to do high-performance networking in the kernel, and it's not bad.
DPDK still has a ~30% advantage over an optimized kernel-space application with a huge maintenance burden. A lot of people reach for it, though, without optimizing kernel interfaces first.
Do you have a example article? I haven't encountered the advice, but I'm curious if the reasoning matches my guess.
reply