datashovel

Not particularly directed at you, but it's certainly a dichotomy in that managers are the only ones responsible for "rethinking another's employment". I'm curious to know how often you would consider reflecting on / rethinking your own employment?

I say this because I was recently hired to work on a project where managers are obviously the only ones responsible for deciding how a developer should function within the organization. It is obvious the state of the project is anything but healthy at the moment. Attrition rates are astronomical and the code is beyond ugly in a lot of cases.

I wonder if it's that fewer females prefer STEM, or is it that more men are doing things they would prefer not to?

My guess is the doctors who don't spend extra time trying to solve the case probably shouldn't be paid for the time separately as is being suggested here.

It would appear to me that they have already lost the innate curiosity (if they ever had it) that made them want to become doctors in the first place.

Or they're not confident enough in their ability. Doctors are already paid substantially compared to most other professions, so for them to not put in extra time on the exceptional cases makes me feel they probably feel entitled. Too much so to have any impact on the rare cases.

The doctors who could realistically find the solution are the ones who will likely want to take the case on for free.

A great example of why I think the entire core ecosystem of the web is backwards.

I've had a number of comments here on HN related to this. Imagine this same scenario, except instead of the User being in charge of deciding which engine is used to render a website / webapp, the Developer is making that choice. What would a developer need to do if they were in control of which "engine" rendered their website on the user's computer?

Instead of being at the mercy of Google / Chrome, the developer of said site could simply change their HTTP Header "X-BrowserEngine" or something like this, and the client's computer would know how to (a) download the new engine if it's not on the computer already (b) sandbox the new engine (c) run the site / app in said engine.

I've called this idea the "Meta Browser" in the past. It's a concept for an app that sandboxes and runs sites on different browser engines seamlessly. The user experience is more or less as though they're continuing to use a single app to browse the web, but behind the scenes could be any number of custom engines rendering the content.

I don't get the impression you understood what I said.

Thank you for the post, and finding and reading my comment. It's extremely thought provoking, and inspiring to know that these conversations are happening.

The "new tab type" idea sounds like it fits. In a way I see the "browser renaissance", that I think (hope) is going to happen within the next decade, is also more than just about sandboxing browser engines. When you follow the line of thought further I think the browser core becomes supported by a set of decoupled libraries which will be reused by different browser engines.

I think the toughest hurdle to this kind of thing is probably abstracting away the details, but still making it possible for end users to make educated / granular decisions so that they can understand more or less what the security implications of certain actions / settings would be. I imagine those 2 things (user knowledge and need for abstraction / shielding users from themselves) will eventually converge to a happy middle ground. But for starters could (for the least knowledgeable users) probably be something like providing a handful of options like "extra safe", "safe", "maybe trouble", "danger zone".

Though to be fair "danger zone" would probably mean something different than it historically would, since the "shell app / meta-browser" hosting the browser engines in theory would prevent an application from escaping its sandbox, but instead could allow an app, within the confines of the user's settings, to do things the user didn't expect.

In a nutshell. It would only be a simple shell, with extremely minimal API (for user settings, etc), which could sandbox browser engines. This (a) makes "switching between browsers" a seamless experience to the end user, (b) makes the development experience much more friendly to the developer [since they're developing for their browser engine of choice].

  "...unless you work at Google or Microsoft you can’t meaningfully impact the technical direction of the web"

I think this is a great argument for why we need a (for lack of a better name) "meta-browser". An application on the user's machine that contains and runs browsers. Then flip the control to the developer. If I'm only going to design for [name of obscure but super secure browser], my success doesn't have to be dictated by the fact that 99.99% of users didn't originally open my browser of choice. If they come across a page only supported by this little-known browser, they are prompted that they can install it, or they can decide to move on to the next website if the developers didn't write any fallback.

This doesn't just ensure the web can remain open, but makes the whole architecture (the web itself) an open question and allows all aspects of "the web" to evolve more smoothly.

I had an idea that I was going to turn into a side project related to this, but find myself too busy to work on it at the moment.

Imagine a simple ML engine that would allow an artist to pipe in a selection of "art", whether that is visual or aural. The engine would then build a network on top of that data. The next step would be for the ML engine to build pieces "inspired" by the artist's selections which would, in theory, inspire the artist.

I've seen a handful of projects posted that are similar to this, but have yet to take the step of allowing the user to select which pieces of music / art the engine should use for inspiration.

Of all the professions that exist today, I think artists have a special distinction in that they are probably some of the only people who will be immune to the possibility of ML "taking their jobs".

Generally speaking. Given that DynamoDB is a NoSQL database service, I'm not certain that moving larger clients to their own dedicated AWS resources should cause too many negative side effects. Especially ones who are so large they're causing scalability issues.