Dr_tldr

...and that's why it's a bad idea to separate QA from your dev team. In the long run, everyone would've been happier if his role on the dev team had been to automate the tests and then continue to work on more interesting things. If he and his company had taken that route, he'd be a very well-qualified and well-paid senior engineer right now.

Third party vendors doing sketchy stuff with shipping does not profit Amazon enough for this to be part of their overall business plan. 350k is definitely only a warning shot, but in this case, the interests of the FAA, Amazon, and public safety are all in fairly close alignment.

It really depends on so many different factors. The javascript ecosystem is at least 100x the size of clojure's, but as a consequence, the average quality of what's available is much lower. If the pre-existing libraries and services will work for your use case, javascript is going to be faster, simply because most of the code you need has already been written.

Another important consideration is your familiarity with both. If you have a deep knowledge of javascript and its ecosystem, many of the architectural wins you get from clojure out of the box are fairly trivial to port over. I suspect the reverse is not as true, because a clojure expert dipping their toes into javascript doesn't have as clear a picture of what the limitations are and how to overcome them.

As we can already see in this thread, there's a tendency for people who use clojure to believe that some architectural concepts are literally impossible for all other languages, rather than merely less common or requiring some pre-configuration.

Do you debug your code with a microscope and soldering iron?

Layers of abstraction are useful, especially when we don't fully understand how the hardware works.

> To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem

That's simply untrue, and even the author's conclusions contradict your point. You can already do all of these things with just javascript. And if you're arguing that javascript has rebuilt the entire clojure ecosystem, then what is the non-aesthetic case for clojure?

I like clojure a lot and I've made a few toy projects with it, but I see its primary value as helping me write better code in all languages I use.

So you were part of the group of schools that refused to agree to a transparency initiative (https://news.ycombinator.com/item?id=11872261) but you think self-publishing your own methodology with zero breakdown of what your categories mean is just as good?

Like, where are all of the grads employed by Hack Reactor to pad the numbers accounted for? What percentage of your students already have a CS degree when they walk in the door? Why is the size of the average class increasing at the same time the price is going up? Most importantly, why do some big name companies effectively blacklist your graduates now, and what are you doing about it?

Your "towering accomplishment of staggering magnitude" looks like marketing hype and a lack of transparency.

For a totally new project, especially with React and React Native, it's not trivial to get things right, but it's not that hard either. Technically it's not "one app", but if you build them in parallel and you know what you're doing, 90% of the codebase can be shared.

The author is putting forth a false dichotomy between "write one web app that works on everything" and "write a new app from scratch for every platform." The right answer in 2016 is a hybrid approach.

100% agree, it's usually not the fault of the engineers. But in a better system, they wouldn't face political pressure to tell people that indefinite growth without inconvenience or long term investment is possible.

Two second grammar lesson: who is the implied SUBJECT in the phrase "laughing out loud"?

Whereas if someone (not me, though) were to say "People named Mark always leave terrible comments because they have severe learning disabilities", that would be a truth-claim.

The implication that people who have more knowledge about a local area have more right to publicly maintained resources than those who don't is even more troubling. Maintaining unequal access to public resources is a form of corruption, discrimination, or both.

A traffic engineer whose designs are only effective when there's information asymmetry is either

A) dealing with impossible project restraints/requirements B) terrible at their job

Of course you have the right to say you don't find it funny and don't think it's an appropriate way to introduce code, but put some subjective terms like "I feel" rather than "it is." One acknowledges personal preference, while the other implies an objective truth-claim without the possibility for disagreement.

I'm not so sure about the "faster to write" since my IDE and linting will already take care of that. The java-style boilerplate is a huge turnoff for me, and the validation seems to produce false negatives so often as to actually introduce more bugs. Ie, If a variable gets mutated without changing type, TS is now worse than useless for validation.

The self-documenting part is the strongest argument I've heard, but writing real documentation and real tests still seems better.

Yes, but what about mutating objects/primitives in a way that causes all validations to pass but still be passing the wrong data?

It seems like using type checking as a reason to write fewer tests actually just creates nastier bugs in areas where your coverage is based on type validation.

What am I missing about checking type mutation !== mutation being a problem?

What is the advantage of strong types if your data structures are immutable? Is there any? I'm genuinely trying to understand if TS is just for cases where uncontrolled mutation is the norm and test coverage is poor.

Q: What is a concrete advantage of Typescript?

A: C's type system is very useful for data validation.

Please read at least one sentence before writing a response next time.

But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime?

Certainly type checking can prove that it's the right type, but in my experience knowing that it's the right type but the wrong data is useless, I care if it's the exact data it's supposed to be.

How does type checking protect you (or someone else) from inadvertently mutating a value without changing it type and causing problems later? It's perfectly possible to do this without having any checks for class/instance throw a warning, unless there's something I'm missing.

It seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations.

But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?

It's placing blame for a general problem on the decisions and values of certain people and societies.

In terms of logical structure, taking an anecdote and universalizing it without a falsifiable explanatory mechanism is indistinguishable from blaming faraway natural disasters on other people sinning against the gods.

In both cases, people and society are held to be at least partially culpable for something bad that happened to them without presenting any evidence other than that they don't do all the same things that you do, and you're doing fine.

> “Do I need to go down and get the certificate that says I’m CEO of the company to get you to stop challenging me on this?”

In my experience at Amazon, there's a lot of free discussion and invitations for criticism of management ideas, but once a decision has been made, everyone is expected to get behind it for at least the next 6-12 months.

I don't think most teams at Amazon engage in "shaming" behavior, as much as they set a standard. Ie, if we agreed that all new modules are going to have 100% or near 100% test coverage and someone turns in a commit that doesn't have any tests at all, they're going to get some shit from the rest of the team.

There's a difference between an implementation that doesn't work as well as hoped that needs to be refactored, and intentionally adding technical debt and going against best practices to save yourself time. Quirky implementations are treated pretty indulgently at Amazon as long as you fix them once it's clear they're a problem, while laziness and causing harm to other developers who have to maintain the codebase is clamped down on pretty hard.

Most people would be in favor of "shaming" an airplane mechanic who doesn't follow the safety checklist after they've been taught how to, but not so if it was their first day.

> But outside these few cases we don't know. One factor is reporting. Do poor kids in India suffer fewer allergies or are they simply dwarfed by the other problems -- or just not reported?

This is a great point that gets overlooked: lack of data is often taken as non-existence, even implicitly. When the average life expectancy is under 50 and there's fewer than one doctor for every 10,000 people, sneezing and occasional sinus pain doesn't even warrant a mention.

But beyond being a humblebrag, it's also bordering on a just-world view of the universe that's basically superstition.

Without reference to a larger dataset, the inference "I"m never sick because I played in the woods and ate weird stuff. If you get sick a lot, it's partially your fault because you didn't do that." could easily be replaced with "I'm never sick because I prayed to the right god every day. If you get sick a lot..."

I like WeWork quite a bit and they have a few locations in Seattle, but they also seemed way overstaffed. Other than putting sliced cucumbers in the water and answering the rare phone call, it's not clear why they would ever need more than 2-3 people working there at a time, but I always saw 6+ people there.

I also noticed the staff spent a lot of time hanging out on couches, playing ping pong, and chatting with their friends. Everyone was always really friendly and professional when I needed something and it contributed to a laid-back vibe, but that's not a good staffing model for a business that's running at scale and not for fun.

Yes, always take the private chat logs of a socially awkward guy in his early twenties trying to sound flippant/cool in front of his friend as a complete and eternal expression of someone's innermost character. How substantive, how insightful!

And in fairness, there are very few people from 18-25 who would not be classified as "dumb" when it comes to thinking through privacy, consequences, and boundaries.

Oh good, an anecdote. Those are always indicative of larger data sets, and definitely not meaningless and heavily biased.

It's pretty irrating to support stigmatizing/banning a drug that millions of people use and get therapeutic effects from based on a few unrelated anecdotes.

Failing to fully investigate allegations of human slavery while part of a large and underfunded bureaucracy !== being a human slaver, in terms of "level of fundamentally problematic cultural values."

I imagine you in a grocery store somewhere, railing against free samples. "You never should've given me a piece of sausage if you were going to start charging for them."

So what do we do with the waste that takes 10,000+ years to become safe, given that the average corporation has a lifespan of less than a hundred years?

I can confirm that's not and could never be a HIPAA violation. The information that Doctor X once ordered a blood test for John or Jane Doe with Result Z is totally fine. There's no non-HIPAA violating metadata that could make that information useful.

But isn't there a little bit of circular reasoning there? The median is the best statistic because it's the most common, and it's the most common statistic because it's the best.

I'm not advocating for any other single-number analysis presentation, nor do I think the median number is totally meaningless, but you're leaving a lot of data out in the name of creating a simple chart without asking if it's informative.

Anytime someone talks about the need for tort reform and capping non-economic medical malpractice damages, this is what they're advocating for.

The idea that a "cap on damages" number could be found to cover lifetime expenses incurred for all malpractice cases would be difficult to swallow even if the number was backed up by a fairly large data-set. It's totally absurd when you consider that these numbers are usually arbitrarily set by uninformed politicians and highly biased lobbyists.

The good news is that with V8 and ES2015, we now have a formalized, (fairly) fast, and tolerably buggy implementation of Half of Common Lisp. Oh yeah, and it runs natively on devices owned by literally billions of people.