Just this guy, you know?
Yeah, I am. But more bottlenecked on cost and flexibility (ability to shift from use case to use case) than directly on capability.
Neither. Robots are bottlenecked on ROI, and the fact that humans remain massively cheaper than robots for many jobs, both on average and on the current margins.
Software has a pretty short ramp to profitability - even when it's not obvious exactly how it'll pay off, there are so many applications that simply couldn't be done before that something is going to work.
Hardware has a longer ramp, and needs more clarity of payback before starting.
Also, software benefits from generality much more than hardware does. The tradeoffs in complexity and maintenance for software get overwhelmed by more use cases. Those same tradeoffs in hardware make it vulnerable on all fronts to purpose-built machinery that does fewer jobs, but does them much more cheaply or reliably.
I like thinking about ways to use and get value out of our voting system, but I pretty strongly suspect there's no low-hanging fruit like this. It's too easy to vote, strong votes overwhelm normal ones, and the bias against downvotes gets in the way of interesting disagreements.
I do wish they'd show number of voters in addition to total score, but I don't think anything more complicated than that is likely to work.
I've done a LOT of interviewing for all levels of software engineering, at big and small companies, and it's simply wrong to say it's all leetcode-style ranking. Short-duration coding challenges are a big part of most interview processes, but it's not graded the same way as competitions are. (at the better employers, at least) It's not about the right answer, it's about the explanation, follow-up questions, and understanding of the algorithm and code. And perhaps a bit about the right answer and the fluency of coding, but that's more pass/fail than requiring tons of practice. I routinely give hints to get the candidate on the right path to remember/figure out a working solution.
It's disturbing just how many applicants can get to an interview without having done minimal practice on those sites (or coding regularly in their previous job). It's a necessary part of the interview, just to weed out the non-starters. For more senior roles, the design discussions and tech dives into resume topics ("I see you've worked with distributed caching - tell me how you managed varying invalidation needs.") are more useful for final decisions.
More importantly, interview and hiring is a pretty small part of the career impact of a developer. In-role impact is also never 100% meritocratic, but at a lot of places is pretty good.
I have no clue if young attorneys are tested by actually knowing what cites to start with or how to prepare for a relevant case, but I kind of hope they are.
TL;DR leetcode-style interview coding is (or should be, if done well) satisficing, not ranking. Being competent at it is just as good (possibly better, if it lets you show other strengths) as being great at it.
Yeah, I suspect we mostly agree, and I apologize for looking to find points of contention.
The majority of such complaints that do well on LW are in reference to users or discussions on LW or related groups. Not always a specific individual, but often a specific set of posts or comment patterns. There are exceptions, where someone complains about some ideas in oped or twitter, but those tend to get downvoted unless they're truly pervasive.
And even so, if they're not steelmanning the opposition, or pointing out some interesting pattern or reasoning for the disagreement, they tend to do poorly here.
I certainly wouldn't bet against that prediction. Modern (say, since 1980) finance definitely seems to be a series of conspiracies to engineer public risks for private profit. In theory, every transaction has two parties, so if someone loses a bunch of value, someone else gained it. In the case of inflation changes, those gains went to debtors, especially to long-term debtors who didn't immediately have to refinance at higher rates. The Treasury is one of them - their long-dated bonds went way down in value, but they didn't have to give back any of the purchase price.
Unfortunately, guarantees create a ratchet effect - there's no clawback for past years' bonuses, dividends, or un-justified expenses, so the taxpayers eventually end up paying for all the value extracted.
I wish we could just do away with the guarantees - have the fed offer retail post-office-like banking services, fee based and at a loss, with strong guarantees and no profit motive nor ability to seek risk/alpha. And un-insured (or partly-insured) higher-paying investment collectives, with some spread between interest and services to depositors and return on investments.
It won't happen, of course, until the US government really comes to grip with it's debt problem, and the firehose of money to the private sector has to dry up.
Exceptioncraft is seeking results within a set of constraints that don't make the path to those results obvious. Engineering and gaming are just other words for understanding the constraints deeply enough to find the paths to desired (by the engineer) results.
Powered heavier-than-air flight is gaming the rules of physics, utilizing non-obvious aerodynamic properties to overcome gravity. Using hold-to-maturity accounting to bypass rules on risk/capitalization is financial engineering in search of profits.
The words you choose are political, with embedded intentional beliefs, not definitional and objective about the actions themselves.
"arbitrary" is doing a lot of work here. If it's agent-chosen specificity/completeness, that IS ALREADY a game, with exceptioncrafting just a move within in it. If the arbitrariness is randomly or "naturally" distributed, replace "gamability" with "engineering" and "exceptioncraft" with "craft".
Recognizing adversarial (including semi-cooperative and mixed sequences of cooperative/adversarial) situations is a big modeling hole in many rationalists' worldviews.
You're incorrect to put zeros in the right column. Following an ought that is incorrect is a cost. And then you need to factor in probabilities and quantified payouts to decide what to optimize.