Live data from Hacker News

You've heard of “yes men”. Now learn about “no men” (2011)

rachelbythebay.com

131–140 of 151 posts

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#131
post #79

Earlier quoted context omitted.

JavaScript is indeed a very good example of this. Not just in the ecosystem, but even just the standard itself. People are pushing for more and more stuff. People on the committee can say "no", but there's an infinite amount of bullshit to push, and only a limited amount of time to push back. So sooner or later, bullshit makes it in.

What are examples of bs in the javascript standard?

Not in the standard yet, but good incoming examples are decorators and private fields. They are not bad in all languages, but the way they are getting pushed in JS is awful.

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#132

A powerful "no man" can be a valuable asset sometimes. I was involved in the design of an ASIC. This was going to be used by people from all different areas of the company, and they all had various demands. Most had never worked on a chip before, and didn't realize the cost of what they were asking for. The easy thing to do would have been to ensure that every requested feature was added But that would have burned ar…

I have an unofficial board of advisors for my small company, and one of them is a "No Man". I knew that when I asked him to join. Every time the company has an idea, this guy will shut it down immediately. He forces us to defend every single decision. Do we always listen to him? No. Does he always win? No. Is he always right? Absolutely not. But I keep him around because he forces everyone in the company to defend ev…

I'll admit to being a semi-frequent "no" person and I'm fortunate to work for someone that values that.

I've learned some people can take personal offense to having their ideas challenged, particularly when...ahem... There are some glaring holes in them they frankly should have caught. So over time I've found ways to try and take the people out of it, and also to be enthusiastic about the act of having ideas, because I'd rather have people have a bunch of ideas that mostly don't work, with occasional nuggets of gold than people who aren't capable of or engaged enough to think of new things.

Personally, I start considering most ideas, particularly my own, from the standpoint of "why will this NOT work?" It helps me sift through things quicker by identifying potential deal breakers earlier in the process, and helps me make sure I've done my due diligence on important decisions.

The net result is that I kind of enjoy poking holes in things all day, even if others see it as "not optimistic enough."

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#133

Earlier quoted context omitted.

Thanks for the repro case! I wasn't precise enough. The case where we needed swap not to error out was in a big mapreduce process, consuming maybe 44GB out of a 48GB host. When we didn't have swap on the box, the big process would exec a small command line process and the exec would fail, there wasn't 88GB of address space available during the brief period between the call to fork and the overlay. Adding a swap devic…

I'm a bit out of my depth here, but maybe you could solve this by: echo 1 > /proc/sys/vm/overcommit_memory According to documentation, 0 (the default) means usually allow overcommits according to some heuristic (which was probably failing in your case), 1 means always allow, and 2 means don't allow. Edit: It appears from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... that things will go wrong if you…

Yes, one example where overcommit can be better than swap is Redis.

When redis is persisting its state to disk, it temporarily needs 2x the memory because it forks a child that does this in the background. Since fork uses copy-on-write, only the difference between child/parent is actually consumed as extra memory. The rest is "de-duplicated" in a sense.

The choice is then to

1) enable swap, possibly killing performance 2) enable overcommit, possibly killing the redis process

It is sometimes preferable for a service to fail hard and fast than get bogged down with swap. I believe this is the idea behind the "no swap" policy, at least on Linux.

Redis is a good example here because any amount of swapping will kill performance since literally all of its allocated memory is consistently accessed for the purposes of doing a dump. And Linux will always try to swap things out, even with vm.swappiness=1.

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#134
post #91

I agree with the author's overall premise, which is that other people who don't own and who are not responsible for your system should not have authority over how you build and operate it. One of the things that I like about the current company where I work is that owners always have the final say about their systems, not any external technical authority. There is no such authority who could say no where I work (with…

But not having swap will cause the machine to misbehave ( https://utcc.utoronto.ca/~cks/space/blog/unix/NoSwapConseque... ). Swap in this situation acts like a backup, surely you would prefer temporal degradation then total system shutdown. The solution here is continuous monitoring of free memory (we use datadog) + swap.

> surely you would prefer temporal degradation then total system shutdown

Sometimes, but sometimes you want the opposite.

A slow service (e.g. a db server with a failing disk) might still pass health checks but degrade overall system performance.

It is easier/simpler to detect a total outage than a slow/flapping service.

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#135
post #101

Earlier quoted context omitted.

Even before I became the manager, as a Lead I felt half my time was explaining to younger, less experienced engineers why "no, we should not" introduce something. And it really was an explanation, not a condescending or dismissive refusal. That part is key.

I wish more places understood this. Change of leadership where I am is causing so many issues because there isn't any substantiated reasons why something is a 'no'. Its just 'no', and attempts to get clarifications and how to proceed in the future are met with little clarification (and sometimes ignored altogether)

All while you're the "no wizard" ;)

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#136
Microsoft used to be like this in 00's (I don't know about now). You had to run everything by Legal, and the default answer from Legal was always "no", no matter what you're asking. Want to use zlib in your product? Even though Windows is using it in like 3 different places already, the answer is still "no". JQuery? Out of the question. Anything more exotic, might not even ask. I'm pretty sure Microsoft wasted hundreds of millions of dollars reinventing a wheel, and doing it badly, over the past few decades.

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#137
post #115

Earlier quoted context omitted.

How hard is it to say "these are the types of things we want to do. anything must look like these types of things in terms of (insert x y and z criteria: size, scale, opportunity, profitability, growth, etc) spoiler alert: it isn't hard and this is what we do at my startup that is currently experiencing hyper growth and is on multiple "unicorn" lists

Ahh hahahahahahaha! Sorry. I had a more substantive comment but it drowned in ignorance and inexperience.

You could have just refrained from posting.

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#138
post #34

Earlier quoted context omitted.

“Trust but verify” litteraly meant “Don’t trust” (as in “don’t trust the Russians” in context). Was it the nuance you intended ?

That's not what it meant. https://en.wikipedia.org/wiki/Trust,_but_verify

does it ?

> Reagan used the phrase to emphasize "the extensive verification procedures that would enable both sides to monitor compliance with the treaty"

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#139

I used to have a “don’t know/can’t remember” man in my team. Can you recall what this code you wrote previously do? “I can’t remember.” Do you know where the files are placed? “I don’t know.” Where are the documentations for xxx. “I don’t know.” Do you know the difference between xxx in testing in production server? “I can’t remember.” It was frustrating. 9 out of 10 questions were “I don’t knows” and “I can’t rememb…

Of course it would be great if everyone remembered everything, but isn't an "I don't know" better than an 80% guess? The longer I do this job, the more likely I am to say I don't know, when I don't know.

> Can you recall what this code you wrote previously do?

What it actually does might be different from what I remember. It might have been changed since then -- maybe by me, maybe by someone else. I might have made a mistake in the first place, and it doesn't do what I think. "I'm not sure, let's look at it."

Re: You've heard of “yes men”. Now learn about “no men” (2011)

#140
post #19

I don’t get it. 1 - there is a Mr.No guy but, the author only knows him by reputation 2 - there is a technical problem that seems to revolve around memory 3 - the author has an idea of a solution, she actually tries as people don’t believe her 4 - her solution works, but she is told the “No” guy said “no swap” once a long time ago Her reaction: “Did I care what he supposedly said? No.” Why doesn’t she go talk to him…

> It seems like nobody communicates correctly in that company, the author included, and it must hurt in so many places. Depending on what you think of Google (or maybe Rackspace, but I think Google's more likely the source of that post), you might be surprised at what company you're talking about. I think you're spot on but am curious if you'd write that if you knew where they worked.

I see Google as a super huge organisation with smaller organisations within (I never worked there so that's just an image).

It would be less surprising to have these kind of disfunctionments within giant corps I think. As a consumer, Google's product strategy also mirrors that image (the number of messagings platform they released that ironically don't talk to each other is legendary by now)

In particular, a very small company with a lack of internal communication would fail very fast, so it's less likely IMO.

Post reply on HN