Years ago my team was tasked with greenfield dev of a cloud native app while the platform/infrastructure was also evolving. We worked nights and weekends to get it done on time only to find out at the last second that the platform team had enforced controls on internal services being able to access the internet, requiring authentication to do so. This was news to us.
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.
Not quite what was asked but a few of the stories here reminded me of this.
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.
Nobody becomes a billionaire off salary. Generally speaking, billionaires come to be billionaires because they created something that has value in the billions.
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.
I see a lot of negativity here, and I do agree about the daily ping which I see you’re removing, which I think is a good move.
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.
That’s a different problem. “Fix toxic environments that keep certain types of people out of an honest line of work” is a good problem to solve. That is not the same as “let’s increase the number of people of a certain demographic within an industry”, in and of itself, taken entirely on its own.
As a fellow practitioner, I entirely agree. Actually, reading this article made something click for me regarding the oft discussed and denigrated “bias in AI” always brought up in discussions of the “ethics of AI”: there is no bias problem in the algorithms of AI.
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.
This comment made me realize what my mentor did years ago. He would have the entire team list all possible solutions to a problem, including the obviously bad ones, then have us whittle down the list based on pros and cons of each until we reached consensus on what to do. It was a teaching exercise and I didn’t realize it.
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.
> running anything related to AI involves GPU instances
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.
Indeed, often legal language is left as open to interpretation when new so that the manifestation of reality can polish it over time. This is a new venture; being imprecise about “long-term” now is, in my interpretation, the right move, because it should be refined over time based on how this all plays out.
The idea is good, in my opinion, and will develop over time to become more concrete, most likely.
I’m a senior software engineer and software architect at a tech giant that has been lucky to have the experience of launching a new product twice, operationally treating it as a well funded startup and growing it to multimillion dollar revenue while instilling development practices that ensure quality while also being adaptive to change. I read the job description for the senior software engineer posting, and at first thought I might be a good candidate.
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).
> Sadly, the changes also include a significant reduction in our workforce by approximately 250 people. These are individuals of exceptional professional and personal caliber who have made outstanding contributions to who we are today. To each of them, I extend my heartfelt thanks and deepest regrets that we have come to this point.
The goal of the shelter in place is to “flatten the curve” so that the medical system is not overloaded. According to that article, they believed that their medical system could handle the load and has.
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.