ef4

> It's pretty much a rite of passage here... most people have or will

That's pretty silly. Plenty of people working in startups never put themselves through that kind of BS.

There are at last two obvious strategies for avoiding the whole problem: (1) be a founder, (2) work in a more established tech company until you have the experience, personal network, and finances to intelligent pick a startup to work for.

This is describing two stages in the growth of programmer skill.

The researchers are at beginner stage and make classic beginner-stage mistakes. The developers are at intermediate stage, and they make classic intermediate-stage mistakes.

There is a later stage of people who can avoid both, but the author probably hasn't worked with anyone in that stage. Which is not surprising, because once you're that experienced there are big financial incentives to get out of academia.

Surprised nobody has already pointed out why the high traffic from Ashburn, VA is "hard to interpret".

That is the home of one of the biggest AWS data centers. It would be an obvious place to run bulk downloading of sci-hub content. It's also an easy place to host a VPN server, which users may be motivated to do if their ISPs are blocking sci-hub.

Fitting into a bulk launch with hundreds of other tiny craft makes the hardest part -- getting into low earth orbit -- relatively affordable. Once you're there, by being small and patient you can gradually lift your orbit using slow-and-steady methods like solar sails or electrodynamic tethers.

Yup, when your founders were fathered by Mars and suckled by a she-wolf, you can only go downhill from there.

The original comment was almost certainly about zoning regulations, not safety regulations. Obviously inspecting elevators so people don't plunge to their deaths is something we know how to do.

This architecture fails precisely when you need it the most. Any failure that breaks your server's ability to respond to requests in a timely fashion will also break it's ability to render this monitoring page.

Monitoring that can't give you actionable information during an outage is just pretty pictures.

> everything is open to them, source included

Certifiers typically don't review source code. They are operating at least two levels of abstraction away: they review documents that describe procedures that are supposed to ensure quality.

> If the code was open-sourced, don't expect to find lots of buffer overflow attack vectors

That is a big fat citation needed. Researchers working without access to source code have demonstrated multiple vulnerabilities in safety-critical medical devices. We have no way of knowing how many more they would find if they also had access to the source.

> will triple the traffic on the remaining through-street.

It is almost certainly less than triple, because of latent demand.

It does, and I think Montessori schools are great.

My one complaint is that a lot of Montessori teachers seem to have a blanket distaste for all electronics that lumps the good (Scratch and Logo) in with the bad (passively watching videos all day).

This is actually why so many organizations that are good at shipping other kinds of products suck at software: the distinction between "what to build" and "how to build it" is very squishy, and on a complex enough project the distinction is nonexistent.

A complete specification could just be executed. It is the program.

Yup. Most schools can't authentically do the things that Papert describes in Mindstorms. It goes against their very structure.

I don't blame the commercial vendors -- they are following the public-policy-directed money. I blame the schools for their culture of top-down control and conformity.

The total output of the world economy is about $13,000 worth of goods and services per person per year. That's not enough to provide even just education and healthcare up to a standard that would be considered remotely acceptable by people in the west.

(For comparison: the average public school student in the US costs $12,000 to educate. And yet plenty of people will say that even that is not enough.)

But the good news is if we don't fuck up, that number will continue to grow nonlinearly, just as it has for many decades. We will live to see it cross the point where it really is high enough to give everybody a comfortable life.

My bet for carbon-neutral aviation is not batteries, it's synthetic hydrocarbon fuels.

A factory that can make kerosene out of atmospheric carbon and electricity at a reasonable cost seems like a smaller stretch than an exotic new battery with orders of magnitude better energy density.

The explanation for that behavior is that instead of a cursor, emacs has a mark and a point. If you want to view something else without losing your place, you can leave the mark behind and then jump back.

The main benefit of this is that you get to find the "something else" quickly using the full suite of normal search and movement commands. It's also nice that you can jump through the stack of past marks, not just one.

Yeah, keeping them apart makes no sense. Definitely a single market.

If they belong apart, then so do Manhattan and Brooklyn.

In venture dollar terms, Boston is 3x bigger than Austin:

http://www.inc.com/associated-press/top-20-cities-for-tech-s...

That list excludes biotech, and Boston is one of the top biotech hubs, so I suspect that would boost it even higher.

I'm sure Sergei Brin, Larry Page, Jeff Bezos, and Jimmy Wales would be interested in hearing how their Montessori educations prevented them from competing in today's society.

That's simply not true. Per student spending in the US is among the highest in the world.

http://nces.ed.gov/programs/coe/indicator_cmd.asp

We just blow it on administration-heavy bureaucracies and demonstrably failed methods.

There are already commercial VR camera rigs that can do translation within a sphere big enough for head motion. The camera makers want to be able to make content for use with things like Gear VR.

We are on the cusp of solving the peripheral vision piece, because 360 degree camera rigs are getting cheap and popular. As soon as they can stream in realtime, you could have low-latency VR as if your head was really on top of the robot.

If anything it is pessimistic. It amounts to 7.2% total annual costs, which would include a jumbo mortgage rate, real estate taxes, and condo fees.

Well, there are 1,200 Harvard faculty, average effective annual salary $274,005.

600 MIT faculty, average effective annual salary $249,509.

900 Google employees, of which quite a few are at least Staff Software Engineers, which average $200,418 based on Glassdoor's estimates.

Then you also have Microsoft, Akamai, Facebook, Twitter, and Amazon, all of which have pay grades for individual contributor software engineers that go over $200k, and staffs in the hundreds of engineers.

We can thrown in many hundred MD PhDs at the world-class research hospitals: MGH, Brigham and Women's, Tufts Medical, etc.

My point is that the Boston/Camberville economy has many institutions that compete globally. They bring revenue from around the entire world and concentrate it here, and they compete vigorously with each other over the most qualified people.

People from elsewhere don't often appreciate the way that this city punches above its weight. Only New York and San Francisco are really in this league, and they are both much larger cities.

So yes, a few hundred new luxury condos are hardly a blip. The median home price in Cambridge is now $1.6 million. During the 2008 crisis when real estate was falling nearly everywhere, it merely leveled off here. It's not hard to see why, when you consider the value of having neighbors with endowments of $37 billion and $13 billion who form a global skill vortex.

In Boston & Cambridge there are quite a lot of tech people making $200k, even as individual contributors. And there are many two-job couples with household income over $300k.

A million dollar mortgage will cost $6000 per month, which is only 36% of $200k or 25% of $300k.

So yes, plenty of people can afford it.

> assuming this guy paid cash

There's no reason to assume that, although there _are_ a surprising amount of cash buyers around here.

> Anything that gets your heart rate somewhere between 110 and 140 beats per minute is enough.

There's a related point that people often get really wrong when they take up distance running: you can (and should!) actually run within that easy heart rate range. It may seem unbearably slow at first, but that just means you aren't ready yet to go faster.

When the goal is "faster pace at low effort", it's tempting to think you can train at faster pace + high effort and wait for the effort to fall. But that doesn't reliably work. You're better off training at low pace + low effort and wait for the pace to rise, holding low effort constant. Mostly this is because you (definitely) reduce the risk of getting hurt and (probably) don't waste a bunch of energy training the wrong metabolic pathways.

> Possibly, but I think you underestimate the effort required to create and distribute a toolchain that would become shared and standardized.

Not really, because we're already doing it. It's definitely hard, but it's also definitely possible.

ember-cli has unlocked major community-wide sharing that is otherwise not possible. Like a healthy addon ecosystem (https://emberobserver.com) where things are far more likely to _just work_.

And this has kicked off a virtuous cycle. Big engineering organizations with long-term vision are joining in.

> become their "standardized" toolchain.

That's exactly the problem: once you create _your own_ standardized toolchain, you are the only one who can document it, teach it, ensure other things are compatible with it, and integrate upstream upgrades. When a community works together to decide on a much broader set of standardization, that burden is shared and everybody goes faster. And developer knowledge is much more portable.

Nobody making iOS apps thinks it's smart or necessary to write their own XCode. People writing ambitious web apps shouldn't either. (And I say that as someone who finds XCode annoying -- it's _still_ better than trying to build it yourself from scratch for each app).

I'm going to go against the JS ecosystem grain and say that boilerplates are a total anti-pattern. And not because you should be doing this stuff by hand either, which is probably the second most popular answer.

"Boilerplate" implies copying a bunch of code into your project that should be library code but isn't because it's too poorly designed to have an API cleaner than "just fork it, YOLO". It's dramatically harder to update than something with well-designed API boundaries.

Your web app really isn't a unique snowflake. Shared, standardized toolchains are harder to build but once you do they're a dramatically better long-term investment.

In Javascript it's really just ember-cli that operates this way, which started in the Ember community and has now also been adopted by Angular.

> there will be no assimilation possible.

While I can't speak for Europe, in America there are approximately zero second-generation immigrants who aren't thoroughly Americanized.

That doesn't necessarily contradict the proverb. It's saying that somebody who starts out poor and then rises is still likely to have descendants who are poor. That is actually a statement that social classes are sticky.

I have seen some of the most excruciating fake-agile organizations you can imagine. I am 100% on board with efforts to criticize that.

But even the critics seem to get blinded by methodology. Methodology is only a second-order effect. The real issue is cultural and structural. If your culture is all about command and control, your agile methodologies will keep mysteriously not helping.

Debating methodology is quite beside the point. Some organizations are just structurally waterfall, deep in their bones, and can't be salvaged without massive social upheaval. You don't fix them by changing what people do, you fix them by changing how people define their relationships to the organization and each other.