- Most eye opening experience in my personal development was attending HR conferences (we sold an HR product but I am an engineer), where speakers were openly saying this out loud. I know you won’t believe me given your statement, but using codewords they said they were trying to hire “diverse candidates”, retain “diverse candidates”, explicitly mark “non-diverse candidates” leaving as non-regrettable churn, filtering and searching for diverse employees within the company to fast track for promotion, etc. I was in shock how brazenly they were saying the quiet part out loud, and breaking the law. This was 10 years ago, there were no repercussions for it, in fact they were all lauded.
- Localstack makes that pretty easy. Before Localstack I had a pre-staging environment (dev) target I would deploy to. Their free/community offering includes a Lambda environment; you deploy your dev "Lambda" locally to docker, using the same terraform / deploy flow you'd normally use but pointed at a Localstack server which mimics the AWS API instead. Some of their other offerings require you to pay though (Cloudfront, ECS, others) and I don't use those, yet at least.
- > The trouble is that "fast" doesn't mean anything without a point of comparison.
This is what people are missing. Even those "slow" apps are faster than their alternatives. People demand and seek out "fast", and I think the OP article misses this.
Even the "slow" applications are faster than their alternatives or have an edge in terms of speed for why people use them. In other words, people here say "well wait a second, I see people using slow apps all the time! People don't care about speed!", without realizing that the user has already optimized for speed for their use case. Maybe they use app A which is 50% as fast as app B, but app A is available on their toolbar right now, and to even know that app B exists and to install it and learn how to use it would require numerous hours of ramp up time. If the user was presented with app A and app B side by side, all things equal, they will choose B every time. There's proficiency and familiarity; if B is only 5% faster than A, but switching to B has an upfront cost in days to able to utilize that speed, well that is a hidden speed cost and why the user will choose A until B makes it worth it.
Speed is almost always the universal characteristic people select for, all things equal. Just because something faster exists, and it's niche, and hard to use (not equal for comparison to the common "slow" option people are familiar with), it doesn't mean that people reject speed, they just don't want to spend time learning the new thing, because it is _slower_ to learn how to use the new thing at first.
- as a layman, wouldn't you need a more-accurate clock to measure the accuracy of a clock? How is clock accuracy measured when the clock is the most accurate clock?
- felt more like an article legitimizing an origin myth than authorship
- Great video, I really enjoyed how down to earth it was. It reminded me of The Secret Life of Machines [1], where we get to peek behind the curtain and see how seemingly "magical" machines (in your case a digital computer) emerges from simple fundamental concepts.
[1] https://en.wikipedia.org/wiki/The_Secret_Life_of_Machines
- Spotify used to have a "dislike" button for their Discover Weekly which helped with pruning music you don't like, but with the natural law of tech enshitification they removed that feature a month ago.
function x() {/* ... */} const x = function() {/* ... */} const x = function foo() {/* ... */} const x = (function() {/* ... */}).bind(this) const x = (function foo() {/* ... */}).bind(this) const x = () => {/* ... */} const x = () => /* ... */- Agree that the repository/service pattern is a good way to adhere to separation of concerns and make refactoring and readability easier.
That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a frustrating experience.
I can make sure my code is good before I submit it for review, not when I'm just trying to make sure my work has been saved so I can continue working on it later (commit).
- He was saying that Uber will no longer operate in NL/EU, the pining was for "equal access to US services", not your data. FWIW, I am annoyed myself about having to accept GDPR popups on every website I visit, so I too pine for a day where US companies have nothing to do with "EU citizens".
- As was LinkedIn, who was forced to rate stop limiting / IP-banning scrapers for public pages.
- I think the issue primarily is that there are two frames of reference used: "earlier" / "later" terms use the absolute frame of reference (time progressing forward), the numerical terms ("100s" / "4th century") are relative to the common era (higher BCE numbers mean further back in time).
To me it is confusing that they've mixed the two, even though it is convention to do so.
- Not to be pedantic but I was genuinely confused by this statement:
> He lived and wrote in the late 200s and early 100s BCE
Shouldn't this instead be phrased as:
> He lived and wrote in the early 200s and late 100s BCE
He was born in 254 BCE and died in 184 BCE, he lived from the mid 200s BCE, started writing in the _early_ 200s BCE, and died in the _late_ 100s BCE.
- Who ever answers these questions truthfully though? It seems that this just tests for the ability to spin yarn at the interviewer.
I was recently asked this question, and while I've had some disagreements with coworkers over minor things, I've never had a major disagreement that was noteworthy, so I (to my inevitable detriment) said: "Nothing really comes to mind at the moment but if something like that were to happen, I'd do X, Y, and Z". Given the reaction from the interviewer I doubt I passed. I still have 2 more interviews with this company.
- non paywalled, found on Reddit: https://www.msn.com/en-us/money/companies/why-it-s-hard-to-g...
- > It shows that family/environment influences life outcomes
Not to nitpick but this statement implies causation (family environment causes life outcome) which you contradict right after.
Sorry to sound obtuse, but, I asked because it may seem obvious to you, but it's not so obvious to me that there will be much improvement. I've seen data that indicates that outcomes are not changed (much) when those early interventions / "investments" are made. There is _an_ improvement, but not to the level people expect. Like a person's height, access to high quality food will only do so much; some people are just going to have short stature however much money you invest into making sure they have access to nutritious meals.
I think every time I swipe I need to do at least one correction like this, where I type one similarly spelled word with as minimum an edit distance as I can think of in the moment, then do a manual correction.