HN user

joekim

74 karma
Posts0
Comments44
View on HN
No posts found.

The community here is very forgiving of software bugs, but why did the rep act that way? To paraphrase Warren Buffet, what are the incentives that directed that led to this outcome? Why did the rep in this case act so viciously?

If Hack Club did pony up the $200k the rep would probably be compensated in some way. That would increase the propensity of a rep to strong arm with short deadlines and hold their 11 year chat history hostage even if it’s not the appropriate pricing for a non-profit.

Since this is bad for Slack and Salesforce’s brand I imagine they’ll be putting in new mechanisms to disincentivize this in the future. When it comes to the rep getting paid they’ll become an expert at how to do it properly.

I would think so if the right to be forgotten was legal principle in the United States. It only applies in Europe and I don’t think it applies to court records that are public.

What I learned from past experiences is to never use analogies. They are almost always a source of distraction, people start to argue about the analogy itself instead of the topic at hand, which is almost always completely counter productive.

As other's have mentioned, perhaps this is only for literal minded thinkers. In Pre-suasion by Robert Cialdini metaphors are identified as the most effective persuasion device. Essentially, take something the audience understands well and use it explain something else.

An anecdote Cialdini provides is from a person who had many years of being the top life insurance salesman in the country. He used a metaphor of "when you check out, your life insurance checks in". The metaphor brought up feelings of abandonment and support in a way that people quickly understood and bought into.

Sorry it seems really vague. I think it's so simple it's confusing. Essentially, the Sedona method is to connect with whatever's bugging you and ask yourself these questions.

1. Could I let it go? (You can say yes, or no or anything. Saying "yes" is typical because it's just asking if it's possible. Saying "I don't know", is to be generally avoided because it doesn't let you "try it out".)

2. Would I let it go? (Same deal as question 1, but it puts you in the driver's seat in terms of would you take action)

3. When would you let it go? (It's an invitation to say, "now!", but answer honestly)

When explaining the Sedona Method they have you hold a pen and when you "let it go" you physically let it go. That's it. People protest and say, "it's not that easy", but if you do it earnestly you find you have a slight release. Then you just keep doing it over and over again and most stuff just tends to go away.

The way I think about it is that our mind can be run as a powerful emotional simulator, but all emotions are actually real. When we watch movies it's all a simulation but we have a genuine emotional reaction when we watch. The Sedona Method is a process that simulates letting go of resistant feelings that we have, but amazingly it does actually go away. It may come back but like regular exercise you keep chipping away at it bit by bit. Over time it does wonders.

"Pushing through via sheer force of will isn't possible." That's exactly what I'm saying. I'll check out the link.

What I'm saying is that you can't push your way through Navy Seal training by trying harder. But you can significantly increase your output and down regulate the process around "quitting" by using other techniques that will trigger the norepinephrine reset.

Re: the football team though, no matter how energized they are, that team will not be able to lift more than their 1RM (1 rep max), they won't be able to lift their 10RM (10 rep max) more than 10 times (maybe a few more on a good day). Eventually there are physical limits to their ability. Similarly if that team had not slept for 48 hours, or had done non-stop math problems for 18 hours and was asked to continue doing them.

I want to challenge your thought experiment. Consider Navy Seal training. Pushing through via sheer force of will isn't possible. There needs to be a cycling and restorative process that enables above and beyond grit.

Clip of Prof Huberman on "quitting behavior" such as quitting a long bout of work. (Note: Noradrenaline is norepinephrine. It's a weird historical thing where two teams discovered it and nobody agreed on the real name)

https://podclips.com/ct/y4Ucji

Good Joe Rogan with Huberman.

https://www.youtube.com/watch?v=gLJowTOkZVo

Well it is a lot more complicated. There is no "mental energy reserve", but we do get energized by norepinephrine in the brain and once it becomes saturated it it loses its effect.

A simple technique to reset it is to activate the "sigh reflex". You just breathe in twice at a normal pace and then slowly exhale through the mouth.

Another more powerful reset is to do yoga nidra for 10-20 minutes. Yoga nidra, once you figure it out, will actually deactivate the prefrontal cortex and simulate sleep. Which has a huge boost for your cognitive abilities.

Both of these techniques will increase serotonin and dopamine in the brain which will decrease norepinephrine. Once norepinephrine is no longer saturated you can become energized by it again.

For example, imagine a football team winning the super bowl. They've been pushing 110%. Suddenly, they're jubilant and jumping all over the place. The dopamine and serotonin pushes out the norepinephrine allowing to return and become effective again.

Nobody said anything about "owing." Simply that we've been "compensated" via tremendous value hence as programmers there's no need to feel exploited for providing "free" labor.

Here's my variation:

1) Using a text editor like Visual Studio Code, write core components in react-primitives. This code can be largely the same as your real react-native code with all it's handling of layout and internationalization.

https://github.com/lelandrichardson/react-primitives/

2) Create a library of core components. In aggregate, this library is your DLS (Design Language System)

http://airbnb.design/building-a-visual-language/

3) Use react-sketchapp to transform your core components in react-primitives to sketch symbols. If you have a large design system and support multiple languages, then this will save you a lot of time as the number of combinations of layout, language and potential input values are explosive.

http://airbnb.design/painting-with-code/

4) Use sketch to design your new feature. Use sketch symbols to quickly pull in core components. If you need to create a new core component go back to step 1. With all your fancy tooling, it can be as fast as 1 minute to build a new page.

https://twitter.com/karrisaarinen/status/849733176150773761

5) When core components change, go back to the "source of truth", the react-primitives code and modify that. Re-run react-sketchapp. Now all sketch files that depend on that core component will be automatically updated because of updated sketch symbols.

Snack - Description: Web-based react-native playground. Snack was previously called Sketch which led to much confusion. - Built by: Expo

Sketch.app - Description: Most popular native mac app for designing UIs - Built by: Bohemian Coding

react-sketchapp - Description: Convert a UI written in react-primitives to sketch. react-primitives is a subset of react-native. - Built by: Airbnb

I want to say Snack has nothing to do with react-sketchapp, but unfortunately they do share a couple of things. The developer/user of both tools will write code that is largely compatible with each other, basically a shared subset of react-native. Then, there's the whole confusion with the name Sketch. Snack used to be called Sketch. react-sketchapp uses "Sketch.app" as a rendering engine and editing interface. "Sketch.app" is basically the next program in the workflow for the user of react-sketchapp.

Whether or not you have the "right" to be rude, I think the more cordial we are the more we can align around learning through discussion.

If someone is rude to someone who's mistaken that could help them unlearn something, but more likely they will become more entrenched because of consistency principle.

Cialdini talks a lot about consistency principle in his book the "Influence: The Psychology of Persuasion"

https://www.amazon.com/Influence-Psychology-Persuasion-Rober...

Thanks for your response. I generally agree with the technical approach, but not with your assessment of Slack's products.

By "offensively wasteful" I mean off by orders of magnitude. At which point the problem isn't one of mere programming but of actually having some idea of what you are doing.

That would imply that Slack, doesn't know what they're doing. Slack is an extremely successful company. I myself use it for several teams simultaneously. From a user and business perspective it generates a lot of value and that ultimately trumps criticisms of their implementation.

One doesn't produce a resource hog like Slack by doing one or two things in a wasteful and sloppy manner. One does it by having the wrong attitude and systematically doing a bad job.

Perhaps what you're taking into consideration isn't broad enough. Going back to the original comment, if they did such a bad job, then why am I able to get a lot of value from it? Their implementation seems "good enough".

What's the negative consequences of their "orders of magnitude" performance problems? Does it destroy it's business value? What would you do if you were the CEO? Cease all active development and re-build everything in scratch in c++?