danek

Someone I know had to sign one of these as a prerequisite to getting a severance, but before the actual amount of severance was revealed to him. He asked my advice on it and I suggested he sign bc it would be reasonable for both parties. (But basically his very new boss was very authoritarian and vindictive and didn't like him, he was doing fine for years..). So he signed it. And then he got an astonishingly tiny severance check. So much so that I nearly disparaged the company.

Yes this too. Someone I know was interviewing at google (his first choice, he did a few rounds), and then later at some other places. Google took three months to get back to him and gave him a really good offer, but by that time he had already accepted somewhere else.

Fwiw, one "advantage" of "wanting to work there" is that counterproductive management practices can survive longer. If I'm your boss and am treating you like trash, and you complain, I can just say "oh it sounds like your commitment to this company isn't very high, shall we discuss your future?" That will work a multitude of times with a gaslit employee who really drank the company kool-aid.

I'm profoundly more productive when syntax highlighting is enabled. It's easier for my brain to focus on the details it needs at any given point, versus when it's all the same color

Does "parallel construction" mean "finding plausible but fake explanations for how we got the evidence so we don't burn our successful and secret investigation techniques"? Just guessing from context...

I feel the same way (though I never ran my own startup). On the surface it would make sense for me to start companies. I tick most of the boxes, but at heart I'm more of an artist. Maybe 10 years ago I'd be interested in spending five years of my life for a 1% chance of getting better returns than working for a regular salary. Also I'm no longer in my 20s, not independently wealthy, and most importantly I don't want the stress of being responsible for a company. But that's just where I'm at right now...

That's exactly the attitude that leads to more pilot error ;)

But seriously, it's important to understand how it made sense to the pilot from his perspective at that point in time. Because he believed he was aiming for the runway (I'm gonna give the benefit of the doubt and assume he wasn't distracted with online farming). So understanding why it made sense to him can lead to actions to prevent this in the future.

Versus chalking it up to "pilot error", in which we assign blame and don't take action to prevent this kind of mixup in the future, thus practically ensuring it happens again. Because if it made sense to him, it'll make sense to someone else too. In fact the top comment says this type of mixup is rather common!

This. I've been "in the loop" on several people getting PIPs. Two were 100% a pretext for firing. One of those two was fired less than a week after going on the PIP, despite it being a six week plan. I thought that was especially shitty as it didn't give the person sufficient time to line up other work.

The third instance was "we wanna fire this person but if we see improvement then they can stay". This person stayed for almost a year.

In all cases the PIP was to create a paper trail to support an argument of firing for legal cause in a potential lawsuit.

I had to close it because it was too similar to being at work, on my day off.

I've had to do this a lot. It's kind of fun to skip work to get work done, but it also annoys me because it makes it apparent that you can't get useful work done at work, and that makes me feel useless when I do go to work.

Some would say "perpetually busy management is bad management", and I'd agree.

In some companies you need to keep up appearances and look like you're busy all the time.

That's not an example of "shifting the power dynamic"

To be honest this is news to me and I lurk on hn every day :-/

I thought Minority Report was still a few years away...

Thanks for the links, this stuff is both fascinating and scary.

For many people, even if completely innocent, a plea deal is a smarter choice than going to trial. So at the very least they are guilty of taking a plea deal. Possibly something more, but that can't be inferred.

This gives a great perspective on complexity. Reminds me a lot of the book An Introduction to General Systems Thinking by Jerry Weinberg. https://www.amazon.com/Introduction-General-Systems-Thinking...

I think you are right, the change likely happened in one of the preview versions leading up to this release. I didn't notice any documentation on it for any of the releases, though I could have easily missed it.

This is pretty cool and I was excited to hear about it.

But this release also changes the way unit testing integrates with the tooling, so now my suite of 1000+ nunit tests won't run via the 'dotnet test' command, nor in visual studio 2017.

If not for that, we would have upgraded today. Eventually the nUnit team will release a test runner that works with the new tooling, but in the meantime, we will stay on preview2 of the tooling & vs2015 where our tests work.

I think it depends on the quality of the feedback. Most tooling sucks, so the messages are very literal trace statements peppered through the code. , vs what the user-facing impact will be. When the thing is just spitting raw information at me, I'm probably going to train myself to ignore it. But if it can tell me what is going to happen, in terms that I care about, then I'll pay attention.

Imagine I just entered a command to remove too many servers that will cause an outage:

  "Finished removing servers" 
  (better than no message, I suppose)

vs

  "Finished removing 8 servers"
  (better, it's still too late to prevent my mistake 
    but at least I can figure out the scale of my mistake)

vs

  "8 servers will be removed. Press `y` to continue"
  (better, no indication of impact but if I'm paying
     attention I might catch the mistake)

vs

  "40% capacity (8 servers) will be removed. 
    Load will increase by 66% on the remaining 12 servers. 
    This is above the safety threshold of a 20% increase. 
    You can override by entering `live dangerously`."
  (preemptive safety check--imagine the text is also red so it stands out)

This is a good pattern to use. The more pre-feedback I get, the less likely I am to make a horrible mistake. However one problem I often see with this pattern is the numbers are not formatted for humans to read. Suppose it prompts:

  "1382345166 agents will be affected. Proceed? (y/n)"

Was that ~100k or ~1M agents? I can't tell unless I count the number of digits, which itself is slow and error-prone. It's worse if I'm in the middle of some high-pressure operation, because this verification detour will break my concentration and maybe I'll forget some important detail.

Now if the number is formatted for a human to consume, I don't have to break flow and am much less likely to make an "order-of-magnitude error":

  "1,382,345,166 (1.4M) agents will be affected. Proceed? (y/n)"

I always attempt to build tooling & automation and use it during a project, rather than running lots of one-off commands. I find this usually saves me & my team a lot of time over the course of a project, and helps reduce the number of magical incantations I need to keep stored in my limited mental rolodex. I seem to have better outcomes than when I build automation as an afterthought.

Management is interesting because you can be a terrible manager yet still have a successful career at it.

A lot of competent management practices seem counter-intuitive if you've never been exposed to them. Most managers I know have have never even read a book on the subject. Management is often the blind leading the blind. Most likely this kind of environment will scare away any good managers, so the cycle continues.

So, unfortunately, it shouldn't be surprising that these counter-productive practices continue.

That said, reports like this never cease to amaze me.

It's probably an indication that your use-case is not a good fit for dynamo, or that you didn't adapt your use-case to dynamo, you're doing something "wrong" like trying to use it as a relational database. I've experienced some of these pains as part of my dynamo learning curve.

For example by changing my query strategy I was able reduce the provisioned write units from 1900 to 150 (write units dominate the cost).

Almost anything can user test well. It's really hard to get right, and really easy to fool yourself.

Sorry, you guessed wrong

Yes, that's correct

While your comment sounds like it makes sense at face value, I find it naive and simplistic. I think the logical outcome of a policy like that is that you end up worse off.

We all unwittingly break many laws day. Living in the US is inherently illegal, even if you happen to be a citizen. My point is that there isn't some binary division between people that break the law and those that don't.

If businesses need to be immigration police, they'll just hire illegal immigrants under the table (moreso), and be more exploitive about it.

If people are afraid to talk to the police, they won't. This breeds gangs & protection rackets, which presumably you don't want, because they increase crime.

As these problems will become worse and worse, the more we will try to crack down on illegal immigration, intensifying said problems. The tragic irony is that the solution is the cause of the problem and it is part of a nasty feedback loop.

I'm always surprised to learn a band is English when I expected they'd be from Chicago or Detroit

fwiw i've heard it called both "Trans-Atlantic" & "Mid-Atlantic"

What's with this trend of calling an author's writing "childish" instead of saying you don't care for his style?

In addition to that, I would also worry about interactions between issues. I tend to lean towards spreading out the issues over time to make the eventual diagnosis easier.

Occasionally we'll have a problem where we cannot deploy to production for several days (normally it's once a day). A massive inventory of ready-to-deploy features builds up. When we do finally deploy, this deluge of features and fixes creates new issues that force a rollback, delaying the deploy even longer...