adamzerner

It doesn't intend to provide such guidelines nor give out a license to cooperate with anyone.

I think this comment[1] from the post's author does a good job of answering this:

I would word the intended message as "whether or not someone shares our values is not directly relevant to whether one should cooperate with them". Moral alignment is not directly relevant to the decision; it enters only indirectly, in reasoning about things like the need for enforcement or reputational costs. Monstrous morals should not be an immediate deal-breaker in their own right; they should weigh on the scales via trust and reputation costs, but that weight is not infinite.*

I don't really think of it as "pro-cooperation" or "anti-cooperation"; there is no "pro-cooperation" "side" which I'm trying to advocate here.

[1] https://www.lesswrong.com/posts/o4cgvYmNZnfS4xhxL/working-wi...

Hm. I'm interested in hearing more about the specific scenarios where this sort of tool is useful.

I skimmed through the HN comments and see that it can be used for adding diagrams to code comments. But what else? Slack, Jira, READMEs, SMS, Signal etc all allow you to include pngs.

That's a really cool app. What JavaScript framework did you use?

I strongly disagree. Relative to other books, maybe it is on the expensive side. But relative to the value you get from it, I think it is incredibly low.

One way to think about it is in terms of how much you value your time. If you value your time at $25/hr and this book saves you more than 4 hours of time learning UI design, it is worth it.

Another way to think about it is in terms of ROI. As someone in the tech industry I think that having these skills is likely to pay off way more than $99. Not in a legible way -- it's not like anyone will ever say to you "I see you have these UI design skills, here's a $5,000 raise." But I believe that the skills will ultimately shine through and improve your ability to get jobs and make more money.

Also, in practice, if you're in the tech industry, there's probably a good chance that you can get your employer to pay for it.

I have linked to this so many times over the years. Very cool to see it on the front page.

Interesting. Thanks for the comment.

Unfortunately, I'm having trouble understanding though. The furthest I got with math is calculus. I'd love to hear a more ELI5 description of what you said. Something that doesn't require prior knowledge of abstract algebra. (I recognize that's a big/difficult ask. No obligation or anything ofc.)

That makes sense to me that in these two particular situations they have leverage. But what if they don't have enough board seats and you also aren't looking to raise a subsequent round? It sounds like then they don't really have leverage, right? If so, it seems easy enough to guard against the risk that VCs end up with too much leverage over you.

I've never understood why React components are considered to be pure. The output is not just a function of the props, it's also a function of the state (as in `useState`) and context (as in `useContext`).

Taking Eric Normand's course Beginning Clojure (https://ericnormand.podia.com/beginning-clojure).

As someone with most of their experience in JavaScript and Ruby, I really like how Clojure is just so _different_. It's like someone who speaks English learning Chinese instead of a similar language like Spanish. I think doing that opens your mind and teaches you more than if you learned something that is "more of the same". Similar to how it is useful to learn about other fields instead of continuing to grind away at "more of the same" within your field.

This strikes me as overly cynical. A pendulum swung too far. Yes, someone who takes "we don't want to change a thing" at face value is probably overconfident. OTOH, someone who says that the old culture "ceases to exist" is underconfident, I would wager. Reality is somewhere in the middle.

This advice boils down to "be the best of the best" because you'd only go out of your way for someone if they're that good.

I don't think people who haven't reached that bar are necessarily doing something "wrong". It takes hard work to reach it and some people prioritize other things in life over hustling. Others simply don't have the talent to reach it.

I disagree. The question at hand is how we should update our beliefs in response to the evidence of Zuck making the statement. Given the priors of P(M|R) and P(M|~R), it tells us that we shouldn't really update. Different priors would lead to a different update.

Sometimes this sort of thing happens where our priors don't allow for a belief update in response to evidence. For example, does me writing this comment change your best guess as to whether my favorite color is blue? That depends on what you think of P(favorite color blue | comment) and P(favorite color blue | ~comment). Both of those are probably the same right? If so, my comment doesn't allow you to update.

This excerpt from http://www.hpmor.com/chapter/20 is relevant:

  Professor Quirrell looked at Harry. "Mr. Potter," he said solemnly, with only a slight grin, "a word of advice. There is such a thing as a performance which is too perfect. Real people who have just been beaten and humiliated for fifteen minutes do not stand up and graciously forgive their enemies. It is the sort of thing you do when you're trying to convince everyone you're not Dark, not -"

  "I can't believe this! You can't have every possible observation confirm your theory! "

  "And that was a trifle too much indignation."

  "What on Earth do I have to do to convince you? "

  "To convince me that you harbor no ambitions of becoming a Dark Lord?" said Professor Quirrell, now looking outright amused. "I suppose you could just raise your right hand."

  "What?" Harry said blankly. "But I can raise my right hand whether or not I -" Harry stopped, feeling rather stupid.

  "Indeed," said Professor Quirrell. "You can just as easily do it either way. There is nothing you can do to convince me because I would know that was exactly what you were trying to do. And if we are to be even more precise, then while I suppose it is barely possible that perfectly good people exist even though I have never met one, it is nonetheless improbable that someone would be beaten for fifteen minutes and then stand up and feel a great surge of kindly forgiveness for his attackers. On the other hand it is less improbable that a young child would imagine this as the role to play in order to convince his teacher and classmates that he is not the next Dark Lord. The import of an act lies not in what that act resembles on the surface, Mr. Potter, but in the states of mind which make that act more or less probable."

  Harry blinked. He'd just had the dichotomy between the representativeness heuristic and the Bayesian definition of evidence explained to him by a wizard.

Yes, thank you! I appreciate that. I should have elaborated in my OP.

https://arbital.com/p/bayes_rule/ has some great follow up info.

I think a Bayesian perspective is helpful here. 1) How likely is it that Zuck makes that statement if he feels like he is responsible? 2) How likely is it if he doesn't feel responsible? I think the answers to those questions are quite similar, in which case hearing the statement doesn't actually tell us much.

The idea here reminds me of one of my favorite blogs posts ever: https://justinjackson.ca/words.html

I think you'd find the books Digital Minimalism and ADHD 2.0 useful. The former talks about how digital maximalism, for lack of a better term, leads to a lot of what you're experiencing. And the latter is written by a world renowned expert in ADHD. My personal takeaways from reading it were: it's a spectrum not binary; it has its pros and cons; there are things you could do to mitigate it; it's not a deficit of attention it's a matter of controlling it.

How did you handle design stuff? It looks pretty good! I'm a programmer without design training and always end up using Bootstrap.

Related: Bring Back the Sabbath (https://thezvi.wordpress.com/2017/10/07/bring-back-the-sabba...)

However, it's all automated... Also, It's limited to things that can be verified from fitness trackers and other apps thats many people do not use.

That isn't true. You can track progress on a goal manually, as well as automatically. For example, I used to use Beeminder to track how many push ups I did.

There's also https://www.beeminder.com and their competitors (https://blog.beeminder.com/competitors/).

There is something I've never understood about this. Actually, I suspect that it is just plain old wrong.

It looks at what ages people died in the year 2019. If you die at age 80 in 2019, that means you were born in 1939. But if people born in the year 1939 are living to age 80... how do I put this... wouldn't you expect people born in, say, 1989 to live longer? Wouldn't people born 50 years later have longer life expectancies? Especially if you believe the stuff about accelerating rates of technogical growth.

I'm really sorry to hear about those traumas and your current difficulty. Shoot me an email, maybe I can help: adamzerner@protonmail.com. https://adamzerner.bearblog.dev/ if you want to internet-stalk me first.

Things like skin color are different from things like leetcode ability. Looking through a veil of ignorance, I definitely would not want hiring decisions to be made based on the former. But looking through the same veil of ignorance, I would be ok with hiring decisions being made based on the latter.

Well, actually, thinking about it again now, I'm not so sure. But this now becomes an ethical question. Which is certainly important. But I want to be clear that the ethical question is a different question from the question of what a purely self-interested company should do. To that self-interest question, I think the OP and lots of people argue that the answer is "leetcode-style questions having nothing to do with the job and are thus a bad idea".

My claims are that 1) this is the wrong way to think about that self-interest question. The right way is to ask whether it is predictive of job performance. And 2) although I also suspect that leetcode-style questions aren't predictive, it's hard to be confident in that without good data.

I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.

Sounds to me that the author likes to program by "sketching". I do too! Paul Graham recommends this in Hackers and Painters.

For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging. > For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

On the other hand, as the post describes, interviews are geared towards a more waterfall-y approach. I find this frustrating as well, but I think that there is something really important to keep in mind that this post misses, and that most conversations about coding interviews miss. The question is whether something is _predictive_ of job performance.

For example, consider the question "What is your favorite number?". Imagine that the larger the answer to that question, the more likely you are to perform well as a developer. You might object "But I'm never doing anything relevant to my favorite number on the job!". IMHO, it doesn't matter. The goal is to predict who will perform well on the job, and if having a large favorite number does this, it should be incorporated.

Now consider the question of how well you perform on waterfall-style interview questions. Like "What's your favorite number?", it isn't something that you will find yourself doing on the job. But that isn't the right question. The right question is whether or not it is predictive of job performance.

Of course, it seems unlikely that "What is your favorite number?" would predict job performance. And it seems unlikely that if you never code in a waterfall-style on the job, that coding in that style during an interview would predict job performance. But maybe it does. I'm skeptical, but who knows. More importantly, I think that this is the question that needs to be asked. And without strong data, it's hard to be too confident in the answer.

Through whatever quirk of my psychology, looking stupid has always been something that I have been 100% ok with. There are various stories that come to mind, but the two that stick out the most happened in middle school science class.

One time we were learning about volcanoes. And, of course, that they erupt. I was thinking about how the eruption is dangerous and causes harm, and what we could do to prevent it. My first thought was, well, to put a cap on the volcano. So I raised my hand and asked the teacher "what if we put a cap on it?", and everyone laughed.

Another time we were learning about plants, and how if you give them too much water they will die. That immediately sounded insane to me and I raised my hand to ask, "Wait, why don't they just not drink it?!"

Both of these stories lingered around for years and people knew me as someone who lacks "common sense" and who is known for asking silly questions.

No worries. And I gotcha, your comments make more sense to me now.

What I was going for in giving the examples was just to build up from the most simple to stuff that is more complex. Like: "Here they aren't the simplest tool for the job. What about here? No. What about here? No. What about here? Not quite. What about here. Yes!"

It felt like a solid way of making the point. I didn't mean to imply that I think it is common for people to use classes for eg. print statements. I tried to protect against this interpretation in the the last section:

I want to keep the scope of this post narrow. I don't want to start getting into the weeds about the pros and cons of using classes vs using alternatives to classes. My goal here is just to point out that simpler alternatives often do exist. Hopefully that perspective can help better inform the decisions you make when writing code, and the opinions you form about programming languages.

---

The park about this theme of OOP criticism that irks me is that there's a lot of irrational class hate out there and writing that classes aren't the best option for things which classes aren't intended for just adds to it. Yes, classes are not replacements for all functions, they never were.

I hear ya. I think that like most things, there are people at the extremes of both sides of the spectrum saying stupid stuff. On on end you've got the people who love classes and think eg. that it's ok to not have first class functions. And then on the other end you've got people who hate classes and think eg. that there is basically no good use case for them ever (I came across this a decent amount actually as I was googling around before writing this post). It sounds like you and I are both somewhere in the middle and agree about the broad strokes.

As an example, of the "love classes" extreme, there is a particular pattern I've been forced to use before that I hate. In a ruby codebase, instead of creating a utility function, we have to create a class with an instance method named `call`, instantiate the class with the arguments you intend to use for the method, and then call the method with no arguments. So like instead of `getFullName(first, last)` you'd have to do `NameService.new(first, last).call`.

I am confused. Is there something you disagree with? Or are you saying that the points are obvious and thus not worth making?

(FWIW, I wasn't too happy with the writing quality when I published it. I think it is fine, but not great. I spent some time trying to improve it, but the words weren't quite coming to me. I considered throwing the post away, but decided not to. I think that the central point (as in DH6 from How to Disagree[1]) is a good one, and even though I wasn't able to express it as clearly as I'd like, it is still worth publishing as more of a conversation starter type of post, not as the official/reference post on the topic. In retrospect it would have been good express this in an epistemic status section[2].)

[1] http://paulgraham.com/disagree.html [2] https://www.lesswrong.com/posts/Hrm59GdN2yDPWbtrd/feature-id...

I don't find the end result to be significant for anything other than code cleanliness/readability.

Agreed, I think. But isn't readability a very important goal? "Programs must be written for people to read, and only incidentally for machines to execute."

I often find the decision to make class/function/object to be somewhat negligible when the purpose is as trivial as the examples provided.

Yeah I agree with that. The reason I chose trivial examples was just to make it easier to understand.

I agree! I actually wanted to include one, but as I started to explain it it started getting too wordy, which made the post feel like it was more about composition vs inheritance than classes vs alternatives, thus distracting from the main point.

I think this is mostly a limitation of me as a writer though rather than being an inherent thing. Ie. I think there's gotta be a way to give that example in a concise enough way where it doesn't distract from the main point.