Kamq

Their post said that load growth had a mitigating effect on prices. Not letting the data centers come online would, presumably, result in higher prices.

That seems slightly weird, but that sounds like there's some large fixed costs that they can spread over the entire subscriber base, so the extra data centers are picking up some of those fixed costs.

I just read what it produces.

I don't think that's average right now.

Let's not pretend Microsoft has a monopoly on idiocy in the software world.

Entirely fair, but let's not pretend the situation is symmetrical. Canonical doesn't have monopoly on the linux or broader *nix world the same way that Microsoft has on the Windows world.

The government.

You'd have to prove that the CEO knew that it would hurt the company and still did it or that it's so ridiculously negligent that any sane person should have known.

This is BS. A shareholder lawsuit against the CEO/board/executives for investing in the employees in the hope of long term profits would never succeed. The idea of a fiduciary duty doesn't mean that. It means the CEO can't take actions that intentionally hurt the company.

And there are very few large public companies with active enough investors to oust a CEO over this, and even fewer that have both active and activist investors that would be interested in such a thing.

This is true whether an AI wrote the code or a co-worker

I agree. I just don't think code reviews are as load bearing as everyone seems to think. They're important, but not nearly enough.

My "actual job" isn't to write code, but to solve problems.

Yes, and there's often a benefit to having a human have an understanding of the concrete details of the system when you're trying to solve problems.

That has increasingly shifted to "just" reviewing code

It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.

Oh come on. They're obviously using the word "science" in this context as a shorthand for the institutions and processes we've set up to do research. Mostly because that's too many words for a title and nobody has come up with a catchy name that's not politically coded. It's also pretty normal usage of the word out in the wild.

This should be the only entity that's approved to have nuclear weapons.

This speaks like someone who has never been outside of a heavily bureaucratized regime. People don't get "approval" for things, they just do them.

Just because I'm a middle aged male I see trucks, and beer, and football advertisements all day long

Well, yeah. Those companies will pay to send their ad to all middle aged men. Those companies could slice and dice more to get better demographics, but they don't think it's worth it.

Google's business isn't to slice and dice the demographics to show you better ads. It's to slice and dice the demographics in any way that the advertisers will pay for.

Because the people who are willing to pay money are, ultimately, the customers.

Go's simplifications often introduce complexities elsewhere

It does occasionally, although I'll push back on the "often". Go's simplifications allow most of the codebase to be... well... simple.

This does come at the cost of some complexity on the edge cases. That's a trade off I'm perfectly willing to make. The weird parts being complex is something I'm willing to accept in exchange for the normal parts being simple, as opposed to constantly dealing with a higher amount of complexity to make the edge cases easier.

There's no free lunch here

This I'll agree with as well. The lunch is not free, but it's very reasonably priced (like one of those hole in the wall restaurants that serves food way too good for what you pay for it).

the compromises Go makes to achieve its outcomes have shown themselves to be error-prone in ways that were entirely predictable at design time.

I also agree here, although I see this as a benefit. The things that are error prone are clear enough that they can be seen at design time. There's no free lunch here either, something has to be error prone, and I like the trade offs that go has made on which parts are error prone. Adding significant complexity to reduce those error prone places has, in my experience, just increased the surface area of the error prone sections of other languages.

Could you make the case that some other spot in design space is a better trade-off? Absolutely, especially for a particular problem. But this spot seems to work really well for ~95% of things.

Equal in voting rights. Gerrymandering has been perfected by Republicans. Through that they manage to dilute votes of the opposition.

This thread is talking about the Senate. The senate isn't gerrymandered. Both senators are state-wide races.

If you want to view it that way, you can view the senate as "pre-gerrymandered". But the last time that was an option was in 1959, and both of those are just "the entire area the US owned, but wasn't a state yet. To get senate gerrymandering, you have to go back to 1912 and the admission of New Mexico/Arizona.

And yet so many of them kinda rule the world by running the biggest corporations in the world.

Have you looked at the state of the world recently?

Imagine not being able to get a shitty fast food job because ... Or just moved to the US and speak too weird and don't have anyone to vouch for you.

You've obviously never worked food.

That’s incredible! The capability of an AI model is approximately junior level in the fields I’ve tested it in (programming, law, philosophy, neuroscience). If you’d don’t see any possible uses for the technology, keep thinking about it.

It is absolutely incredible from a technical perspective, but your next statement does not follow.

In a lot of (most?) fields, juniors are negative ROI, and their main value is that they will eventually be seniors. If AI isn't on the road to that, then the majority of the hype has been lies, and it's negative value for a lot of fields. That changes AI from a transformative technology to an email summarizer for a lot of people.

Then your industry is atypical in the type of applicants that you are getting

Based on the quality of candidates that get through at other companies, I'm guessing our problem isn't atypical. Or at least, good devs often aren't getting through their pipelines at all. It's possible that in trying to reduce the false positive rate, they screened out all of the actual positives, but that doesn't paint a good picture of the industry.

How do you scale interviewing everyone if you don’t pre screen?

We do pre-screen. The fact that they haven't encountered a tricky algorithm before isn't a problem. For ones where the syntax is valid, a dev at my company does a code review on it.

It’s absolutely fantastic at filtering the lower 95% of applicants because they will _never_ be able to pass.

This is the part I disagree with. It hasn't been true for years. Anyone with the free version of ChatGPT can pass a hacker rank today.

but that doesn’t matter to the outcome of your company

It does for mine, because we've hired all of the good developers that get through the process you're describing and it isn't enough. We actively moved away from what you're describing and turned the interview into a 2-3 hour pair programming session where the person completes a mini version of a ticket.

This has much more predictive power than what you're describing.

Leetcode is bad, but it’s bad in the sense that it errs too heavily on filtering out false negatives

But, it doesn't. It filters for something orthogonal to development, which is ability to obsess over clever algorithmic solutions. Ok, well my company does HackerRank instead of LeetCode, maybe LeetCode is magically better, but I'm not seeing anything that tells me someone who grinds LeetCode is actually going to be useful on my team.

Look, you want an idiot check to make sure someone is actually able to code, fine. That's probably a good idea. But the number of stories on here about people being turned away because they hadn't run into a particular tricky algorithm problem is concerning.

Giving Tim the benefit of the doubt in this story, it still holds true that for every extraordinary and invisible superstar like Tim there are 99 under-performers who are indistinguishable from him.

But they aren't indistinguishable. The author of the blog post was perfectly able to distinguish them. That's my point. There are plenty of ways to be able to distinguish them, this metric just isn't one of them. Because it's a bad metric.

It may not be legible to the higher ups, but good lower level managers have no problem distinguishing good unconventional people, and under-performers.

We need to empathise with our managers and the processes in our organisations to understand their purpose and how they came to be.

I do empathize with the managers, at least the lower level ones. That's why I advocated for putting them in complete control and giving them unilateral firing privileges and increasing their pay.

the best organisations that I’ve worked with used metrics in a very effective way (mostly in start ups). The worst did too.

You're really making it sound like metrics (at least as traditionally practiced in software) are orthogonal to being a good organization. If that's true, we might want to re-think how much time we spend on them and how much money we spend capturing them.

Now, if you want to use profit, adoption, or user satisfaction as metrics, I'd love to talk about that, but I've seen nothing in my experience in the corporate world that tells me that the way we're currently using them is even net positive value.

So on one hand, you're kinda right. HN is filled with exaggeration (imo often justified) from people venting because they have to deal with the bad parts of this system all day. That seems natural in a dev filled space.

But I don't think your comment is fair.

We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer efficiency with a Leetcode or whiteboard problem.

Because this is a bad way to judge engineers. Or, rather, it's a great way if they don't know how to invert a binary tree. Most of the job is to figure out something you don't know yet and do it. Giving an engineer a random wikipedia page on an obscure algorithm and having them implement it is a great interview tactic. Having them regurgitate something common is bad, there will be a function for it somewhere, and you just need to call it.

Meanwhile in the real world, hordes of awful engineers deliver no story points, because they in fact, do nothing and only waste time and lowers morale.

I agree with you on this one. Those people need to be fired. That doesn't mean story points are a good metric, often 90% of long term value can come from the kind of people who are like Tim, and losing them can destroy projects. Just because something bad is happening, it doesn't justify killing 90% of value for a team.

The only thing I've seen that works is to give team managers more discretion and rigorously fire managers who regularly create poor preforming teams (you often have to bump manager pay for this, that's fine, good managers are worth their weight in gold).

Meanwhile in the real world, each job opportunity has thousands of applicants who can barely write a for loop. Leetcode and whiteboards filter these people out effectively every day.

You do need to filter for people that can code. That doesn't mean filtering for inverting binary trees is a good idea. Having people submit code samples that they're proud of is a much better approach for a first filter.

Meanwhile in the real world, metrics on delivery, features and bugs drive company growth and success for those companies that employ them.

Bullshit. Basically all companies use metrics, and most companies are garbage at delivering useful software. A company being years behind and a million over budget on a software project, and eventually delivering something people don't want is so cliche that it's expected. And these companies regularly get out competed by small teams using 1% of the resources, as long as the small teams give half of a shit. In fact, if you want my metric for team success, what percentage of the team actually cares is a good one.

You're proposing a solution with a <20% success rate. Don't act like it's a gold standard that drives business value to new heights. With the system as it is today, most companies would be better off getting out of software and having a third party do it for them.

Rust's ? operator - effective and ergonomic

It is, but it's also subtle, and if you want branches (especially sad-path branches) to be explicit, that's not a good thing.

I hear outright wrong arguments for why the USA has not moved to a modern filing system.

The argument I always hear from the right about this is that they worry that making taxes more efficient will allow them (and government action in general) to increase. The right is explicitly committed to reducing that, so it's not in their interest.

Same reason I've heard from people on the right about ending withholding. They think that if people had to cut an actual check to the government every year (or quarter) that people would realize how much it's costing them and be more amenable to reducing it.

Fair, but I'd prefer phone over a poorly done app.

And given the state of most apps...

This is at best specious reasoning, and to me reflects that the blogger completely misses the point of having tests.

I mean, yeah. Most devs don't understand the point. It turns into a check-boxing exercise. And most devs are vaguely smart and can figure out how to do a check-boxing exercise with minimal effort while evading the point of doing it.

Relying on people who don't care enough to write good code to care enough to write good tests has a certain irony to it.

To start off, there is no such thing as a false positive test. Your tests track invariants, specially those which other components depend on. The whole point of having these tests is to have a way to automatically check for them each and every single time we touch the code, so that the tests warn us that a change we are doing will cause the application to fail.

I'll push back on this. I'm a veteran of a codebase where the tests broke all the time with tons of false positives. This was mostly because of over-mocking, and an abundance of assert X called with Y and Z tests. Even pure functions were mocked.

Every time I re-wrote a function implementation, even if it was a pure function and produced the same results, it would break tens of tests. Bonus points if the implementation of the thing that was mocked out had changed since the last time someone reviewed the tests and the way it was calling the function didn't do what the test assumed anymore.

Horse archers had been a thing before him, though they were quite powerful.

His great accomplishment was marrying that with the ability to besiege walled cities. Nobody expected barbarian horse archers to be able to do that.

But absent that I think it's safe to say that this case doesn't raise the first amendment.

I still think it does, but it's Apple and Google's right to propagate the app, not TikTok's right to be on the app store. And since neither Apple nor Google are party to the lawsuit, nobody really has standing to take that particular line of argument.

Browsers shouldn't set a preferred colour scheme by default.

I mean, they really don't (the defaults are exactly what they have been since Mosaic left the scene). Unless the user tells them to do something else.

And at that point, it's my computer, and I told it to do something, why shouldn't it do that?

We only regulated broadcast using the public airwaves. That's why cable TV is generally exempt.

the Constitution doesn't apply to foreign entities

Sort of true. Sometimes the constitution just says "persons", which has generally been interpreted to anyone.

But it's not material, because the 1st amendment is a restriction on congress. That's why it starts with "Congress shall make no law...". The argument isn't about if TikTok has rights, it's about if congress is authorized to take this action. They're inter-mixed a bit because if TikTok does have the rights they claim, then congress automatically isn't authorized, but they are separate.

there is no First Amendment right for RT to be carried on US cable networks.

There might be, but it would be the cable network's first amendment right to carry them, not RT's right to be carried.

The argument in court was kind of backwards, nobody violated TikTok's rights by taking them off the app store, but you could fairly easily argue that Apple and Google's rights were violated by telling them that they can't carry it. That would, presumably, require either Apple or Google to bring a lawsuit though, and they seem to want to play nice with the incoming administration.

What do you think the percentage of computation is with respect to hand-written vs compiler generated?

If small hot loops tend to be disproportionately hand written, and certain programs spend the majority of time in their hot loops, that could still be a decent percentage of time/instructions executed.