m0dc

I love Ember - and one of the best things about it is its emphasis on convention over configuration. React is the exact opposite. While it's an amazing library, it only makes up one part of a front-end stack, which causes everyone to waste tons of time deciding on what the other parts should be.

A set of sane, accepted defaults would help the community tremendously. Personally, I'm hopeful that that's what React/Redux/Webpack turns out to be.

The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and micro-libs are introduced every couple of months.

I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.

Sounds like an opportunity to sell some roadside assistance (either from Tesla directly, or from a third party that will pick up the slack otherwise).

Biases come into play even when judging supposedly objective things like technical merit. In a startup environment where every new hire has a huge impact on the outcome of the company, the subconsciously perceived 'safe bet' will always be to favor the person who talks and acts the most like a young Zuckerberg.

Being able to view source is a design goal of WebAssembly, according to [0].

If an organization doesn't want you reading their JS, there are already plenty of tools to make it nearly impossible as-is. Do you really learn anything from reading minified, obfuscated code? At some point you're just reverse engineering, which is obviously still possible with WebAssembly.

'Open source by default' is a problem to be solved at a cultural level, not a technical one.

[0] https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...

I think that last sentence is spot on. It's an extension of the American Dream: "those who deserve reward will be rewarded." The problem is that many people also believe its insidious contrapositive: "those who are punished are deserving of punishment." This leads to a constant reinforcement of the status quo.

At what point does it make sense for Google-likes to educate their own workforce, skipping the university model entirely? They've already created a B.A. substitute by sponsoring Udacity's nanodegree programs, and now they're working on the other end of the spectrum with a masters / PhD equivalent.

Assume these companies have an excellent selection process (obviously a big 'if'). Could they pluck bright students straight out of high school, send them to two years of specialized super-accelerated Google School, and have a molded and productive employee come out the other side? They have the resources and the expertise, and there's only so many Stanford grads each year.

A workforce of bootcamp devs sounds unpleasant - but with skyrocketing tuition costs, and ever-increasing demand for 'only the best' talent at these companies, there's probably a point at which it makes economic sense for both employer and employee.

The professor's attitude that you're talking about is perfectly valid - as is your own (opposite) attitude. The tension is a result of modern universities being dual-purpose.

On one hand, the university is supposed to be a crucible where difficult problems are confronted, hard work is accomplished by making sacrifices, and mature professionals are forged through years of dedicated effort. On the other hand, it's also the students' home and living space for several years, and it should provide the comfortable and low-stress lifestyle that most adults need to be mentally healthy.

Inflated tuition costs and degree commoditization have lead universities to adopt a "customer is always right" attitude, bringing the two purposes directly in contention in an attempt to please everyone.

The solution is probably somewhere in between. There's a place for puppy rooms, and a place for strict educational standards - but the two shouldn't mix.

Memorizing documentation and obscure bash tricks is the last thing a developer should be expected to do.

Even reading the documentation (in its 'raw' form) can sometimes be harmful, because you miss out on the contextual information that a search engine provides. Especially if you're new to a language or domain, it's easy to fall victim to the XY problem [0] - you comb the docs trying to implement your perceived solution, when a simple Google search or Stack Overflow answer would give you the solution you're really looking for in seconds.

If something is important to you, you'll absorb it over time anyways.

[0] http://www.perlmonks.org/?node=XY+Problem

This is great! What's everyone's strategy?

I was able to get 20 by obsessively combining small tiles first, but just barely. The biggest problem is the rows that calcify and lock together if you don't actively try and break bonds.

A relevant quote from Chris Inglis, former NSA Deputy Director:

"If we were to score cybersecurity the way we score soccer, the tally would be 462-456 twenty minutes into the game."