skysight-inc/HackerNews huggingface dataset:
Not everyone will play the metrics games.

Some people will just find the metrics dumb and depressing, and avoid them. (As might've happened in the article.)

Some assume it will go away in time, or that their manager will cover for them. (As eventually happened in the article.)

Some have behind-the-scenes talks with managers+execs+HR, to end bad metrics.

Some will melt the metrics with the intensity of their look of disapproval. (Management ProTip: this level of will is better harnessed to solve business and engineering problems.)
If Trump wanted to, he could simply send the marshals to arrest him. Zuckerberg has a lot of ability to evade, but it's not infinite.

Trump probably was just grandstanding there. He makes hundreds of meaningless threats per day, to make it impossible to tell which ones he means to carry out. But they do cause fear, because you can never be 100% certain. And not even other oligarchs are safe.
LLMs seem clearly better for learning the basics, which IMO is what this paper is measuring?

Infinitely patient interlocutor who you can ask for code reviews on sketchy/embarrassing WIP.

Maybe as the quality bar for generated code rises we’ll see more engineers giving up on learning entirely. But I feel that just forces the human up one level, eg now you are learning how to build products and iterate on user requirements rather than the minutia of writing code. And the LLM can help you to learn that new skill too.
Tim probably realizes that if he tries to get on tickets he’s helped with, he’ll probably end up on maybe 30-50%. If he never asks for credit, and yet is seen constantly working, people will inflate the zero to hallucinatory levels of productivity.
Most tourists have zero awareness of it.
The fourth interpretation is that the something has not been clearly verified. The misinformation problem could lie with the accuser as well.
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.
I agree. I think it's pretty absurd that the manager was all set to fire him just based on metrics. There's a quote that I'm going to horribly paraphrase that goes like, "when you can measure something, that ends up being the only thing that matters."

At least he asked the author his opinion first.

Having said all that, if he took it upon himself to be a mentor to other developers and didn't do any tickets himself, that seems a bit odd, unless it was explicitly decided/communicated that would be his role. I would think roles like that are half time mentoring and half time doing tickets, but I don't know enough about the team to judge it. Like I said, I'm assuming the manager was new to the team.
Has it occurred to you that tools are created by people for reasons, which absolutely may be judged both for intentional malice and insufficiently forestalled harmful consequence?
> The wealth gap growing, and the median person being better off aren't mutually exclusive.

The wealth gap was growing since 1980. Is the median person better today when the median person cannot afford a college education or a house?

Both of those were easily afforded in the 80s.

Also remember: the average job didn't require a college education back then either. College has become a gatekeeper due to its rising costs and diminishing returns.
> Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure.

It didn't work on nixos because the build-time check included checking whether the build was being executed in a debian or fedora build environment. This was to avoid suspicious build failures on distros with weird toolchains or incompatible architectures/ABIs/library versions. (The backdoor was a precompiled .o file so rather ABI sensitive)
And obesity.. there are several adenoviruses associated with it.
Example: https://www.nature.com/articles/s41366-021-00805-6

(Although the article takes pains to say that obesity is multifactorial, conflicting evidence in humans, etc.)
When you look at damage per second graphs and conclude that all your healers need to be kicked from the raid.

It’s so difficult to quantify the value of “support” but they’re indispensable. I have yet to really find a sensible way to quantify it. It’s ultimately just something that you need to trust leaders to get right.
Yes, absolutely — and can effectively communicate that to their manager.
> he probably just believes a source that didn't turn out to be directly funded by the US government

One probably sponsored by the Russian government: https://apnews.com/article/russian-interference-presidential...
I’ll second that. Cobra is the industrial strength flag parsing package most of the professional Go ecosystem has settled on. It’s the boring choice in the best sense of the word. Use it and move on with life.
> it'll probably do better than the average OSM contributor

let us reconsider this statement, please. An unexpected and powerful effect of the Openstreetmap project is iterated convergence on ground truth. No person is perfect in contribution, and few people are consistently terrible. Revision and updates, common vision towards accuracy, an appreciation of cooperative contributions.. have astounded the public and humbled critics repeatedly. Not because every key stroke and mouse click is perfect, but because iteration and plural sources have converged in a usable system of software and data.

AI inputs to Openstreetmap are not new, as noted in other comments. The path forward is bright, useful to humans and participatory in the Openstreetmap project.
It's a reference to "scientific management" aka Taylorism, the pejorative name by which that now-universal practice was rightly known the last time labor had something resembling the power we deserve in this country.
I've spent 400+ hours working with a Nreal glasses, Android running Termux in Samsung Dex, and a Twiddler single handed chorded keyboard which is similar to the bubby.

The future is already here if you work in a terminal. This entire set-up fits in a 1 liter dry bag, but gives me about 70% of my desktop productivity as measured by completion time on 10 leetcode medium exercises, alternating first implementation between devices. For tasks requiring less pondering, this probably drops. For tasks requiring a lot of thinking and little rote terminal work, I suspect my productivity is higher due to improved creativity when I'm outdoors. LLms are ever improving this situation, with raw typing speed becoming less important.

The learning curve is significant though. I probably invested 40 hours to reach the 40 wpm and competency with special symbols necessary for real coding work before I was at all productive.

I'm also an exceptional case for a viability study on this mode of working though. I am a very hyperactive person that thrives outside. This means that I do better work when I'm able to work from a trailhead, ripping quick laps on my mountain bike to think through hard problems. I used to do this by parking my campervan with a full desk and starlink at the trailhead. Now I find I can throw my Twiddler and glasses in my MTB pack and ride straight from my house, stopping wherever ideas flow to write and code. I'm able to provide very deep insights on areas of vast complexity for my consulting clients by working this way, where I would lack the focus to retain context and continuity of thought indoors.

Anyway, I've topped out at about 50wpm with the Twiddler, curious to see if folks are able to exceed that with the bubby and may consider a switch!
This is something like it, though no finished standard exists: https://en.wikipedia.org/wiki/HAR_%28file_format%29

(An abandoned spec is at https://w3c.github.io/web-performance/specs/HAR/Overview.htm...)
Very nice write-up. Quite compelling!
No.

But there are limitations. DMA off, only formally verified drivers

It's also important to note that se4L multicore kernel is not yet verified.
> These simulators are so much fun, even the crappy ones ...

How? Why? Tell us ... :)
Goodhart's law - https://en.wikipedia.org/wiki/Goodhart%27s_law
I think there is a big gap between providing a historic clone of what a government agency has said in the past (even after/due to gov. policy) and misrepesenting by publishing something never said under their logo.
Nobody’s arguing things aren’t better in some ways than the past. But your argument amounts to what is essentially trickle down economics. The median American is getting a marginal improvement - the top .1% American has gotten an astronomical improvement.

The wealth gap increasing is a moral failure of our billionaires. They should take pride in building a better tomorrow for their fellow countrymen. And what we have now is the exact opposite of that.
Probably depends on the complexity of the permissions in the application. I'd also expect something more along the lines you described for more complex applications. The middleware would do authentication, but then just attach that information to the request. Later parts would then use the attached information to make decisions about permissions/authorization.

In more complex cases this would be outside middleware, so it should fail as no authentication/authorization information is attached to the request if you skip that middleware.

But putting the security checks into middleware could easily make sense for more rigid or simple cases. In C# for example I can add attributes to the methods that handle each endpoint. So if you need a basic admin/no-admin check you could add a [RequireAdmin] attribute on the relevant endpoints and use a middleware to check that.

I would agree that checking the URL in middleware to make decision about permissions would be a bad idea, it moves this important check to a mostly invisible place.

This probably also allows different attacks, e.g. skipping middleware that does other security-relevant checks (maybe anti-CSRF mechanisms could be vulnerable here).
It could be a big company. There might be some layers of C-levels, the a layer of managers to listen to them and turn their commands into concrete things, and then a couple crumple-zone layers of management to make sure that the concrete bricks from the top don’t damage actual productivity when they hit.
> "I keep begging people to have conversations in public channels... Guess what, devs refuse to do that."

So, stop begging. Managerial directives come as orders, not pretty-please requests. Also, stop letting your subordinates refuse you. They are your reports, you are approving their money, that can change if they aren't doing their jobs. Fire one for ignoring policy, and their attitudes will change.

On the tech side, clarify that you want all project comms logged and searchable for onboarding and auto-generating documentation as well as identifying technical hotspots where investments in refactoring can save the team time. Whatever. What gets measured gets done, if you are trying to spy on everyone, this is a bad way. Do it if it has value.

> "Many cultures don’t allow for someone to say bad things about their coworker"

Managers in any culture, and especially across cultures, are tasked with learning those cultural sensitivities and then working around them pragmatically. You have identified a problem. That is the start of solutions, not the end of them.

> "If you have better metrics or management skills than what everyone in the world has figured out"

This kind of attitude isn't productive at finding genuine answers, and might be obfuscating the problem.

Lots of people have figured out better metrics and management skills than the local application suggests. It's not the advanced esoteric stuff that is missing, it's the basics.
> But if it's the case that all day, every day there's at least one person on the team who is blocked, then you don't need a "Tim", what you really need is a new team, because that's an unacceptable level of blockage.

I don't think your opinion is educated, or based on any experience working on a functioning team, let alone a high-functioning one. Any team working on non-trivial projects does stumble upon critical bugs that are hard to catch or features that are faster to roll out if a subject matter expert sits down with someone to show them the ropes. If you care about performance and time to market, this is your baseline already. You are not better off with a dozen cowboy developers who wouldn't even piss on a team member if they were on fire.
That's only cheaper because we've made it someone else's problem. Someone is paying that cost -- fast fashion is a real issue that causes waste, pollution, and human rights violations. Now as we face tarriffs on foreign manufactured goods, things don't seem so cheap anymore. Mending socks looks a little better.

You're right, there's no reason to believe the same won't happen to code, but there's also no reason to believe it won't similarly end in all kinds of problems that come back to bite us down the line when the goodtimes are over.
Huh? None of that makes any sense to me, starting from the premise. Feel free to explain in a way that matches commonly-understood notions of history, law and instituons.
Lean is Hardy. Type-checking is Hardy.
They all have their warts, but "just pick cobra/kong/cli" is what I go with these days. I'm still partial to Cobra because of the nice autocompletion scripts it generates for me so I get tab-completion for free.
Formalizing a productivity metric won't help you with any of that. And I'm sure that one guy you mentioned will learn to game the metric faster than the other developers will learn to fit it.
> Um, IMO someone who hired a team of 5 new grads sounds like an MBA bean counter and not someone that's willing to invest in people. It sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.

Nah, this was a pet project of my skip level, and I joined after he asked my boss for solutions to the delay. The manager who owned the project had all of his experienced eng working on direct contracts.

This company had a lot of contracts in where the number of engineering hours allocated are specified. This was an internal project, without a hard cap on number of hours, and they were assigned because it would have been malpractice otherwise. This was very much a team built out of the resources available, rather than intentionally selecting only new grads.

I couldn't be replaced because it being an internal project, it would have been killed once it had no active development. And I suspect internal politics would have prevented it getting restarted after the first delay/failure. Turns out stuff is way more complicated than the easy assumptions people like to make.

> sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing.

It's easier to predict failure than success. That's that same zero or negative sum game though. Usually a cheap way to feel superior instead of doing the harder things. My previous edit already addresses that though. Failure wasn't actually a given like you want to predict.

edit:

> I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)".

Right, of course I know you didn't say that, nor do I think you'd actually advocate for it. But taking something to the extreme to see where it fails is a useful rhetorical tool. The point being, that only hiring experts is obviously bad, for the same reason that only hiring new grads is bad.

I think we agree that there is a balance to be struck?

I think 5 noobs to 1 expert is fine, just like 5 to zero is bad, just like 1 to 1 is bad. The point being, there's no magic line where one is right, the other wrong. This team had no problem once the missing puzzle piece was added. And it was able to be successful in ways that 1 and 1 wouldn't have been. There is no reasonable way to say "what you should have done" when describing a puzzle where you can't see most of the pieces.
Also worth noting that this commit in Dec 2024 previously added a bunch of internal headers (aside from this one) to a restricted external access list (one of them was vulnerable to SSRF) and there was never a CVE for it.

https://github.com/vercel/next.js/pull/73482/files

Source: https://news.ycombinator.com/item?id=43449986
Mozilla engineers think they are way better than the rest of us though. Don’t need to follow the same rules.
Yeah the thing is there were better jobs that ex-farmers (or at least their children) could go to. I'm unconvinced that's the case this time round. Especially for unskilled people.
Ah ok, yeah.. unfortnutely this type of lag/mismgmt is pretty common once a company gets big enough. Often times the right people don't get involved on first-pass... even at tech-first companies like this -- though at that point perhaps you're no longer tech-first :/
Oh jeez, I totally missed the C, haha. Silly of me given the topic of the thread.
The article is demonstrating the API, not suggesting you define Data objects dynamically. Notice the objects are assigned to constants.
Going back to the original "Bitter Lesson" article, I think the analogy to chess computers could be instructive here. A lot of institutional resources were spent trying to achieve "superhuman" chess performance, it was achieved, and today almost the entire TAM for computer chess is covered by good-enough Stockfish, while most of the money tied up in chess is in matching human players with each other across the world, and playing against computers is sort of what you do when you're learning, or don't have an internet connection, or you're embarrassed about your skill and don't want to get trash-talked by an Estonian teenager.

The "Second Bitter Lesson" of AI might be that "just because massive amounts of compute make something possible doesn't mean that there will be a commensurately massive market to justify that compute".

"Bitter Lesson" I think also underplays the amount of energy and structure and design that has to go into compute-intensive systems to make them succeed: Deep Blue and current engines like Stockfish take advantage of tablebases of opening and closing positions that are more like GOFAI than deep tree search. And the current crop of LLMs are not only taking advantage of expanded compute, but of the hard-won ability of companies in the 21st century to not only build and resource massive server farms, but mobilize armies of contractors in low-COL areas to hand-train models into usefulness.
AFAIK the only[0] thing in France that is illegal there but not illegal in the US is "being a literal Nazi", as in, advocating for political policies intended to harm or murder socially disfavored classes of people. Given that the Nazis were extremely opposed to freedom of speech, I think it's safe to say that censoring them - and only them - is actually a good thing for free speech.

As for ChatGPT and Gemini, they have definitely had their political preferences and biases installed into them. Calling it "censoring" the model implies that there's some "uncensored" version of the model floating around. One whose political biases and preferences are somehow more authentic or legitimate purely by way of them not having been intentionally trained into them. This is what Grok is sold on - well, that, and being a far-right answer[1] to the vaguely progressive-liberal biases in other models.

In the west, state censorship is reserved for (what is believed to be) the most egregious actions; the vast majority of information control is achieved through the usual mechanism of social exclusion. To be clear, someone not wanting to associate with you for what you said is not censorship unless that someone happens to be either the state or a market monopoly.

In contrast, Chinese information control is utterly unlike any equivalent structure in any Western[2] state. Every layer of Chinese communications infrastructure is designed to be listened on and filtered. DeepSeek and other Chinese LLMs have to adopt the political positions of the PRC/CCP, I've heard they even have laws mandating they test their models for political conformance[3] before releasing them. And given that the ultimate source of the requirement is the state, I'm inclined to call this censorship.

[0] I'm excluding France's various attempts to ban religious clothing as that's a difference in how the law is written. As in, America has freedom of religion; France has freedom from religion.

[1] Casual reminder that they included a system prompt in Grok that boiled down to "don't blame Donald Trump or Elon Musk for misinformation"

[2] Japan/South Korea inclusive

[3] My favorite example of DeepSeek censorship is me asking it "what do you think about the Israel-Palestine conflict" and it taking several sentences to explain the One China policy and peaceful Taiwanese reunification.
Musk is suddenly a fan of anything that directly benefits him even if it directly contradicts previously made comments. I thought this was pretty much self-evident at this point