We were behind schedule and had, I think, three separately implemented/maintained/deployed services that needed to be able to access the internet to do their work. Rather than implementing the intended auth mechanism in each service, writing tests for it, going through code review, and redeploying, I instead added nginx to the base Docker image they all used, configured them to send requests to that nginx instead of as normal, and made that nginx instance man-in-the-middle our own services to attach a hardcoded HTTP header with the right creds.

I man-in-the-middled my own services as a hack - dumb but it worked. It was meant as a quick hack but stayed for I think a couple years. It did end up being eventually being the source of an outage that took a week to diagnose, but that's a different story.

Years ago I was working on developing a new cloud native service. The particular microservice I was working on had to call out to multiple other services, depending on the user parameters. Java 8 had just come out and I implemented what I thought was an elegant way to spin up threads to make those downstream requests and then combine the results using these fancy new Java 8 stream APIs.

I realized at some point that there was a case where the user would want none of those downstream features, in which case my implementation would spin up a thread that would immediately exit because there was nothing to do. I spent a couple days trying to maintain (what I saw as) the elegance of the implementation while also trying to optimize this case to make it not create threads for no reason.

After a couple days I realized that I was spending my time to try to make the system sometimes do nothing. When I phrased it that way to myself, I had no problem moving on to more pressing issues - the implementation stayed as is because it worked and was easy to read/understand/maintain.

To this day, I avoid the trap of "sometimes make the system do nothing". One day, that performance optimization will be necessary, but that day has not yet arrived in the ~7 years since then.

Someone who has created their own worth saying that there are people being paid salaries without creating enough value to justify said salaries is not tone deaf. I bet most billionaires - at the very least, the self made ones, which is most of them in the US - have a better sense of value than most other people.

The comment isn’t about making too much money. It’s about being given too much money in exchange for what is produced.

As someone that has done cloud development at a giant corporation that offers public cloud, I think that this tool absolutely has an enterprise use case. In my particular experience at my particular (tens of billion dollars plus yearly revenue) previous employer, our SREs would have massively benefitted from having this. I’ve been woken up at 3am while on call for L3 support just to step out SREs through tools we wrote to help them do their jobs that we failed to adequately train them on and/or that they didn’t have the bandwidth to absorb due to the volume of services they were tasked to support.

From that point of view, supporting macOS first is the right move in my opinion because at enterprises developers are standardizing on macOS, and so are SREs.

This can solve a real pain point. Best of luck! And if it may happen to be helpful, let me know if you’d like to chat about this use case in more detail.

AI algorithms _need_ bias to work. This is the bias-variance trade off: https://en.m.wikipedia.org/wiki/Bias–variance_tradeoff

The problem is having the _correct_ bias. If there are physiological differences in a disease between men and women and you have a good dataset, the bias in that dataset is the bias of “people with this disease”. If there is no such well-balanced dataset, what is being revealed is a pre-existing harmful bias in the medicinal field of sample bias in studies.

If anything, we should be thankful that the algorithms used in AI, based on statistical theory that has carefully been developed over decades to be objective, is revealing these problems in the datasets we have been using to frame our understanding of real issues.

Next up, the hard part: eliminating our dataset biases and letting statistical learning theory and friends do what they have been designed to do and can do well.

I’ve repeated it that exercise with junior engineers to great effect. Some catch on over time and start intuitively considering the trade offs of a few reasonable solutions to a problem; some don’t.

I never reflected on what he was doing there; thanks.

This is not true. A _lot_ of AI applications use algorithms such as logistic regression or random forests and don’t need GPUs - partly, of course, because GPUs are so expensive and these approaches are good enough (or more than good enough) for many applications.

The idea is good, in my opinion, and will develop over time to become more concrete, most likely.

I generally want to dedicate my efforts to long term betterment of humanity, rather than “we make the world better by making a mobile app for dog walkers” sort of thing, so this position is attractive to me. However, this “full stack” position mentions only JavaScript and Rails as required experience.

Is your entire stack Rails and JavaScript? That turns me off entirely (and makes me unqualified).

From TFA.

https://en.wikipedia.org/wiki/Simpson%27s_paradox