i remember sometime recently that someone talked about how "design a webhook system" is a decent interview question for a infra/backend engineer because of how simple it is on the surface and how complex it can get underneath.
the interesting question is: what is the barrier we need to cross to trust LLMs with stuff like this? we'll probably cross the barrier but I'd have a hard time setting a true percentage success boundary
Sometimes the things that people say, says more about themselves than the thing they said.
If the only reason you give advice is predicated on the transactional value of that action, I think you've given up on acting ethically.
While to some extent we all are motivated by some abstract transactional value, I think immediately perceiving and reducing everything to a surivivalist, transactional mentality is an empty, cynical existence.
> If the only reason you give advice is predicated on the transactional value of that action, I think you've given up on acting ethically.
I said nothing of the sort.
Let me give a different example: I would not ride on a plane being flown remotely by a pilot on the ground. But I will ride on a plane with the pilots aboard. I do not necessarily believe the remote pilot would intentionally endanger me, but at the same time they are not facing mortal peril if they screw up. So I would need some other reason to trust them (maybe the remote pilot is a family member).
An AI has nothing to lose for misidentifying a mushroom, and I have my life to lose by trusting it. It can’t even fear for my life on my behalf.
Neither does a radiologist but yet we trust them to read a CT scan. Your relatives can sue if there is malpractice, but in practice, misreading happens, and nobody goes to jail for that.
Everything performs a particular task to the best of its ability and we all accept the level of risk we are willing to tolerate. If machines gain trust from enough sources, it will be accepted.
All I'm saying here is (if you walk back the necessity of having "skin in the game") -- all I'm saying here is, we regularly trust our lives to situations and people we expect to reasonably fulfill a given task. Most of us get in an elevator, or drive in a car, or even just buy food from a store.
> Neither does a radiologist but yet we trust them to read a CT scan.
I also don’t really have any other options in that regard, so there’s no real choice to make, other than getting a second opinion. I may not have a chance for a second opinion if I fully trust an AI on mushroom ID.
> Most of us get in an elevator, or drive in a car, or even just buy food from a store.
Of course, and I do too. Mostly because I have to and because there are many aspects of those risks that remain under my direct control. At times I have decided to take the stairs instead of the elevator.
I guess if you had a billion dollar you could assemble an ML team and fine-tune a frontier LLM specifically for that purpose through RL, and it could work better than your local pharmacologist, but I doubt anyone would bother doing that.
So it will probably come long after airplanes actually.
Sorry, wasn't specific - and yeah mostly stuff like Pacaso, timeshares, and REITs all deincentivize the creation of low income housing and decrease affordability. This is mostly a personal view, but second home ownership should come with serious costs.
Middle Management doesn't really control the purse strings. They can certainly lobby for it and they do. In most companies budget's are allocated at the executive level to each of the departments.
They are positioned critically as information transmitters between high level and low level. As such they are conveniently situated to shape the narrative to flatter themselves, in both directions. No wonder then that so many middle managers blame their underlings and insist they would be good at their job except for the meddling engineers. So of course execs would hear this and think "middle managers deserve more money, engineers need to improve their performance so let's dangle bonuses but not raise their salaries".
I don't think blaming your underlyings is a good strategy even for the mediocre middle manager. That might make work if there is a re-org and your entire org is changed and you inherit a new one.
However, your org is typically the one that you hired, trained, and grew. So, if you are saying that you failed to make the commitments that you promised because your org sucks, then you are just telling everybody that not only did you not fail to meet your commitment you are also not good at building an org.
You can't blame your underlings, if you blame your underlings then people aren't going to think you are doing a good job. If you have any character you will take responsibility and admit that you failed. Then you will work with others to fix the issue, it's not the end of the world.
Now, if you really want to deflect blame, there are many better places to deflect it. You can blame
1. The business/sales/product/external factors ... whatever, they imposed a deadline that was unrealistic. You were brought in too late and you did the best to salvage the situation.
2. A parallel org that you had an external dependency. Bonus points if you compete for budget with this org. If you can successfully deflect blame to those yahoos in the parallel org, then maybe you'll capture some of their budget and get more head count to grow your org. Yes, you want to grow your org. This is another reason why blaming your underlings is a bad idea. Why would you get more budget to grow your org, if you've done a bad job at hiring and training your current org.
In conclusion there are a bunch of bad middle managers out there, and it might be widely thought that blaming the underlings and ICs is a good move. But it's a terrible move for both selfish and selfless reasons. Even bad managers will know that it's a terrible move.
I think it's more that managers seek to maximize their career advantage by having the work done according to "their idea". Then the engineer is just a commodity resource implementing what they are told. And to the degree that this added constraint on the engineer does not fit with their experience or with what would work best (or at all), the engineer's productivity is lower. This is addressed by adding more engineers.
reply