I learned about open source and Linux; in time that went from a new hobby to a change of direction in my career.

I learned about startups, and figured I should try since I'm also a genius who can build a great product. It took quite a bit of money and time lost to convince me otherwise.

I found out about the online CS Masters program at Georgia Tech and did that a few years ago, this led to moving countries and getting a job doing AI.

This is why the article read fairly false to me, not that there wasn't the odd nugget of value, but coming up with a new MVT, is just adding to the confusion.

You did, but your quote comes directly after he said:

"Once you’ve finally tested enough hypotheses to have more confidence about your product viability, then go to the next steps:"

The MVP is the next step and it distinctly different from what he calls an MTP.

An MTP is not a useable product, it doesn't have a login, stack or maybe any code at all.

If you're looking at the highest fidelity level D simulators, the instruments and controls in the cockpit are either the same parts as the aircraft, or functionally identical (but cheaper).

> If you simulated a broken AoA sensor, would the simulated plane behave similar to the real plane? Would the MCAS system have the same bugs in the simulator as in the one in the real aircraft?

One of the big costs in building a simulator is buying the data package from the aircraft manufacturer, with the aero model and details of system internals, things like electrical and hydraulic schematics. Sim makers build a software model of these internals at a pretty low level. For the most part, if you introduce a fault in some part of the system it will behave the right way as an emerging property, not because you're forcing the system to have the right outputs.

Some software components from the aircraft get installed on the simulator with the same hardware platform from the aircraft, others get run as executables on the simulator's computers, and others get re-implemented from scratch (lots of FORTRAN and C).

That kind of detail comes into play when the instructors introduce multiple failures at the same time - pilots have to take corrective actions to make the faults go away or manage them - if you don't model the systems at a pretty low level you'll never high fidelity.

> Can you try new scenarios in a simulator, or can you just try scenarios that the simulator was designed to run?

There is a list of malfunctions available to the instructor, who runs the session from the back of the "cockpit" on touch panels. For the most part, these malfunctions cover failures that are anticipated by the aircraft manufacturers, and the corrective actions / system behavior are well understood. Each fault is tested to make sure it works properly. You don't go and fail some random component in the system.

When an important failure happens in the real aircraft, it might get added as a training scenario to simulators already in operation.

I always wondered if they did that, something akin to fuzzing tests in SW. Wouldn't it be useful to detect unexpected situations that'd be catastrophic? Or the benefits from it wouldn't outweigh the cost/time loss?

Also, imagine you're an airline with thousands of pilots and dozens of instructors: you're running an airline and a school at the same time. You need to build a curriculum of training and testing that will standardize your pilots. There's room for thinking outside the box but not too much.

Well Boeing certainly doesn't fuzz their software as evidenced by the major bugs in the 737 NG and 747-400's flight displays. Both had bugs that would black out all instruments under specific conditions. That got fixed fairly quickly on the 747, but apparently Boeing didn't learn their lesson with the NG.

The bug blacked out all six display units. What other instruments are you thinking of?

For example, I ran across this gem recently:

"In the same way as people who've been to a concert carry about with them the melody and haunting quality of pieces they've just heard, interfering with their thinking and preventing them from concentrating on anything serious, so the talk of snobs and parasites sticks in our ears long after we've heard it. And it's far from easy to eradicate these haunting notes from the memory; they stay with us, lasting on and on, coming back to us every so often."

I would never connect those two ideas. It's beautiful. The writer is Seneca, a Roman who was born around the time of Christ. He was idealistic yet street-smart, lofty though sometimes petty, and very opinionated. I enjoyed walking a mile in his sandals.

"You’ve got a lot of learning to do - minimum nine months - before you even get to working with me."

Such an unpleasant disposition. People who demand humility of others could use a bit of more of it.

Getting in to their OMSCS program is far from guaranteed - they have lots of older applicants and they evaluate each on its own merits.

The best thing they've done is structure the entire course around building a web database app. They provide a real-world description of what's needed, and break it down into big chunks that are synchronized to the content of the course's three exams. This gives a clear over-arching goal to the class. For people who have never build web db apps, they will really feel like they've accomplished something by the end.

You may find that successful parents who balance two or more kids with full-time jobs and some measure of sanity will not have the interest or energy to put into such a project. The more enlightened among them may also hold their tongues, having realized that what works for their kids is not universal.

Of course I forget all the details, that's what books are for. It does seems more effective than just trying to map what I know from other languages into the new one.