> To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible.
I transitioned from startups (for 10 years) to a large company (for 5 years). Part of that move was adjusting from a culture of no lengthy documents to a culture full of lengthy documents, and I would never want to go back. Having explicit documentation in writing, where folks can debate the merit of ideas is so so much better than having it living in a few people's heads, unable to be critiqued.
I guess I shouldn't be surprised by the "this is fine" comments here, but I am. Geological changes happen in geological time (outside of massive disruptive events). This change happened in 100 years. Also, comparing this to clay pots is simply not understanding the scale of modern production and waste. It's like saying a forest fire doesn't pose any problem to my house because I lit a match one time.
> It’s hard to do FP in any language that isn’t designed for it.
I don't see why this is true, and perhaps it's because I don't have a full enough concept of functional programming.
In any language, why can't we write functions that don't modify the arguments, offer the same return for the same arguments, and modify no internal state when called? And then compose those functions together to form a full working program?
Thanks for stating this so clearly. I am always confused why data flow frameworks, DSLs, or other syntactic sugar inevitably gets entangled with functional programming. Once more logic is in stateless functions and easy to test and compose (as you stated), one can gradually introduce layers, sugar, and abstraction (should the team choose)
From a circuit perspective, it seems trivial to open a switch back to the grid to prevent grid-feed, while still feeding the internal circuit that is the house. Can you help me understand why this is hard?
I read "This changes everything: capitalism vs the climate" by Naomi Klein. I bought it several years back. By complete accident, I read it immediately after "Lame Deer Seeker of Visions". It was a nice one two punch. Those were my favorite reads of the year
I actually don't think it's a bad take. Everyone theoretically falls somewhere on a spectrum of "optimum sleep requirements". That's a given. What I take from the advice is that you may be well above your optimum. In my experience, it's easy to get in a habit of sleeping beyond what's needed. I, for one, feel terrible all day if I let myself sleep too long. Waking up earlier is harder, but my body consistently feels better for it. YMMV.
I have a hard time with the Google docs is the "collaborative editing and versioning" state of the art bit. My team has several long running docs that we maintain in it, and the UX for finding relevant comments around a blurb of text is bad. You can either (a) never resolve comments so that they always appear in the sidebar, cluttering the doc to no end or (b) tap the comment icon in the top right and scroll through resolved comments that have lost all relationship to the text body. I think there must be better solutions, but vendor lock-in means we'll probably never leave it (at least, not without major disruption).
Regarding the concrete example: IMO these questions have nothing to do with being autistic. They are product 101 questions to ask before jumping into a rash rewrite, and the manager in this example took the author's sensible questions poorly. Speculation: perhaps it was not the content of the questions themselves that set off the manager? IDK.
I'd venture that the majority of mid+ engineers ask these questions out of habit. That is, if such a proposition even makes it to them. A good product manager would ask these questions well before the proposal even made it to engineering.
You have to be the most sensible programmer I've run into here. If I could plus one a single section of your post it would be the "Good software is <bullets> none of which depends on the language". Had me nodding excitedly in agreement, subduing the urge to shout YES at my screen.
Reading this makes me feel quite insecure in my own comprehension of these books. I've read Pale King, Infinite Jest, Consider the Lobster, and Broom of the System. I liked them all. But I read this article and I don't really understand the majority of it, which makes me think that I also missed a lot of what I was supposed to take from the books. Genuine question, does this make sense to most readers? Do you need to be a literature major to understand this article?
> I see that you have a hard time following an argument and the rhetorical techniques I used. I will break it down.
In this one sentence you betray yourself as uninterested in debate, and instead just like to hear yourself talk. The person you are responding to offered an interesting comparison, that of stats from the US versus other countries (and, I might add, they gamely came to your turf, which you subsequently tried to dismiss). Instead of doing the hard work of revising your views in the face of a potentially fruitful comparison, you dismiss it out of hand and assert your self-righteousness.
You're almost there, IMO. This internet stranger encourages you to ditch the rule of DRYing based on the number of repetitions at all, and instead think of DRYing based on what deserves to change to together. Sometimes a single repetition in code deserves to be DRY. Sometimes 10 repetitions don't deserve to be DRY.
To each their own. I find the hover states on the jam3 site unintuitive, like the clickable area is moving out from under me, forcing me to track it before perfoming the actual click. Reminds me of a flash ad where the target moves as your mouse gets closer.
Doesn't record a video, but I've been a happy user of LICEcap to make animated gifs of a portion of the screen that I share with co-workers (to github, slack, etc.)
Agree that the amount of entitlement in this thread is wild. People, ostensibly respected principal engineers, will turn down jobs because they are asked a puzzle question during lunch. I _hope_ we are fortunate enough for this attitude to be a possibility in the next decade.
I have seen "worse is better" trotted out many many times, used mostly as an appeal to authority instead of a clear instantiation of the argument presented in the essay. I think this is because the argument in the original essay is not crisply presented (at least not to me). So authors take "worse" and "better" on some random dimension that's beneficial to them in the moment, and then appeal to the authority of this well respected essay to "prove" that their approach is better.
This post is stating that they tried to generalize too much instead of building to narrow use cases first. There is no need to bring "worse is better" into it at all, IMO
It was at the entrance to stonestown mall in SF. Looks like it's called iRepair, and reviews are completely polarized so maybe I should see how long it works before singing their praises, as another commentor recommended:
https://news.ycombinator.com/item?id=31112815
This is only ever so slightly related, but I just have to write this somewhere because it happened yesterday. An iPhone X is what, 4 years old? I took one that died completely to the apple store yesterday. They said that it's out of warranty and the "logic board was dead" so there was nothing they could do. But I could pay $560 for a new one! I dissappointedly gave them the phone to recycle. Then on the walk out of the mall I saw one of the "we fix phones" kiosks and thought I'd give it a shot. I was thankfully able to get the "paperweight" phone back from the Apple Store. And, I'm not kidding here, this single employee at the kiosk had the phone split open and booting in under two minutes. The genius bar staff just resorts to "bad logic board" when they don't want to spend even a minute diagnosing the problem. Or maybe they don't have the skills, IDK. I was happy that this solo kiosk rep was a repair wizard.
I'm going to join you down at the bottom here. I agree with you it isn't quite right, and I _think_ the reason comes from a couple sleights of hand. One: healthy people don't go in testing for the presense of a rare disease. That is, if you are administering this test to 10,000 people and only one truly has the disease, then any statistic that you back out of this trial is well below any significance. Two: the colloquial use of 'accuracy' is not the statistical use of 'accuracy'. This post uses the former for our 'intuition' and the latter to demonstrate that our intuition is wrong.
I don't like this one bit! In many cases, finding the right docs in an org is like finding a needle in a haystack. When someone asks a question that's in the docs, I default to assuming they looked and they couldn't find it, not that they are lazy or trying to put down my work. FWIW with this approach I have not had people needling me like the author here, and I have a ways to go but I have been in this industry for 17 years now.
I think the people that could use more effort in communication will see this post as relatable, and will justify their behavior when interacting with other teams / team members. In my experience infra teams are particularly bad at this, which I attribute to lack of building up a "customer first" muscle that feature teams tend to build by necessity. Of course this is wreckless speculation. I do know that it's annoying when other teams are short with reasonable questions, and have this self righteous attitude that what they work on is obviously perfect and that I'm an idiot for asking these questions!