thisiszilff

> Comparing that to kubernetes, the latter is indeed some kind of crazy complex system to operate.

I think the fair comparison here would be that to google's kubernetes engine. Getting a kubernetes cluster up and running in GCP is really easy.

Yeah, I kind of agree with the author, but not 100%. The takeaway shouldn't be "don't use CI, kubernetes, etc." but rather "don't learn something new" when your goal is to get a product out the door. If you already know kubernetes, then it might seem silly to not use it given how it simplifies things. It's only when you don't know kubernetes that you'll run into problems.

> Calling something what it is is an important part of addressing it.

I think this is the problem the article is addressing -- "calling something what it is" doesn't convince people that don't agree with you on what it is, especially when the terms you use are loaded with possible implicit interpretations. A lot of this is related to the implied worldview these words drag in.

> Whitewashing conflict just makes it less clear what your position is.

Which is to say that in a discussion or persuasive piece, it should be clear what you are arguing for or discussing without having to expose your whole worldview. Arguments about the distribution of chores between males and females in a household, doesn't need to use the word "patriarchy" to make its argument. In fact, it tends to make the argument weaker given that "patriarchy" hides a lot of things that would otherwise need to be unpacked.

It's true, in a way, society looks like what the people in power want society to look like because the people in power are those with money and people who figure out how to make more money get power. It's like you say, that TV and ads are on the trailing edge as people figure out how to keep up with the distribution of money in society.

I'll bite and say I think it can be pretty personal. I struggled with insomnia-like symptoms for a while (eg, I simply was not tired and could not fall asleep) until I began to experiment with a couple of things. For me the most important where

- waking up at a consistent hour, every day, even the weekends

- no caffeine after noon, ideally not after 11, but I like coffee (individual tolerance will vary, I'm apparently on the sensitive side)

- make sure you're comfortable at night. It's baffling that I didn't realize this sooner, but the trick to falling asleep for me is to just get comfortable enough that I don't really want to move. When you hit that point where you're so comfortable and don't feel the need to move, then drifting off is easy.

- have a planning method to make sure you are organized and offload any thoughts about what needs to happen. I read Getting Things Done and implemented some of the stuff there and that helped a lot in freeing up my mind from worrying - remind yourself, routinely, that whatever you are doing, you'll be able to do it better in the morning

> I can work around this by moderating the length of my sleep, ie, allowing myself to go for at least 7.5 hours no matter when I fall, but sometimes IRL obligations get in the way. For most folks working more strict office hours (or god, retail) this is not a workable suggestion. Even then, eventually I'll drift too far, one of the sleep cycles gets shorted, then there's this weird recovery period with some short naps, and surprise now we're waking up at dawn again.

That is pretty much where I was. I'd go to sleep at varying hours from 10PM to 5AM, always somehow later each night. Sometimes it would take me very long to fall asleep (ie 2 hrs +) unless I felt very tired. Looking back, it is like I needed to be truly exhausted -- not just sleepy, but exhausted -- to fall asleep and that pushed back my sleep schedule every night a little bit.

It wasn't until I got brutal headaches and brain fog everyday that I made it my top priority and began to take an inventory of everything that got in my way. I still go to bed late (between midnight and 1) though, in part because it lets me do regular social things and still, usually, go to bed on time.

Certain parts of it do make sense, but it can also cause a feedback loop whereby the shift is away from concrete policy goals and towards power seeking behavior. Much of the present day political toolkit is postmodern flavored which unfortunately erodes the role of reason in communication and makes it less likely that that power is wielded towards concrete policy objectives.

> folks have a hard time divorcing their interpretations for a moment to hear someone out.

I think the key here is that in our current political landscape, "interpretation" and "hear someone out" don't really mean what they used to mean. Communication today is increasingly performative and less oriented towards synthesis and common understanding. In many of our recent political discussions, the topic hasn't been a specific policy or proposal, but a vague nebula of idea and mindsets that some would like people to adopt wholesale.

https://nymag.com/intelligencer/2020/11/inside-the-new-york-... is a great article about changes at NYTimes in the past few years.

The cooking section, I think, is the biggest winner for them these days.

You can also recommend a good article that you disagree with because you think it argues an opposing point well.

I think the biggest question here is to what extent can productivity in basic research be quantified. Or, what are the value to failed experiments and explorations of "out there" ideas? Basic research is tricky because it is at the periphery of human knowledge, so getting our bearings there is difficult. The focus should, you are right, be on "overall productivity" and not on individual productivity, but the question is how do we make decisions about individuals based on overall productivity goals.

This actually sums up my feeling when read the NYT article: reporter wades into a sub-culture only kind of understands what is going on but sees words and reports on them for the "general" audience. The article feels very... surface level, like the reporter didn't really read much of the blog or didn't think it was worth engaging with. The meat of the story is linking to prominent tech figures and the blog is this curiosity side piece that links the two.

The Economist is good because they are a centrist publication with a liberal economics bent and they don't hide it. It's refreshing because their "bias" ends up feeling more like "here is a centrist perspective" unlike some other publications where you're left questioning their agenda.

A particularly choice quote from Dijkstra here:

"The question of whether machines can think is about as relevant as the question of whether submarines can swim."

In this case I guess it's the other way around, but the sentiment still stands.

Yes, I suspect it is a pitfall of a multi-paradigm language that cannot assume so much about code in order to optimize. Opinionated functional languages (ie clojure, haskell) can have a lot more guarantees about what is going on in order to optimize all those function calls, lexical bindings, etc.

A guess: general operations

The article mentions they used other radio satellited to confirm it wasn't an artifact

I'd imagine the answer is yes, viewing the source code would increase the risk relative to an attacker that did not have access to the source code, but the statement is saying that whatever risk assessment Microsoft does already assumes attackers have knowledge of source code. EG, they are conservative and do not rely on source code secrecy when making any security evaluations.

Yeah, I'd agree. When the principle was introduced it was stated as:

> The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"

(from wikipedia)

It feels like the name really took over the intention and it became about code repetition instead of knowledge repetition.

> Consolidation is a decent goal, but it really needs to be measured. For me, it is FAR more important to consolidate on the how to do things and not the what does things. In otherwords, rather than making an "elasticsearch connection library" specify "This environment variable is the elasticsearch host/credentials" and let the apps move from there.

I think we're in agreement here. Config is the most basic kind of knowledge because when something wants to know about the elastic credentials,it almost never makes sense to have it in two places if those two places are supposed to be the same thing.

How to actually connect to elastic -- that's the part that is more iffy. If there is some knowledge we've added there, then it makes sense to DRY it up, but the knowledge of "this is how you pass credentials to this elastic search client" isn't the kind of system knowledge we care about. If, for example, there were some kind of parameters that we had to set on each connection and we claimed it as a piece of knowledge that all of our connections to this service are of this specific TYPE and have these specific parameters, then we've started to add some additional systemic knowledge that might need to get consolidated.If someone were to start working on a piece of code and I feel the need to tell them "Don't forget about X" then that is the kind of situation where DRY comes into play. If it's just a vanilla connection to a database and we don't care about the connections made, then I do given't think we have a violation of DRY given that there isn't an important piece of knowledge that's repeated.

At some point, especially when we pay too much attention to copy-pasted code, we end up abstracting. Abstracting is hard, more general, very difficult to do right, almost always done to early. DRYing out knowledge is easier and almost always improves things.

There is definitely a spectrum of "knowledge" at play when it comes to these considerations. The most obvious DRY violations are those kinds of things that you go "oh I need to test for this case" because that is usually an indication of some knowledge you need to know when interacting with a piece of code. EG, if you ever use -1 as a sentinel value then the knowledge of "what -1" means should be consolidated together, otherwise all clients will have to know that -1 is a sentinel, what it means and at best you'll have duplicate code, at worst those interpretations won't align and you might have a subtle bug where that -1 is doing something somewhere (ie it is supposed to mean "No information provided" but somewhere something is keeping an arithmetic mean of this field and those -1s are now screwing up your metrics and you don't really notice).

When we think about the knowledge of "how to do something" that's where things can get confusing. 9/10 times I'd say that right move is to look for common assumptions or facts. IE it isn't just "doing something" that is important, but the assumptions made in the process of doing it:

As an example, consider finding the average word length in some piece of text. We might start writing that feature like:

  def count_words(text: str) -> int:
      return len(text.split(' '))

  def average_word_length(text: str) -> int:
      num_words = count_words(text)
      word_lengths = []
      for word in text.split(' '):
          word_lengths.append(len(word))
      return sum(word_lengths) / num_words

then the piece of knowledge they share is "what a word is" and the DRY refactoring would pull out that piece of knowledge into its own function

  def words(text: str) -> List[str]:
      return text.split(' ')

that might be code you write when starting to write a feature and that's the kind of "ding ding ding there's common knowledge here" that should guide refactoring. The system has a concept of a "word" that we've introduced and its important that knowledge about "what a word is" in one place. For DRY things it frequently doesn't make any sense for there to be multiple statements of "what a word is" where the system wants to use the same concept.

Kind of orthogonal to this is abstraction where the focus is on "usefulness" and that is where 100% you can abstract incorrectly, prematurely, get screwed over by requirement changes, write a library that hides everything and makes people angry. The example you provide seems more like an error in abstraction where things that should be close together are too far apart in the system (ie, some "fact" is hidden away and another part of the system wants to know it), but the consolidation and DRYing of those facts, I'd argue, is a lot easier once we've figured out how to identify them

I think this misses the point of DRY a little bit. DRY isn't about not copy pasting code, it's about ensuring that knowledge isn't repeated. If two parts of the system need to know the same thing (for example, who the currently logged in user is, or what elasticsearch instance to send queries to, etc.), then there should be a single way to "know" that fact. Put that way, DRY violations are repetitions of knowledge and make the system more complex because different parts know the same fact but in different ways and you need to maintain all of them, understand all of them, etc. etc.

Code blocks that look to be syntactically the same are the lowest expression of "this might be the same piece of knowledge" insofar as they express knowledge about "how to do X", but the key is identifying the knowledge that is duplicated and working from there. Sometimes it comes out that the "duplication" is something like "this is a for loop iterating over the elements of this list in this field in this object" and that is the kind of code block that contains very little knowledge in terms of our system. But supposing that that list had a special structure (ie, maybe we've parsed text into tokens and have information about whitespace, punctuation, etc in that list) and we start to notice we're repeating code to iterate over elements of the list and ignore the whitespace, punctuation elements in it, then we've got a piece of knowledge worth DRYing out given that all the clients now need to know what whitespace & punctuation look like even when they'd like to filter them out.

It's worth pointing out that DRYing out something isn't necessarily "abstracting", it is more like consolidating knowledge into one place.

I think the best case scenario for AI ethics is that those researchers work to develop processing & metrics to ensure AI systems are fair. The current model seems overwhelmingly adversarial where AI researches do X and then the ethics researches come in an indicate problems P, Q, R. I'm curious how much internal communication there is between the ethics department and the AI departments. Instead of doing research on how the datasets are biased or something of that sort, it seems more fruitful to help researches develop balanced and fair datasets. AI is going to develop yes or yes. The best case scenario is that AI ethics is a first class concern for those researchers and is factored into their development rather than being a case of "look at this gross, unethical behavior in this model!"

> It's also an is-ought fallacy. America is also the only rich country that's built that much of its wealth on slave labour, so does that mean slave labour is a good thing?

I'm curious about this one. Most of what I've read indicates that modern American wealth was largely circumstantial due to european economies being obliterated during WW2. Do you have a source for how much slavery affected American wealth?

From what I've gathered the contents of the email were largely like "Either we do XYZ or we can work towards setting a date where I leave the company." So it is open to interpretation and vague enough that both sides can get their interpretation in. The way I phrase it to myself is that she was fired for threatening to resign. IE, that relationship wasn't good to begin with and this was just the last straw that pushed them to severing it. I suspect that people who try to claim she was fired/that she resigned don't focus enough on the broader context where that relationship was bad in the first place. This doesn't seem like it was something out of the blue, this has definitely been going on for a bit, so given that, which party took it over the line to breaking up their employment relationship seems like a detail rather than an important fact.

First off, I don't think I will ever be convinced by someone calling something "un-American" or "American." That is almost always lazy thinking that tries to wrap up an emotional sentiment into some kind of conclusion. America and what it is to be American has changed and it will continue to change. We'd better hope that change is guided by reasoning about what is good or bad for this country instead of appeals to what is "American" or not.

Second, I'm rather disappointed by the defenses of free speech we see these days. They are flimsy, lack substance, and at times seem unwilling to actually argue for free speech. Is free speech actually good for anything? Is the only reason we attack attempts by people to encroach on it because it is "American"? I, for one, would like an argument for its value.

This piece is flimsy. The discussion is about youtube getting removing election misinformation. Ok, controversial. I get it.

It brings up Hunter Biden's laptop as a case where

> That news was denounced as Russian disinformation by virtually everyone in “reputable” media, who often dismissed the story with an aristocratic snort, a la Christiane Amanpour

with those lovely scare quotes around "reputable". I'm not sure what to say here. Is it better for the media to run around screaming after every single lead? Even the ones that look flimsy to them? Is it better for the US media to be so willing to report and investigate on anything and everything these days when the media making a hubub about anything is enough to have an effect?

Taibbi proceeds to ask us to indulge in a hypothetical, one where

> what would have happened if Facebook and Google had banned 9/11 Truth on the advice of intelligence officials in the Bush years

and the natural result of this is that

> it will start to make sense that Trump voters in Guy Fawkes masks are now roaming the continent like buffalo.

I'm sorry but this is incredibly lazy thinking. I'm going to stop quoting the piece because I'm tired and I have things to say. Things have changed. We've had Trump in office and he was most assuredly different than other presidents -- in good ways and bad. We've had the rise of the internet, of smartphones, of digital technology, and social media. Information flows freely. Nowadays we don't risk not having access to information, we risk being drowned in it. The "echos" in our echo chambers aren't some soft faint whispers we can't see beyond, they are roaring deluges that drown out everything else.

I'm sorry for the longer post, but the truth is that I hate these kinds of articles. They seem to just gawk at the problems we face today and do little to inform or provide perspective or argue. Taibbi in this case seems to think it's enough to post a tweet or some headlines; the reader will draw the right conclusions for themselves. It's obvious after all. Isn't it? But then that's exactly the problem we face, where everything is obvious but somehow the other guy's come to a different conclusion and but it's all wrong!

Offer some damn arguments. Try to convince people. If free speech is worth fighting for it isn't because it's some kind of "American" ideal, it's because its a good thing, a worthwhile ideal to practice, a civic habit that improves our democracy and secures it for the future. People deal with information differently these days; that landscape has most assuredly changed. Is it any surprise that free speech will need to fought for again?

I guess the appeal of clojure in that case is that the language is a lot simpler than other languages.

To what extent do you think it is a clojure problem vs a people problem? Further up in the comment thread there was a post discussing how some orgs had problems because people would be writing java in clojure (or python or ruby, etc.). I can see there being problems with people no writing idiomatic clojure code in part because clojure is nwe and their experience is in OO/procedural languagees.

What works for me is a few things:

(1) Separate work from life, be able to walk away for a bit when work isn't going well. And do walk away if things aren't going well. If you haven't been able to write any code for the past few hours, odds are you won't be able to write any in the next few hours.

(2) Focus on process over results. IE have a good process to minimize the amount of time you spend thinking about what you should be doing, whether you did the right thing, etc. What honestly helps in these cases is just having a task list of "I need to get XYZ done today" and then blasting through it without leaving room for thinking about things too much. I like Getting Things Done (ie https://www.amazon.com/Getting-Things-Done-Stress-Free-Produ...) because it helps separate work from life.

(3) Take the long view of your life/career. The truth is that you are going to make mistakes, bugs will get into prod, you're going to get burned out, etc, so you need to accept that you will have "bad" days (or days, weeks, moths where you just don't care about what you're doing in which case it is obviously going to be crap) and focus on the process for improving them to minimize them over the long run. I think the important question here isn't "did I make mistakes" but rather "is my process resulting in a slower rate of mistakes/less severe mistakes.

(4) Never forget to eat, sleep, drink water, and exercise. Especially sleep. when things are bad we tend to sacrifice sleep, that almost always makes it worse.

Most of it I think is summarized as having a process you can trust so that when things do go poorly you can focus on the process in those moments. The process will get you out.

A lot of it boils down to another entry on that list

> Use your brain

IE, here is your confidence in our code (0...100%) and here are tools to increase that confidence (unit testing, integration testing, monitoring, etc.). At that point it is straightforward to say, "does this unit test increase my confidence?" and then go onwards. The thing is you need to learn to accurately gauge your confidence which can be difficult at times, especially when you are dealing with unknown unknowns, but if you iterate on it you get to a place where problems pop up in the areas you are least comfortable with and that is a good signal you're at least approximating it correctly.

> The original legislation before the board had sought to exempt only medicinal cannabis users from the indoor smoking ban, but the board voted to exclude marijuana smoking in general because state law prohibits cannabis users from smoking in public places

Maybe the key caveat here, glad to see we avoided the kafkaesque situation of "you can freely smoke cannabis, just not inside or outside".