The City of London has a system not too dissimilar.
Note: The City of London is not the same thing as London. It’s real weird.
4,479 karma · joined October 1, 2009
I used to work on making the robots that carry hundreds of humans around inside them safer. Which is another way of saying I worked on trains. Now I work elsewhere.
Note: The City of London is not the same thing as London. It’s real weird.
> Googling seems to suggest the differences are fairly minor however.
> I guess Airbus benefits in the A320 being a newer airframe than the 737 (which is ~50 years old now)?
The 737 is uniquely low to the ground among modern aircraft. (This was an advantage at airports without jetways high off the ground a long time ago.) Which means for every other model there’s plenty of space for new larger style engines under almost all of the existing planes. This makes airbus’s neo programs comparatively simple and reasonable for keeping the same type rating. The 737 doesn’t have the space, so they moved the engine location and came up with the MCAS as a workaround. It was clever, but unfortunately, too clever.
That's why we added the metal detectors. Reinforcing the cockpit doors may have been an okay response to the events of 9/11 and potentially would have been sufficient to prevent most major terrorist attacks that seek to use the plane itself as a weapon rather than merely destroying it. (Also people will generally gang up to attack hijackers now rather than just remaining calm and letting them fly the plane elsewhere. Which sufficiently changes the dynamic.)
I would argue Panda Express is spiritually similar in some ways.
Imagine how women feel.
Not really, for almost everyone who works there. I know a few exceptions. A rare few.
Look, I'm not arguing that we go string up all facebook engineers from the nearest tree. I'm merely saying that it is in fact quite reasonable to say that you shouldn't work for a company that is actively causing harm. And that there is "cool work" being done there does not obviate that.
And yes, good research is sometimes done in bad places. That isn't a justification for joining bad places so you can do good research. Your logic is all messed up there. It's better to instead do good research at a good place.
The simple matter is most of the people who work there, are there because of the relatively high compensation, and have plenty of other better options to do equally exciting work at more ethical organizations. But maybe not quite as well paid.
So. Let's stop sugar coating that.
Look, selling out is a thing humans do from time to time. Sometimes people are even in places where making that choice is totally justifiable. But don't tell me someone isn't doing it when they are. And you shouldn't let them tell you that either. Because if we don't let them tell us that, maybe they'll have more trouble telling themselves that, and honestly, that's what's really going to be important in the end.
Whenever I go to a country I spend some time on seat61 looking up the local train system. For a number of systems without websites, seat61 is the place where you can find the information about what trains go where before you get there and it’s just slowly (actually surprisingly quickly, all things considered) populated as people find out various pieces from ticket agents on site or physical boards posted at stations and email bits and pieces in.
You just have things do stuff and then toss pointers to threads on the other side of the workqueue. Most things I do this with I basically keep each thread in a different part of the pipeline and they pass the task to the next one. Sometimes this means each thread has a warm cache for the part of the task it's working on, assuming the majority of the working set of each task is more correlated with the stage of the pipeline than the specific data moving through it.
Managing your team is table stakes. Managing 360 isn’t a sign of lack of experience.
2) That's an argument for literally any possible metric. You could make an equally passionate argument that looking at and keeping track of free/busy times on calendars or soda consumption or how full the garbage cans are on the floor as an indication and early warning sign that something changed. It doesn't mean those are good things to track. Pay attention to the things that matter. Align whole teams and organizations around those things. Don't let them get distracted with metrics that don't matter.
3) Metrics are a double edged sword and influence behavior. If you're tracking the wrong things, you will get the wrong things.
None of the proposed metrics capture project health. Test coverage is the closest and that still isn’t great. (Unit tests are important but you can have 100% test coverage and a 0% working product. In fact, this is how every project begins before the first line of code is written.)
No one gives a damn how many pull requests happen or how many days apart they are.
1) Does the software work yet?
1a) How much of it works?
2) Does it do what we want?
2a) .... everytime? Less? How many 9s?
Report on the things that matter. Track the things that matter. Everything else is actively harmful and distracts your teams from doing what matters.
Also, when you ship the software you haven’t finished, you’ve begun. It is absolutely still useful to keep metrics on outcomes and track improving them over time. It is absolutely not “too late” and any planning that assumes software is done after you ship it is flawed. Features can become done, software never is.
Evaluating teams on outcomes will force them to collaborate to make something great. Evaluating teams on collaboration will just make teams do whatever it is you’re measuring.
(Full disclaimer: I am also currently working as one of those project managers you mentioned. If your project managers aren’t communicating clearly about how engineering impacts outcomes, find new project managers.)
Measure outcomes. Only outcomes. Try and make sure your metrics capture the real outcomes and not just what you see in a lab. This usually means you need to use field data to get that information.
2) Differential privacy
3) On device learning
4) Other techniques
Pick any or all of them. Explain what you’re doing and why. Don’t write platitudes about how you’re protecting people’s privacy and have built something privacy preserving if you haven’t used any privacy preserving technologies in your system.
Details would be welcome here. From the linked portal and whitepaper I just see a discussion about mostly their operations practices that may offer some protections against inadvertent data disclosure to third parties but nothing about how they preserve any of the users’ privacy from their own servers.